Skip to main content
Every request to the TagPay API (except merchant registration) requires a valid access token. This page explains how to get a token, how to use it, when it expires, and how to handle expiry gracefully.

Get an access token

Call POST /auth/login with your merchant account email and password. The API returns tokens in response headers, not in the response body.
The email and password values must be Base64-encoded before sending. The server decodes them server-side before validation. Example: Buffer.from("[email protected]").toString("base64") in Node.js, or echo -n "[email protected]" | base64 in bash.

Request

string
required
Your merchant account email address, Base64-encoded.
string
required
Your account password (minimum 6 characters), Base64-encoded.
object
Optional device context for audit logging. Useful for identifying sessions.

Response

The access and refresh tokens are in the response headers. Response body
If your account has not been verified, the login response will include "requiresVerification": true and the API will send a new verification code to your email. Verify your account using PUT /merchant/verify before attempting to log in again.

Authenticate requests

Include the access token in the Authorization header on every request:

Refresh your token

Access tokens expire. When a request returns 401 Unauthorized, use your refresh token to obtain a new token pair without asking the user to log in again.
Pass the refresh token in the X-Refresh-Token request header (not in the body).
The API rotates the token pair on every refresh. Store the new X-Access-Token and X-Refresh-Token from the response headers and discard the old ones. Response headers (on success)
Each refresh token can only be used once. Once you call /auth/refresh/token, the previous token pair is invalidated. If your refresh token is expired or invalid, the user must log in again.

Automatic token refresh in Node.js

Access keys (for webhook signing)

In addition to your access token, TagPay gives you a public key and private key for your merchant account. These are used to sign and verify webhook payloads — they are not used for API authentication.

Get your access keys

Response
Your private key is sensitive. Do not expose it in client-side code or commit it to version control. Store it as an environment variable or in a secrets manager.

Rotate your access keys

If your private key is compromised, generate a new key pair immediately. The old key pair is invalidated as soon as you generate new ones.
Response

Common authentication errors

Always check for a 401 response in your HTTP client and implement automatic token refresh. Users should never see an authentication error if your refresh logic is in place.