The decision
Payment events can arrive more than once, concurrently, and in a different order than expected. Verify the event signature, retrieve current payment state when needed, and commit the order plus its fulfillment jobs in a database transaction. Return success only after durable storage succeeds.
A worked example
Two workers receive checkout completion for the same session. Both verify the signature and retrieve the session. A unique session ID creates one order, and deterministic job IDs create one email job and one analytics job. If the database is unavailable, the handler returns a failure so the provider can retry.
How to put it into practice
- Read the raw request body for signature verification before parsing or modifying it.
- Use a unique business key for the order and each intended side effect.
- Keep webhook handling short: store durable work, then let a worker deliver email.
- Test duplicate events concurrently and test database failure before acknowledgment.
A failure to plan for
Fire-and-forget email can disappear after a serverless request returns. Waiting for email inside the webhook avoids that specific loss but makes provider outages block acknowledgment. A durable job queue separates those concerns.
Try it on your project
Send the same signed test event twice at the same time. Check that there is one order and one delivery job. Then make the database unavailable and verify that the webhook does not return a successful acknowledgment.
Primary reference
Keep the next step small
Use the free demand scorecard or planning tools to make your assumptions explicit. The $19 launch kit brings the blueprint and seven editable worksheets together.