At Green Hat, before we built a real deployment pipeline, developers uploaded files straight to production. Somebody would overwrite something on a Tuesday afternoon, and the first sign of trouble was a client complaining that the homepage was broken, or that the checkout wasn’t working.
A WooCommerce checkout that stops working almost always fails in one of four layers: the checkout type your store runs, a PHP or JavaScript error breaking the request, a caching or session problem destroying the cart, or a payment gateway that has quietly died. It’s fairly easy to find where the problem is, if you follow the steps below. Most of them require no code update.
What actually breaks when WooCommerce checkout is not working
A WooCommerce checkout is four systems doing a coordinated handoff while pretending to be one page. WordPress renders it, WooCommerce validates the cart and totals, a payment gateway processes the transaction over its own API, and a browser-side script ties all of that together with AJAX or REST requests. Any of them can fail alone, and the customer-facing symptom looks almost identical either way: a spinner that never stops, a button that does nothing, a redirect back to an empty cart, or, even worse, an error message vague enough to be useless.
Broken checkouts also hide well. Baymard Institute puts the average cart abandonment rate at 70.22% across a meta-analysis of fifty studies. When seven out of ten carts are supposed to be abandoned, a checkout failing for a subset of customers does not move the graph enough to notice. Most stores find out from a customer email.
So the diagnostic starts with observation. Disabling plugins comes later, if at all.
Step 1: Find out which checkout your store is running
Every fix you find online applies to either block checkout or classic checkout, and usually not both. Go to Pages, edit your Checkout page, and look at what is in it. A Checkout block means you are running block checkout. The text [woocommerce_checkout] means classic shortcode checkout.
Block checkout became the default for new installations in WooCommerce 8.3. The classic shortcode still exists and still works, but it is in maintenance mode, receiving just security fixes rather than new features. Architecturally, both are different enough that any fix needs to be handled in different ways. Classic checkout is a PHP template rendered server-side and customized with hooks and template overrides. Block checkout is a React application talking to the Store API.
This is why a snippet that works perfectly for one store does nothing on another.
Step 2: Read the failed network request
The HTTP status code of the failed checkout request tells you which layer broke, and the error message on screen almost never does. Open your browser devtools, go to the Network tab, add a product to the cart, and attempt a real checkout with test credentials.
Block checkout posts the order to /wp-json/wc/store/v1/checkout. Classic checkout posts to /?wc-ajax=checkout. Find that request and read it.
A 500 means a PHP fatal error, so go to step 3. A 403 usually means an expired nonce, a firewall rule, or a security plugin blocking the REST route. A 504 or a hanging request points at server timeouts rather than WooCommerce. A 200 that comes back carrying an error message in the response body means WooCommerce ran fine and something rejected the order on purpose, normally a validation rule from an extension or a gateway declining the transaction.
And if no request fires at all when you click Place Order, the JavaScript died before it could submit. Check the Console tab for an uncaught error and note which file threw it. That filename is usually your culprit.
Step 3: Open the fatal-errors log
WooCommerce writes PHP fatal errors to its own log automatically, and most store owners never look at it. Go to WooCommerce > Status > Logs and open the most recent file named fatal-errors. Per WooCommerce's documentation on finding PHP error logs, this captures PHP fatal and runtime errors along with the file and line where they originated.
That file path is the answer to "which plugin is doing this.” And, while you are on that screen, open the Scheduled Actions tab. Stuck actions there explain a surprising number of orders that get created and never progress.
Step 4: Establish what changed and when
A checkout that worked yesterday and fails today broke because something in the stack moved. Find the timestamp of the first failed order, then look at everything that changed in the 48 hours before it.
WooCommerce itself ships dot releases at a pace most store owners underestimate. Version 10.9.3, released July 3, 2026, fixed a fatal error caused by filters on WC_Email. Version 10.9.4 arrived four days later to fix VAT exemption logic in block checkout for logged-in users. WooCommerce 11.0 was scheduled for July 28, 2026 and got pushed to August 4 after a fatal error surfaced during release-candidate testing.
Add WordPress core updates, theme edits, a host silently bumping your PHP version, an expired SSL certificate, and a gateway plugin auto-updating overnight. Yes, things can break even with a minor update.
If you cannot answer "what changed" because nobody tracks it, that is its own finding. A WordPress maintenance strategy with staged updates and a changelog turns this step into a two-minute lookup.
Step 5: Rule out caching and lost sessions
A cart that is full on the shop page and empty on the checkout page points at the session layer. WooCommerce stores the cart server-side and links it to the browser with a session cookie. Anything that strips, blocks, or caches around that cookie breaks the connection.
The usual suspects are a full-page cache serving a cached version of /checkout/, a CDN configured to strip cookies from responses, a WAF rule matching the cookie pattern, or a cookie consent banner that blocks everything until the visitor clicks accept.
Exclude /cart/, /checkout/ and /my-account/ from full-page caching. Classify WooCommerce session cookies as strictly necessary in your consent tool so they set before consent. Then clear every cache layer you have, including the CDN, and retest in a private window.
Caching also produces the infinite spinner, where block checkout loads but never resolves totals because a stale response is being served against a live cart. WordPress speed optimization shortens the timeout window that lets these failures happen at all.
Step 6: Separate "no payment method" from "payment failed"
These are two different problems reported with the same sentence. Confirm which one you have before troubleshooting either.
No payment method visible at checkout usually comes down to gateway configuration, missing HTTPS, an unsupported country, or block incompatibility. The last one catches people out. To appear inside block checkout, a gateway has to register itself with the Store API through WooCommerce's payment method integration API, which is separate from the older Payment Gateway API used for actual processing. A gateway that never implemented that registration is invisible in block checkout while working perfectly under the classic shortcode. The same applies to some checkout field extensions, which is why plenty of stores stayed on the shortcode long after 8.3.
A payment method that appears and then fails is a different investigation. Check whether live credentials are saved while the gateway sits in test mode, and whether the cart contains only virtual products, which skips shipping and disqualifies some methods. Then open the gateway's own dashboard and read its transaction log. Stripe and PayPal both show you the declined request and the reason code.
Step 7: Check whether the order was actually created
If the order exists in WooCommerce, your checkout is working, and the failure is somewhere after it. Go to WooCommerce > Orders and filter by today's date, including pending and failed statuses.
Finding orders there changes the investigation completely. The customer saw an error or a blank page, but WooCommerce processed the transaction. Now you are looking at the thank-you page redirect, the transactional email layer, or a webhook that never came back from the gateway. Those failures cost you support tickets and duplicate charges rather than lost orders. WooCommerce subscription webhook failures follow this exact pattern, where the gateway log and the WooCommerce log both look correct, and the gap between them is where the money goes.
Finding no orders at all confirms the failure happens before order creation, which sends you back to steps 2 and 3 with better information.
When to stop diagnosing and call a WooCommerce developer
Stop when the next step would cost you more than the fix. That threshold arrives faster than most store owners expect.
A store doing $60,000 a month averages roughly $83 an hour in revenue. Four hours of trial and error on a live checkout costs about $330 in lost sales before anyone touches a line of code, which buys a lot of WooCommerce development support, and that assumes the guessing breaks nothing else on the way through.
The situations that genuinely need someone else:
- The fatal-errors log names a plugin your business depends on, so removing it costs you a working function
- Checkout fails for some customers only, filtered by country, currency, device, or product type
- The Store API returns 200 and no order appears, which means an extension is hooking into validation and silently rejecting
- The error traces to a template override inside your theme
- You have no staging environment and the only place left to test is production
- Ninety minutes of structured testing has produced no reproducible cause
That last one is the honest boundary. These seven steps find the cause in most cases. When they do not, the problem is usually architectural, and architectural problems get worse when you keep poking them on a live store during business hours.
In 2024 I took over as technical lead on a regulated-products ecommerce platform in Canada where the subscription billing engine was failing in ways the logs described as successful. That kind of failure does not appear in a seven-step checklist, because the checklist assumes the logs are telling the truth.
Run the seven steps first. They are cheap, and they are usually enough. If you finish them holding a plugin name you cannot remove or a 200 response with no order behind it, you have moved from troubleshooting into engineering, and the smart move is handing it to someone who does that on purpose.
If your checkout is failing right now and steps one through seven left you with more questions than answers, that diagnostic work is what I do. Tell me what you are seeing and we can find where it actually breaks. If it's quiet at the moment and you would rather not have this conversation under pressure, WooCommerce development and maintenance covers the audit version.