Skip to main content
Every RadiumOne integration starts with a sandbox account and a pair of API keys. This page covers both environments, the key types you’ll use, and how to keep your keys safe.

​
Environments and hosts

Sandbox and production use separate credentials, hosts and webhook endpoints — see Sandbox and API keys. The Elements SDK CDN adds one more host per environment: sandbox at https://js-sandbox.radiumone.io, production at https://js.radiumone.io.

​
Sandbox behaviour and limits

Sandbox behaves like production — the same API shapes, statuses, and error codes — but no real money moves and no real card issuer is involved. Use test cards from Test your integration rather than real card numbers; sandbox tokenizes and processes them the same way production does, so there’s no separate “mock” token format to learn.
Sandbox is also the place to test your retry logic. Before you write integration code, read Prevent duplicate payments so your request_id/order_reference handling is safe from the start.

​
Key types

The environment a key belongs to is determined entirely by its prefix — a _test_ key never works against production, and vice versa.

​
Getting keys

The exact self-service flow for provisioning keys, webhook endpoints, redirect secrets, and allowed redirect domains is still being finalized. Until then, contact support to request sandbox and production keys for your account, including how many keys you can hold at once.

​
Least-privilege keys

Secret keys can carry any of RadiumOne’s API scopes (payment creation, capture, void, referenced and standalone refunds, session management, and more). By default a new secret key is issued with every scope enabled — but having the refund scope isn’t the same as being able to refund: the acquirer channel itself must also have the REFUND operation enabled, which isn’t on by default. See Refunds require enablement.
When you request a secret key, ask for only the scopes your integration actually needs. In particular, leave out the standalone-refund scope unless you use that operation — it’s high-risk and covered separately in Standalone refunds.
Publishable keys are always scoped to session creation only — they can never create, capture, void, or refund a payment directly, which is why it’s safe to expose them in browser code.

​
Outlet-scoped keys

A key can be bound to a specific outlet (store/location). If you omit outlet_id on a request, RadiumOne uses the key’s bound outlet by default. Sending an outlet_id that doesn’t match the key’s binding fails with a 403 error; every response echoes back the outlet the request was actually resolved against.

​
Key safety

Never use a secret key (r1sk_…) in browser code, mobile apps, or anywhere a shopper can inspect it. Secret keys belong on your server only.
Rotating or revoking a secret or publishable key, and emergency revocation if a key leaks, both go through Support today. Access tokens and refresh tokens are yours to manage directly — see the next section.

​
Exchange a secret key for an access token

Payments API requests are authenticated with a short-lived access token, not the secret key itself — exchange your secret key once, cache the token for up to its expires_in (300 seconds), and refresh it before it lapses.

Authentication

The full token exchange, refresh, and revoke flow, including sample requests.

​
Moving to production

  1. Request production keys (see Getting keys above).
  2. Swap every _test_ key for its _prod_ equivalent.
  3. Point your integration at the production hosts instead of the sandbox hosts.
  4. Update your webhook endpoint and redirect secret for the production environment.
  5. Work through the go-live checklist before you accept real payments.

​
Next steps

Quickstart

Accept your first sandbox payment with the keys you just requested.

Authentication

Full reference for the token, refresh, and revoke endpoints.

Security and PCI scope

Key storage, rotation, and monitoring guidance.

Support

Request keys, enablement, or emergency key revocation.
Last modified on September 15, 2026