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.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 aBearer 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. Omittingoutlet_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 anX-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-typeX-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.