3 days of Stripe retries vs 10 Sume attempts 30 seconds apart

Stripe's live-mode retry schedule runs up to three days with exponential backoff. Sume's is much shorter: up to 10 attempts at a fixed 30 second spacing, which is about 4.5 minutes. The short Sume window is safe only because the job survives the failed delivery and you have two recovery tools: the status endpoint and the redeliver endpoint.

A note on method: figures in the table are from the vendors' pages and the ratio is my arithmetic.

Retry behaviour compared

The arithmetic

Three days is 72 hours, or 259,200 seconds. Ten Sume attempts leave nine gaps of 30 seconds, so 9 x 30 = 270 seconds, about 4.5 minutes of spacing, plus up to 10 seconds of timeout on each attempt if every one hangs. The ratio is 259,200 / 270 = 960, so Stripe's outer limit is up to roughly 960 times longer than Sume's spacing. Stripe's figure is a ceiling, since backoff is exponential and Stripe does not retry at a uniform rate.

What a short window means for you

If your receiver is down for more than a few minutes, Sume will stop trying but nothing is lost on the generation side. The job reached its real terminal state. Your options, in order:

• Poll GET /v1/jobs/{id}/status for jobs you stored, honouring next_poll_after_seconds.
• Call POST /v1/jobs/{job_id}/webhook/redeliver (jobs:write) for each missed job; Sume re-sends the real terminal event with a fresh timestamp and signature.
• Fetch the output from GET /v1/jobs/{id}/result when result_ready is true.
• Run a scheduled reconcile so you do not depend on noticing an outage.

Pick your design on purpose

Stripe's long retry gives you slack for a lazy receiver. Sume's does not, so the receiver must be quick (store durably, return 2xx) and the poll must be real. Read the Sume webhooks docs and the jobs docs before you launch.