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.
What this symptom actually tells you
The creation interval and request logs distinguish double-clicks from server retries and integration duplication.
Capture evidence before changing anything
- 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.
Most common causes
- 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.
Safe diagnostic and repair sequence
- 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.
How to choose between the likely causes
Do not treat Double submission and Network retry as interchangeable. The checkout button remains active or JavaScript sends twice. By contrast, a proxy, client or integration repeats a non-idempotent request. Use two checks to separate them: Export duplicate order IDs, timestamps, customer, cart hash and transaction IDs; and compare browser checkout requests and gateway/webhook deliveries. Those observations usually show whether the next safe move is to make the checkout submission idempotent and disable repeated clicks or to preserve the current state and widen the investigation.
On a live store, reproduce the issue with a controlled test order and follow the same payment, stock, tax and notification path used by customers. Avoid changing several checkout components at once because that changes the application state and can obscure the original sequence of events needed to attribute the failure. Record the exact timestamp, affected URL or transaction, last known good state and every change made during diagnosis. That handover is often what separates a repeatable repair from a temporary disappearance of the symptom.
What not to do
Do not bulk-delete duplicates. They contain payment, stock, tax and audit evidence needed to decide which record is authoritative.
How to verify the repair
- 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.
A visible symptom disappearing is not enough. Close the incident only when the original failing action, the surrounding business journey and the relevant logs all agree that the fault is gone.
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.