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

# FAQ - Resources

> Quick answers to common RadiumOne integration questions: keys and environments, payments and refunds, duplicates, webhooks, testing, and security.

<Info>
  **TL;DR** — Short answers below, each linking to the full guide. If your question isn't here, [contact support](/resources/support).
</Info>

## Getting started and choosing an integration

<AccordionGroup>
  <a id="hosted-checkout-vs-elements" />

  <Accordion title="What's the difference between hosted checkout and Elements?">
    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](/get-started/choose-your-integration).
  </Accordion>

  <a id="switch-integrations-later" />

  <Accordion title="Can I switch between hosted checkout and Elements later?">
    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?](/get-started/choose-your-integration#can-i-switch-later).
  </Accordion>

  <a id="build-my-own-payment-page" />

  <Accordion title="Do I need to build my own payment page?">
    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](/hosted-checkout/overview).
  </Accordion>

  <a id="which-paths-support-3ds" />

  <Accordion title="Which integration paths support 3D Secure?">
    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](/get-started/three-d-secure).
  </Accordion>
</AccordionGroup>

## Accounts, keys and environments

<AccordionGroup>
  <a id="get-sandbox-and-production-keys" />

  <Accordion title="How do I get sandbox and production API keys?">
    Contact support with your account details — self-service key provisioning isn't available yet. See [Getting keys](/get-started/sandbox-and-api-keys#getting-keys).
  </Accordion>

  <a id="secret-vs-publishable-key" />

  <Accordion title="What's the difference between a secret key and a publishable key?">
    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](/get-started/sandbox-and-api-keys#key-types).
  </Accordion>

  <a id="sandbox-vs-production-separation" />

  <Accordion title="Are sandbox and production completely separate?">
    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](/get-started/sandbox-and-api-keys#environments-and-hosts).
  </Accordion>

  <a id="default-scopes-and-enablement" />

  <Accordion title="What scopes does a secret key have by default, and is a scope enough to perform an operation?">
    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](/get-started/sandbox-and-api-keys#least-privilege-keys).
  </Accordion>

  <a id="outlet-bound-keys" />

  <Accordion title="Can a key be bound to a specific store or outlet?">
    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](/get-started/sandbox-and-api-keys#outlet-scoped-keys).
  </Accordion>
</AccordionGroup>

## Payments and refunds

<AccordionGroup>
  <a id="purchase-vs-authorize-vs-capture" />

  <Accordion title="What's the difference between purchase, authorize, and capture?">
    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](/payments-api/charge-or-authorize#purchase-vs-authorize).
  </Accordion>

  <a id="partial-capture" />

  <Accordion title="Can I capture only part of an authorization?">
    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](/payments-api/capture#full-capture-rule).
  </Accordion>

  <a id="capture-window-length" />

  <Accordion title="How long do I have to capture an authorization?">
    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](/payments-api/capture#the-capture-window).
  </Accordion>

  <a id="void-vs-refund" />

  <Accordion title="What's the difference between void and refund?">
    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](/payments-api/void#void-or-refund-never-both).
  </Accordion>

  <a id="refunds-disabled-by-default" />

  <Accordion title="Are refunds enabled by default?">
    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](/payments-api/refund#refunds-require-enablement).
  </Accordion>

  <a id="partial-and-multiple-refunds" />

  <Accordion title="Can I issue a partial refund, or refund a payment more than once?">
    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](/payments-api/refund#partial-and-multiple-refunds).
  </Accordion>

  <a id="standalone-refunds" />

  <Accordion title="What's a standalone refund, and when should I use it?">
    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](/payments-api/standalone-refunds).
  </Accordion>

  <a id="supported-payment-methods" />

  <Accordion title="Which payment methods does RadiumOne support today?">
    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](/payments-api/payment-methods/overview).
  </Accordion>
</AccordionGroup>

## Duplicates, timeouts and reliability

<AccordionGroup>
  <a id="what-to-do-after-a-timeout" />

  <Accordion title="What should I do if a payment request times out?">
    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](/get-started/api-basics/prevent-duplicate-payments#retry-safely-after-a-timeout).
  </Accordion>

  <a id="reused-request-id-different-body" />

  <Accordion title="What happens if I reuse a request_id with a different body?">
    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](/get-started/api-basics/prevent-duplicate-payments#how-radiumone-reacts-to-a-repeated-request).
  </Accordion>

  <a id="order-reference-not-durable" />

  <Accordion title="Is order_reference a reliable way to prevent duplicate orders?">
    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](/get-started/api-basics/prevent-duplicate-payments#the-defence-layers).
  </Accordion>

  <a id="webhooks-source-of-truth" />

  <Accordion title="Are webhooks or the synchronous API response the source of truth?">
    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](/payments-api/core-concepts#9-webhooks-are-the-source-of-truth).
  </Accordion>

  <a id="check-transaction-status-directly" />

  <Accordion title="How do I check a transaction's status directly instead of guessing?">
    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](/payments-api/check-transaction-status).
  </Accordion>
