Skip to main content
Work through All integrations below, then the checklist for your integration row, then High-risk operations if it applies to you — before you request production keys. Every item links back to the guide that covers it in full.

​
All integrations

  • You’ve run the relevant scenarios in Test your integration, including idempotent replay, body mismatch, and timeout recovery.
  • Every create-type request path retries a timeout, 5xx, or PENDING result with the same idempotency key — never a new one.
  • Your code branches only on status (never on the HTTP status code alone, never on response_code) — see Problem format and retries.
  • You confirm the payment result server-side — a status inquiry or a verified webhook — before fulfilling an order. Never from a client redirect or the browser alone.
  • If you refund payments, you’ve requested enablement for the acquirer channel(s) you refund through — unlike most gateways, refunds are disabled by default on RadiumOne. See Refunds require enablement.
  • You’ve swapped every _test_ key and sandbox host for its _prod_ / production equivalent — see Moving to production.
  • Your webhook signature check passes a known-answer test before you point it at a live endpoint — see Verify webhook signatures.
  • Your webhook handler dedupes on event id and doesn’t assume delivery order — see Retries, ordering and duplicates.
  • You handle the failure scenarios in Handle Payments API failures.

​
Duplicate payments

  • You persist request_id (or operation_id) to your database before sending the first request, and reuse that same key on every retry of the same order attempt — never a new one just because a call was slow.
  • You generate one order_reference per checkout session attempt, and store the resulting transaction_id in your own order record — not the order_reference itself.
  • You check your own order state before creating a new checkout session — order_reference only dedupes within the session’s TTL; after it expires, a retry creates a new session even for an already-paid order.
  • Your Elements integration disables the Pay button while a submission is in flight — the SDK’s submit throttle isn’t a substitute for this.
  • Your webhook handler dedupes on the event id before crediting or fulfilling anything a second time.
  • You’ve read Prevent duplicate payments and know which of the checks above apply to your integration.
  • Redirect to hosted checkout works end-to-end in sandbox with approval, decline, and timeout test cards.
  • Embedded mode only: your postMessage handler covers every CHECKOUT_* event you rely on, and doesn’t wait for CHECKOUT_CANCELLED (never emitted) — see Embed hosted checkout.
  • Fail-closed redirect verification: if you’ve configured a redirect secret, your return-page handler treats a missing or invalid sig as unverified — never as proof of payment — see Verify the payment result.
  • Your return pages send Referrer-Policy: no-referrer (or stricter) so redirect query params aren’t leaked to third-party resources.
  • Your production success_url/cancel_url domains are registered in allowed_domains .
  • You handle the failure scenarios in Handle hosted checkout failures.
  • Install and load Elements using the npm loader (with SRI where applicable), not an unpinned CDN <script> tag.
  • Accept a card payment works end-to-end in sandbox with approval and decline test cards.
  • Your Content Security Policy matches Content Security Policy, rolled out report-only first before you enforce it.
  • You handle ElementsError from submit() by showing customerMessage and checking retryAllowed — never the raw message.
  • You handle the failure scenarios in Handle Elements failures.
  • 3DS with Elements works end-to-end in sandbox with frictionless, challenge, and not-authenticated test cards.
  • Your server independently verifies the three_ds ref at charge time and never branches on the client-reported status alone — see 3D Secure overview: server policy.
  • Challenge return pages send Referrer-Policy: no-referrer, matching Challenge presentation and redirects.
  • Your CSP allows the 3DS challenge iframe/redirect hosts, including your API origin in connect-src, scoped to checkout/return routes only.
  • You’ve requested enablement for RadiumOne 3D Secure on this account before testing this row.
  • You’ve requested enablement for this outlet — the gateway rejects three_ds evidence for outlets that aren’t enabled.
  • Use your own 3DS provider works end-to-end in sandbox, including the case where your provider is unreachable.
  • Your PCI scope assessment accounts for your 3DS provider handling card data outside Elements .
  • Your server still independently verifies the evidence the gateway accepted — never trust your own provider’s client-side result alone.

​
High-risk operations

Only applies if you use standalone refunds.
This is a high-risk operation. Follow these practices:
  • Least privilege: request a secret key scoped to only the operations it needs, not a key with every scope.
  • Key storage: store secret keys in a server-side secrets manager, never in client code, source control, or logs.
  • Emergency revocation: if a key is compromised, rotate or revoke it immediately — see Emergency key revocation.
  • Monitoring: monitor refunds and settlements for unexpected activity and alert on anomalies.
  • The key used for standalone refunds is scoped to only that operation — not a general-purpose key.
  • Secret keys live in a server-side secrets manager, never in client code, source control, or logs.
  • Only the specific server-side service that needs it can call the standalone-refund endpoint.
  • You monitor refund and settlement volume for anomalies and alert on unexpected spikes.
  • You know who to contact for emergency key revocation if a key leaks .
  • You’ve run a rotation drill — rotating a key end-to-end with no downtime — at least once before go-live.

​
Next steps

Test your integration

Run every scenario in this checklist first.

Security and PCI scope

Full key-safety and PCI guidance.

Frequently asked questions

Quick answers on keys, refunds, duplicates, and hosted checkout.
Last modified on September 15, 2026