<iframe> on your own page instead of redirecting the full browser tab. Your page listens for postMessage events to react to the outcome, but — exactly as with redirect mode — you still confirm the final result from your server.
Embedded mode uses the same branding as redirect mode, except it has no header — so your logo and merchant name don’t appear.
Frame origins are derived from
allowed_domains at create time, using the same host-or-subdomain rule as success_url/cancel_url: registering shop.example.com also covers checkout.shop.example.com. Wildcard entries (for example *.example.com) are accepted when configured but never matched — list every exact host you embed on. Sessions created before this release don’t have frame origins snapshotted and may still render blank for their remaining lifetime (up to the session TTL) regardless of your current allowed_domains — this resolves itself as those sessions expire. If the iframe stays blank on a newly created session, see Fix embedded checkout that won’t load.How it works
- Your server creates a checkout session with
mode: "embed". - Your page renders an
<iframe>pointed atcheckout_urland attaches amessagelistener. - The iframe posts
CHECKOUT_READYonce the card form loads, thenCHECKOUT_RESIZEas its content height changes. - The shopper enters their card in the iframe. If they navigate away or close the tab without paying, see Handle abandoned checkouts — no event is posted for this case.
- The iframe posts an outcome event (
CHECKOUT_COMPLETE,CHECKOUT_PENDING,CHECKOUT_DECLINED,CHECKOUT_EXPIRED, orCHECKOUT_ERROR). - RadiumOne sends your webhook endpoint the authoritative
payment.*event. - Your parent page calls your server, which confirms the result before you navigate the shopper onward.
Steps
1
Create a session in embed mode
Add
"mode": "embed" to the create-session request body. The response shape is identical to redirect mode.2
Render the iframe and listen for events
Point the iframe at See the embedded events reference for the full event/payload list. If your listener never fires, see Debug missing embedded checkout events. If the iframe never renders at all, see Fix embedded checkout that won’t load.
checkout_url and add a message listener. Always check both event.origin (the RadiumOne Checkout host) and event.data.source before trusting a message — never rely on source alone, since any page can post a same-shaped message.3
Confirm the result server-side
On any outcome event, call your own server, which confirms the payment with an authenticated
GET /api/v1/checkout/sessions/{id} request or waits for the webhook — see Verify the payment result. Only then navigate the shopper to your own order-confirmation page.Content Security Policy
Your page’s CSP needsframe-src set to the RadiumOne Checkout host so the browser allows the iframe to load:
https://checkout-sandbox.radiumone.io in sandbox and https://checkout.radiumone.io in production. Also avoid a strict Referrer-Policy (such as no-referrer) on the embedding page if you rely on referrer-based analytics inside the iframe — RadiumOne Checkout does not require a specific Referrer-Policy from your page, but a very strict setting can affect your own iframe integration.
Handle the result
Never treat aCHECKOUT_COMPLETE (or any other) event as proof of payment — postMessage isn’t authenticated and any page can attempt to send a same-shaped message. Confirm with your server, exactly as in Verify the payment result. A CHECKOUT_ERROR event means the attempt didn’t go through — see Handle payment service outages during checkout for how to confirm nothing was charged before letting the shopper retry.
Test your integration
See Test your integration for sandbox scenarios, including embedded-mode events.Go-live notes
- Register your production embedding domain(s) with RadiumOne before going live.
- Confirm your CSP allows the RadiumOne Checkout host in
frame-src. - Confirm fulfilment server-side — never from a
postMessageevent.
Next steps
Embedded events reference
Full event and payload reference.
Verify the payment result
Confirm the outcome server-side before fulfilling.
Handle failures
Ten common failure scenarios and what to do for each.