Endpoints a Personal Access Token can reach

A Personal Access Token does not unlock the Paysera API as a whole. The API gateway routes a small, fixed set of paths to the token check, and a request to any other path with a bearer token never reaches a service that would accept it. The table below is that set.

Read it as the operations you are meant to use rather than as a hard security boundary. Two gateway routes are prefixes — every GET and every DELETE under /public/transfer/rest/v1/transfers/ goes through them — and inside the service a scope grants a permission, which can cover more operations than are published here. transfers:read, for example, also reaches a transfer's timeline and its signature information. So size the risk of a token from the scopes you granted it, not from the length of this table.

All of these are served from https://api.paysera.com.

Accounts

Method	Path	Scope	Purpose
GET	/public/account/rest/v1/accounts/{accountNumber}/full-balance	accounts:read	Balance per currency for one account
GET	/public/account/rest/v1/accounts/{accountNumber}/statements	statements:read	Statement entries for one account

accountNumber is a Paysera account number in the form EVP followed by digits, for example EVP1234567890.

Full balance

curl -sS "https://api.paysera.com/public/account/rest/v1/accounts/EVP1234567890/full-balance" \
  -H "Authorization: Bearer $PAYSERA_PAT"

The response reports every currency held on the account, splitting what you can spend now from what is held against pending operations:

{
  "account_number": "EVP1234567890",
  "balance": [
    {
      "currency": "EUR",
      "at_disposal": { "amount": "1250.00", "currency": "EUR" },
      "reserved": { "amount": "40.00", "currency": "EUR" }
    }
  ]
}

Statements

from is a required query parameter and is a Unix timestamp. Without it the request fails validation.

curl -sS -G "https://api.paysera.com/public/account/rest/v1/accounts/EVP1234567890/statements" \
  -H "Authorization: Bearer $PAYSERA_PAT" \
  -d "from=1700000000" \
  -d "to=1700086400" \
  -d "currency=EUR" \
  -d "limit=50"

Commonly used filters, in addition to from and to:

Parameter	Meaning
currency	Comma-separated currency codes (currencies also accepted as an array)
direction	Restrict to incoming or outgoing entries
party_name	Match the other party's name
text	Free-text match over the entry
amount	Match a specific amount
limit	Page size

The response is a standard Paysera list envelope — an items array plus a _metadata object carrying the paging information.

Transfers

Method	Path	Scope	Purpose
POST	/public/transfer/rest/v1/transfers	transfers:create	Create a transfer
GET	/public/transfer/rest/v1/transfers	transfers:read	Filter the transfer list
GET	/public/transfer/rest/v1/transfers/{id}	transfers:read	Read one transfer
PUT	/public/transfer/rest/v1/transfers/{id}/register	transfers:create	Register a created transfer
DELETE	/public/transfer/rest/v1/transfers/{id}	transfers:cancel	Cancel a transfer

Request and response bodies live in the Transfer API reference

These are the Transfer API's own operations, reached with a different credential. The fields you send and receive are documented once, in the reference: Create transfer · Get transfers · Get transfer · Register transfer · Revoke transfer.

Different base URL from the reference pages

The Transfer API reference documents the MAC-authenticated host, https://wallet.paysera.com/transfer/rest/v1. With a Personal Access Token the same operations are called on https://api.paysera.com/public/transfer/rest/v1. The resource paths and payloads match; only the host and the /public prefix differ.

Minimal example — the point of interest is the header, not the body:

curl -sS -X POST "https://api.paysera.com/public/transfer/rest/v1/transfers" \
  -H "Authorization: Bearer $PAYSERA_PAT" \
  -H "Content-Type: application/json" \
  -d '{ ... transfer fields, see the Transfer API reference ... }'

Creating a transfer does not move money, and neither does registering it. A transfer is executed only once it is signed, and a Personal Access Token cannot sign one — there is no scope for it. Use a token to prepare and track transfers; completing them stays outside this credential.

Token spending limits

Method	Path	Scope	Purpose
POST	/public/rest/v1/token-spending-limits	transfers:create	Set spending limits for a token
GET	/public/rest/v1/token-spending-limits/{jti}	transfers:create	Read a token's spending limits

These two are the only endpoints in this list that are about the token rather than about your money. The GET takes the token's jti — its token ID — as a path parameter; the POST identifies the token by the bearer token in the Authorization header. A limit is always written by the token it applies to.

Normally you never call these yourself: the limits are fields in the token creation form, and the interface calls the POST for you with the token it has just created. The endpoints are public so that it can — and so that you can call the POST yourself, with a token you already hold, when the form's own attempt was refused. Creating the token still needs a signed-in session, and no Personal Access Token can do it.

Write once, no update, no delete

There is no PUT, PATCH or DELETE for a spending limit. A second POST for the same token returns 409 Conflict, so a limit can never be changed — only replaced by revoking the token. See Token controls for the bodies, the minor-unit amounts and how the limits are enforced.

What is not available

• Token management. Creating, listing, suspending and revoking tokens happens in your Paysera account, not through this API. See Getting started.
• Everything else. The Wallet, Checkout, Delivery, Open Banking, Recurring Billing and LightSMS APIs do not accept the token described in this guide. Use the authentication method documented in their own guide.

The POS API uses a token of the same name

POS API authentication calls its credential a Personal Access Token too. It is a different credential from a different system — issued in the POS application at pos.paysera.com/user/settings, sent to pos.paysera.com, and carrying its own permissions over orders, invoices, products and carts. Neither token works in the other's place. This guide covers the token you issue at bank.paysera.com/en/personal-access-tokens and send to api.paysera.com.

Next steps

• Token controls
• Errors and limits