When your server misses a payment webhook—because your hosting provider had a blip, your endpoint timed out, or you deployed code at the wrong moment—you’re relying on the processor’s retry logic to deliver it again. But each platform handles retries differently, and the windows are shorter than most operators assume.
Miss the retry window entirely, and you’ll never know that subscription was canceled, that payment failed, or that refund was issued. Here’s what actually happens behind the scenes.
Stripe: exponential backoff over three days
Stripe retries failed webhooks with exponential backoff. The first retry happens within minutes. Subsequent attempts spread out over roughly three days, with the final attempt landing around 72 hours after the initial event.
If your endpoint returns anything other than a 2xx status code—or times out after 30 seconds—Stripe marks it as failed and queues a retry. The dashboard shows each attempt, including response codes and timing.
The three-day window sounds generous, but if your server is down for a long weekend or you’re troubleshooting a bug that takes four days to identify, you’ve lost the event. Stripe doesn’t retry indefinitely.
Non-obvious detail: Stripe disables your webhook endpoint automatically after multiple consecutive failures across different event types. You’ll get an email, but if you’re not monitoring closely, subscription updates can go silent for days before you notice.
Paddle: 72-hour retry, then manual replay required
Paddle’s retry behavior mirrors Stripe’s three-day window but with a stricter cutoff. After 72 hours, failed webhooks stop retrying. To recover them, you need to manually request a replay through the dashboard or API.
The replay feature is helpful if you know what you’re looking for—filter by event type and date range, then trigger a resend. But it requires you to notice the gap first. If a handful of subscription.updated events went missing during a deploy and you don’t audit logs regularly, you might not realize users were downgraded or upgraded until they complain.
Paddle also enforces the same 30-second timeout as Stripe. If your webhook handler queries a slow database or chains multiple API calls, you’ll hit that ceiling faster than expected.
Lemon Squeezy: five retries over 24 hours, then it’s gone
Lemon Squeezy retries webhooks five times over approximately 24 hours. The schedule isn’t publicly documented down to the minute, but the final attempt lands within a day of the original event.
This tighter window means less room for error. If you deploy a breaking change Friday afternoon and don’t catch it until Monday, you’ve missed every webhook that fired over the weekend. Unlike Stripe and Paddle, Lemon Squeezy doesn’t surface retry history in the dashboard with the same granularity—you’ll see that an event was sent, but forensic details are limited.
The shorter retry window makes Lemon Squeezy less forgiving for solo operators who don’t monitor uptime 24/7. It’s workable if your stack is stable, but the margin is thin.
What to do when retries aren’t enough
Webhook retries are a safety net, not a guarantee. If you’re running a subscription business, you need a second layer: periodic reconciliation.
Once a day—or once a week, depending on volume—query your payment processor’s API for subscription and payment statuses, then compare them against your database. Look for mismatches: active subscriptions in Stripe that your app thinks are canceled, payments marked pending that actually settled, refunds that never updated your records.
This reconciliation step catches what retries miss. It’s not real-time, but it prevents the worst-case scenario where a customer’s access is wrong for weeks because a single webhook disappeared.
Set up logging that writes every incoming webhook to a separate table before processing it. If your handler crashes mid-execution, you’ll still have the raw payload to replay manually. Most processors let you trigger test webhooks from the dashboard—use those to validate your endpoint handles retries and errors correctly before real money flows through.
Want more architecture breakdowns like this? Subscribe to One Two Three Send—every article is written for operators running the business, not just the content.
Set up alerts, not just logs
Failed webhooks usually show up in your payment processor’s dashboard, but dashboards require you to look. Set up an alert—Slack notification, email, SMS, whatever you’ll actually see—when your endpoint returns a non-2xx status or when the processor reports multiple failures in a row.
If you’re on a platform like Stripe, enable the option to email you when an endpoint is disabled. That email might be the only signal you get before revenue events start disappearing.
Webhook retries buy you time to fix an outage, but they don’t extend indefinitely. Understand your processor’s retry schedule, build reconciliation into your workflow, and monitor failures in real time. The three-day window Stripe offers feels comfortable until you realize you didn’t check the dashboard for four.