Open banking

Use Radom open banking when you want a customer or operator to start from a bank payment flow and have the result tracked inside Radom. Depending on your enabled configuration, this can support customer-facing checkout, merchant treasury funding, or broader bank-to-crypto product flows.

Open banking is asynchronous. A bank redirect or authorization does not always mean funds have arrived. Build your integration around Radom status reads and webhooks, not the browser redirect alone.

When to use it

Open banking is typically useful when you need:

A bank-led payment option in checkout.
Bank-to-crypto funding into supported Radom balances.
A customer or merchant funding flow with bank references for reconciliation.
Status visibility before final settlement, especially for standard bank rails.

Availability depends on geography, onboarding status, enabled products, and the exact payment flow you want to launch.

Integration models

Model	Use when	Main objects
Hosted open-banking checkout	You want Radom to host the customer payment journey.	Checkout session, hosted checkout URL, checkout status reads, webhooks.
Bank preselection	You want to show bank-specific choices in your UI before creating the Radom checkout session.	Bank catalogue, `gateway.openBanking.bankId`, checkout session.
Bank-to-crypto funding	You want fiat from bank rails to settle into supported crypto balances.	Onramp or checkout configuration, settlement balance, webhooks.

The standalone public onramp API currently creates SEPA funding instructions. In some enabled EUR checkout experiences, customer-facing bank methods can appear as Sepa Credit or Sepa Instant, depending on the product flow and organization setup.

Recommended checkout flow

Confirm open-banking availability for the markets, currencies, and settlement model you want to support.
Decide whether the customer chooses their bank inside Radom checkout or inside your own UI.
If you preselect a bank, call GET /open_banking/banks and store the returned Radom bank id.
Create a checkout session with gateway.openBanking.
Redirect the customer to the returned hosted checkout URL.
Read the checkout session to show progress while the bank transfer is pending.
Fulfill only after the final managedPayment webhook or a final successful checkout status.

Create an open-banking checkout session

Create a checkout session with the openBanking gateway. The exact line items, totals, and settlement configuration depend on your product setup.

{
  "total": 100.00,
  "currency": "EUR",
  "gateway": {
    "openBanking": {
      "email": "customer@example.com"
    }
  },
  "successUrl": "https://example.com/checkout/success",
  "cancelUrl": "https://example.com/checkout/cancel",
  "metadata": [
    {
      "key": "orderId",
      "value": "order_123"
    }
  ]
}

If you pass gateway.openBanking.bankId, Radom starts the checkout with that bank selected. See Bank preselection for the full flow.

Bank preselection

Use bank preselection when you want to show bank-specific buttons in your own UI, such as "Pay with Revolut", before redirecting the customer to Radom checkout.

First list Radom bank options for the market and currency:

curl "https://api.radom.com/open_banking/banks?market=DE&currency=EUR&search=Revolut" \
  -H "Authorization: Bearer <api-key>"

Use the returned id as gateway.openBanking.bankId when creating the checkout session. This is a Radom bank identifier. Do not store or pass underlying provider bank IDs.

If the same bank is available in multiple markets, also pass gateway.openBanking.market, such as DE, FR, or NL, so Radom can route the checkout to the correct local bank option.

Status tracking

Use the checkout session response to track open-banking status changes. Do not treat a browser redirect from the bank as final payment confirmation.

Read the provider status from:

openBankingPaymentData.status

Common progress statuses include:

Status	Customer or operations message
`processing`	The bank payment flow has started.
`waiting_for_payment`	The transfer may have been submitted, but Radom is still waiting for it to be sent or detected.
`authorized`	The bank authorized or submitted the transfer, but settlement can still be pending.
`finalizing`	Radom has detected the transfer and is completing final checks.
`failed`	The bank transfer did not complete.
`canceled` or `cancelled`	The bank authorization or transfer was cancelled.
`paid`	Radom has confirmed the successful payment. A `managedPayment` webhook is also emitted for fulfillment workflows.
`in_refund`	Refund processing has started after payment.
`partially_refunded`	Part of the payment has been refunded.
`refunded`	The payment has been refunded. A successful open-banking `refund` webhook can include `openBankingPaymentData.status` with `refunded`.

The final successful-payment signal remains the managedPayment webhook and the successful checkout status. For open-banking payments, the final managedPayment payload can include eventData.managedPayment.openBankingPaymentData.status with paid, plus rail fields such as paymentScheme and instantPaymentScheme.

For standard rails such as SEPA Credit, a transfer can be sent before it arrives at Radom. Tell the customer that the payment has been sent or is processing, but keep fulfillment pending until Radom confirms success.

For instant rails such as SEPA Instant or Faster Payments, confirmation is usually faster, but you should still wait for Radom's final success signal.

Refund completion is delivered through the existing refund webhook. For open-banking refunds, the payload can include eventData.refund.openBankingPaymentData.status with refunded.

Settlement and rail details

Fiat-connected settlement networks today include Arbitrum, Base, Ethereum, Polygon, Solana, and Tron. Public flows commonly settle into USDC today, with USDT available on selected destination networks.

Use the following fields when you need to explain or reconcile the bank rail:

Field	Description
`paymentScheme`	Bank rail or payment scheme when supplied, for example `Sepa Credit`, `Sepa Instant`, or `Faster Payments`.
`instantPaymentScheme`	Whether the provider identified the rail as instant.
`statusHistoryList`	Provider status history when supplied.
`paymentReference`, `endToEndId`, `remittanceInformation`	Bank references for reconciliation when supplied.

Broader asset flexibility is expanding through Convert, including automatic asset movement in more workflows.

Operational checklist

Before launch:

Confirm market, currency, rail, and settlement availability with Radom.
Decide whether bank selection happens in your UI or inside Radom checkout.
Store your own order ID in checkout metadata for reconciliation.
Subscribe to managedPayment, refund, and any payout or deposit events relevant to your workflow.
Make your webhook handler idempotent using the webhook message id.
Make customer-facing copy distinguish "sent" or "processing" from final payment success.
Refresh the bank catalogue periodically if you show bank-specific options.

Open banking

When to use it​

Integration models​

Recommended checkout flow​

Create an open-banking checkout session​

Bank preselection​

Status tracking​

Settlement and rail details​

Operational checklist​

Related docs​