Retries & Timeouts

Simpler retries Platform Interface calls and webhook deliveries on transient failures. Cart recoveries are the exception and are sent only once. 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

Aim well under 30 seconds

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.

Idempotency

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.

Cart recovery delivery

Cart recoveries are sent once. An abandoned cart is a follow-up opportunity rather than a business-critical event, so Simpler does not currently retry failed deliveries.

Field	Value
Total attempts	1
Per-attempt timeout	2 minutes
Delivered on	Any 2xx response. The response body is ignored.
Failed on	Any non-2xx response, network error, or timeout
After a failure	The cart recovery is dropped and is not sent again. Simpler does not email the shopper instead.
Duplicates	Rare, but possible. Cart recoveries are not deduplicated.

Keep your endpoint available

Because failed deliveries are not retried, any downtime on your cart recovery endpoint means missed follow-ups. Return 202 Accepted as soon as you have stored the request and do the rest in the background.

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.
• Cart Recovery tutorial — receiving abandoned checkouts.