Errors, status checks and retries

Always inspect both the HTTP response and the transaction status. A 200 or 201 can contain a rejected or pending transaction.

HTTP result	Integration action
400 / 422	Check the supplied fields, types, amount scale, environment and recipient. Do not resubmit unchanged validation failures in a loop
401	Check the credential, its validity and the API host
403	The authenticated account or key lacks permission; do not switch accounts or environments automatically
404	Check the identifier and account context. This does not prove another account has no such resource
409	Inspect the conflict and recover the original operation before creating anything else
429	Respect Retry-After when present and retry reads with bounded backoff
Timeout / 5xx	The result may be unknown. Look up the original operation by id or txid before resubmitting

Error response shapes can differ by endpoint. Prefer a documented machine-readable error code where available; error_description is human-readable text and not a stable code. Redact credentials and payment instrument data from logs.

Transaction outcomes

• charged: the transaction completed successfully.
• rejected or failed: inspect the reason and the original operation; do not report success.
• refunded or reversed: funds have a different outcome from a newly settled payment.
• Pending/action-required/unknown status: show that state and the required user action. Never infer success from an unrecognized status or a timestamp alone.

Use GET transaction to verify an operation. Keep the same txid for retries of the same business instruction. Webhook delivery failures and a payment processing failure are different events.