Retries & Timeouts
Simpler retries Platform Interface calls and webhook deliveries on transient failures. This page is the canonical source for retry counts, backoff schedules, and timeout behavior.
Platform Interface — /submit retries
Simpler retries /submit on transient failures using hashicorp/go-retryablehttp with exponential backoff.
| Field | Value |
|---|---|
| Total attempts | 4 (1 initial + 3 retries) |
| Backoff | Exponential, bounded between 1s and 3s between attempts |
| Per-attempt response timeout | 30 seconds |
| Connection-phase caps | TCP dial: 10s · TLS handshake: 10s · Idle connection: 61s |
| Worst-case end-to-end window | ~2 minutes (4 × 30s + ~6s total backoff) |
| Retried on | 5xx responses, network errors, response timeouts |
| Terminal (not retried) | Any 4xx response, malformed 2xx |
| After exhaustion | Order marked failed in the Simpler dashboard with the authorization held, so it can be retried or cancelled; Simpler Integrations Support contacts the partner |
A handler that runs close to the 30-second cap will frequently be cut off mid-response, wasting one of the four retry attempts. Aim for well under 30s — a practical ceiling of ~15s leaves headroom for network variability and keeps retries meaningful. The response must contain the order_id of the created order, so create the order within the request and move only secondary work (emails, ERP sync) to a background queue.
Webhook delivery retries
Webhook deliveries retry on a more aggressive schedule because the underlying events (payment confirmations, cancellations) are business-critical.
| Field | Value |
|---|---|
| Total attempts | 7 |
| Backoff | attempt^4 seconds, ± 10% jitter (~1s → 16s → 81s → 256s → 625s → 1,296s) |
| Total window | ~56 minutes end-to-end |
| Per-attempt timeout | 2 minutes |
| Retried on | Any non-2xx response, network error, or timeout |
| Terminal (not retried) | None. Even 410 Gone is retried like a 5xx. The only non-retry path is when the merchant is marked as not supporting webhooks at all. |
| Delivery guarantee | At-least-once |
| Dead-letter behavior | Logged in Simpler's internal dashboard. No re-drive API and no partner-facing visibility; Simpler's team is alerted to facilitate manual synchronization in rare cases. |
Because delivery is at-least-once and every non-2xx retries, duplicates are expected. Simpler sends an Idempotency-Key HTTP header on each webhook request — dedupe on that key in your handler.
See also
- Handling Webhooks tutorial — receiver implementation including signature verification.
- Webhook event catalog — list of event types and their payloads.
- Order lifecycle — how retries interact with payment states.