Skip to main content
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.
RadiumOne’s two APIs authenticate differently — the Payments API exchanges your key for a short-lived access token, while the Checkout API takes your secret key directly on every request:

Key types

Sandbox and production use separate credentials, hosts and webhook endpoints — see Sandbox and API keys. See Sandbox and API keys for how to get keys for your account.

Payments API authentication

Every request to the Payments API (except the token exchange itself) uses a Bearer access token, not the API key directly:
1

Exchange your API key

POST /v1/auth/token with your API key. A secret-key exchange also returns a refresh token; a publishable-key exchange does not — publishable keys never receive a refresh token, so a stolen browser-side key can’t be used to mint long-lived credentials. If the exchange fails, see Fix rejected or expired access tokens.
2

Use the access token

Send it as Authorization: Bearer <access_token> on every subsequent request. It’s an opaque JWE string — treat it as an opaque bearer credential, never decode or inspect it.
3

Refresh before it expires

Access tokens are short-lived. Before expiry, call POST /v1/auth/token/refresh with your refresh token to get a new pair. Refresh tokens are single-use — each refresh rotates to a new one.
4

Revoke when you're done

POST /v1/auth/token/revoke invalidates a refresh token immediately. Idempotent — safe to call even if it’s already revoked or unknown.

Scopes and least-privilege keys

Scopes apply to Payments API access tokens only — the Checkout API checks only whether the key is a secret key, not a per-operation scope. Access tokens carry scopes inherited from the API key that created them. A secret key’s default scopes include every operation — transaction create/capture/void/refund and standalone (unreferenced) refund — unless you request a narrower key. Because standalone refunds move money with very little to check them against, request a key scoped to only the operations your integration actually needs, and keep a separate, more narrowly-scoped key for anything high-risk. See Security and PCI scope for the full key-safety checklist (storage, rotation, emergency revocation, monitoring). A publishable key’s default scopes are limited to creating and binding a tokenization session — it cannot create a transaction.

Outlet-bound keys

A key can be bound to a specific outlet. Omitting outlet_id on a request uses the key’s bound outlet (or your default outlet); requesting a different outlet than the key is bound to is rejected with 403 urn:radiumone:auth:outlet-binding-violation on the Payments API, or 422 on the Checkout API — see Checkout API errors. This applies to both APIs.

Checkout API authentication

Checkout API requests (create, retrieve, and cancel a hosted-checkout session) don’t use the token exchange above. Instead, send your secret key directly on every request as an X-Api-Key header — the same secret key you use for the Payments API, from Sandbox and API keys.
1

Send your secret key on every request

No exchange step — the secret key itself authenticates each call. A publishable key is rejected: the Checkout API’s create/cancel operations require a secret key.
2

Keep it server-side

Same rule as above — the Checkout API’s X-Api-Key is your secret key, so create, retrieve, and cancel calls must all originate from your server, never the shopper’s browser. See Verify the payment result for how your server confirms an outcome with an authenticated GET.

Auth failures

A missing, malformed, unrecognized, or wrong-type X-Api-Key is rejected before your request body is even validated. See Checkout API errors — Authentication and authorization for the full catalog — missing/malformed/unrecognized key, a publishable key used where a secret key is required, the domain allow-list, and the outlet-binding case — each with its exact code, HTTP status, and what to do.
Last modified on September 15, 2026