Retries and errors

How it works

Retries must preserve the identity of the business operation and respect the payment state. A network timeout is an uncertain result, not permission to create another charge.

Implementation

Apply bounded exponential backoff to transient transport and server errors, respect Retry-After where returned, and stop on invalid input or authentication. Inspect the deployed release's idempotency support. Retrieve an uncertain capture, refund or cancellation before retrying. Log redacted resource IDs and errors; a declined payment can arrive in a 2xx response.

In this area

• Idempotency
• Retries
• Errors

Related guides

• Idempotency
• Webhooks
• Errors