Open Banking payments
Open Banking payments, connected to settlement and reconciliation
Give customers a bank-led way to pay, track the payment through its asynchronous lifecycle, and connect confirmed funds to the rest of your Radom workflow.
Product information reviewed . Availability is subject to onboarding and enabled capabilities.
Answer first
What Radom provides
Radom Open Banking is a bank-led checkout and funding route for businesses that need payment initiation, status tracking, reconciliation, and supported bank-to-crypto settlement in one operational flow. Availability, rails, currencies, and settlement assets depend on the market, onboarding outcome, and capabilities enabled for your organisation.
Product fit
Who this is for—and when it is not the right route
Good fit
Payment and checkout teams
Add a bank-led payment option to a hosted flow or preselect a supported bank inside your own interface.
Fintech and platform operators
Connect bank-funded customer or merchant journeys to supported crypto balances and downstream payment operations.
Finance and reconciliation teams
Track orders with your own metadata and retain bank-rail references and status history when those fields are supplied.
Use another route when
A replacement for a bank account
Use virtual accounts when you need named or repeatable fiat collection details rather than a checkout-led payment journey.
Uniform real-time settlement everywhere
Standard bank transfers can remain pending after authorisation. Rail speed and availability differ by bank, market, and configuration.
Fulfilment based on a browser redirect
A customer returning from their bank is not final proof of payment. Fulfil only after Radom reports a final successful status.
Capabilities
A connected operating workflow
Hosted Open Banking checkout
Create a checkout session with the Open Banking gateway and send the customer to the returned payment URL.
Bank preselection
List bank options for a market and currency, then pass the Radom bank identifier into checkout when you want bank-specific choices in your UI.
Asynchronous status tracking
Read progress through checkout state and use the final managed-payment webhook as the dependable fulfilment signal.
Bank-to-crypto funding
Where enabled, connect supported bank flows to crypto settlement balances rather than operating a disconnected collection and conversion stack.
Operational references
Use your checkout metadata alongside payment references, end-to-end identifiers, remittance information, and scheme fields when available.
Refund events
Track supported Open Banking refunds through Radom's existing refund webhook rather than inventing a second operational process.
Implementation
From requirements to reconciled operation
- 01
Confirm the commercial route
Define the customer market, transaction currency, expected rail, refund requirement, and settlement destination with Radom.
Control: Do not expose a bank, rail, or instant-payment claim before it is enabled for your organisation.
- 02
Choose the checkout model
Let Radom present available banks in hosted checkout, or retrieve Radom bank identifiers and show supported choices in your own UI.
Control: Refresh the bank catalogue rather than treating a previously returned list as permanent.
- 03
Create the checkout session
Send the order value, currency, success and cancel URLs, Open Banking gateway details, and your internal order reference as metadata.
Control: Use a stable internal order ID so the payment can be reconciled without relying on customer-facing text.
- 04
Show honest progress
Redirect the customer and display processing, waiting, authorised, or finalising states while the transfer is unresolved.
Control: Do not translate an authorisation or redirect into a paid state.
- 05
Confirm and fulfil
Treat Radom's final successful checkout state and managed-payment webhook as the confirmation used by your order system.
Control: Make webhook handling idempotent so retries cannot fulfil the same order twice.
- 06
Reconcile and operate
Store the Radom object ID, your order ID, payment scheme, final state, and available bank references with the ledger entry.
Control: Route failed, cancelled, delayed, and refund states into defined operations queues.
Decision guide
Choose the route by operating requirement
| Route | Use when | Plan for |
|---|---|---|
| Open Banking checkout | A customer should initiate a bank payment as part of a specific order or funding journey. | The flow is asynchronous; availability and speed vary by market, bank, and rail. |
| Virtual accounts | A customer, merchant, or treasury operation needs reusable collection details and clearer attribution of inbound bank transfers. | Account type, currency, settlement asset, and destination network must be confirmed before launch. |
| Crypto payments | The payer already holds a supported digital asset and should pay on-chain through checkout, an invoice, or a payment link. | Network choice, confirmation state, refunds, and treasury handling remain part of the implementation. |
| Payouts | Your main requirement is disbursing an existing balance to a beneficiary rather than collecting from a payer. | Destination, corridor, funding balance, beneficiary data, and enabled payout rails govern availability. |
Operations
Reconciliation and controls
Separate sent from settled
Model a transfer that has been submitted or authorised as pending until Radom reports the final successful state.
Keep a three-way identifier map
Store your order or account reference, the Radom checkout identifier, and the bank reference fields supplied for the payment.
Process events idempotently
Deduplicate webhook messages, record state transitions, and make downstream fulfilment safe to retry.
Build exception ownership
Assign operational owners for delayed, failed, cancelled, duplicate, and refunded payments before opening the rail to customers.
Risks and limitations
Know the boundaries before launch
Coverage is configuration-specific
A public description of a currency or rail is not a promise that it is active for every organisation or country.
Instant is a rail property, not a slogan
SEPA Instant and Faster Payments can be quick when available, but final confirmation is still the correct fulfilment control.
Settlement paths differ
Supported settlement assets and networks depend on the specific Open Banking or funding product configured for your organisation.
Compliance remains part of the flow
Onboarding, transaction review, account permissions, and applicable customer checks are not removed by API integration.
Frequently asked questions
Practical answers
What is Radom Open Banking?
Radom Open Banking is a bank-led checkout and funding route that connects payment initiation with Radom checkout state, webhooks, reconciliation fields, and supported settlement workflows. Exact availability depends on market, onboarding, and enabled capabilities.
Does a bank redirect mean the payment is complete?
No. A redirect or bank authorisation can occur before funds are finally confirmed. Keep fulfilment pending until Radom reports a final successful checkout state or the final managed-payment webhook.
Can we let a customer choose their bank in our own interface?
Where enabled, yes. Your application can retrieve Radom bank options for a market and currency and pass the selected Radom bank identifier into the checkout session.
Which currencies and instant bank rails are supported?
Public Radom documentation describes EUR flows including SEPA Credit and, in enabled experiences, SEPA Instant, plus Faster Payments rail details in supported setups. Confirm the specific market, currency, bank coverage, and rail enabled for your organisation before launch.
Can Open Banking funds settle into a stablecoin balance?
Supported bank-to-crypto flows can settle into an enabled crypto balance. The settlement asset and destination network vary by product configuration, so they must be agreed and tested for the intended route.
How should Open Banking payments be reconciled?
Store your internal order reference in checkout metadata, retain the Radom checkout and payment identifiers, record every status transition, and capture scheme and bank-reference fields when they are supplied.
Product provenance
Grounded in Radom's public documentation
These sources describe the public product behaviour used on this page. They do not replace a coverage and onboarding check for your organisation.
Checkout, preselection, statuses, webhooks, settlement, and controls.
Primary public product documentation for the workflow and operational states described on this page.Event verification, idempotency, and fulfilment guidance.
Primary public documentation for event-driven confirmation and operational handling.Current public payment-method reference.
Use with an organisation-specific coverage check before exposing a rail to customers.
