How Do You Prevent Duplicate Orders When a Payment Webhook Arrives Twice?

Short answer

Order creation must not run again when the same payment webhook is redelivered. Use the provider’s event identifier together with a unique business-rule key, and store processing state atomically in the database. A successful webhook response and actual completion of an order are different stages.

Event IDs and order IDs provide separate safeguards

The provider’s event identifier helps recognise redelivery of the same notification. However, different event types can arrive for the same payment. Checking only whether an event has already arrived may therefore be insufficient. A uniqueness rule must also protect the payment and business key associated with the order. Design duplicate delivery as a legitimate, expected failure scenario.

Checking the database before inserting a record creates a race between concurrent requests. Protect processing with a unique constraint and an appropriate transaction boundary. Distinguish received, processing, completed and failed event states. The existence of an unfinished record does not mean the work succeeded.

Signature verification and a safe queue

Apply the provider’s signature-verification method before executing business rules. Consult official documentation for the body format required by verification. Do not queue an invalid request as a normal payment event. Once a valid event is durably recorded, long-running tasks can run in a controlled queue. Do not retain sensitive payment details in logs.

Delivery behaviour in Stripe documentation is a reference for integrations using Stripe; other providers’ retry windows and signature formats must not be assumed identical. The proposal should identify the selected provider, event types, retry rules and owner of failed tasks. Idempotent API requests are also a separate layer from webhook-processing protection.

Reconciliation is as important as preventing duplicate orders

Test delivery of the same event twice, concurrently and again after processing was interrupted. Open a reconciliation task if payment completes without an order being created. The operations screen should link payment and order and show what reprocessing will change. The test goal is not merely to avoid duplicate records, but also to detect missing orders.

Implementation checklist

Is the webhook signature verified?
Is there a unique constraint on the event ID?
Is the payment-linked order key protected separately?
Can interrupted processing be retried?
Is payment–order reconciliation visible?

Frequently asked questions

Does a successful HTTP response mean the order is complete?

No. Acceptance of delivery and completion of the business workflow are separate records.

Do all providers use the same retry rules?

No. Use the selected provider’s official agreement and documentation.

Scope and limitations

This approach does not replace provider-specific integration testing. Verify payment and refund workflows in the relevant provider’s test environment before going live.

Sources and currency

Source review: 7 October 2026. Linked document versions and provider terms may change. Check the current version of the relevant source before implementation.