Skip to main content
TL;DR — Short answers below, each linking to the full guide. If your question isn’t here, contact support.

​
Getting started and choosing an integration

Hosted checkout sends the shopper to a RadiumOne-hosted payment page, so you never handle card data at all. Elements renders secure card fields on your own page, so you keep full control of the checkout UI while RadiumOne tokenizes the card. See Choose your integration.
Yes. Both call the same Payments API and emit the same webhook events, so your backend logic for capturing, refunding, and reconciling doesn’t change. See Can I switch later?.
No. Hosted checkout needs no payment UI at all — you create a session and redirect the shopper to a RadiumOne-hosted page. See Hosted checkout overview.
3D Secure is live with Elements + the Payments API, Beta with hosted checkout, and available Beta (and gated) if you bring your own 3DS provider through Elements. See 3D Secure overview.

​
Accounts, keys and environments

Contact support with your account details — self-service key provisioning isn’t available yet. See Getting keys.
A secret key (r1sk_…) is server-only and can create and manage transactions. A publishable key (r1pk_…) is browser-safe and can only create or bind a session — never a payment. See Key types.
Yes — different hosts, different keys, no shared state. A _test_ key only ever works against sandbox, and a _prod_ key only against production. See Environments and hosts.
A new secret key is issued with every scope enabled by default. But a scope alone isn’t the gate — the acquirer channel and terminal your outlet routes through must also have that operation enabled, so holding a scope doesn’t guarantee you can use it. See Least-privilege keys.
Yes. Omitting outlet_id on a request uses the key’s bound outlet; sending an outlet_id the key isn’t bound to fails with a 403. See Outlet-scoped keys.

​
Payments and refunds

Purchase charges a card in one step. Authorize reserves funds without taking them, so you can capture a (possibly different, smaller) amount once you’re ready to fulfil. See Purchase vs. authorize.
No — capture is all-or-nothing and must equal the authorized amount exactly. To charge less, capture in full and refund the difference once the batch closes, or void the authorization and create a new one. See Full-capture rule.
Your account’s capture window, which defaults to 7 days from authorization and can be configured shorter or longer per acquirer. See The capture window.
Void cancels an authorization or capture before its settlement batch closes, so no funds ever move. Refund returns money after the batch has closed — you can never do both to the same transaction. See Void or refund, never both.
No — unlike most gateways, refunds are disabled by default on RadiumOne. The acquirer channel your outlet routes through needs the REFUND operation explicitly enabled before a referenced or standalone refund succeeds. See Refunds require enablement.
Yes. Send any amount up to the original transaction’s amount minus refunds already issued, and you can refund the same transaction multiple times as long as the running total never exceeds the original. See Partial and multiple refunds.
A standalone (open) refund credits a card with no original RadiumOne transaction to bound the amount or confirm the card — a high-risk escape hatch for a legacy order or a goodwill credit, not the normal refund path. See Standalone refunds.
Card and UOB Rewards points redemption are both live everywhere — hosted checkout and Elements + the Payments API. Instalments, digital wallets, and in-store (POS) payments are coming soon. See Supported payment methods.

​
Duplicates, timeouts and reliability

Never mint a new request_id — resend the identical body with the same request_id, or wait for the confirming webhook; RadiumOne replays the stored result whatever it turned out to be. See Retry safely after a timeout.
RadiumOne rejects it with a 409 body-mismatch error instead of creating a new transaction or applying your change — resend the stored original body, or mint a genuinely new key for a new attempt. See How RadiumOne reacts to a repeated request.
Only within a checkout session’s TTL. RadiumOne never enforces order_reference uniqueness at the gateway, so you must check your own order record before creating a new session or retrying a payment. See The defence layers.
Webhooks. A synchronous response can be PENDING or time out entirely, so treat webhooks — deduped on the event id — as authoritative for reconciliation, not just a convenience notification. See Webhooks are the source of truth.
Call the live status-inquiry endpoint with a transaction id you already have — it asks the acquirer directly and writes nothing. See Check a transaction’s status.

​
Hosted checkout

Default to redirect — it needs no domain registration or CSP changes and behaves consistently across browsers and in-app WebViews. Embedded keeps the shopper visually on your domain but needs your embedding domain registered in allowed_domains first. See Redirect vs embedded.
Yes, once you’ve registered at least one domain in allowed_domains — session create returns 422 embed:origins_not_configured if none is configured. See Embed hosted checkout.
Set ttl_minutes explicitly (5–60); if you omit it, the session uses your environment’s default — 10 minutes in production, 25 in sandbox. See Expiry (TTL).
Confirm from your server with a webhook or an authenticated GET request — never from the redirect query string or a postMessage event alone. See Verify the payment result.
Yes, from your server, while the session is still pending. Cancelling a session that’s already processing or reached a terminal state returns a 409. See Merchant cancellation.
The session simply stays pending until it expires — closing the tab or clicking back doesn’t cancel it. Call the cancel endpoint yourself if you need it cancelled sooner. See Merchant cancellation.

​
Elements SDK

Yes — card fields render in sandboxed, RadiumOne-hosted iframes, so your JavaScript never sees the raw card number, expiry, or CVV. See PCI DSS scope by integration path.
Chrome, Firefox, and Edge from version 90, and Safari from 14 (15.4+ for split card fields). Elements requires a secure (HTTPS) context and the Web Crypto API. See Browser support.
Yes — 3D Secure with Elements is live, not Beta. See 3DS with Elements.
Card fields alone need a narrow policy with no connect-src. Adding 3D Secure needs your API origin in connect-src, scoped to your checkout and 3DS-return routes only. See Content Security Policy.

​
Webhooks

Check the X-RadiumOne-Signature header against the raw request body with HMAC-SHA256 and a constant-time comparison, before you trust anything in the payload. See Verify webhook signatures.
No — delivery is at-least-once and unordered by design. Dedupe on the event id, and use created_at (or a fresh status read) if you need the true sequence. See Retries, ordering, and duplicates.
RadiumOne retries for about 29.6 hours across 8 attempts by default. An endpoint with sustained, unfixable failures (bad DNS/TLS, a 410) can be suspended and receives nothing until support reactivates it. See Endpoint suspension.

​
Testing and going live

No — always use the published test cards. Sandbox tokenizes and processes them exactly the way production does, without touching a real card issuer. See Test your integration.
Work through the go-live checklist — idempotent retry handling, server-side result verification, a webhook signature check that passes a known-answer test, and refund enablement if you refund. See Go-live checklist.

​
Security and compliance

Store secret keys only in a server-side secrets manager, request least-privilege scopes, rotate on a regular schedule, and contact support immediately for emergency revocation if a key leaks. See Key safety.
No. The webhook signing key is the raw bytes from hex-decoding the string after stripping whsec_; the redirect signature’s key is the full rsec_… string used directly. Using the wrong encoding makes every signature fail to verify. See Verify webhook signatures.

​
Support and versioning

Reach out through your onboarding contact or account representative — the enablement table lists exactly what to ask for, from refunds to UOB Rewards to narrowed key scopes. See Request enablement.
The Payments API and Checkout API are versioned in the URL path (/v1/...), with additive-only changes shipping inside a version. The Elements SDK follows semantic versioning — pin to a specific version rather than always loading latest. See Versioning and deprecation.
Last modified on September 15, 2026