Payment service providers
Payment infrastructure for PSPs that need more than another checkout
Connect collection, conversion, balances, webhooks, reconciliation, and payouts to your own merchant and operations model—without presenting every underlying capability as a separate product.
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 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.
Before implementation
Define the operating requirement
A clear merchant object
Decide which PSP merchant, customer, order, and settlement record owns each Radom checkout, account, conversion, and payout object.
Capability-based provisioning
Expose only the rails, assets, networks, and operations enabled for the relevant organisation and merchant cohort.
A real ledger and event model
Treat webhooks as state changes to process idempotently, not as an accounting system or a substitute for your internal books.
Route-specific controls
Apply appropriate onboarding, transaction monitoring, beneficiary, refund, exception, and disclosure controls to every enabled route.
Operating model
From requirement to reconciled operation
- 01
Map the merchant journeys
Separate payment acceptance, repeat deposits, conversion, treasury settlement, and beneficiary payout requirements before selecting APIs.
Control: Do not force every merchant requirement through crypto checkout when a bank-led, account-led, or payout route is the better fit.
- 02
Design the object and permission model
Map PSP merchant and transaction identifiers to Radom objects, and decide which users or services can quote, accept, refund, or pay out.
Control: Use least-privilege credentials and keep production and test environments separate.
- 03
Build dynamic product choices
Read supported payment methods, conversion pairs, and enabled account or payout options from current sources rather than a hard-coded commercial list.
Control: Availability can differ by organisation, market, asset, network, corridor, and onboarding outcome.
- 04
Operate final states
Process payment, deposit, refund, subscription, conversion, and payout events into a state machine with retries and exception ownership.
Control: A redirect, submitted transfer, or quote is not the same as final payment or settlement.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| White-label payment infrastructure | Radom capabilities should sit behind the PSP's own merchant and product experience. | White-label delivery does not remove required disclosures, compliance controls, or route limitations. |
| Crypto payments | A merchant needs customer payment acceptance in supported digital assets. | Network choice, confirmation policy, refunds, settlement, and reconciliation still need explicit handling. |
| Virtual accounts | Repeat fiat deposits need attributable account details rather than a checkout session. | Account format, currency, settlement asset, network, and permitted use depend on configuration. |
| Mass payouts | The PSP needs to disburse an existing balance to approved beneficiaries. | Funding, beneficiary data, destination support, approvals, and corridor availability govern execution. |
Operations
Controls that make the workflow durable
Preserve three-way references
Store the PSP transaction ID, merchant reference, and Radom object ID through every collection, conversion, and payout leg.
Reconcile legs separately
A collected payment, resulting balance, conversion, and payout are related but distinct events with different final states.
Prevent capability leakage
Do not let one merchant discover or invoke routes, assets, or destinations enabled only for another merchant or programme.
Own exceptions
Assign teams and response rules for delayed payments, unmatched deposits, conversion rejection, refund requests, and failed payouts.
Practical answers
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.
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.
- Radom developer documentationPublic entry point for available implementation guides and API surfaces.
- Crypto payments guidePublic implementation guidance for supported crypto-payment workflows.
- Webhook guidePublic guidance for event delivery and operational state handling.
- Payouts overviewPublic overview of payout workflow requirements.
Plan the workflow
