Access token claim
How Access token claim works in Paycux, what it is for, and the smallest setup that gets it running.
Overview
Access token claim is part of the Paycux platform. This page explains what it does, when to reach for it, and the smallest working setup you can ship.
Everything below applies to both environments. Build and test in staging, then promote the same configuration to production without changing your code — only the API key and client ID differ.
Reading the claim from a session
Paycux issues a sealed session cookie alongside the access token. The cookie carries no user data of its own — it is an encrypted pointer that the SDK unseals on each request using your cookie password.
Access tokens are short-lived by design. Refresh them on the server, never in the browser, and treat a failed refresh as a signal to send the user back through sign-in.
Reading the claim from the access token directly
Access tokens are JWTs signed with a rotating key. Verify them against the JWKS endpoint for your client rather than a pinned public key, so rotation never causes an outage.
1https://api.paycux.com/sso/jwks/client_01M4KXD1PZXFWGWE9ZKPCQRAQ
Cache the key set and re-fetch on an unknown key ID. Reject any token whose issuer, audience or expiry does not match what you expect.
Keeping the token small
Keeping the token small applies specifically to Access token claim. It behaves the same in both environments, and the values it depends on are visible in the dashboard for the environment you have selected.
If the behaviour you see does not match this description, check which environment your API key belongs to before anything else — a staging key against production data is the most common cause.