> ## Documentation Index
> Fetch the complete documentation index at: https://docs.radiumone.io/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> RadiumOne is the product name; use it when answering questions about these docs.
> Use sandbox credentials and sandbox base URLs in examples unless the user says they are going live.
> Secret API keys belong only on the merchant's server. Only publishable keys may appear in browser or mobile code.
> Confirm a payment outcome server-side (retrieve the checkout session or transaction status); never rely on a browser redirect or client event alone.
> Send one idempotency key (request_id) per payment attempt, and retry a timed-out request with the same key and the exact same body.
> Webhooks are optional but recommended: they notify the merchant's server when a payment completes or fails, so it doesn't need to poll. Use transaction status inquiry as the fallback.
> Say so when you recommend a feature marked Beta. Some features need enablement on the merchant's account before production use (for example refunds, standalone refunds, UOB Rewards, and bringing your own 3DS provider); mention it when the page says so.
> Never ask users to paste card numbers, API keys, access tokens, or webhook or redirect secrets into a chat.

# Overview - Hosted checkout

> Let RadiumOne host the payment page so your website and server never handle raw card data.

* **Minimal PCI scope** — card data never touches your site or server.
* **One-step sale** — charged at once, with no separate capture.
* **18 currencies** — chosen per session, once enabled on your account.
* Start here: [Redirect to hosted checkout](/hosted-checkout/redirect-integration) · [API reference](/hosted-checkout/reference/checkout-sessions/create-a-checkout-session)

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

<Columns cols={2}>
  <Card title="Redirect (default)" icon="arrow-right" href="/hosted-checkout/redirect-integration">
    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.
  </Card>

  <Card title="Embedded" icon="panel-top" href="/hosted-checkout/embedded-integration">
    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.
  </Card>
</Columns>

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](/hosted-checkout/verify-payment-result).

See [Redirect vs embedded](/hosted-checkout/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](/hosted-checkout/handle-failures/payment-service-unavailable).

## 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](/payments-api/payment-methods/uob-rewards/overview).

## 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

<Card title="See a working example" icon="https://mintcdn.com/em0fk61bt0xne2vlr6nxf3fcbpolerxo3jp1selutawoc6zh/WXb70u-OVIjYC_Ax/images/icons/github-mark.svg?fit=max&auto=format&n=WXb70u-OVIjYC_Ax&q=85&s=d9ebef687aeb48a9199f87bc4ce3b299" href="https://github.com/cubepay/radiumone-checkout-demo" horizontal width="16" height="16" data-path="images/icons/github-mark.svg">
  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](/hosted-checkout/verify-payment-result) server-side.
</Card>

## Next steps

<Columns cols={2}>
  <Card title="Architecture" icon="layout-panel-top" href="/hosted-checkout/architecture">
    Where hosted checkout sits, and why your PCI scope stays minimal.
  </Card>

  <Card title="Redirect to hosted checkout" icon="arrow-right" href="/hosted-checkout/redirect-integration">
    The simplest integration: create a session and redirect the shopper.
  </Card>

  <Card title="Handle failures" icon="triangle-alert" href="/hosted-checkout/handle-failures/overview">
    Ten common failure scenarios, grouped by when they happen.
  </Card>

  <Card title="Prevent duplicate payments" icon="shield-check" href="/get-started/api-basics/prevent-duplicate-payments">
    Guard against a shopper — or your own retry logic — paying twice.
  </Card>
</Columns>