Errors & retries
Handle errors explicitly and keep payment retries predictable.
200 / 201Request succeeded or a resource was created. Check the returned transaction status before treating a payment as delivered.
202Online checkout was initialized. Follow data.payment_link; payment and fulfilment are still pending.
400 / 422The request could not be processed. Check message and any errors fields, fix the values, and use a new idempotency key for the corrected purchase.
401 / 403The key is missing, invalid, revoked, or the account cannot perform this action.
404The resource does not exist or is not owned by this account.
409An identical request is still running. Wait before retrying the same request with the same key.
429Rate limit reached. Respect Retry-After when provided and back off.
5xx / timeoutThe outcome may be uncertain. Check transaction history before making another purchase. Do not assume a timeout means the purchase failed.
Idempotency for purchases
Send a unique X-Idempotency-Key for every purchase. Reuse that key only with the exact same request when retrying. The key is shared across your account; never reuse it for another operation. Successful and validation-error responses are retained for 24 hours. After that window, reconcile the original transaction before retrying.
Rate limits
Authenticated integration routes allow up to 120 requests per minute per account. Purchases also have a 30-per-minute limit. Limits are shared by the account’s keys.
Transaction status values
processing means the purchase is still in progress. successful means it succeeded, and failed means it failed. Inspect the transaction’s status separately from payment_status; successful payment does not by itself confirm product delivery.
Payment status updates
Use transaction details to check pending payments with a delay between requests, or subscribe to transaction webhooks. Never fulfil an order solely because a checkout link was created.
Get transaction details