Why Stripe can send the same webhook more than once

Stripe's webhook documentation notes that the same Event can be delivered more than once. A retry or manual resend can therefore present the same Event again. Seeing the same provider Event more than once is a normal condition to design for, not proof that Stripe has created a second business event.

Use durable Event identity

For Stripe, the Event identifier is a useful part of the deduplication key. Stripe also notes that two separate Event objects can occasionally represent duplicate notifications; in that case, compare the data.object ID together with event.type rather than relying on the Event ID alone. Store the relevant identity with the business operation it represents and enforce uniqueness at the durable state boundary. Comparing the shape of two HTTP requests is not enough: headers, timing, and transport details can differ while the underlying Event is the same.

What duplicates can damage

Without idempotency, a repeated delivery can:

• provision the same account twice;
• send duplicate emails;
• apply a credit more than once; or
• repeat a state transition that should only happen once.

Make the operation and its durable result explicit. A unique Event or business key can prevent a second transition, while a recorded result lets a later delivery return or reuse the original outcome safely.

Retries and replay are both another attempt

Provider retries and application retries can both produce duplicate delivery. Manual replay intentionally creates another attempt as well. Replay history helps an operator understand what was tried, but it does not make arbitrary downstream code idempotent.

Webhook Handoff provides at-least-once delivery and does not eliminate the need for idempotent Destination processing. Treat the stable Event or business identity as part of your consumer contract.

A practical consumer pattern

1. Read and verify the provider Event identity.
2. Look up an existing durable operation keyed by that identity.
3. If it is complete, return the previously recorded result.
4. If it is pending, coordinate the transition rather than starting a second one.
5. If it is new, record the operation and its outcome atomically where possible.

Further reading: Stripe's duplicate Event guidance.