Fintechs
Payment and settlement infrastructure for fintech product teams
Build collection, conversion, stablecoin, and payout journeys with explicit states, attributable references, and operational controls from the outset.
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
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.
Before implementation
Define the operating requirement
Journey before rail
Define whether the user is paying, funding an account, converting a balance, settling treasury, or receiving a payout before choosing the route.
Explicit money movement states
Represent initiated, pending, confirmed, converted, paid out, returned, and failed states without collapsing them into one balance update.
Attributable records
Carry the fintech's customer, account, order, and ledger references into the corresponding payment infrastructure objects.
Configuration-aware UX
Show only routes currently enabled for the customer market, organisation, currency, asset, network, or payout destination.
Operating model
From requirement to reconciled operation
- 01
Define the regulated product boundary
Document what the fintech offers, which entities and partners perform each activity, and what the customer should be told.
Control: Do not infer permissions or regulatory coverage from an API capability.
- 02
Select the collection model
Use checkout for a specific payment, virtual accounts for attributable repeat fiat deposits, or deposit addresses for repeat on-chain deposits.
Control: Prevent unsupported currencies, networks, account purposes, or payment methods from being submitted.
- 03
Connect conversion and settlement
Use current route catalogues and quotes when value needs to move between supported assets or into a settlement balance.
Control: Present quote amounts and final execution separately, and retain the accepted quote reference.
- 04
Close the ledger and operations loop
Reconcile infrastructure events to customer and treasury ledgers, then route exceptions to named operators.
Control: Do not use a webhook receipt alone as proof that every downstream ledger and payout leg completed.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Open Banking | A user should make a bank-led payment for a specific checkout or funding journey. | Payment initiation and bank authorisation are not necessarily final settlement. |
| Virtual accounts | A customer or ledger entity needs reusable fiat collection details and clearer attribution. | Published examples include enabled USD, EUR, MXN, and BRL formats; actual access is organisation-specific. |
| Crypto conversion | Supported balances must be converted through a quoted API route. | Build from the current pair catalogue, minimum amount, and quote rather than a static pair list. |
| Stablecoin settlement | A supported stablecoin is an operating or settlement leg in a wider payment flow. | It is payment infrastructure, not a yield, investment, or token-issuance product. |
Operations
Controls that make the workflow durable
Use exact decimal handling
Store fiat and token quantities without binary floating-point rounding, especially across quotes and ledger postings.
Make events idempotent
Deduplicate event delivery and make every balance, fulfilment, refund, and payout transition safe to retry.
Keep an evidence chain
Join the user instruction, infrastructure object, quote, transaction, fee, timestamp, and final destination record.
Design for exceptions first
Define ownership for unmatched deposits, delayed bank transfers, wrong-network attempts, quote expiry, and returned payouts.
Practical answers
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.
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.
- Open Banking guidePublic implementation guidance for bank-led checkout and status handling.
- Virtual accounts guidePublic guide to documented account types, collection, and settlement models.
- Conversion API guidePublic guidance for route discovery, minimums, quotes, and acceptance.
- Payment methods cataloguePublic catalogue for currently documented payment-method examples.
Plan the workflow
