Where it sits
Components
- Your website — runs in the shopper’s browser; sends the shopper to RadiumOne Checkout and reacts to the return.
- Your server — holds your secret key and your webhook endpoint; the only part of your stack that talks to RadiumOne directly.
- RadiumOne Checkout — the hosted payment page plus the Checkout API, where the shopper enters their card.
- Payments API — the gateway that actually charges the card once RadiumOne Checkout submits it.
- Card networks & issuer — resolve the authorization request.
Data flows
The letters match the flow tags in the diagram.PCI scope: card data never reaches you
With hosted checkout, the shopper enters their card details on a RadiumOne-hosted page. Your server and website never see or handle raw card data, which keeps your PCI DSS scope minimal. The card fields render inside RadiumOne Checkout, and the browser sends the card data straight to RadiumOne — it’s never proxied through your server, and your website’s own code never touches it either. That’s what keeps card entry outside your systems entirely, and it’s the main architectural difference from Elements, where card fields render on your page (still tokenized in the browser, never touching your server).Trust boundaries
Three mechanisms keep the pieces above honest about who can claim a payment succeeded:1
The redirect is a hint, never proof
A redirect back to your
success_url (or a postMessage event in embedded mode) can carry a sig — an HMAC over the outcome, signed with your redirect secret. Even signed, treat it as a UI signal: confirm the actual result with an authenticated request or a webhook before you fulfil anything. See Verify the payment result for the signature format and the full decision table.2
Webhooks are the source of truth
RadiumOne delivers
payment.* webhook events for every terminal outcome, signed and retried on your behalf. Your server should treat a verified webhook (or an authenticated GET on the session) as the only basis for shipping an order — see Webhooks.3
Your secret key never leaves your server
Session creation is the one call your server makes directly to RadiumOne, authenticated with your secret key.
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.Next steps
Redirect vs embedded
Compare the two integration modes and how to choose between them.
Redirect to hosted checkout
Build the simplest integration: create a session and redirect the shopper.
Embed hosted checkout
Keep the shopper on your domain with an iframe.
Verify the payment result
The signature format and the server-side confirmation decision table.