</AccordionGroup>

## Hosted checkout

<AccordionGroup>
  <a id="redirect-vs-embedded-choice" />

  <Accordion title="Should I use redirect or embedded 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](/hosted-checkout/redirect-vs-embedded).
  </Accordion>

  <a id="embedded-checkout-availability" />

  <Accordion title="Is embedded hosted checkout available today?">
    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](/hosted-checkout/embedded-integration).
  </Accordion>

  <a id="checkout-session-length" />

  <Accordion title="How long does a checkout session last?">
    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)](/hosted-checkout/session-lifecycle#expiry-ttl).
  </Accordion>

  <a id="verify-hosted-checkout-result" />

  <Accordion title="How do I verify a hosted checkout payment result?">
    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](/hosted-checkout/verify-payment-result).
  </Accordion>

  <a id="cancel-a-checkout-session" />

  <Accordion title="Can I cancel a checkout session?">
    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](/hosted-checkout/session-lifecycle#merchant-cancellation).
  </Accordion>

  <a id="shopper-never-returns" />

  <Accordion title="What if the shopper closes the tab instead of completing checkout?">
    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](/hosted-checkout/session-lifecycle#merchant-cancellation).
  </Accordion>
</AccordionGroup>

## Elements SDK

<AccordionGroup>
  <a id="elements-pci-scope" />

  <Accordion title="Does Elements reduce my PCI scope?">
    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](/resources/security-and-pci#pci-dss-scope-by-integration-path).
  </Accordion>

  <a id="elements-browser-support" />

  <Accordion title="Which browsers does Elements support?">
    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](/elements/overview#browser-support).
  </Accordion>

  <a id="3ds-with-elements-live" />

  <Accordion title="Is 3D Secure available with Elements?">
    Yes — 3D Secure with Elements is live, not Beta. See [3DS with Elements](/elements/three-d-secure/add-three-d-secure).
  </Accordion>

  <a id="elements-csp-requirements" />

  <Accordion title="What Content Security Policy does Elements need?">
    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](/elements/content-security-policy).
  </Accordion>
</AccordionGroup>

## Webhooks

<AccordionGroup>
  <a id="verify-webhook-signature" />

  <Accordion title="How do I verify a webhook signature?">
    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](/payments-api/webhooks/verify-signatures).
  </Accordion>

  <a id="webhook-delivery-ordering" />

  <Accordion title="Are webhook deliveries ordered and exactly-once?">
    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](/payments-api/webhooks/retries-and-ordering).
  </Accordion>

  <a id="webhook-endpoint-down" />

  <Accordion title="What happens if my webhook endpoint is down or broken?">
    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](/payments-api/webhooks/retries-and-ordering#endpoint-suspension).
  </Accordion>
</AccordionGroup>

## Testing and going live

<AccordionGroup>
  <a id="real-cards-in-sandbox" />

  <Accordion title="Can I use real card numbers in sandbox?">
    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](/resources/test-your-integration).
  </Accordion>

  <a id="before-production-access" />

  <Accordion title="What should I check before requesting production access?">
    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](/resources/go-live-checklist).
  </Accordion>
</AccordionGroup>

## Security and compliance

<AccordionGroup>
  <a id="key-safety-practices" />

  <Accordion title="How do I keep my API keys safe?">
    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](/resources/security-and-pci#key-safety).
  </Accordion>

  <a id="webhook-vs-redirect-signature-keys" />

  <Accordion title="Do the webhook signature and the redirect signature use the same key encoding?">
    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](/payments-api/webhooks/verify-signatures#algorithm).
  </Accordion>
</AccordionGroup>

## Support and versioning

<AccordionGroup>
  <a id="contact-support-or-enablement" />

  <Accordion title="How do I contact support or request a gated feature?">
    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](/resources/support#request-enablement).
  </Accordion>

  <a id="api-and-sdk-versioning" />

  <Accordion title="How does RadiumOne version its APIs and SDKs?">
    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](/resources/versioning).
  </Accordion>
</AccordionGroup>