Skip to main content
All errors share the same shape:
  • error: stable snake_case code — use it in your logic.
  • message: human-readable explanation — may change, don’t parse it.
Sanitized error messages. An error message will never expose provider names, infrastructure details, URLs, raw upstream bodies (JSON/HTML), or internal configuration — not in API responses, webhooks, or stored status fields. Business rejections from the payment processor keep their actionable reason (for example, why a document or account was rejected); infrastructure failures are replaced by the fixed generic message "the payment provider could not process the request" — retry those operations with the same idempotency_key.

Codes by category

Authentication and permissions

OTP / 2FA

Full flow and details in security and 2FA.

Social login (OAuth)

Full flow and details in social login.

Organization admin panel

These codes come from organization administration surfaces (the CBPay Admin panel), not from the account-level API documented above — they never appear on /v1/* account endpoints.

Validation (400)

Money and state (402 / 404 / 409 / 422)

Compliance (403 / 503)

Transactional firewall

Errors from the review of operations held by the transactional firewall (guide). The hold itself is not an error: the create call answers 202 Accepted with status: in_review and a review_id.

Real-time events (SSE)

Codes from GET /v1/events and its history.

Service (5xx)

How to handle them

  • Validation 4xx: fix the request. Don’t retry as-is.
  • 402: fund the account and retry (new idempotency key only if the operation was never created).
  • 5xx / timeouts: retry with the same idempotency key; the operation will never duplicate.
Last modified on August 7, 2026