Business payouts
Move from payable balances to controlled global payout operations
Validate the beneficiary and route, make approvals explicit, prevent duplicate execution, and reconcile each instruction to its final destination state.
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 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.
Before implementation
Define the operating requirement
An approved entitlement
Create a stable payable record that states who should receive what, why, and under which approval.
Validated beneficiary data
Collect the exact account, address, currency, asset, network, and identity fields required by the enabled destination.
Funded route selection
Confirm the source balance, destination support, expected fee treatment, limits, and execution timing before submission.
Final-state reconciliation
Keep submitted, processing, completed, failed, and returned instructions visible to finance and operations.
Operating model
From requirement to reconciled operation
- 01
Create the payable record
Assign an immutable entitlement ID linked to the beneficiary, source ledger, purpose, gross amount, fees, and approval state.
Control: A scheduled job should select approved entitlements, not construct new payables from loose account balances.
- 02
Validate route and destination
Check the enabled corridor, asset or currency, network or bank fields, beneficiary requirements, minimums, and available balance.
Control: Never substitute an unsupported network, currency, or beneficiary field silently.
- 03
Submit idempotently
Use a stable instruction key and persist the provider response before the job can attempt the same entitlement again.
Control: Retries must query or resume the existing instruction rather than creating a second payout.
- 04
Reconcile the outcome
Post the final amount, fee when supplied, destination reference, timestamps, and failure or return reason to the payable ledger.
Control: Keep uncertain outcomes in an exception state instead of guessing whether the beneficiary was paid.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Mass payouts | Multiple approved beneficiary instructions should be disbursed through supported crypto or fiat routes. | Destination support, beneficiary data, source funding, corridor, approvals, timing, and fees vary by route. |
| Crypto conversion | The source balance needs a supported quoted conversion before payout. | Conversion and payout are separate final states and should be reconciled separately. |
| Stablecoin settlement | A supported stablecoin balance is part of a wider collection, treasury, and disbursement workflow. | The operating model should cover collection provenance, conversion, balance ownership, and destination. |
| White-label infrastructure | A PSP or platform needs to embed payout capabilities into its own merchant or beneficiary experience. | The platform remains responsible for its entitlement, permissions, disclosures, and operational support model. |
Operations
Controls that make the workflow durable
Dual-control high-risk changes
Require appropriate approval for new beneficiary details, material route changes, and high-value instructions.
Reconcile batches to entitlements
A batch total is not enough; every payout must trace back to one approved payable and final destination result.
Protect credentials
Keep payout permissions separate from read-only reporting and scope automated services to the minimum operations required.
Plan failed and returned funds
Define who investigates, when a retry is allowed, whether new approval is required, and how balances are restored.
Practical answers
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.
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.
- Payouts overviewPublic guidance for supported payout workflow concepts.
- Conversion API guidePublic guidance for conversion where a payout requires another supported balance.
- Webhook guidePublic guidance for operational event processing.
Plan the workflow
