Webhook Retry and Exponential Backoff Explained | MockGateway

When your server doesn't respond to a webhook in time, the gateway sends it again. That's the entire model — gateways guarantee delivery, not uniqueness. Most handlers are written as if each event arrives once. That assumption doesn't hold, and the bugs it creates tend to surface at the worst moments: duplicate confirmation emails, orders fulfilled twice, customers charged once but confused by two receipts.

What the retry schedule actually looks like

Every major gateway follows the same basic pattern: fast first retry, then progressively longer gaps. Stripe retries over three days — roughly 30 attempts with the interval growing from seconds to hours. PayPal retries for 72 hours. Retries come quickly at first, then slow down.

An endpoint that recovers after a brief outage will catch the next retry. An endpoint that stays down for hours may miss a block of events entirely. The only way to know what didn't arrive is to compare the gateway's webhook log against your own database records.

Why the gap between attempts grows

If a gateway retried every few seconds indefinitely, a server outage affecting thousands of merchants would generate a huge burst of traffic the moment the server came back online. Exponential backoff spreads those retries out so recovery is gradual. Adding a small random offset — jitter — prevents all those merchants from retrying at exactly the same moment even within the schedule.

Handling the same event twice

Here's the scenario behind most duplicate-order incidents: your server receives a webhook, starts processing it, runs past the timeout, and returns nothing. The gateway schedules a retry. But the first delivery may have already completed your logic — the order is fulfilled, the stock is decremented, the email is sent. When the same event arrives again, your handler doesn't know that.

The fix is to store the event ID when you first receive it, check for it before doing any work, and return 200 even for events you've already processed. The gateway just needs confirmation; it doesn't care whether the work was new or already done.

After all retries run out

Once the retry window closes, the gateway stops trying. There's no automatic recovery. For events that never delivered, the options are a manual replay from the gateway dashboard or a reconciliation job that compares gateway records against your own. Both require noticing the problem first. An alert when an endpoint records several consecutive failures is worth setting up before you need it.

Testing retry logic in development

Waiting three days for a real retry sequence to run is not a development workflow. MockGateway lets you replay webhook events on demand and configure failure responses, so the full delivery cycle — first attempt, failure, retry, eventual success — is something you can walk through in a single sitting. The playground covers Stripe, PayPal, Razorpay, and other templates without requiring an account on any of them.