Webhook duplicate replay test
Payment providers can deliver the same event more than once. A replay test confirms your handler processes the first delivery and skips duplicates without repeating billing side effects.
Open the free replay simulatorUse a stable idempotency key
Derive a key from trusted fields after signature verification, for example lemon_squeezy:order_created:order_id. Store that key before sending emails, creating licenses, granting access, or changing subscription state.
Assert process-once behavior
Replay the same fixture three times in a unit test. The first delivery should run exactly one billing side effect, while the second and third deliveries should return success without repeating the side effect.
Keep retry checks in CI
Duplicate replay tests belong beside signature verification tests. Run them in CI whenever raw-body parsing, event mapping, entitlement writes, or webhook retry handling changes.
FAQ
Why test duplicate webhook replay?
Payment providers retry webhook delivery after timeouts and network failures. A duplicate replay test proves that billing side effects run once even when the same event is delivered multiple times.
What should the idempotency key include?
Use a stable provider event or object identifier, such as provider:event_name:object_id, and store it before granting access, sending email, or mutating subscription state.
Use the free sample before wiring production checkout
Download a public sample pack with fake Lemon Squeezy fixtures, signature tests, contract checks, duplicate replay tests, and CI skeletons. The Pro Kit preview shows the full paid package structure without exposing the private archive.