Getting started

Authentication

QRPay authenticates in two layers. Your long-lived API keys never travel on payment requests — they’re only used once per session, to mint a short-lived access token:

Exchange keys for a token. Send your Client/Primary key(client_id) and Secret key(secret_id) to {{base_url}}/authentication/token. You get back an access_token that expires after 600 seconds — full details on the Access token page.
Send it as a Bearer header. Every API call after that carries Authorization: Bearer {{access_token}}(see the code rail). An expired or malformed token returns 403 · Requested with invalid token! — request a fresh token per payment session rather than caching one long-term.

Where your keys live

Client/Primary keyclient_idIdentifies your merchant account when requesting a token.

Secret keysecret_idProves the request is really yours. Treat it like a password — anyone holding it can create payments as you.

Keys are created in SANDBOX mode and can be switched to PRODUCTION in the same panel — the base URL never changes, only the key’s mode (see Environments & base URL).

Keeping keys safe

Server-side only. Request tokens and create payments from your backend. Never embed the Secret key in browser JavaScript, mobile app code or anything else you ship to users.
Out of source control. Load keys from environment variables or a secrets manager (see the code rail) — never commit them.
Rotate when in doubt. If a key may have leaked, delete it in the merchant panel and generate a new pair, then update your configuration.

No merchant account yet?

Authenticated request HTTP headers

POST {{base_url}}/payment/create

Authorization: Bearer {{access_token}}
accept: application/json
content-type: application/json

Key storage .env

# Keep keys out of source control —
# load them from the environment.

QRPAY_CLIENT_ID=tRCDXCuztQzRYThPwlh1KXAYm4bG3rwW...
QRPAY_SECRET_ID=oZouVmqHCbyg6ad7iMnrwq3d8wy9Kr4b...