What matters first: Two orders that look identical are not necessarily the same incident. One may have no payment attempt, both may share a transaction ID, or a webhook may have repeated an idempotent operation incorrectly.
Establish whether the duplicate orders share one payment
The creation interval and request logs distinguish double-clicks from server retries and integration duplication.
Evidence that separates browser and server retries
- Export duplicate order IDs, timestamps, customer, cart hash and transaction IDs.
- Compare browser checkout requests and gateway/webhook deliveries.
- Inspect custom hooks attached to checkout and payment completion.
- Check whether the client retried after a timeout or blank confirmation page.
Where duplicate order creation begins
- Double submission: The checkout button remains active or JavaScript sends twice.
- Network retry: A proxy, client or integration repeats a non-idempotent request.
- Custom code duplication: A hook or API consumer creates another order.
- Webhook misuse: A repeated event runs order-creation logic instead of updating existing state.
Make order creation idempotent
- Make the checkout submission idempotent and disable repeated clicks.
- Use unique transaction or idempotency keys in gateway integrations.
- Correct custom hooks to update the existing order.
- Reconcile historical duplicates before cancelling, refunding or restoring stock.
Double submission or network retry?
Double submission originates in the customer/browser path and usually shows two near-identical checkout requests. A network or integration retry may repeat the same non-idempotent request without a second user action. Compare request timing, transaction IDs, cart hashes and webhook deliveries before deciding which layer must own the idempotency guard.
Duplicate orders and duplicate charges are related but not the same incident. Use the duplicate-payment reconciliation flow when more than one capture exists. If the customer retried because the final page failed, inspect the order-received confirmation path as a possible trigger for the second attempt.
Do not delete the audit trail
Do not bulk-delete duplicates. They contain payment, stock, tax and audit evidence needed to decide which record is authoritative.
Verify one customer action creates one order
- One customer action creates one order.
- Repeated webhook delivery does not create another order or side effect.
- Historical duplicates are reconciled with documented stock and payment decisions.
The incident is resolved when one customer submission creates one order, replayed callbacks and technical retries cannot create another order or repeat side effects, and every historical duplicate has a documented payment, stock and cancellation decision.
WP REPAIR INCIDENT STANDARD
How to narrow the fault without guessing
The creation interval and request logs distinguish double-clicks from server retries and integration duplication.
Export duplicate order IDs, timestamps, customer, cart hash and transaction IDs.
Compare browser checkout requests and gateway/webhook deliveries.
Inspect custom hooks attached to checkout and payment completion.
Check whether the client retried after a timeout or blank confirmation page.
What must be verified
- One customer action creates one order.
- Repeated webhook delivery does not create another order or side effect.
- Historical duplicates are reconciled with documented stock and payment decisions.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Are two identical-looking orders always the same underlying incident?+
No. One duplicate order may have no payment attempt at all, both may share the same transaction ID, or a webhook may have repeated an operation that should have been idempotent, so each pair needs its own evidence rather than a blanket assumption.
How do I tell a double-click duplicate from a server or webhook retry?+
The creation interval and request logs are the deciding factor: a double submission typically shows two near-simultaneous requests from the same browser session, while a network or webhook retry shows a gap tied to a timeout or a repeated delivery from the gateway or integration rather than the customer's browser.
Is it fine to bulk-delete the duplicate orders once I've spotted them?+
No, this is called out as a mistake. Duplicate orders contain payment, stock, tax and audit evidence needed to determine which record is authoritative, so they should be reconciled and resolved deliberately rather than deleted in bulk.
Can custom code or a webhook integration actually be the root cause instead of the checkout button?+
Yes. A custom hook attached to checkout or payment completion can create a second order, and webhook misuse can trigger order-creation logic on a repeated event instead of simply updating the existing order, so inspecting custom hooks and webhook handling is a required check, not just checkout UI behavior.