Two order states look similar in the list and mean opposite things. Confusing them either cancels orders that were paid for or leaves paid orders unfulfilled.
Failed means declined
The payment provider refused the transaction. No money moved. The customer knows, because they were told at checkout.
Causes are mundane: insufficient funds, an expired card, a mistyped number, or the bank's own fraud checks.
The useful response is not investigation but recovery: a clear message saying what happened, and an easy way to try again with a different method. A customer who fails at checkout and is shown a generic error usually leaves.
Checkout optimisation covers the path they take, and a high failure rate is frequently a checkout problem instead of a payment one.
Pending means nobody told the store
The order was created and the store is waiting to hear the outcome. That usually means the provider's notification never arrived, not that anything went wrong with the payment.
Which means the money may already have been taken.
Cancelling the order is then cancelling something the customer paid for, and they will discover that when nothing arrives. Leaving it indefinitely means never fulfilling it.
Check the provider, not the store
For any pending order, the store's status is exactly the information that is missing. The provider's own dashboard is the source of truth.
Search their records for that order reference. If the payment is there and successful, mark the order paid manually and fulfil it. If it is not there, the payment did not complete and the order can be cancelled with confidence.
Do this before contacting the customer, asking them whether they were charged is asking them to do your reconciliation, and they frequently do not know.
Recurring pending orders are a broken notification path
One pending order is normal. A pattern of them is a fault, and fixing the orders individually is treating the symptom.
The usual causes:
The callback address is wrong. Frequently after a site moves, a domain changes, or a switch to HTTPS. The provider is posting to an address that no longer answers. Moving a site to HTTPS goes into the endpoints that get missed.
Something is blocking the request. A security plugin, a firewall rule, or a rate limit refusing the provider's servers. The store never receives the notification and nothing logs a refusal.
Scheduled tasks are not running. Some gateways rely on a background job to check payment status. If that is stalled, statuses never update. Why scheduled tasks do not run goes into it.
Webhooks and integrations goes into testing the path deliberately, which is the way to confirm a fix instead of waiting for the next order.
On-hold is different again
On-hold usually means awaiting a payment that happens outside the store; a bank transfer, a cheque, a manual arrangement.
That state is correct and requires a person to reconcile it. Automating its cancellation is how legitimate bank-transfer orders get cancelled before the money arrives, which is a poor customer experience and an avoidable one.
Automatic cancellation needs care
Stores commonly cancel unpaid orders after a period to release reserved stock. That is reasonable and the period matters.
Too short and slower payment methods are cancelled while in progress. A day is usually safe; an hour is not, particularly for bank transfers.
Inventory and stock management walks through the stock side of the same decision.
Reconcile periodically
Once a month, compare the store's completed orders against the provider's settlements for the same period.
Differences reveal exactly this class of problem: payments taken without a corresponding order, or orders marked paid with no payment. Both exist on stores that have never checked.
Reading WooCommerce analytics and reports walks through the store's side of that comparison.
Read the gateway's own record for the order
The store's status is the information that is missing, so the resolution starts at the provider rather than in WooCommerce.
Search their dashboard for the order reference; most stores pass it as metadata on the transaction. Where they do not, the customer's email address and the amount narrow it sufficiently.
Three outcomes and three actions. A successful payment means marking the order paid and fulfilling it. A failed payment means the order can be cancelled with confidence. No transaction at all means the customer never reached the gateway, which points at the checkout rather than at payment. Checkout optimisation sets out that case.
Test the callback path deliberately
Waiting for the next order to find out whether the notification path works is a slow way to test it.
curl -sI https://example.com/?wc-api=WC_Gateway_Example curl -sI https://example.com/wc-api/WC_Gateway_Example
The endpoint should answer: typically with a redirect or an error about a missing payload instead of a 404. A 404 means the callback address is wrong or being intercepted, which is the fault producing pending orders.
Then check the server log for the provider's own requests:
grep -iE 'wc-api|webhook|ipn' ~/logs/example.com | tail -20
Their absence means the requests are not arriving at all. A firewall, a security plugin, or an address the provider has recorded incorrectly.
Do not resolve it by editing the order alone
Marking a pending order complete makes the list look right and skips everything the payment normally triggers.
Stock is not decremented, the confirmation email is not sent, and any integration expecting the order never hears about it. The customer receives nothing and the accounting system has a gap.
Where the payment is confirmed at the provider, use the store's own action for recording a payment rather than changing the status directly. That runs the hooks the rest of the system depends on. Inventory and stock management walks through what silently does not happen otherwise.
Tell the customer before they ask
A customer whose payment succeeded and whose order shows nothing will assume it failed and may pay again.
A short message. We have your payment, the order is confirmed, here is the reference: prevents the duplicate order and the refund that follows it.
Where the payment genuinely failed, saying so with a way to retry recovers a share of them. Silence recovers none, and it is the response that costs the most. There is more on the record either way in managing orders and customers.