WooCommerce Checkout Not Working After an Update? A Diagnostic Checklist

If you're here mid-incident, work through the checklist in order — it's sequenced from most-likely and fastest-to-check down. If you're here after fixing one of these at 11pm, skip to the last section, because the real problem is that nothing told you.

First: Establish What "Broken" Means

Before touching anything, reproduce the failure yourself and note exactly where it stops. The fix path is different for each of these:

The checkout page doesn't render — blank page, fatal error, or an endless skeleton loader. Usually a PHP fatal or a JavaScript crash.

The page renders but "Place Order" fails — spinner, generic "an error occurred," or a validation complaint on fields that look fine. Usually a payment gateway, session, or AJAX/API problem — payment gateway failures have their own checklist.

The order goes through but something downstream is wrong — no confirmation email, order stuck in pending, stock not reduced. Usually a webhook, cron, or gateway callback issue.

Also check: does it fail for guests and logged-in customers? On mobile and desktop? With every payment method or one? Two minutes of scoping here saves an hour of guessing.

The Checklist, In Order

1. Check what changed last. The update log is your prime suspect list. WooCommerce core, the payment gateway plugin, the theme, and anything that touches checkout fields or shipping are the usual offenders. If a plugin auto-updated overnight, start there — plugin updates are the single most common cause of checkout breakage.

If the problem starts earlier — the product never reaches the cart — work through WooCommerce Add to cart not working first.

2. Look at the browser console, not just the page. Open dev tools on the checkout page. A red JavaScript error at load or at the moment you click "Place Order" points at a script conflict — often between the payment gateway's script and an optimization or consent plugin. The Network tab shows the failing request: a 403 there is commonly a security/firewall plugin or an expired nonce; a 500 is PHP.

3. Test with the gateway in sandbox/test mode (testing checkout without real orders; on Stripe, see WooCommerce Stripe not working). If the failure is at payment, switch the gateway to test mode (or use its test card numbers). If test mode works and live doesn't, the problem is credentials, webhooks, or the gateway's side — check the gateway plugin's own log and your account dashboard for declined webhook deliveries.

4. Rule out caching and optimization. Checkout and cart pages must never be cached, and their scripts must not be minified into a combined bundle that loads out of order. If you run a caching plugin, a CDN, or an optimizer: exclude /cart/, /checkout/, and the WooCommerce session cookie, purge everything, and retest. This one causes "works for me, broken for customers" more than anything else.

5. Do the conflict binary-search. On a staging copy if at all possible: switch to a default theme (Storefront), retest. If fixed, it's the theme. If not, disable all non-WooCommerce plugins and re-enable in halves until the failure returns. Tedious, reliable, and still the fastest route when the console gives you nothing.

6. Check the Store API and AJAX endpoints directly. Blocks-based checkouts talk to the WooCommerce Store API; classic checkouts post to admin-ajax or the checkout endpoint. If those requests return errors in the Network tab, verify a security plugin, WAF rule, or permalink change isn't blocking them — a failing Store API breaks checkout while the page itself looks perfect.

7. Read the logs where WooCommerce actually writes them. WooCommerce → Status → Logs (fatal-errors log first), plus the gateway's log if it keeps one. A fatal with a plugin path in the stack trace usually ends the investigation.

8. Roll back deliberately. Once you've identified the updated component, roll it back to the last working version and pin it until a fix ships. Rolling back blindly without steps 1–7 works too — but you won't know which update to hold back, so it breaks again on the next update run.

Symptom by Symptom: What Each Checkout Failure Usually Means

Once you know which bucket you're in, these are the specific failures behind most "WooCommerce checkout not working" reports — and where each one usually comes from.

The "Place Order" Button Does Nothing or Spins Forever

On the classic checkout, clicking "Place order" sends an AJAX request to ?wc-ajax=checkout; on the block checkout it goes to the Store API at /wp-json/wc/store/v1/checkout. Open the Network tab, click the button, and find that request:

