Deposit reconciliation
Reconcile repeat customer deposits
Choose attributable fiat account details or dedicated on-chain addresses, preserve the customer mapping, and keep pending funds out of available balances.
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 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.
Before implementation
Define the operating requirement
One accountable owner
Map each issued account or address to exactly one customer, merchant, entity, or internal treasury purpose.
Currency and network validation
Tell the sender which enabled currency, rail, asset, and network applies and reject unsupported substitutions.
Final-state processing
Keep deposits pending until the appropriate bank or blockchain confirmation state has been reached.
An exceptions queue
Provide a recoverable process for unmatched, duplicated, below-minimum, wrong-network, returned, and delayed deposits.
Operating model
From requirement to reconciled operation
- 01
Choose bank or on-chain attribution
Use a virtual account for repeat fiat transfers or a dedicated deposit address when the sender already holds the supported digital asset.
Control: Do not issue both without defining how the resulting balances and customer intent are distinguished.
- 02
Persist the mapping
Store the Radom account or address identifier, customer or ledger entity, currency or asset, network, and lifecycle state.
Control: Treat account-detail or address changes as auditable configuration changes.
- 03
Process deposit events
Match inbound events to the stored owner and carry payment, bank, transaction, and internal references into the deposit record.
Control: Make event processing idempotent and preserve out-of-order state transitions safely.
- 04
Reconcile and release
Post the confirmed source amount, resulting balance movement, fees when supplied, timestamps, and exception outcome.
Control: Do not credit spendable value while the route is pending or the ownership match is unresolved.
Product routing
Choose the product by the job it needs to do
| Product route | Use when | Plan for |
|---|---|---|
| Virtual accounts | The sender uses bank rails and needs reusable attributable fiat collection details. | Currency, format, permitted purpose, settlement asset, network, and region depend on enabled coverage. |
| Deposit addresses | The sender already holds a supported digital asset and repeat on-chain deposits need attribution. | Asset, network, address ownership, confirmation state, minimums, and wrong-network handling need controls. |
| Open Banking | A specific customer action or order should initiate a bank payment through checkout. | It is a payment journey rather than a reusable bank-account identifier. |
| Crypto checkout | A specific purchase should be priced and completed through a hosted on-chain payment flow. | Checkout attribution differs from a standing customer deposit address. |
Operations
Controls that make the workflow durable
Keep the mapping immutable
Version ownership changes instead of overwriting historical account or address attribution.
Record both identifiers
Keep the external bank or blockchain transaction reference alongside the Radom and internal ledger identifiers.
Block unsupported substitutions
Do not assume a transfer in another fiat currency or on another blockchain network will be received or recoverable.
Measure exception ageing
Track how long unmatched and pending deposits remain unresolved and alert operators before customer-impact targets are breached.
Practical answers
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.
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.
- Virtual accounts guidePublic guidance for attributable fiat collection accounts.
- Crypto payments guidePublic guidance for supported on-chain payment and deposit concepts.
- Webhook guidePublic guidance for receiving and processing operational events.
- Payment methods cataloguePublic catalogue for currently documented payment-method examples.
Plan the workflow
