Stripe Webhooks: Delivering to Systems You Do Not Control
also called Signed Webhooks
Outbound event delivery to arbitrary customer endpoints requires signing, retries over days, explicit at-least-once semantics and a replay interface.
The problem
Webhooks invert the usual dependency. Stripe must deliver events to endpoints it does not control, which may be slow, misconfigured, temporarily down, or behind a firewall — and the customer's failure to receive an event becomes Stripe's support problem.
What the design includes
Asynchronous dispatch, so a slow consumer never blocks the payment that generated the event.
Signature verification — an HMAC over the payload with a shared secret, plus a timestamp, so the receiver can confirm the event genuinely came from Stripe and is not a replay. Without this, a webhook endpoint is an unauthenticated interface that anyone who learns the URL can post to, which has been the mechanism behind real fraud.
Retries with backoff over an extended period — hours to days — so a consumer's outage does not lose events.
Documented at-least-once semantics with no ordering guarantee. This is the part that surprises integrators and is stated explicitly: a retried event can arrive after later ones, so consumers must be idempotent and should reconcile against the API rather than treating the event stream as authoritative.
Event identifiers so consumers can deduplicate, and a dashboard with delivery history and manual replay, because consumers will lose events and will ask.
The trade-off
Every one of these is engineering the provider does so that thousands of integrators do not have to. The alternative — polling an API — is simpler for the provider and worse for everyone: higher latency, far more requests, and each integrator implementing their own cursor management.
The transferable lesson
If you emit webhooks, the checklist is: sign them, retry generously, guarantee at-least-once explicitly, include a stable event id, provide replay, and document the ordering guarantee you do not provide.
And a security note that is easy to miss on the sending side: consumer-supplied URLs are a server-side request forgery vector. An endpoint that will POST to any URL a customer supplies can be pointed at internal addresses or the cloud metadata endpoint, so outbound targets must be validated against internal ranges.