# Radom — condensed page content > Radom provides payment and financial infrastructure for businesses using crypto, stablecoins, open banking, virtual accounts, conversion, and payout workflows. This file condenses Radom's core commercial pages for assistants and answer engines. It is generated from the same data that renders the pages, so the text below matches the live pages it links. Availability of any product, rail, asset, network, currency, or corridor depends on onboarding, market, and the capabilities enabled for an organisation, as each page states. Verify implementation detail against https://docs.radom.com/ and the canonical pages. The link index for the whole site is https://www.radom.com/llms.txt. ## Open Banking payments, connected to settlement and reconciliation Canonical: https://www.radom.com/open-banking Content last reviewed: 2026-07-23 **What is an Open Banking payment?** An Open Banking payment is a bank-led payment initiated for a specific checkout or funding journey. Radom connects that initiation to checkout status, final-state webhooks, reconciliation, and supported bank-to-crypto settlement. Availability, rails, currencies, and settlement assets depend on the market, onboarding outcome, and capabilities enabled for your organisation. Audience: Fintechs, platforms, PSPs, marketplaces, and online businesses. ### Who this is for - Payment and checkout teams: Add a bank-led payment option to a hosted flow or preselect a supported bank inside your own interface. - Fintech and platform operators: Connect bank-funded customer or merchant journeys to supported crypto balances and downstream payment operations. - Finance and reconciliation teams: Track orders with your own metadata and retain bank-rail references and status history when those fields are supplied. ### Not the right route when you need - A replacement for a bank account: Use virtual accounts when you need named or repeatable fiat collection details rather than a checkout-led payment journey. - Uniform real-time settlement everywhere: Standard bank transfers can remain pending after authorisation. Rail speed and availability differ by bank, market, and configuration. - Fulfilment based on a browser redirect: A customer returning from their bank is not final proof of payment. Fulfil only after Radom reports a final successful status. ### Capabilities - Hosted Open Banking checkout: Create a checkout session with the Open Banking gateway and send the customer to the returned payment URL. - Bank preselection: List bank options for a market and currency, then pass the Radom bank identifier into checkout when you want bank-specific choices in your UI. - Asynchronous status tracking: Read progress through checkout state and use the final managed-payment webhook as the dependable fulfilment signal. - Bank-to-crypto funding: Where enabled, connect supported bank flows to crypto settlement balances rather than operating a disconnected collection and conversion stack. - Operational references: Use your checkout metadata alongside payment references, end-to-end identifiers, remittance information, and scheme fields when available. - Refund events: Track supported Open Banking refunds through Radom's existing refund webhook rather than inventing a second operational process. ### Limitations - Coverage is configuration-specific: A public description of a currency or rail is not a promise that it is active for every organisation or country. - Instant is a rail property, not a slogan: SEPA Instant and Faster Payments can be quick when available, but final confirmation is still the correct fulfilment control. - Settlement paths differ: Supported settlement assets and networks depend on the specific Open Banking or funding product configured for your organisation. - Compliance remains part of the flow: Onboarding, transaction review, account permissions, and applicable customer checks are not removed by API integration. ### Frequently asked questions **What is Radom Open Banking?** Radom Open Banking is a bank-led checkout and funding route that connects payment initiation with Radom checkout state, webhooks, reconciliation fields, and supported settlement workflows. Exact availability depends on market, onboarding, and enabled capabilities. **Does a bank redirect mean the payment is complete?** No. A redirect or bank authorisation can occur before funds are finally confirmed. Keep fulfilment pending until Radom reports a final successful checkout state or the final managed-payment webhook. **Can we let a customer choose their bank in our own interface?** Where enabled, yes. Your application can retrieve Radom bank options for a market and currency and pass the selected Radom bank identifier into the checkout session. **Which currencies and instant bank rails are supported?** Public Radom documentation describes EUR flows including SEPA Credit and, in enabled experiences, SEPA Instant, plus Faster Payments rail details in supported setups. Confirm the specific market, currency, bank coverage, and rail enabled for your organisation before launch. **Can Open Banking funds settle into a stablecoin balance?** Supported bank-to-crypto flows can settle into an enabled crypto balance. The settlement asset and destination network vary by product configuration, so they must be agreed and tested for the intended route. **How should Open Banking payments be reconciled?** Store your internal order reference in checkout metadata, retain the Radom checkout and payment identifiers, record every status transition, and capture scheme and bank-reference fields when they are supplied. ### Public documentation - [Radom Open Banking implementation guide](https://docs.radom.com/guides/open-banking): Checkout, preselection, statuses, webhooks, settlement, and controls. - [Radom webhook guide](https://docs.radom.com/webhooks/guide): Event verification, idempotency, and fulfilment guidance. - [Radom supported payment methods](https://docs.radom.com/additional-resources/payment_methods): Current public payment-method reference. ## Stablecoin settlement built for payment operations Canonical: https://www.radom.com/stablecoin-settlement Content last reviewed: 2026-07-23 **What is stablecoin settlement?** Stablecoin settlement uses a supported stablecoin as an operational balance or value-transfer leg after a payment is collected. Radom supports stablecoin settlement workflows by connecting supported crypto payments, Open Banking or virtual-account collections, Radom balances, quoted conversions, webhooks, and payout routes. It is payment infrastructure, not a yield product: exact assets, networks, currencies, corridors, timing, and permissions depend on the products enabled for your organisation. Audience: Payment processors, fintechs, platforms, marketplaces, and treasury teams. ### Who this is for - Payment processors and fintechs: Connect bank or crypto collection to a supported stablecoin operating balance and downstream disbursement. - Platforms and marketplaces: Separate payer experience from treasury and beneficiary settlement while retaining a traceable reference chain. - Treasury and finance teams: Use supported conversion pairs and explicit payment events rather than reconciling transfers across unrelated tools. ### Not the right route when you need - Investment, yield, or token issuance: Radom's settlement workflow is for collecting, converting, holding operational balances, and moving payments—not promising returns or issuing your own stablecoin. - Every asset on every network: Only expose routes returned by the current product or API for the organisation and network you have enabled. - A substitute for controls: Faster value movement still needs approval ownership, counterparty data, reconciled ledgers, and exception handling. ### Capabilities - Multiple collection entry points: Begin with supported on-chain payments, bank-led checkout, virtual-account deposits, or dedicated crypto deposit flows. - Stablecoin destination balances: Where enabled, bank-connected collection can settle into supported stablecoin balances on an agreed destination network. - Quoted conversion: List supported pairs, request an amount-specific quote, and accept that quote through Radom's documented Conversion API. - Event-led reconciliation: Join your internal references to Radom payment, deposit, conversion, and payout records and react to final states through webhooks. - Treasury-to-payout handoff: Use supported crypto or fiat payout routes after the source balance, destination, and beneficiary model have been confirmed. - API and dashboard operations: Choose the operating surface appropriate to the workflow, from developer integration to finance-led operational actions. ### Limitations - Stablecoin is not the same as fiat: A stablecoin tracks a reference asset through its own issuer and network design. Businesses must assess the asset, custody, liquidity, and accounting treatment. - Routes are not universal: Available currencies, stablecoins, networks, conversion pairs, and payout destinations vary by region, onboarding, and enabled product. - Timing is end-to-end: Settlement time includes the source rail, finality checks, conversion, internal controls, and destination payout—not merely blockchain block time. - This page is not legal or accounting advice: Your compliance, finance, and legal teams should determine the appropriate use and treatment of each route for the business and jurisdiction. ### Frequently asked questions **What is stablecoin settlement?** Stablecoin settlement uses a supported stablecoin as an operational balance or value-transfer leg after a payment is collected. A complete workflow also covers source-rail confirmation, conversion where needed, reconciliation, controls, and the final payout or treasury destination. **Does Radom provide stablecoin settlement infrastructure?** Radom supports settlement workflows that connect enabled crypto payments, Open Banking or virtual-account collection, balances, quoted conversion, webhooks, and payout routes. The exact combination available depends on onboarding and product configuration. **Which stablecoins and networks can we use?** Public Radom documentation describes USDC in commonly enabled bank-connected flows and USDT on selected destination networks. Supported assets and networks change by route and organisation, so production choices should come from current configuration and API responses. **Can customers pay by bank while we settle in a stablecoin?** Where the relevant Open Banking or virtual-account flow is enabled, bank collection can connect to a supported crypto settlement balance. Confirm the source currency, market, asset, destination network, timing, and refund model before launch. **Can Radom automatically convert every incoming payment?** Do not assume automatic conversion for every flow. Radom publicly documents a Conversion API for listing pairs, requesting quotes, and accepting conversions. Any automated or product-specific conversion behaviour must be confirmed for your configuration. **How should finance teams reconcile stablecoin settlement?** Maintain one reference chain from the source order through collection, transaction, conversion quote, ledger movement, and payout. Reconcile source and destination amounts, fees, network, status timestamps, refunds, exceptions, and residual balances. ### Public documentation - [Radom crypto payments overview](https://docs.radom.com/guides/crypto-payments): Collection, webhooks, balances, conversion, and payouts. - [Radom Conversion API guide](https://docs.radom.com/guides/conversion-api): Supported pairs, quotes, and quote acceptance. - [Radom virtual accounts guide](https://docs.radom.com/guides/virtual-accounts): Inbound fiat collection and supported crypto settlement models. - [Radom payouts guide](https://docs.radom.com/guides/payouts-overview): Funding models, destination types, and operations. ### Related guides - [Stablecoin settlement for businesses](https://www.radom.com/guides/stablecoin-settlement-for-businesses): A practical walkthrough of settlement flows, controls, and reconciliation. - [Stablecoin settlement for payment processors](https://www.radom.com/guides/stablecoin-settlement-for-payment-processors): How PSPs connect collection, conversion, and settlement in one workflow. - [How to set up stablecoin settlement](https://www.radom.com/guides/how-to-set-up-stablecoin-settlement): Step-by-step implementation from requirements to reconciled operation. - [Stablecoin settlement infrastructure for payment processors](https://www.radom.com/guides/stablecoin-settlement-infrastructure-for-payment-processors): Infrastructure-level view of settlement rails for processing platforms. ## White-label crypto and fiat payment infrastructure Canonical: https://www.radom.com/white-label-payment-infrastructure Content last reviewed: 2026-07-23 **What is white-label payment infrastructure?** White-label payment infrastructure lets a business embed payment capabilities into its own product and customer journey while using an underlying platform for selected collection, conversion, event, balance, or payout functions. Radom's APIs and configurable payment surfaces can support a branded payment experience for PSPs, fintechs, platforms, and marketplaces. Teams can combine enabled crypto checkout, bank-led payments, virtual-account collection, conversion, webhooks, and payouts while keeping their own customer journey and ledger. White-label does not remove required disclosures, onboarding, compliance controls, or route-specific availability. Audience: PSPs, fintechs, platforms, marketplaces, and software providers. ### Who this is for - Payment service providers: Add selected crypto, bank-led, conversion, and payout capabilities behind your own product and operational controls. - Fintechs and software platforms: Embed payment creation and status handling into an existing customer experience using APIs, metadata, and webhooks. - Marketplaces and multi-party products: Connect collection, treasury, and disbursement journeys while retaining your own account, order, seller, or merchant references. ### Not the right route when you need - A licence or compliance shortcut: Technology does not transfer permissions or remove your obligations. The legal, disclosure, onboarding, and responsibility model must be scoped. - Unbounded global coverage: Each payment method, currency, network, country, settlement route, and payout corridor depends on enabled coverage. - A generic reseller page: Successful integrations need a real customer journey, ledger, support model, exception handling, and accountable operations. ### Capabilities - Hosted and integrated checkout: Choose a faster hosted route or render supported payment instructions inside your own product when deeper experience control is required. - Bank-led payment initiation: Add enabled Open Banking checkout, including bank preselection in your UI and final-state handling through Radom events. - Crypto collection surfaces: Use checkout sessions, payment links, invoicing, or supported deposit models according to the customer and reconciliation requirement. - Conversion and settlement: Validate supported pairs, request and accept quotes, and connect the resulting balance movement to an operational ledger. - Payout infrastructure: Disburse from enabled balances to supported fiat or crypto destinations after beneficiary and corridor checks. - Webhooks and metadata: Maintain your own object model by attaching internal references and processing Radom's payment, refund, deposit, subscription, and payout events. ### Limitations - Branding is not invisibility: The presentation model is configurable, but contractual, compliance, payment-method, and customer-disclosure requirements still apply. - Capability is organisation-specific: Public product documentation shows possible workflows; production access depends on onboarding and the exact products enabled. - An API does not remove payment risk: Finality, refunds, fraud, sanctions controls, beneficiary errors, network selection, liquidity, and operational incidents still require policy and ownership. - This is infrastructure, not legal advice: The responsibility and regulatory analysis for your business model must be completed with qualified advisers and agreed counterparties. ### Frequently asked questions **What is white-label payment infrastructure?** White-label payment infrastructure lets a business embed payment capabilities into its own product and customer journey while using an underlying platform for selected collection, conversion, event, balance, or payout functions. **Can a PSP or fintech embed Radom under its own brand?** Radom's APIs and integrated payment surfaces can support a branded product experience. The exact presentation, contracting, onboarding, disclosure, support, and compliance model must be scoped for the business and enabled products. **Which Radom capabilities can be combined?** Depending on configuration, an integration can combine crypto checkout or collection, Open Banking, virtual accounts, conversion, webhooks, and fiat or crypto payouts. Do not assume every route is enabled for every organisation or market. **Should we use hosted or integrated checkout?** Hosted checkout is usually the shorter launch path. Integrated checkout provides more control inside your interface but requires more payment-state, security, testing, support, and operational work. **Does using Radom give our business regulatory permissions?** No. Payment technology does not grant a licence or remove your obligations. Your business model, jurisdictions, customer relationships, disclosures, onboarding, and allocation of responsibilities must be assessed separately. **What should we build before going live?** Implement server-side route controls, durable object mapping, verified and idempotent webhooks, final-state handling, a reconciled ledger, refund and payout exceptions, monitoring, support escalation, and canary limits. ### Public documentation - [Radom developer documentation](https://docs.radom.com/): Current public guides and API reference. - [Radom integrated checkout guide](https://docs.radom.com/guides/integrated-checkout): Payment instructions inside a custom product interface. - [Radom hosted checkout guide](https://docs.radom.com/guides/hosted-checkout): Hosted customer flow and checkout lifecycle. - [Radom webhook guide](https://docs.radom.com/webhooks/guide): Event handling, verification, and idempotency. ## Virtual accounts for clearer payment operations Canonical: https://www.radom.com/virtual-accounts Content last reviewed: 2026-07-23 **What is a virtual account?** A virtual account provides reusable fiat collection details assigned to a customer, merchant, entity, or operating workflow so inbound transfers can be attributed. Radom connects enabled virtual accounts to reconciliation and supported crypto settlement. Public documentation describes enabled USD account and routing details, EUR IBAN and SEPA details, MXN CLABE details, and BRL Pix details. The account type, region, settlement asset, destination network, and operating model depend on onboarding and the capabilities enabled for your organisation. Audience: Fintechs, platforms, marketplaces, crypto businesses, and treasury teams. ### Who this is for - Platforms with repeat collections: Assign inbound bank details to a customer, merchant entity, or operational workflow so transfers can be attributed without a shared-reference guessing game. - Crypto and fintech treasury teams: Connect supported fiat collection to enabled crypto balances while retaining the account, currency, settlement asset, and network in the operating record. - Finance and reconciliation teams: Maintain a durable mapping from the assigned collection account to the internal customer or ledger entity that owns the resulting balance movement. ### Not the right route when you need - A checkout-led bank payment: Use Open Banking when the payer should choose a bank and initiate a transfer for a specific order inside a checkout journey. - Direct on-chain collection: Use dedicated crypto deposit addresses when the sender already holds a supported digital asset and the collection should start on-chain. - Universal account coverage: Do not design around every account type, country, currency, settlement asset, or network being available. Coverage is specific to your organisation and route. ### Capabilities - Named inbound collection: Use enabled virtual account details for repeat or operationally structured fiat deposits rather than treating every inbound transfer as an anonymous shared-account event. - Multiple account formats: Public documentation describes USD account and routing details, EUR IBAN and SEPA details, MXN CLABE details, and BRL Pix collection details, subject to coverage. - Customer and workflow attribution: Map each issued account to the customer, merchant, legal entity, or treasury workflow represented in your own system of record. - Supported crypto settlement: Connect eligible fiat deposits to an enabled crypto balance, with the settlement asset and destination network confirmed before launch. - Webhook-led operations: Use Radom event delivery or related operational tooling to drive deposit processing, reconciliation, notifications, and exception queues. - Connected treasury routes: Where enabled, use conversion and payout workflows after collection rather than moving funds through an unrelated, difficult-to-reconcile stack. ### Limitations - Coverage is organisation-specific: Supported account types and corridors depend on region, onboarding, enabled capabilities, and the exact operating model. - Settlement is not identical across currencies: Public documentation describes different settlement assets and network choices by account type. Confirm the production route rather than generalising one setup. - An account number is not reconciliation: The operational value comes from a reliable ownership map, event processing, ledger posting, and exception process around the account details. - This is not legal or accounting advice: Your legal, compliance, tax, and finance teams should determine how accounts, payer relationships, funds flows, and settlement are treated for the business. ### Frequently asked questions **What is a Radom virtual account?** It is a named fiat collection account used to receive bank-led deposits into Radom while keeping attribution clearer than a shared-account model. Availability and the exact account details depend on your organisation and region. **Which virtual account types does Radom describe publicly?** Radom's public documentation describes enabled USD accounts with account and routing details, EUR accounts with IBAN and SEPA details, MXN accounts with CLABE details, and BRL accounts with Pix details. Confirm the account types enabled for your organisation. **How do virtual account deposits settle?** Public documentation says virtual account deposits generally settle into supported crypto balances. The settlement asset and destination network differ by account type and configuration and must be confirmed before launch. **Are virtual accounts available to every business and country?** No universal availability is promised. Region, onboarding status, organisation permissions, required account type, currency, settlement model, and intended use all affect coverage. **When should we use Open Banking instead?** Use Open Banking when a payer should initiate a bank transfer for a particular checkout or funding session. Use a virtual account when the business needs reusable collection details and repeat attribution. **How should virtual account deposits be reconciled?** Store the virtual account and Radom identifiers against your internal customer or ledger entity, process events idempotently, and record the fiat source leg separately from the resulting settlement balance movement. ### Public documentation - [Radom virtual accounts guide](https://docs.radom.com/guides/virtual-accounts): Account types, use cases, settlement models, networks, and rollout. - [Radom webhook guide](https://docs.radom.com/webhooks/guide): Event verification, retry behaviour, and idempotent processing. - [Radom Conversion API guide](https://docs.radom.com/guides/conversion-api): Supported pairs, minimum amounts, quotes, and quote acceptance. ### Related guides - [Virtual accounts for fintechs](https://www.radom.com/guides/virtual-accounts-for-fintech): Fit, implementation, and reconciliation for fintech collection flows. - [EUR virtual accounts](https://www.radom.com/guides/eur-virtual-accounts): Named EUR collection details and inbound attribution in practice. - [GBP virtual accounts](https://www.radom.com/guides/gbp-virtual-accounts): UK collection routes with reference-led reconciliation. - [Virtual IBANs and named accounts](https://www.radom.com/guides/virtual-ibans-and-named-accounts-for-businesses): How named account details map to customers, ledgers, and controls. ## Crypto on/off-ramp infrastructure for controlled fiat and crypto flows Canonical: https://www.radom.com/crypto-on-off-ramp Content last reviewed: 2026-07-23 **What are crypto on-ramps and off-ramps?** A crypto on-ramp moves value from fiat or bank rails into crypto; an off-ramp moves crypto towards fiat through an enabled payout route. Radom connects enabled bank-to-crypto funding with supported conversion, balance, webhook, and payout workflows. The public standalone onramp API currently creates SEPA funding instructions; a crypto-to-fiat route is assembled from the conversion and payout capabilities enabled for your organisation, not a promise of one universal off-ramp endpoint. Markets, currencies, assets, networks, destinations, timing, and permissions remain route-specific. Audience: Fintechs, platforms, PSPs, marketplaces, and treasury teams. ### Who this is for - Fintech funding journeys: Connect an enabled bank funding route to a supported crypto balance while keeping the customer or merchant state visible throughout the asynchronous flow. - Platforms and payment processors: Add selected fiat and crypto movement behind an existing product with explicit route controls, internal references, and event-driven status handling. - Treasury and settlement teams: Combine supported balance conversion and fiat or crypto payouts when the business needs to move operational funds between rails. ### Not the right route when you need - A universal one-call corridor: The public product surface is component-based. Do not assume one endpoint covers every bank-to-crypto and crypto-to-bank route. - Crypto-to-crypto conversion only: Use Crypto Convert when the requirement is a quoted conversion between supported assets and networks without a bank collection or payout leg. - Unverified instant cash-out: Rail speed, conversion acceptance, payout processing, banking cut-offs, and operational review can all affect the end-to-end timeline. ### Capabilities - Bank-to-crypto funding: Use enabled Open Banking or onramp configurations to start from bank rails and settle into a supported crypto balance. - SEPA funding instructions: Radom's current public standalone onramp API creates SEPA funding instructions for the enabled flow documented publicly. - Asynchronous onramp events: Use the onramp webhook and related status surfaces to distinguish processing from a completed state in your customer and operations systems. - Supported asset conversion: List currently supported pairs, check minimum source amounts, request a quote, and accept it before initiating conversion. - Fiat or crypto disbursement: Use enabled payout routes for the destination leg after confirming the funding balance, beneficiary data, corridor, and permissions. - End-to-end reconciliation: Link the originating customer or treasury instruction to the funding object, conversion quote, balance movement, and payout record. ### Limitations - There is no universal ramp route: The exact combination of funding, conversion, balance, and payout capabilities varies by market, organisation, and intended use. - End-to-end timing has several parts: Bank processing, status confirmation, quote acceptance, internal controls, blockchain finality, and payout processing can all affect completion. - Conversion and payout are separate controls: A successful funding event does not prove conversion or payout completion. Reconcile each leg and its exceptions independently. - This page is not legal advice: Technology does not grant permissions or remove obligations. Assess the business model, customer journey, jurisdictions, disclosures, and responsibilities separately. ### Frequently asked questions **What is Radom's crypto on/off-ramp infrastructure?** It is a configurable operating route that can connect enabled bank-to-crypto funding with supported balances, conversion, webhooks, and fiat or crypto payouts. Exact components and coverage depend on your organisation. **What does Radom's public standalone onramp API support?** Radom's public Open Banking documentation says the standalone onramp API currently creates SEPA funding instructions. Confirm the market, currency, settlement asset, and flow enabled for your organisation. **Does Radom offer one universal crypto-to-fiat off-ramp endpoint?** This page does not claim that. A supported crypto-to-fiat operating route can combine an enabled balance, conversion where needed, and a supported payout destination. The exact corridor and product configuration must be confirmed. **Are on/off-ramp transactions instant?** Do not assume they are. Bank rails, status confirmation, conversion, blockchain finality, payout processing, cut-off times, and operational controls can affect the full timeline. **How should an on/off-ramp flow be reconciled?** Keep one reference chain across the source instruction, funding event, conversion quote and acceptance, balance movement, payout, beneficiary, fees when supplied, and final destination state. **Which currencies, assets, networks, and countries are supported?** Coverage is route- and organisation-specific. Use current API responses and an onboarding or coverage check rather than publishing a static assumption that every currency, asset, network, or country is available. ### Public documentation - [Radom Open Banking guide](https://docs.radom.com/guides/open-banking): Bank-to-crypto funding, SEPA instructions, statuses, and settlement. - [Radom onramp webhook reference](https://docs.radom.com/webhooks/onramp): Processing and processed onramp event payloads. - [Radom Conversion API guide](https://docs.radom.com/guides/conversion-api): Supported pairs, minimum amounts, quotes, and acceptance. - [Radom payouts guide](https://docs.radom.com/guides/payouts-overview): Funding models, destination types, corridors, and operations. ## Crypto conversion, built into your operations Canonical: https://www.radom.com/crypto-convert Content last reviewed: 2026-07-23 **What is a crypto conversion API?** A crypto conversion API lets an application discover supported asset and network pairs, request a quote, and accept a quoted conversion. Radom's Conversion API also exposes each route's minimum source amount. It supports payment and treasury conversion workflows, not an order-book exchange or consumer trading venue. Pair availability, minimums, quoted output, and route details should come from the current API response rather than a static marketing list. Audience: Fintechs, platforms, payment processors, crypto businesses, and treasury teams. ### Who this is for - Payment and settlement teams: Convert an enabled balance into a supported treasury or settlement asset without disconnecting the movement from the originating payment workflow. - Fintech and platform engineers: Populate a conversion picker from live supported pairs, validate minimum amounts, and execute the exact quote confirmed by the user or operator. - Treasury and finance operators: Keep the source route, amount, quote identifier, quoted destination amount, acceptance result, and resulting balance movement in one audit trail. ### Not the right route when you need - Fiat collection or bank initiation: Use Open Banking or virtual accounts when the flow begins with an inbound bank payment rather than an existing supported balance. - A static promise of every pair: Supported source and destination combinations can change. The current pair catalogue is the control surface for what your interface should offer. - Speculative trading functionality: The documented API covers pair discovery, a conversion quote, and quote acceptance for payment and treasury operations—not an order-book trading product. ### Capabilities - Current pair discovery: Call the supported-pairs endpoint before presenting routes so the interface reflects the combinations Radom currently returns. - Minimum amount validation: Read each pair's minimum source amount and reject an undersized conversion before requesting a quote. - Quoted destination amount: Request a quote using the source amount and the selected source and destination payment method objects. - Explicit quote acceptance: Accept the returned quote identifier only after the user or authorised operator confirms the intended conversion. - Native and token assets: Represent native assets with a network and null token, and tokenised assets with the network and token value returned or documented for that route. - Connected settlement workflows: Use conversion between supported collection and payout legs while preserving the source payment, treasury instruction, and destination references. ### Limitations - Supported pairs can change: A previously available route is not a permanent promise. Fetch the current pair catalogue before exposing or executing a conversion. - Minimum amounts are route-specific: Validate the minimum returned for the selected pair rather than applying one threshold across every asset and network. - Acceptance initiates the request: The documented success response means Radom accepted the quote and initiated the conversion request. Keep that state distinct from downstream payout or settlement completion. - This is operational infrastructure: The documented API supports payment and treasury conversion workflows. It does not remove your accounting, compliance, risk, approval, or customer-disclosure responsibilities. ### Frequently asked questions **What does the Radom Conversion API do?** It lets an authorised integration list supported conversion pairs, request a quote for a source amount and selected route, and accept the returned quote to initiate the conversion request. **Which endpoints are used for conversion?** The public guide documents GET /conversion/pairs, POST /conversion/quote, and POST /conversion/accept. Use the current API reference and authenticated server-side requests for implementation. **How do we know which conversion pairs are available?** Call the supported-pairs endpoint and build the interface from its response. Do not rely on a static list because supported source and destination combinations can change. **How should minimum conversion amounts be handled?** Read min_from_amount for the selected pair and validate the source amount before requesting a quote. Keep amount handling precise rather than using binary floating-point arithmetic. **What should be stored with a conversion quote?** Store the source and destination payment method objects, source amount, quote identifier, quoted destination amount, requesting user or system, and the confirmation and acceptance timestamps. **Does a successful quote acceptance mean a payout is complete?** No. The documented response confirms that Radom accepted the quote and initiated the conversion request. Any later payout or settlement route is a separate operational leg with its own state. ### Public documentation - [Radom Conversion API guide](https://docs.radom.com/guides/conversion-api): Pair discovery, minimums, quote requests, and quote acceptance. - [List conversion pairs API reference](https://docs.radom.com/api/#/operations/list_conversion_pairs): Current operation reference for supported route discovery. - [Request a conversion quote API reference](https://docs.radom.com/api/#/operations/quote_conversion): Current operation reference for quote creation. - [Accept a conversion quote API reference](https://docs.radom.com/api/#/operations/accept_conversion): Current operation reference for accepting a quote. ### Related guides - [Business crypto exchange integration](https://www.radom.com/guides/business-crypto-exchange-integration): Connect quoted conversion into an existing operational workflow. - [Crypto exchange API for fintechs](https://www.radom.com/guides/crypto-exchange-api-for-fintechs): API-led conversion patterns for product teams. - [Crypto exchange liquidity infrastructure](https://www.radom.com/guides/crypto-exchange-liquidity-infrastructure): How conversion, liquidity, and settlement fit together for businesses. - [Business crypto on-ramp and off-ramp](https://www.radom.com/guides/business-crypto-on-ramp-and-off-ramp): Move between fiat and supported assets around the conversion step. ## Payment Infrastructure for PSPs Canonical: https://www.radom.com/industries/payment-service-providers Content last reviewed: 2026-07-25 **How can a PSP add crypto and fiat payment infrastructure?** A PSP can use Radom as an infrastructure layer for selected payment operations: crypto checkout or payment links, enabled Open Banking payments, attributable virtual-account collection, quoted conversion, event delivery, and supported payouts. The PSP retains its own merchant, permissions, risk, ledger, and customer-experience responsibilities. The exact routes available are configuration-specific and must be confirmed before being offered to merchants. Audience: Payment service providers, merchant acquirers, payment platforms, and orchestration teams. ### Product routing - [White-label payment infrastructure](https://www.radom.com/white-label-payment-infrastructure): Radom capabilities should sit behind the PSP's own merchant and product experience. Watch for: White-label delivery does not remove required disclosures, compliance controls, or route limitations. - [Crypto payments](https://www.radom.com/crypto-payments): A merchant needs customer payment acceptance in supported digital assets. Watch for: Network choice, confirmation policy, refunds, settlement, and reconciliation still need explicit handling. - [Virtual accounts](https://www.radom.com/virtual-accounts): Repeat fiat deposits need attributable account details rather than a checkout session. Watch for: Account format, currency, settlement asset, network, and permitted use depend on configuration. - [Mass payouts](https://www.radom.com/payouts): The PSP needs to disburse an existing balance to approved beneficiaries. Watch for: Funding, beneficiary data, destination support, approvals, and corridor availability govern execution. ### Frequently asked questions **Can a PSP use Radom behind its own interface?** Radom documents APIs and configurable payment surfaces that can support an embedded or branded implementation. The PSP still needs to provide required disclosures and operate the merchant, permissions, compliance, support, and reconciliation layers appropriate to its service. **Does every PSP receive the same currencies and rails?** Availability is not inferred from a general marketing page. The countries, currencies, assets, networks, bank rails, payout corridors, limits, and account formats available to a business depend on onboarding, its operating markets, and the capabilities enabled for its Radom organisation. Confirm the intended route with Radom and build dynamic choices from the current API or documented catalogue where one is provided. **Should a PSP build one balance status for every product?** No. Model checkout, bank collection, on-chain deposits, conversion, refunds, and payouts as related but distinct lifecycles. A single generic success flag usually hides operationally important states. ### Public documentation - [Radom developer documentation](https://docs.radom.com/): Public entry point for available implementation guides and API surfaces. - [Crypto payments guide](https://docs.radom.com/guides/crypto-payments): Public implementation guidance for supported crypto-payment workflows. - [Webhook guide](https://docs.radom.com/webhooks/guide): Public guidance for event delivery and operational state handling. - [Payouts overview](https://docs.radom.com/guides/payouts-overview): Public overview of payout workflow requirements. ## Payment Infrastructure for Fintechs Canonical: https://www.radom.com/industries/fintechs Content last reviewed: 2026-07-25 **What payment infrastructure can a fintech build with Radom?** A fintech can combine the Radom capabilities enabled for its organisation into specific customer or treasury journeys: crypto payment acceptance, Open Banking checkout, virtual-account collection, supported conversion, stablecoin settlement, and payouts. Radom provides selected payment infrastructure; it does not replace the fintech's customer ledger, permissions, compliance programme, disclosures, or product-specific regulatory assessment. Audience: Fintech product, payments, treasury, finance, engineering, and operations teams. ### Product routing - [Open Banking](https://www.radom.com/open-banking): A user should make a bank-led payment for a specific checkout or funding journey. Watch for: Payment initiation and bank authorisation are not necessarily final settlement. - [Virtual accounts](https://www.radom.com/virtual-accounts): A customer or ledger entity needs reusable fiat collection details and clearer attribution. Watch for: Published examples include enabled USD, EUR, MXN, and BRL formats; actual access is organisation-specific. - [Crypto conversion](https://www.radom.com/crypto-convert): Supported balances must be converted through a quoted API route. Watch for: Build from the current pair catalogue, minimum amount, and quote rather than a static pair list. - [Stablecoin settlement](https://www.radom.com/stablecoin-settlement): A supported stablecoin is an operating or settlement leg in a wider payment flow. Watch for: It is payment infrastructure, not a yield, investment, or token-issuance product. ### Frequently asked questions **Is Radom a complete fintech ledger?** No. Radom provides selected payment and financial-infrastructure capabilities. A fintech should maintain its own customer and accounting ledgers, permissions, reporting, and control framework. **Which currencies and assets can a fintech support?** Availability is not inferred from a general marketing page. The countries, currencies, assets, networks, bank rails, payout corridors, limits, and account formats available to a business depend on onboarding, its operating markets, and the capabilities enabled for its Radom organisation. Confirm the intended route with Radom and build dynamic choices from the current API or documented catalogue where one is provided. **Can bank collections settle into stablecoins?** Radom's public product material describes enabled bank-led collection and virtual-account flows that can connect to supported crypto settlement. Confirm the source currency, market, settlement asset, network, and operating model before launch. ### Public documentation - [Open Banking guide](https://docs.radom.com/guides/open-banking): Public implementation guidance for bank-led checkout and status handling. - [Virtual accounts guide](https://docs.radom.com/guides/virtual-accounts): Public guide to documented account types, collection, and settlement models. - [Conversion API guide](https://docs.radom.com/guides/conversion-api): Public guidance for route discovery, minimums, quotes, and acceptance. - [Payment methods catalogue](https://docs.radom.com/additional-resources/payment_methods): Public catalogue for currently documented payment-method examples. ## Payment Infrastructure for Marketplaces Canonical: https://www.radom.com/industries/marketplaces Content last reviewed: 2026-07-25 **How can a marketplace use Radom payment infrastructure?** A marketplace can use enabled Radom capabilities to accept supported crypto payments, collect attributable bank deposits, maintain event-driven payment records, convert supported balances, and initiate payouts. The marketplace must still define the seller model, ledger ownership, release conditions, disputes, refunds, beneficiary controls, and market availability that govern its own service. Audience: Marketplaces, platforms, creator networks, affiliate platforms, and multi-sided commerce teams. ### Product routing - [Crypto checkout](https://www.radom.com/crypto-checkout): A buyer should complete a specific order through a hosted crypto payment flow. Watch for: Use order metadata, supported networks, and final confirmation before fulfilment. - [Payment links](https://www.radom.com/crypto-payment-links): The platform needs a shareable no-code collection route rather than a full checkout integration. Watch for: Link ownership and order attribution still need a reliable internal model. - [Virtual accounts](https://www.radom.com/virtual-accounts): Repeat bank transfers need account-level attribution to a customer, seller, or operating ledger. Watch for: Account currency, format, purpose, settlement, and availability are configuration-specific. - [Mass payouts](https://www.radom.com/payouts): Approved seller or contractor balances are ready for disbursement. Watch for: Beneficiary verification, funding balance, corridor, destination, fees, and exception handling remain required. ### Frequently asked questions **Does Radom calculate marketplace seller balances?** Radom can provide selected payment, balance, conversion, event, and payout infrastructure. The marketplace should maintain its own seller entitlement and accounting ledger. **Can a marketplace collect in one asset and pay out in another?** Where the required collection, conversion, and payout routes are enabled, they can be connected as separate operational legs. Confirm the current route, quote, destination support, and settlement model before offering it. **Which payout destinations are available?** Availability is not inferred from a general marketing page. The countries, currencies, assets, networks, bank rails, payout corridors, limits, and account formats available to a business depend on onboarding, its operating markets, and the capabilities enabled for its Radom organisation. Confirm the intended route with Radom and build dynamic choices from the current API or documented catalogue where one is provided. ### Public documentation - [Hosted checkout guide](https://docs.radom.com/guides/hosted-checkout): Public guidance for hosted customer payment journeys. - [Webhook guide](https://docs.radom.com/webhooks/guide): Public guidance for payment and operational event handling. - [Conversion API guide](https://docs.radom.com/guides/conversion-api): Public guidance for quoted conversion workflows. - [Payouts overview](https://docs.radom.com/guides/payouts-overview): Public guide to payout workflow requirements. ## Collect Fiat and Settle in Stablecoins Canonical: https://www.radom.com/use-cases/collect-fiat-settle-stablecoins Content last reviewed: 2026-07-25 **How does fiat-to-stablecoin settlement work?** An enabled fiat-to-stablecoin workflow starts with a bank-led collection such as Open Banking checkout or a virtual account, waits for the appropriate final payment state, attributes the source funds, and connects them to a supported crypto balance or quoted conversion route. The exact fiat currencies, markets, settlement assets, networks, timing, and operating model depend on onboarding and the capabilities enabled for the organisation. Audience: Fintechs, PSPs, payment platforms, marketplaces, and treasury operations teams. ### Product routing - [Open Banking](https://www.radom.com/open-banking): The customer should initiate a bank payment inside a specific checkout or funding journey. Watch for: Radom documents EUR and GBP use cases; actual bank, rail, and market coverage is configuration-specific. - [Virtual accounts](https://www.radom.com/virtual-accounts): Customers or treasury entities need reusable collection details for repeat bank transfers. Watch for: Public documentation describes enabled USD, EUR, MXN, and BRL account formats, subject to coverage and onboarding. - [Crypto conversion](https://www.radom.com/crypto-convert): A confirmed balance needs a quoted move into another supported asset or network route. Watch for: Use the current pair catalogue, minimum, and quote response rather than publishing a permanent pair matrix. - [Stablecoin settlement](https://www.radom.com/stablecoin-settlement): The full collection, balance, conversion, payout, and controls model needs to be designed together. Watch for: Stablecoin settlement is an operational payment leg, not a promise of yield or investment return. ### Frequently asked questions **Can Radom collect EUR or GBP through Open Banking?** Radom's public product and implementation material describes enabled EUR and GBP Open Banking flows. Availability varies by bank, rail, market, onboarding, and organisation configuration, so it must be confirmed before launch. **Which virtual-account currencies are documented?** Radom's public virtual-account material describes enabled USD, EUR, MXN, and BRL account formats. That is not a guarantee that every format, region, or settlement route is available to every organisation. **Which stablecoins and networks are supported?** Use the currently enabled payment methods, balance configuration, and conversion routes for the organisation. Radom should not publish a static universal promise because asset and network support can vary by product and configuration. ### Public documentation - [Open Banking guide](https://docs.radom.com/guides/open-banking): Public implementation source for enabled bank-led payment flows. - [Virtual accounts guide](https://docs.radom.com/guides/virtual-accounts): Public source for documented account formats and settlement models. - [Conversion API guide](https://docs.radom.com/guides/conversion-api): Public source for dynamic pair, minimum, quote, and acceptance handling. ## Reconcile Customer Fiat and Crypto Deposits Canonical: https://www.radom.com/use-cases/reconcile-customer-deposits Content last reviewed: 2026-07-25 **How can a business reconcile repeat fiat and crypto deposits?** Assign a durable collection identifier to the customer or ledger entity: an enabled virtual account for bank transfers or a dedicated crypto deposit address for on-chain deposits. Store that mapping with the resulting event and transaction records, validate the submitted currency or network, and release value only after the relevant final state. Shared accounts or addresses can be appropriate in some flows, but they require another reliable attribution key. Audience: Fintechs, exchanges, platforms, marketplaces, treasury teams, and finance operations. ### Product routing - [Virtual accounts](https://www.radom.com/virtual-accounts): The sender uses bank rails and needs reusable attributable fiat collection details. Watch for: Currency, format, permitted purpose, settlement asset, network, and region depend on enabled coverage. - [Deposit addresses](https://www.radom.com/deposit-addresses): The sender already holds a supported digital asset and repeat on-chain deposits need attribution. Watch for: Asset, network, address ownership, confirmation state, minimums, and wrong-network handling need controls. - [Open Banking](https://www.radom.com/open-banking): A specific customer action or order should initiate a bank payment through checkout. Watch for: It is a payment journey rather than a reusable bank-account identifier. - [Crypto checkout](https://www.radom.com/crypto-checkout): A specific purchase should be priced and completed through a hosted on-chain payment flow. Watch for: Checkout attribution differs from a standing customer deposit address. ### Frequently asked questions **When should a business use a virtual account?** Use an enabled virtual account when a customer or operating entity needs reusable bank-transfer details and clearer source attribution than a shared account can provide. **When should a business use a dedicated crypto deposit address?** Use a dedicated address when the sender already holds a supported asset, repeat on-chain deposits are expected, and the business can enforce the correct asset, network, and confirmation rules. **Which fiat currencies and crypto networks are available?** Availability is not inferred from a general marketing page. The countries, currencies, assets, networks, bank rails, payout corridors, limits, and account formats available to a business depend on onboarding, its operating markets, and the capabilities enabled for its Radom organisation. Confirm the intended route with Radom and build dynamic choices from the current API or documented catalogue where one is provided. ### Public documentation - [Virtual accounts guide](https://docs.radom.com/guides/virtual-accounts): Public guidance for attributable fiat collection accounts. - [Crypto payments guide](https://docs.radom.com/guides/crypto-payments): Public guidance for supported on-chain payment and deposit concepts. - [Webhook guide](https://docs.radom.com/webhooks/guide): Public guidance for receiving and processing operational events. - [Payment methods catalogue](https://docs.radom.com/additional-resources/payment_methods): Public catalogue for currently documented payment-method examples. ## Global Business Payout Operations Canonical: https://www.radom.com/use-cases/global-business-payouts Content last reviewed: 2026-07-25 **How should a business build global payout operations?** A reliable payout workflow starts with an approved payable entitlement, validates the beneficiary and an enabled destination route, reserves the funded balance, submits an idempotent instruction, processes final status events, and reconciles the result. Radom can support selected crypto or fiat payout routes where enabled; corridor, destination, currency, asset, network, beneficiary fields, timing, and fees depend on the organisation and route. Audience: Marketplaces, affiliate platforms, fintechs, PSPs, payroll-adjacent platforms, and treasury teams. ### Product routing - [Mass payouts](https://www.radom.com/payouts): Multiple approved beneficiary instructions should be disbursed through supported crypto or fiat routes. Watch for: Destination support, beneficiary data, source funding, corridor, approvals, timing, and fees vary by route. - [Crypto conversion](https://www.radom.com/crypto-convert): The source balance needs a supported quoted conversion before payout. Watch for: Conversion and payout are separate final states and should be reconciled separately. - [Stablecoin settlement](https://www.radom.com/stablecoin-settlement): A supported stablecoin balance is part of a wider collection, treasury, and disbursement workflow. Watch for: The operating model should cover collection provenance, conversion, balance ownership, and destination. - [White-label infrastructure](https://www.radom.com/white-label-payment-infrastructure): A PSP or platform needs to embed payout capabilities into its own merchant or beneficiary experience. Watch for: The platform remains responsible for its entitlement, permissions, disclosures, and operational support model. ### Frequently asked questions **Can Radom pay beneficiaries in both crypto and fiat?** Radom publicly describes crypto and fiat payout capabilities, but actual destination routes, currencies, assets, networks, and corridors depend on the products and permissions enabled for the organisation. **How should duplicate payouts be prevented?** Create an immutable entitlement and idempotency key, persist the first submission result, and make retries resume or inspect the existing instruction rather than issuing another payout. **Which countries and currencies are supported?** Availability is not inferred from a general marketing page. The countries, currencies, assets, networks, bank rails, payout corridors, limits, and account formats available to a business depend on onboarding, its operating markets, and the capabilities enabled for its Radom organisation. Confirm the intended route with Radom and build dynamic choices from the current API or documented catalogue where one is provided. ### Public documentation - [Payouts overview](https://docs.radom.com/guides/payouts-overview): Public guidance for supported payout workflow concepts. - [Conversion API guide](https://docs.radom.com/guides/conversion-api): Public guidance for conversion where a payout requires another supported balance. - [Webhook guide](https://docs.radom.com/webhooks/guide): Public guidance for operational event processing. ## Add Crypto Payments to a Platform Canonical: https://www.radom.com/use-cases/add-crypto-payments-to-a-platform Content last reviewed: 2026-07-25 **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. Audience: SaaS platforms, PSPs, marketplaces, fintechs, and online businesses. ### Product routing - [Crypto checkout](https://www.radom.com/crypto-checkout): A buyer should complete one order in a hosted payment journey. Watch for: Pass reliable order references and fulfil only after final confirmation. - [Payment links](https://www.radom.com/crypto-payment-links): A business needs a shareable collection route without building a complete checkout. Watch for: Link ownership, pricing, expiry, payment purpose, and reconciliation still need definition. - [Crypto invoicing](https://www.radom.com/crypto-invoicing): The payment request should be itemised and associated with a business invoice. Watch for: Invoice state, payment state, expiry, and accounting treatment should not be collapsed. - [Crypto billing](https://www.radom.com/crypto-billing): The customer is entering a recurring subscription or billing relationship. Watch for: Authorisation, recurrence, failed collection, cancellation, and entitlement states need their own model. ### 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. ### Public documentation - [Crypto payments guide](https://docs.radom.com/guides/crypto-payments): Public overview of supported crypto-payment implementation concepts. - [Hosted checkout guide](https://docs.radom.com/guides/hosted-checkout): Public implementation guidance for hosted checkout. - [Integrated checkout guide](https://docs.radom.com/guides/integrated-checkout): Public implementation guidance for integrated payment experiences. - [Webhook guide](https://docs.radom.com/webhooks/guide): Public guidance for final-state and lifecycle event processing. - [Payment methods catalogue](https://docs.radom.com/additional-resources/payment_methods): Public catalogue for currently documented payment-method examples. ## Pricing Canonical: https://www.radom.com/pricing Content last reviewed: 2026-07-15 Current Radom pricing figures are maintained on the pricing page itself and are not duplicated here. Read them at the canonical URL above. ## Comparisons Each comparison page states its competitor facts with visible source retrieval or verification dates on the page. Read the current figures at the canonical URLs: - [BitPay vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/bitpay) - [Coinbase Commerce vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/coinbase-commerce) - [CoinGate vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/coingate) - [CoinPayments vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/coinpayments) - [CoinsPaid vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/coinspaid) - [Confirmo vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/confirmo) - [Crypto.com Pay vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/crypto-com-pay) - [NOWPayments vs Radom: Crypto Payment Processing Comparison](https://www.radom.com/comparisons/nowpayments) ## Editorial policy Canonical: https://www.radom.com/editorial-standards Content last reviewed: 2026-07-23 Radom's sourcing, review, correction, and content-quality policy for everything the site publishes.