A webhook delivers an event from another system to an application endpoint. A valid signature can establish that the delivery matches the sender's signing process. It does not establish that the business operation described by the event has never been processed before.
Retries and duplicate delivery are normal integration conditions. The consumer needs to verify the sender and make repeated processing safe for the business record it changes.
Verify the delivery before interpreting it
Stripe documents signature verification against the raw request body and describes duplicate events, retries, and event-ordering considerations. Its signing timestamp also supports checks against old deliveries. Stripe's webhook documentation explains these provider-specific behaviors.
An illustrative inventory integration receives a shipment event. The consumer validates the delivery before trusting its fields. Parsing and reserializing the body before verification can change the bytes the signature covers, so the implementation needs to follow the sender's documented procedure.
Authenticity and idempotency answer different questions
Authenticity asks whether the event came through the expected signing relationship. Idempotency asks whether repeating the operation produces an additional business effect. A valid event delivered twice should not reduce stock twice if it represents one shipment.
Record an event identity or another stable business key and connect it to the state change. The exact deduplication key depends on the provider's event semantics. Two distinct events can sometimes refer to the same business object, so an event-ID check may need to be combined with object-state validation.
Test duplicates and interrupted processing
In a test environment, deliver a valid event twice and verify one intended state transition. Then simulate an interruption after the business update but before the acknowledgment. When the sender retries, the consumer needs to recognize completed work rather than apply it again.
Also test two workers receiving the same event concurrently. A read-then-write duplicate check can race if the database does not enforce the required uniqueness or transaction boundary. Inspect the final record and event ledger, not only the HTTP response codes.
Handle ordering and failure explicitly
Events can arrive after a related object has changed again. Define which source of truth determines the current state and whether the consumer needs to retrieve the object from the provider. A delayed notification should not silently revert a completed or canceled business process.
Retain failed deliveries in an observable retry or exception process. The assessment can record signature failures, duplicates, concurrency results, and recovery after interruption. These findings establish whether the integration can authenticate events and maintain the intended business state under the delivery conditions the provider documents.
Sources
OWASP: Webhook Security. The inventory integration is illustrative; provider retry and signing rules vary.
