What store owners report
- Checkout will not load or fails at payment.
- Payment is taken but no order appears, or an order appears with no payment.
- Order confirmation emails stop reaching customers.
- Subscription or recurring payments start failing.
- Cart or checkout is cached and shows the wrong information.
- An update or extension changed store behaviour.
The silent failures matter most
A checkout that throws an error is annoying, but you find out about it quickly. In contrast, a store that takes money without recording an order can run for days before anyone notices.
The same is true of order emails. If confirmations stop arriving, customers assume the purchase failed, so they buy again or raise a dispute. Consequently the first job is establishing which failure mode you actually have, because the two lead to different investigations.
How a store is tested safely
Work should happen on a copy wherever hosting allows it. If testing must happen on the live store, the exact actions, identified test transactions, reversal, and record must be agreed in writing beforehand.
Test orders are never created on a production store without approval. An unannounced test order pollutes reporting, can trigger real fulfilment, and may charge a real card. Therefore the method is agreed before anything is clicked.
The order path to check
Add to cart, cart totals, guest and logged-in checkout, each active payment method, tax and shipping where applicable, the order record, customer and merchant email, and the refund path. A store is not fixed until the full sequence works.
Specifically, each of those steps can fail independently. A gateway can authorise while the order status never advances. Email can send while the receiving server silently rejects it. As a result, checking only the step that was reported often hides the real fault.
Caching is a frequent and avoidable cause
Cart and checkout are personal to each visitor, so they must never be served from a shared cache. However, aggressive page caching at the host or the CDN routinely catches them anyway.
The symptom is distinctive: one customer sees another customer’s totals, a cart appears to empty at random, or a logged-out price shows to a logged-in customer. In most cases the fix is a cache exclusion rather than a change to the store itself. The WooCommerce settings documentation is the reference point for the store-side configuration involved.
Where WooCommerce support stops and a provider starts
Payment providers, hosting, and third-party extensions are outside the site owner’s direct control. Establishing which side of that boundary contains the fault is often the most valuable first step.
For example, a declined payment may be the gateway’s risk rules rather than a site fault at all. Where the evidence points outward, we document it so you can escalate to the provider with specifics instead of a description.
Prepare the incident details
Capture what customers see, the time of a failed attempt, recent changes, and whether money was taken. Do not send customer or card data.
An approximate timestamp is unusually valuable. It lets gateway records, server logs and order records be lined up against each other. Similarly, knowing whether the failure affects every payment method or only one narrows the search immediately.
Two more details save time. First, note whether the problem affects every product or only some, because variable and subscription products follow different code paths. Second, say whether it happens for guests, logged-in customers, or both.
Finally, resist the urge to disable plugins one by one on a live store before the evidence is captured. Good WooCommerce support depends on being able to reproduce the fault, and a hurried change often removes the only clue.
If the store was compromised rather than broken
Unexpected redirects, unknown administrator accounts, or a browser warning point at compromise rather than a configuration fault. In that case start with hacked site recovery, because the containment steps come first and changing the store can destroy the evidence.
Otherwise, review the service scope to confirm the work fits, see general WordPress support for non-store faults, or read about ongoing maintenance plans if the goal is to stop update-related breakage recurring.