WooCommerce checkout not working - diagnosis by symptom

A broken checkout is not the same thing as weak conversion - in a failure nobody can buy however much they want to, and you fix it in a completely different way. That distinction is worth drawing up front, because mixing the two is why people spend weeks shortening a form in a store where the order button simply does not work on mobile.

If your symptom is “I have traffic but few orders”, this is not the piece - there the problem is in the path and in trust, and I break it down in technical reasons carts get abandoned. If your symptom is “you cannot place an order”, you are in the right place.

Below are the six symptoms I see most often, each with causes in order of likelihood and a specific place to check.

Step zero: reproduce the failure and note the conditions

Before you change anything, establish exactly under what conditions the checkout fails. Four questions:

On what - phone or desktop, which browser? JavaScript failures are sometimes visible in only one.
With what in the cart - any product or a specific one? Virtual products, variable products, add-ons and bookable items all travel through different code.
With what address - a “no shipping methods” failure almost always depends on country and postcode.
Logged in or as a guest? That is the fastest test for session and cache problems.

Write the answers down. Half the diagnosis is establishing whether the failure hits everyone or one case - and that changes where you have to look.

Always test in a private browser window. Your own window carries a session, cookies and admin privileges that make half the cache problems invisible.

Symptom 1: the checkout page is blank or white

The /checkout/ address opens but there is nothing on it - or just the footer.

Causes in order:

A PHP error stopping the render. Most often after a plugin or theme update. You can check straight away by enabling debug mode (described below) - the log will hold the file name and line number.
The checkout page lost its content. WooCommerce needs either the [woocommerce_checkout] shortcode or the checkout block on that page. If somebody edited the page in a builder and saved it without that element, the checkout stops existing. Check WooCommerce → Settings → Advanced for which page is set as the checkout page, then open it in the editor.
The theme overrides the checkout template with an outdated version. Check WooCommerce → Status: the templates section flags a warning if the theme contains stale WooCommerce files.

If the white screen covers the whole store rather than just the checkout, that is a different failure - I described it in the pieces on the white screen of death and the critical error.

Symptom 2: the checkout redirects to the cart or says “your cart is empty”

The customer adds a product, clicks through to checkout and lands back in an empty cart. This is one of the most common reports and it is almost always about the session.

WooCommerce keeps cart contents in a user session tied to a cookie. If the cookie does not arrive or the session cannot be found, the cart is empty as far as the server is concerned - even if it showed three products a moment earlier.

Causes in order:

Page caching covers the cart and the checkout. That is cause number one. The /cart/, /checkout/ and /my-account/ pages have to be excluded from caching in every layer: the cache plugin, the server cache, the CDN. It is enough for one layer to serve stored HTML and everybody sees the first customer’s cart, or an empty one.
A site address mismatch. A store reachable with and without www, or over http and https, sets cookies separately for each version. Moving from one to the other loses the cart. One canonical version, 301 redirects from the rest.
The WooCommerce session table is bloated or corrupted. Sessions live in a separate table and on a busy store can grow to hundreds of thousands of rows, which slows every read until it times out.
A security or cookie-consent plugin blocks the session cookie. Some consent banners block all cookies until acceptance - including functional ones the store cannot run without. WooCommerce cart cookies belong in the strictly necessary category, always.

Symptom 3: the “Place order” button does nothing

The form is filled in, the customer clicks and nothing happens - no error, no reload. This is nearly always a JavaScript error that stopped the script handling form submission.

Checking takes a minute: open the checkout, press F12, go to the Console tab and click the button. You will see a red message naming the file that fell over - and that usually points straight at the culprit.

The most common causes:

A plugin loading its own copy of jQuery alongside WordPress’s. Two versions in one page cancel each other’s event handlers.
An optimisation plugin combining and minifying scripts. Combining JavaScript files into one is the most frequent cause of a checkout failure in a store that “worked yesterday”. Disable combining and minification on the checkout page and test again - that is a thirty-second check.
A 403 or 400 error on a call to admin-ajax.php or the Store API. You see it in the Network tab as a red request. The cause is usually an application firewall on the hosting side, or a security plugin blocking a request carrying address data as “suspicious”. The fix is a firewall exception for the checkout URLs.
An error in the payment gateway’s script - the console message will then name a file inside the gateway plugin.

