Personal Access Tokens Overview
A Personal Access Token (PAT) lets you call the Paysera API as yourself, without building an OAuth flow and without asking client support for MAC credentials. You create the token in your Paysera account, choose exactly what it may do, and then send it as a bearer token on every request.
When to use a Personal Access Token​
A Personal Access Token is the right choice when you are the account holder and you are the one running the code:
- personal scripts and automations against your own accounts
- an AI assistant or agent that reads your balance or prepares transfers on your behalf
- a one-off integration where a full OAuth 2.0 flow would be disproportionate
- quick experiments, before committing to a server-to-server integration
It is not a replacement for the other authentication methods:
| Method | Acts on behalf of | Credentials issued by | Typical use |
|---|---|---|---|
| Personal Access Token | You, the account holder | You, self-service | Your own scripts, tools, AI agents |
| MAC | Your integration | Paysera client support | Server-to-server integrations |
| SSL client certificate | Your integration | You, agreed with Paysera | Server-to-server integrations |
You issue this token yourself. You do not need to contact client support and you do not need to sign an integration agreement to create one — unlike the MAC and SSL client certificate credentials above.
What a token is​
A Personal Access Token is a JWT. When you create it, Paysera shows you the token string once —
copy it then, because it cannot be retrieved again. From that point on, the token is identified in
the interface and in the API by its jti (its token ID), never by its value.
Every token carries the limits you set when creating it. All of them are described in full on Token controls:
| Property | What it controls |
|---|---|
| Scopes | Which operations the token may perform — for example accounts:read, transfers:create |
| Accounts | Optionally, the accounts every scope on the token is restricted to |
| Expiry | When the token stops working — 30 days, 90 days, 1 year, a custom date up to 365 days ahead, or never |
| Allowed IPs | Optionally, the IP addresses or CIDR ranges the token may be used from — IPv6 ranges are not matched |
| Spending limits | Optionally, a per-transaction and a daily cap on transfers — set when you create the token |
The scopes, the account restriction, the expiry and the allowed IP addresses are checked on every request. The spending limits work differently: they are applied later, while the transfer is processed, so a transfer can be accepted and then fail — see How the limits are enforced.
A token can be suspended and later reactivated, or revoked permanently. None of the
properties above can be edited, so a token that no longer fits is replaced rather than adjusted.
The one exception is the spending limits: a token that carries transfers:create and has no limit
record yet can write that record once, which is why you should set the limits when you create the
token — see Spending limits.
What a token can reach​
A Personal Access Token works against a specific, deliberately small set of endpoints on
https://api.paysera.com — account balance and statements, the transfer lifecycle, and the token's
own spending limits. It does not grant general access to the Paysera API.
See Available endpoints for the endpoints and the scope each one requires — and for what a scope can reach beyond them.
Anyone holding the token string can act as you, within the token's scopes and limits. Treat it like a password: never commit it to a repository, never paste it into a chat or an issue tracker, and prefer a short expiry with the narrowest scope set that does the job.
Next steps​
- Create your first token and make a request
- Understand how the token is sent and validated
- Browse the endpoints a token can reach
- Restrict the token with expiry, IPs and spending limits
- Handle errors and rate limits
Support​
Need help? Contact: tech_support@paysera.com