What matters first: The customer may have paid even though WooCommerce recorded a timeout, callback failure or local fatal error. The gateway transaction is the financial source of truth for whether funds moved.
What this symptom actually tells you
Changing the order to Processing without evidence can fulfil an unpaid order, while retrying payment can create a duplicate charge.
Capture evidence before changing anything
- Record order ID, amount, currency, gateway reference and exact time.
- Check the gateway dashboard for captured, authorised, failed or refunded state.
- Match gateway webhook/API logs with WooCommerce logs and order notes.
- Inspect stock and email side effects before any manual status change.
Most common causes
- Return-page failure: Payment succeeded but the customer-facing redirect failed.
- Webhook rejected: The gateway callback could not authenticate or reach WordPress.
- Local fatal after payment: WooCommerce crashed while updating the order.
- Timeout ambiguity: The request timed out while the gateway completed asynchronously.
Safe diagnostic and repair sequence
- Reconcile each affected order transaction by transaction.
- Correct the callback, webhook or fatal error for future orders.
- Update only confirmed paid orders with an audit note and deliberate stock handling.
- Run a controlled test payment through the full cycle.
How to choose between the likely causes
Do not treat Return-page failure and Webhook rejected as interchangeable. Payment succeeded but the customer-facing redirect failed. By contrast, the gateway callback could not authenticate or reach WordPress. Use two checks to separate them: Record order ID, amount, currency, gateway reference and exact time; and check the gateway dashboard for captured, authorised, failed or refunded state. Those observations usually show whether the next safe move is to reconcile each affected order transaction by transaction 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 ask the customer to pay again until the gateway transaction has been checked.
How to verify the repair
- Gateway and WooCommerce agree on final payment state.
- Stock, email and fulfilment side effects occur exactly once.
- A new controlled payment updates automatically.
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
Reconstruct the incident before fixing it
Changing the order to Processing without evidence can fulfil an unpaid order, while retrying payment can create a duplicate charge.
- 1
Record order ID, amount, currency, gateway reference and exact time.
- 2
Check the gateway dashboard for captured, authorised, failed or refunded state.
- 3
Match gateway webhook/API logs with WooCommerce logs and order notes.
- 4
Inspect stock and email side effects before any manual status change.
What must be verified
- Gateway and WooCommerce agree on final payment state.
- Stock, email and fulfilment side effects occur exactly once.
- A new controlled payment updates automatically.
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.
Should I just change the order status to Processing if the customer says they paid?+
Not without evidence. Changing the order to Processing without confirming payment can fulfil an order that was never actually paid, so the gateway dashboard state (captured, authorised, failed or refunded) is the financial source of truth, not the WooCommerce order status.
Is it okay to ask the customer to just pay again since the order shows failed?+
No, this is explicitly what to avoid. Retrying payment before checking the gateway can create a duplicate charge, since the original payment may have actually succeeded while only the callback or local processing failed.
What's the difference between a return-page failure and a webhook rejection here?+
A return-page failure means payment succeeded but the customer-facing redirect back to the site broke, while a webhook rejection means the gateway's server-to-server callback could not authenticate or reach WordPress at all. Distinguishing them requires checking the gateway dashboard state alongside matching webhook or API logs against WooCommerce logs and order notes.
Can a timeout during checkout mean the payment never went through?+
Not necessarily. A timeout is described as inherently ambiguous, since the request can time out on the WooCommerce side while the gateway completes the transaction asynchronously in the background, which is exactly why reconciling transaction by transaction against the gateway is required before editing any order.