A WooCommerce checkout that is not working is the most expensive kind of broken. Product pages load, the cart fills, and then the customer hits a spinner that never stops, a blank page, or “There was an error processing your order.” Nothing in the admin looks wrong, so the store owner starts guessing — deactivating plugins at random on a live site, which is how a broken checkout becomes a broken store.
We fix this regularly for clients, and the order below is the order we work in. It goes cheapest-diagnostic-first, because the answer is usually in a log file nobody opened. Verified against WooCommerce 10.9.x, checked August 2026.
1. Read the fatal-errors log before you touch anything
WooCommerce keeps its own logger. Go to WooCommerce → Status → Logs, and under Browse log files look for a file whose name starts with fatal-errors. Open the most recent one. It records PHP fatal errors with a timestamp, the error, the exact file and line it came from, and a stack trace — which usually names the guilty plugin in the first three lines.
Two things to know. Log entries are deleted after 30 days by default, so a Woocommerce checkout that “broke last month” may have no evidence left. And the files live in /wp-content/uploads/wc-logs/ unless someone has set the WC_LOG_DIR constant in wp-config.php to point elsewhere — worth checking before you conclude there are no logs.
If the fatal error names a plugin, you are done diagnosing. Update it, roll it back, or replace it. If the log is empty, the failure is not a PHP crash and you continue down this list.
2. The payment method disappeared: block Woocommerce checkout versus classic Woocommerce checkout
This is now the single most common cause we see, and it does not throw an error at all — the payment method simply is not offered, so the order can never be placed.
WooCommerce has two checkouts: the classic shortcode checkout ([woocommerce_checkout], PHP templates, maintenance-only) and the newer block checkout built on React and the Store API. A payment gateway written for the classic checkout does not automatically render inside the block checkout. Gateways must integrate with the blocks and declare compatibility via FeaturesUtil::declare_compatibility( 'cart_checkout_blocks', __FILE__, true ). If the gateway has not done that work, it vanishes from a block checkout.
Diagnose it in two minutes: edit the checkout page and see whether it contains a Checkout block or the shortcode. If it is a block and your gateway is missing, temporarily swap the page content for [woocommerce_checkout]. If the payment method reappears, you have your answer — and a decision to make: keep classic checkout for now, or replace the gateway with one that supports blocks. Note the inverse trap too: some modern gateways are block-first and behave poorly on classic checkout. Our Mollie WooCommerce setup guide covers what a correctly configured gateway should look like on both.
3. Something is caching a page that must never be cached
Cart, checkout and my-account are per-visitor pages. Cache them and customers see someone else’s cart, an empty cart, or a checkout that silently fails because the nonce embedded in the cached HTML is long dead.
Check every cache layer, not just the plugin: page cache plugin, server-level cache (Varnish, LiteSpeed, Nginx FastCGI), and the CDN. Exclude /cart/, /checkout/, /my-account/ and any ?add-to-cart= URLs, plus the WooCommerce session cookies — woocommerce_cart_hash, woocommerce_items_in_cart and wp_woocommerce_session_.
Managed hosts differ sharply here. Cloudways ships a WooCommerce-aware Varnish configuration that excludes cart, checkout, my-account and add-to-cart URLs out of the box, and lets you add your own URL and cookie exclusions from the application settings. Cheap shared hosting frequently caches everything and gives you no exclusion controls at all, which is why “the checkout randomly empties the cart” so often turns out to be a hosting problem rather than a WooCommerce one. We compare that behaviour in detail in Cloudways vs SiteGround for WooCommerce.
4. “Error processing Woocommerce checkout” — expired sessions and nonces
If checkout fails only for logged-out customers, or only after the page has been open a while, suspect nonces. The block checkout talks to the Store API, and POST requests to the cart endpoints plus all checkout endpoints require a valid nonce; an invalid one returns a 403 and the front end shows a generic failure message.
Practical causes: an aggressive cache serving a stale nonce (see above), a security plugin stripping the Nonce header, or a session that expires while a slow customer types. Open your browser’s Network tab, place a test order, and look at the response from /wp-json/wc/store/v1/checkout. A 403 points squarely at nonces or a security plugin. A 500 points back to step 1.
5. The server is quietly running out of resources
A blank white checkout with no log entry is usually a resource ceiling, not a bug. WooCommerce recommends a 256 MB WordPress memory limit, and since WooCommerce 10.8 the platform requires WordPress 6.9 or newer; PHP 8.2 or 8.3 is the sensible target. Check the actual values under WooCommerce → Status, not what your host’s marketing page claims.
Also look at max_execution_time. Woocommerce Checkout is the heaviest request on the site — tax calculation, shipping rate lookups, an outbound API call to the payment provider — and on a slow or oversold server it can exceed the limit and die without writing anything useful to the log.
6. Run the boring conflict test properly
If steps 1–5 come up empty, it is a conflict, and there is no shortcut. Do it on a staging copy, never live. Switch to a default theme (Twenty Twenty-Five or Storefront) and test checkout. If it works, the theme is overriding checkout templates — often an outdated woocommerce/ template folder in the child theme that no longer matches core.
If the theme is innocent, deactivate every plugin except WooCommerce and your gateway, confirm checkout works, then reactivate in batches, testing after each. Tedious, and it finds the culprit every time. Keep the site’s template overrides in mind: WooCommerce → Status flags outdated templates in red near the bottom of the system report.
7. Check the checkout page is the page WooCommerce thinks it is
The one people miss. A site migration, a page duplication, or a well-meaning redesign leaves two checkout pages, and WooCommerce is pointed at the wrong one. Confirm the assignment under WooCommerce → Settings → Advanced → Page setup, then open that exact page in the editor and verify it actually contains the Woocommerce checkout block or shortcode. An empty or duplicated checkout page produces exactly the symptom that sends people down a two-day plugin hunt.
When it is the hosting, not the store
If your fix list keeps landing on caching you cannot control, execution timeouts, or a server that struggles the moment three people check out at once, no plugin will solve it. Managed WooCommerce hosting with proper cart and checkout cache exclusions removes an entire category of these failures — Cloudways is what we most often move struggling stores to, mainly for the Varnish exclusion controls and staging environments that make step 6 safe to run.
The short version
Work in order: fatal-errors log, gateway-versus-block compatibility, caching, nonces, server limits, conflict test, page assignment. Six of the seven are checks, not changes, and most broken checkouts are identified before you alter a single setting. Resist the urge to start deactivating plugins on a live store — that is how a lost afternoon turns into lost orders.
Need this fixed properly? Intec Infosys handles WooCommerce development, payment gateway configuration and checkout debugging on live stores. Get in touch at intecinfosys.com.