Symptom 4: “No shipping methods available”

The customer enters an address and instead of a delivery cost gets a message that shipping is unavailable. The order cannot be placed.

This is almost never a code failure - it is shipping zone configuration. WooCommerce → Settings → Shipping:

The customer’s address falls into no zone. Zones work as filters on country, region and postcode. A customer outside the defined areas drops into the default zone (“Locations not covered by your other zones”) - and that one is often empty.
The zone exists but has no method in it. A zone on its own does nothing; it needs a method added: flat rate, free shipping or local pickup.
A free shipping condition blocks everything. If the zone holds only free shipping over 300 PLN, a customer with a 100 PLN cart has no option at all. Always leave one unconditional method in the zone.
Shipping classes with no rate defined. If a product has a shipping class assigned and the method has neither a rate for that class nor a “no class” rate, the method vanishes from the list.
A carrier plugin getting no answer from its API and showing no option. In that case the WooCommerce logs (WooCommerce → Status → Logs) will hold the plugin’s connection error.

Control test: add a temporary flat rate of 0 to the zone and check whether it appears. If it does, the problem is in method configuration, not in the checkout.

Symptom 5: no payment methods after moving to the block checkout

The customer reaches the payment section and there is nothing there, or only bank transfer, even though the gateway is enabled in settings.

The cause is nearly always the same: the gateway plugin does not declare compatibility with the block checkout. The block checkout does not render legacy payment methods automatically - each one has to register itself in the blocks payment method registry. A plugin that does not do this throws no error; it is simply absent from the list.

Three ways out, in order:

Update the gateway plugin. Most large providers have supported the block checkout for a long time, but stores with frozen updates sit on versions from before that change.
Check whether the provider has a newer plugin under a different name - some rewrote their integrations from scratch instead of updating the old one.
Go back to the classic checkout temporarily (described below) and plan the migration calmly.

The same applies to shipping and invoicing plugins - moving to the block checkout means checking the whole set, not just payments. How to plan an update like that so you do not discover the problem in production is written out in the safe update checklist.

Symptom 6: the order sticks at “pending payment” despite being paid

The customer pays, the bank confirms, the money is there - and in the store the order sits at “pending payment” and nobody gets an email.

Here the failure is not in the checkout but in the callback from the payment provider. Once the payment settles, the gateway sends the store a notification that changes the status. If that notification does not arrive, the order stays put.

Where to check, in order:

The order notes in the admin, right-hand column. Every attempt at communication with the gateway leaves a trace there, and it is the first place I look.
WooCommerce logs (WooCommerce → Status → Logs) - gateway plugins record API responses there.
The provider’s own dashboard - each one keeps a history of notifications sent, with response codes. Anything other than 200 means the store rejected the request.
The hosting firewall and the security plugin - the most common culprit. The request arrives from the provider’s server, looks unusual and trips a blocking rule. The fix is whitelisting the provider’s addresses.
Cache on the thank-you page - it can show a customer a stored page belonging to somebody else’s order.

The symptoms of this problem can look identical to a checkout failure while the cause is entirely different - which is why I described it at length in the payment gateway comparison.

The tools you diagnose this with

Four things without which the diagnosis is guesswork:

The browser console (F12). The Console tab shows JavaScript errors, the Network tab shows requests that came back with an error. That is the first place to look on any “nothing happens when I click”.
WordPress debug mode. In wp-config.php you set WP_DEBUG and WP_DEBUG_LOG to true and WP_DEBUG_DISPLAY to false - errors then land in wp-content/debug.log rather than in front of customers. Turn it back off after the repair.
WooCommerce logs - WooCommerce → Status → Logs. Gateways, shipping plugins and integrations write there in plain terms what went wrong.
A copy of the store for testing. Disabling plugins on a live store in the middle of the day is a standing order for a second failure.

