Skip to main content
RadiumOne Checkout is a hosted payment page: your server creates a session, the shopper enters their card on a RadiumOne-hosted page, and RadiumOne charges the card in a single step. You never see or store raw card data.

​
Shopper experience

  1. The shopper clicks Pay on your site.
  2. Your server creates a checkout session and sends the shopper to RadiumOne Checkout — either by redirecting the full page, or by embedding it in an iframe on your own domain.
  3. The shopper enters their card details (and, where enabled, chooses an alternative method such as UOB Rewards points).
  4. RadiumOne charges the card immediately — hosted checkout is a one-step sale, not an authorize-then-capture flow. A successful payment is final (status: "completed") as soon as the charge clears.
  5. The shopper returns to your site (redirect mode) or your page reacts to an in-page event (embedded mode).

​
Redirect vs embedded

Redirect (default)

Create a session, redirect the full page to checkout_url. No extra setup. Best for the simplest integration and mobile web/webviews. Result signal: redirect to success_url/cancel_url, plus webhook.

Embedded

Create a session, render checkout_url in an <iframe> on your page (mode: "embed"). Requires registering your domain (allowed_domains) — without one, session create returns 422 embed:origins_not_configured. Keeps the shopper on your domain. Result signal: postMessage events, plus webhook.
Both modes end the same way: you confirm the payment result from your server (webhook or an authenticated status check), never from the redirect or the in-page event alone. See Verify the payment result. See Redirect vs embedded for a full architectural comparison of the two modes, including a diagram of how each structures the shopper’s browser, your page, and RadiumOne Checkout. If the payment gateway is briefly unreachable, nothing is charged and the shopper can retry — see Handle payment service outages during checkout.

​
Payment methods

The shopper sees whichever methods are configured for your account and outlet, filtered by currency and amount — there’s no field to choose methods at session-create time. Card payments are always available once your account is set up. If UOB Rewards is enabled for your account, it appears automatically as an additional method — see UOB Rewards.

​
PCI scope

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.

​
See a working example

See a working example

Clone an example cart that creates a session and redirects to hosted checkout — HTML/JS+Node and Next.js/TypeScript examples included. Your own integration should still confirm the result with signature verification server-side.

​
Next steps

Architecture

Where hosted checkout sits, and why your PCI scope stays minimal.

Redirect to hosted checkout

The simplest integration: create a session and redirect the shopper.

Handle failures

Ten common failure scenarios, grouped by when they happen.

Prevent duplicate payments

Guard against a shopper — or your own retry logic — paying twice.
Last modified on September 15, 2026