Error catalog
Every error the TensorRail API returns nests under a top-level error key and carries a stable
ERR_NNNN code. code is the field to branch on — it is the only one present everywhere.
There are two envelopes, and which you get depends on the endpoint:
| Endpoints | Body |
|---|---|
/payments, /refunds, /customers, /disputes | { "error": { "type", "message", "code" } }, plus context fields such as field_name where they apply |
/v1/* (reporting, account, API keys) | { "error": { "code", "slug", "message", "retriable", "user_action", "doc_url", "request_id" } } |
So slug, retriable, user_action and doc_url are available on the /v1/* surface and
should not be relied on when handling a failed payment or refund. Branch on code and you are
correct on both. This page documents the code values you meet on the common integration paths, grouped by family. For the family semantics, the wire shape, and a handling recipe, see Error intelligence.
Treat it as a reference rather than a closed set: it grows as the platform does. Because every error body
carries its own code, a code you have not met before is still handleable from the response alone — read
the band for the family semantics, and look the code up here for whether re-attempting can succeed.
| Family | Band | Codes documented here |
|---|---|---|
| Authentication and authorization | ERR_1xxx | 19 |
| Request validation | ERR_2xxx | 16 |
| Business state | ERR_3xxx | 45 |
| Payment and decline | ERR_4xxx | 70 |
| Server and rate limits | ERR_5xxx | 16 |
| Account policy and compliance | ERR_6xxx | 12 |
code, never on messageCodes are stable contract; message strings are for humans and logs and can change. When a code is retriable, always retry with the same Idempotency-Key.
Authentication and authorization (ERR_1xxx)
Credential and session problems. Fix your configuration; never retry these blindly.
Request validation (ERR_2xxx)
Your call was malformed. Fix the request; the field context in the error body tells you where.
Business state (ERR_3xxx)
The request was valid but the resource's current state does not allow it. Usually a logic bug or a race on your side; retrieve the resource and branch on its actual state rather than looping.
ERR_3040–ERR_3048 belong to settlement, which is not self-served on the merchant API:
/v1/settlements* and /v1/payouts return 404. Anything past reading your balance is arranged
with your account manager. These codes are listed for completeness of the catalogue; you will not
meet them on the endpoints this documentation covers. See
Balances.
Payment and decline (ERR_4xxx)
Collection outcomes from the issuer, network, or acquirer layer. These usually appear as error_code on a payment with status: "failed", not as API request errors. Route them to your checkout's retry experience, not to your alerting.
Card declines and card data (4001 to 4019)
Funds and limits (4020 to 4032)
Fraud signals (4040 to 4048)
Authentication and 3-D Secure (4060 to 4068)
Processing, routing, and async rails (4080 to 4099)
Server and rate limits (ERR_5xxx)
Platform-side failures and throttling. These are safe to retry with the same Idempotency-Key; alert if they persist.
Account policy and compliance (ERR_6xxx)
Account-level policy gates: verification, blocklists, uploads, and compliance records.
TensorRail, Limassol, Cyprus.