Bisection, when the logs show nothing

The classic that always works, dull as it is:

Take a backup and work on a copy of the store.
Switch the theme to a default one. Checkout works? The theme is guilty.
Disable every plugin except WooCommerce and the payment gateway. Works? One of the disabled ones is guilty.
Switch them back on half at a time, checking the checkout after each round. With twenty plugins you find the culprit in five steps, not twenty.

Once you know which plugin, you have three options: update it, replace it, or report it to the author with the exact console error. Keeping a plugin disabled as “the fix” only counts when nobody needs it.

The emergency workaround: back to the classic checkout

If the failure arrived together with the move to the block checkout and the store is down, you have a fast way out. Open the checkout page in the editor, delete the checkout block and put the [woocommerce_checkout] shortcode in its place. The store returns to the classic implementation, where the old plugins and old snippets work.

Treat it as a plaster, not a solution. The block checkout is the direction WooCommerce is going, and in a year some plugins will support only that. But a plaster that restores sales the same afternoon is worth its price - you do the migration later, on a copy and without the rush.

The diagnostic order in short

Reproduce the failure in a private window and note the conditions: device, product, address, logged in or guest
Open the browser console (F12) - the red error names the file
Check the Network tab for requests returning 400, 403 or 500
Look at the order notes and at WooCommerce → Status → Logs
Enable debug mode and read wp-content/debug.log
Check the shipping zones and the cache exclusions for cart, checkout and account
On a copy of the store: default theme, then plugin bisection
Fix the cause, turn debug off, place a test order end to end

The first four steps take fifteen minutes and in most cases point at the culprit. If after them it is still unclear, the problem is usually on the server side, and that is where you have to read the PHP error log.

When it is not a checkout failure

Three situations that look like a failure and are not, worth filtering out before you start digging:

The checkout takes a very long time but eventually works. That is a performance problem, not a failure - I covered it in why a WooCommerce store is slow.
Customers reach the checkout and do not finish. That is conversion, not a failure; the causes and repair order are in abandoned carts.
Orders arrive but nobody gets an email. The checkout is working correctly; the problem is in how the store sends mail - authenticated sending, SPF and DKIM records on the domain, the job queue. That is a separate diagnosis, unrelated to the checkout.

FAQ

The checkout works for me but customers say they cannot buy. How do I check? Test in a private window, logged out, on a phone and on mobile data. A logged-in administrator bypasses the cache, has different privileges and often a different set of scripts - which is why everything works for you. Ask the reporting customer for the exact symptom and a screenshot too; “it does not work” cannot be reproduced without that.

Can a checkout failure lose me orders? Orders already placed are safe - they sit in the database and a checkout failure does not touch them. What you lose are the ones customers never got to place, and there is no trace of those in the panel. That is why with a broken checkout the unit is the hour, not the day: a store that cannot take orders is closed.

The checkout broke after a WooCommerce update. Should I roll it back? Rolling back WooCommerce itself is rarely the right answer, because the problem usually sits in a plugin that did not keep up with the change. Bisection finds the culprit faster. If you have to restore sales immediately, restore the backup from before the update and do the diagnosis on a test copy.

Is a 403 error on admin-ajax.php a hosting problem? Most often yes - an application firewall on the server or in a security plugin blocking a request carrying address data. Report it to the host with the exact request URL and the time; in the firewall logs they will see the rule that blocked it and add an exception. The admin-ajax.php address itself is a perfectly ordinary part of WordPress, not a sign of a break-in.

How long does fixing a broken checkout take? If the cause is a conflicting plugin, caching or a shipping zone - hours, not days. Diagnosis is usually fifteen minutes to two hours, the repair about the same. It takes longer only when an integration has to be rewritten for the block checkout, or when the failure landed on top of another problem such as an overloaded server. I give the specific figure after looking at the store, always in writing, before we start.

Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.