Platforms and marketplaces
Payment operations for marketplaces with buyers, sellers, and split responsibilities
Keep buyer collection, marketplace records, seller balances, conversion, and payout instructions connected without pretending they are one transaction.
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 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.
Before implementation
Define the operating requirement
Separate buyer and seller records
Keep payer, order, marketplace, seller, balance, and beneficiary identifiers distinct and linked.
Defined release conditions
Document when a received payment becomes available for seller settlement, refund, reserve, fee, or payout.
Payout-ready beneficiary data
Collect and validate the destination fields required by the enabled payout route before a balance becomes payable.
Exception ownership
Assign teams for unmatched funds, partial orders, refund disputes, failed conversions, and returned payouts.
Operating model
From requirement to reconciled operation
- 01
Attach the order map
Create the payment or collection object with the marketplace order, seller, buyer, and internal ledger references needed downstream.
Control: Do not rely on a free-text payment description as the only attribution key.
- 02
Wait for the right final state
Confirm the collection using the final state appropriate to its bank or blockchain route before marking the order funded.
Control: A browser return, transaction submission, or bank authorisation can still precede final confirmation.
- 03
Post marketplace ledger movements
Record gross collection, fees, refunds, reserves, seller entitlement, and any conversion as separate entries.
Control: Do not treat the provider balance as a substitute for seller-level accounting.
- 04
Initiate and reconcile payouts
Submit approved beneficiary instructions through an enabled payout route and preserve the resulting final state.
Control: Make batch and retry logic idempotent so a repeated job cannot pay the same entitlement twice.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Crypto checkout | A buyer should complete a specific order through a hosted crypto payment flow. | Use order metadata, supported networks, and final confirmation before fulfilment. |
| Payment links | The platform needs a shareable no-code collection route rather than a full checkout integration. | Link ownership and order attribution still need a reliable internal model. |
| Virtual accounts | Repeat bank transfers need account-level attribution to a customer, seller, or operating ledger. | Account currency, format, purpose, settlement, and availability are configuration-specific. |
| Mass payouts | Approved seller or contractor balances are ready for disbursement. | Beneficiary verification, funding balance, corridor, destination, fees, and exception handling remain required. |
Operations
Controls that make the workflow durable
Use immutable entitlement IDs
Create a stable payout entitlement identifier before batching so retries can be deduplicated safely.
Preserve gross-to-net detail
Retain collection amount, marketplace fees, conversion amounts, refunds, reserves, and final payout separately.
Reconcile by seller and route
Produce exceptions by seller, currency or asset, network, destination, and processing state—not merely one platform total.
Keep route availability honest
Show buyers and sellers only payment and payout methods enabled for the relevant market and organisation.
Practical answers
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.
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.
- Hosted checkout guidePublic guidance for hosted customer payment journeys.
- Webhook guidePublic guidance for payment and operational event handling.
- Conversion API guidePublic guidance for quoted conversion workflows.
- Payouts overviewPublic guide to payout workflow requirements.
Plan the workflow
