Skip to main content
The Payments API is a single gateway your server calls to move money, and that RadiumOne uses on your behalf to reach acquirers, card networks, issuers, and the loyalty host. This page maps the pieces so the guides that follow make sense in context — for the concepts inside a single request (transactions, sessions, idempotency), see Core concepts.

How it works

Components

  • Your server — holds your secret key, exchanges it for an access token, calls the gateway.
  • Your webhook endpoint — receives asynchronous outcome events.
  • Payments API gateway — auth, sessions, transactions; the only thing your integration talks to directly.
  • RadiumOne Elements / Checkout (optional) — browser surfaces that call the gateway with publishable-key-scoped tokens only.
  • Acquirer, network, issuer — approve or decline the authorization (third parties).
  • UOB Rewards host — checks a loyalty balance or redeems points.

Data flows

The letters match the flow tags in the diagram.

Your server

Your server is the only place your secret key ever lives. It’s responsible for:
  • Exchanging your secret key for an access token before calling the gateway — see Sandbox and API keys.
  • Generating a request_id or operation_id for every create-type call, so a retry after a timeout never risks a duplicate charge — see Idempotency with request IDs.
  • Hosting your webhook endpoint — an HTTPS URL that receives asynchronous events and verifies their signature before trusting them — see Webhooks.
Never use a secret key (r1sk_…) in browser code, mobile apps, or anywhere a shopper can inspect it. Secret keys belong on your server only.

Optional browser components

Two RadiumOne surfaces run in the shopper’s browser, and both call the gateway on their own — you don’t have to proxy their requests through your server:
  • RadiumOne Elements renders secure card fields and tokenizes the card client-side, so raw card data never reaches your server.
  • RadiumOne Checkout is a RadiumOne-hosted payment page (redirect or embedded) — the shopper enters their card there instead of on your site.
Either can be combined with RadiumOne’s built-in 3D Secure or your own 3DS provider. Both surfaces are scoped to publishable-key operations only (session creation and binding) — they can’t create, capture, void, or refund a payment.

What’s inside the gateway

Every operation below is served from the same base URL:

Acquirers, card networks, and issuers

The gateway routes each authorization to an acquirer, which in turn goes through the relevant card network to the shopper’s issuing bank. Acquirers, networks, and issuers are third parties RadiumOne integrates with on your behalf — your integration only ever talks to the gateway, and the gateway’s response (or the matching webhook) is the authoritative result. You never call an acquirer or issuer directly.

Loyalty host (UOB Rewards)

When a purchase includes a loyalty redemption, the gateway calls out to the UOB Rewards loyalty host to check a points balance or redeem points against the card residual. See UOB Rewards overview for the full flow, including failures specific to redemption.

Trust boundaries

  • Secret keys never leave your server. Every browser-facing surface (Elements, Checkout) uses a publishable key, which can only create and bind sessions — never charge, capture, void, or refund.
  • Card tokens, not raw card numbers. Elements tokenizes the card in the browser; your server and RadiumOne’s transaction records only ever see a token, not the PAN.
  • Webhook payloads are signed. Verify X-RadiumOne-Signature against the raw request body before you trust anything in a webhook — see Verify webhook signatures.

Next steps

Core concepts

Transactions, sessions, idempotency, and the other ideas you’ll use in every request.

Charge or authorize a payment

Guides — start here to create your first purchase or authorization.

Webhooks

Set up your endpoint and verify signatures.

Security and PCI scope

PCI scope per integration path.
Last modified on September 15, 2026