Error codes

Every response code, what to do about it

Paytia uses standard HTTP response codes. Success lives in the 2xx range, client errors in 4xx, upstream or server issues in 5xx. The response body always carries a plain-text reason — read it before retrying.

API reference menu

Code table

CodeMeaningWhy you got itWhat to do
200OKSuccessParse the response. For flows that return a payment link, pick up linktopay_url. For token charges, check the status field.
208Already reportedDuplicate reference IDYour reference_number has been used before. Either fetch the prior transaction, or regenerate a unique reference.
400Bad requestMissing or invalid parameterResponse body names the offending field. Check the field reference and resend.
401UnauthorizedInvalid API key — wrong key, rotated key, or IP not whitelistedConfirm X-API-KEY matches the value issued for this environment. If the key is IP-restricted, confirm the source IP is in the allowed list.
405Method not allowedWrong HTTP verb for this endpointPayment Service API expects POST multipart/form-data. URL POST API expects GET with query parameters.
500Internal server errorServer-side failure — database or downstream gateway errorRetry with exponential backoff. If it persists, contact support with the request ID from the response.
502Bad gatewayUpstream payment gateway didn't respond cleanlyTransient. Retry with backoff; if stuck, check the status page at status.paytia.com.
503Service unavailablePaytia or a gateway is temporarily downRetry with backoff. Short outages are usually deploys or gateway-side; status page has the detail.
504Gateway timeoutUpstream gateway didn't respond in timeRetry. Don't double-charge — use an idempotent reference_number so repeats don't create duplicate transactions.

Retry strategy

For transient 5xx errors (502, 503, 504), retry with exponential backoff — 1s, then 2s, then 4s, capped at around 30s. Use the same reference_number on retries so Paytia and the downstream gateway can deduplicate. 4xx errors should not be retried — fix the request.

Finding the request ID

Every response carries an opaque request ID in the X-Paytia-Request-Id header. Include it in any support ticket — it lets us trace the request end to end through our logs.

Ready to build with Paytia?

The docs are open. Keys are gated — drop us a line and we'll issue sandbox credentials so you can try every flow against a real endpoint.