• No request at all — a JavaScript error stopped the click handler. The console will show it.
• 403 — a firewall, security plugin, or an expired nonce, often because the checkout page was served from cache.
• 500 — a PHP fatal. WooCommerce → Status → Logs has the stack trace.
• 200 with an error in the response — a validation or payment gateway error that the page failed to display.

Checkout Sends You Back to the Cart

WooCommerce redirects an empty cart away from the checkout page. If customers bounce back to the cart and the items they just added are gone, the session isn't surviving between pages: a cached cart or checkout page, a CDN or proxy dropping the wp_woocommerce_session_ cookie, a consent tool blocking it, or a www/non-www or HTTP/HTTPS mismatch. It's the same root cause as a cart that stays empty after Add to cart.

Totals or Shipping Keep Loading

On the classic checkout, every address change triggers ?wc-ajax=update_order_review to recalculate shipping, tax and totals. If that request fails, the order summary stays greyed out, shipping methods never appear, and "Place order" may not work at all. The causes are the same as above — firewall, fatal, script conflict — plus shipping plugins that call a carrier's live-rates API: when that API is slow or down, it can stall the whole checkout.

It Works for You but Not for Customers

Logged in as an admin, you bypass most page caching and some security rules. Test the way a customer arrives: a private window as a guest, a phone on mobile data, and one real low-value order. The usual culprits are page caching on cart and checkout, a WAF or bot protection challenging real shoppers, and geolocation or currency plugins that behave differently by country.

It Only Fails on Mobile

Check the "Place order" button at phone width. A cookie banner, chat widget, or sticky bar can sit on top of it, and some themes load different scripts on small screens. Test Apple Pay and Google Pay separately: they only appear on supported devices and depend on your domain being registered with the payment gateway.

It Broke After Switching to (or From) the Block Checkout

Since WooCommerce 8.3, new stores get the Cart and Checkout blocks by default instead of the [woocommerce_checkout] shortcode. Some payment gateways, checkout field editors, and upsell plugins only hook into the classic checkout, so their fields or payment methods quietly disappear on the block version. The editor flags incompatible extensions on the checkout page; if a plugin you depend on isn't compatible yet, switch that page back to the classic shortcode until it is.

After the Fix: Make the Next Break Impossible to Miss

Here's the uncomfortable part of every checkout incident: the question is never just "what broke?" — it's "how long was it broken before anyone noticed?" For most stores the honest answer is somewhere between hours and days, and the cost of that window is larger than the cost of the bug.

The fix for the window is structural, not heroic:

Run the checkout as a scheduled journey. A real browser walks shop → add to cart → checkout → place order on a schedule and alerts you at the exact failing step, with a screenshot. That turns "checkout is broken" from a customer complaint into a named, evidenced alert minutes after the break. This is what WooCommerce monitoring means in practice — not pinging the checkout URL. The same approach, applied to billing and shipping fields specifically, is checkout form monitoring.

Re-check immediately after updates. Breakage clusters around update day, so verification should too: run the journey and the health checks right after your maintenance window instead of waiting for the next scheduled slot.

Watch the API layer too. Health checks that record the Store API and AJAX calls a page makes in a real browser surface the failing or slow requests that precede a visibly broken checkout — often before the storefront shows any symptom at all.

A checkout that fails at 9:05 and pages you at 9:10 is an anecdote. One that fails Friday night and surfaces in Monday's support queue is a revenue report. The checklist above fixes today's incident; the monitoring decides which of those two stories the next one becomes.

Summary

• Reproduce the failure first and note where it stops: the page, the "Place order" click, or after the order.
• Start with what changed last, then the browser console and Network tab — the failing request usually names the cause.
• "Place order" failures are mostly script conflicts, firewalls, fatals, or the payment gateway; bouncing back to the cart is a session or caching problem.
• Test as a guest, on mobile, and on the checkout type you actually run (block or classic).
• Then run checkout as a scheduled real-browser journey, so the next break is an alert, not a customer email.