Embedded crypto payments
Add crypto payments to a platform without losing operational control
Choose the right collection surface, attach your customer and order references, wait for final confirmation, and connect refunds, settlement, and reconciliation.
Operating model
- 01Choose the routeMatch the product to the payment intent.
- 02Confirm final stateKeep initiated and completed states separate.
- 03ReconcilePreserve internal and Radom references.
- 04Operate exceptionsMake retries, returns, and failures actionable.
Overview
How can a platform add crypto payments?
A platform can add supported crypto payments through a hosted checkout, integrated payment flow, payment link, invoice, or recurring-billing product. The implementation should select methods from current enabled payment options, attach stable customer and order references, process final payment and refund events idempotently, and reconcile the resulting balance and settlement records. The best surface depends on whether the payment is embedded, shareable, itemised, or recurring.
Before implementation
Define the operating requirement
A product-specific payment surface
Use checkout for an order, payment links for shareable no-code collection, invoicing for itemised requests, or billing for recurring commitments.
Current payment methods
Show only assets and networks available to the organisation and current payment route.
Final-state fulfilment
Wait for the final successful payment state before releasing goods, services, or account value.
Refund and settlement operations
Define how overpayments, underpayments, expiry, refunds, conversion, and treasury movement are recorded.
Operating model
From requirement to reconciled operation
- 01
Choose the collection surface
Match checkout, link, invoice, subscription, or deposit-address behaviour to the real customer and reconciliation requirement.
Control: Do not create separate near-identical payment products merely to target different keywords.
- 02
Create the payment object
Attach your customer, order, merchant, invoice, or subscription reference and use current enabled asset and network options.
Control: Do not hard-code a universal supported-currency list into a long-lived interface.
- 03
Process lifecycle events
Handle pending, confirmed, expired, failed, refunded, and other applicable states in an idempotent state machine.
Control: Treat the event as input to your order state—not as permission to process it twice.
- 04
Reconcile and settle
Join the original order, payment amount, asset, network, transaction, fee when supplied, refund, balance, and settlement records.
Control: Keep payment acceptance and downstream conversion or payout as separate auditable legs.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Crypto checkout | A buyer should complete one order in a hosted payment journey. | Pass reliable order references and fulfil only after final confirmation. |
| Payment links | A business needs a shareable collection route without building a complete checkout. | Link ownership, pricing, expiry, payment purpose, and reconciliation still need definition. |
| Crypto invoicing | The payment request should be itemised and associated with a business invoice. | Invoice state, payment state, expiry, and accounting treatment should not be collapsed. |
| Crypto billing | The customer is entering a recurring subscription or billing relationship. | Authorisation, recurrence, failed collection, cancellation, and entitlement states need their own model. |
Operations
Controls that make the workflow durable
Validate asset and network together
The same token name can exist on multiple networks; store and display the enabled payment method as a complete route.
Make fulfilment idempotent
Use your order or entitlement identifier to prevent duplicate delivery when events are retried.
Retain transaction evidence
Keep the Radom object, internal reference, asset, network, amount, transaction reference, and final timestamps.
Own customer exceptions
Define support handling for payment expiry, wrong-network attempts, amount differences, delayed confirmations, and refunds.
Practical answers
Frequently asked questions
Which Radom crypto payment product should a platform use?
Use checkout for a specific hosted order, payment links for shareable no-code collection, invoicing for itemised payment requests, billing for recurring commitments, and deposit addresses for repeat on-chain deposits. The products solve different operating problems rather than serving as keyword variants.
Which cryptocurrencies and networks are supported?
Use Radom's current payment-method documentation and the options enabled for the organisation and payment flow. Asset and network support should not be inferred from a static universal marketing list.
Can a platform settle or convert collected funds?
Where enabled, payment acceptance can connect to supported balances, conversion, stablecoin settlement, and payout workflows. Treat each as a distinct lifecycle and confirm the permitted route before launch.
Documentation
Product and implementation references
Reference material for the product capabilities and implementation notes on this page. Confirm the exact route and availability for your organisation before launch.
- Crypto payments guidePublic overview of supported crypto-payment implementation concepts.
- Hosted checkout guidePublic implementation guidance for hosted checkout.
- Integrated checkout guidePublic implementation guidance for integrated payment experiences.
- Webhook guidePublic guidance for final-state and lifecycle event processing.
- Payment methods cataloguePublic catalogue for currently documented payment-method examples.
Plan the workflow
