WooCommerce problems divide into three groups that share almost no causes: the store is broken, orders are not completing, and emails are not arriving. Working out which you have before investigating saves most of the time.
First: is it WooCommerce at all
Before anything specific to the store, check whether the account is over its disk quota. A full account cannot write, so orders fail, uploads fail and email stops, and none of the errors mention disk.
Then turn on the debug log, which turns a blank page or a vague failure into a filename and a line number:
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false );
WP_DEBUG_DISPLAY must be false on a live store, errors go to a file rather than appearing to customers mid-purchase. Fixing common WordPress errors goes over reading it.
Orders are not completing
The most expensive category, and the one worth being systematic about.
Find out where it stops. Does the customer reach the payment page? Does the payment succeed at the gateway? Does the order appear in WooCommerce at all? Those three points isolate the problem to a different system each.
Payment taken, no order created usually means the gateway's callback is not reaching your site. That callback is a request from the gateway's servers to a specific URL, and anything blocking it. A firewall rule, a security plugin, directory protection, a redirect, breaks the order while the payment succeeds.
This is the failure that produces angry customers who were charged and have no order. Check the gateway's own logs, which record whether the callback was attempted and what response it got.
Orders stuck in pending is usually the same cause: the payment completed and the notification never arrived to move the status forward.
The checkout page fails or hangs
Checkout cannot be cached, so it runs the full stack on every attempt. Two things commonly break it.
A plugin conflict. Test on a staging copy by deactivating plugins in groups. Checkout attracts plugins, shipping, tax, analytics, marketing, and they interact.
Resource exhaustion. If checkout fails only during busy periods, you are hitting the ceiling on concurrent PHP processes and requests are queueing. That is capacity instead of a bug. There is more on reducing the load, starting with cart fragments in WooCommerce speed optimization.
Emails are not arriving
Order confirmations failing silently is common and damaging, because neither you nor the customer is told.
Three causes in order. The site is using the server's basic mail function, which many receiving servers distrust, configuring WooCommerce to send through authenticated SMTP is the reliable fix. SPF, DKIM and DMARC are missing, so major providers treat the mail as suspect. The account or mailbox is over quota, which stops everything.
Test explicitly by placing a real order instead of using a plugin's test button, those often bypass the path a real notification takes. The email troubleshooting guide walks through the wider set.
Stock and pricing look wrong
Almost always caching. A cached product page shows an old price or an old stock figure after a change.
Clear the cache and confirm. If it recurs, the caching layer is holding product pages longer than the store changes them, and the exclusion rules need adjusting instead of the cache disabling.
After a migration
Three things break predictably. Payment gateway credentials and callback URLs still reference the old site. SPF and DKIM point at the old host, so notification emails start going to spam. And stored URLs in the database still point at the old domain, which breaks images and sometimes checkout.
Fix stored URLs with a tool that understands serialized data: a plain SQL replacement corrupts settings rows.
What to gather before opening a ticket
The exact error, the order number if there is one, whether it fails for every customer or some, when it started, and what changed around then. The last two answer more than the rest.
For the case where the order was fine and the money needs returning, How to Handle Refunds and Returns in WooCommerce goes into recording it and paying it.
Many of these faults arrive with an update, and two steps specific to WooCommerce prevent most of them. How to Update WooCommerce Safely picks it up from there.
A cart that empties, or one showing items the customer never added, has a single usual cause. For that, see Why WooCommerce Carts and Sessions Break with Caching.
Orders stuck on pending are usually a notification that never arrived instead of a payment that failed. There is more in How to Handle Failed and Pending Payments.
Establish whether it affects everyone
Before investigating anything, find out whether the fault is universal or belongs to one customer, because the two lead in opposite directions.
curl -s -o /dev/null -w '%{http_code} %{time_total}\n' https://example.com/checkout/
curl -s -o /dev/null -w '%{http_code}\n' -H 'Cookie: woocommerce_items_in_cart=1' https://example.com/checkout/
Reproduce it yourself in a private window with a fresh basket. If it happens every time, it is the store. If it does not, it is specific to that customer's basket, address, payment method or browser.
The second case is where most time is wasted, because the store looks healthy from every angle. Ask which product, which country and which payment option, and reproduce that exact combination rather than a generic one.
Read what the store recorded about itself
The platform keeps its own record, and it holds the failures that never reach the visible error log.
wp wc tool run clear_transients --user=1 ls -la wp-content/uploads/wc-logs/ 2>/dev/null | tail -10 tail -50 wp-content/uploads/wc-logs/fatal-errors-*.log 2>/dev/null
Payment gateway logs are separate files per gateway, and they contain the actual response from the provider rather than the message shown to the customer. That response is usually specific and actionable where the customer facing message is not.
Stale cached values are worth clearing early, since a store that behaves inconsistently after an update frequently holds data describing the previous version. Handling failed and pending payments goes into the gateway side.
Rule out the layer above the store
Several store faults are not the store at all, and they share a signature of being intermittent and unreproducible.
curl -sI https://example.com/checkout/ | grep -iE 'x-cache|cf-cache-status|set-cookie' curl -sI https://example.com/cart/ | grep -iE 'x-cache|cf-cache-status'
A cache hit on a basket or checkout page is a fault by itself. Those pages differ per visitor, and serving a stored copy produces the classic reports of a basket that empties, shows somebody else's contents, or refuses to update.
The same applies to a security layer that challenges automated looking requests, which can block a payment provider's callback while ordinary browsing works perfectly. Why carts and sessions break with caching deals with the exclusions.