Payment webhooks must assume retries

The risk

Payment providers retry events when acknowledgements are delayed or lost. A valid event can therefore arrive more than once, and blindly repeating business logic can create duplicate side effects.

The approach

Treat webhook receipt and business processing as separate responsibilities.

• Verify the provider signature against the raw request body
• Persist the provider event identifier under a unique constraint
• Acknowledge quickly and process durable work asynchronously
• Make every downstream side effect safe to retry
• Keep enough event history for support and controlled replay

The lesson

Signature validation proves where an event came from; idempotency prevents a legitimate retry from becoming fraud or customer harm. Secure integrations require both.