Safe retries
Retry temporary failures without creating duplicate financial or messaging operations.
# Safe retries
Retry temporary failures without creating duplicate financial or messaging operations.
## Retry only transient failures
Network failures, gateway timeouts, 429 responses, and selected 5xx responses are candidates for a retry. Validation, authentication, and duplicate-reference errors need a change before another request is made.
## Back off and preserve context
Use bounded exponential backoff with jitter. Keep the same external reference, request data, and environment for every retry so reconciliation remains unambiguous.
> **Do not retry blindly:** If the outcome is uncertain after a timeout, check status or await the callback before retrying a financial operation.