Your WooCommerce checkout is not working — and every minute it stays broken, you're losing orders. This guide is the systematic version of what we do when a client calls us with exactly this emergency: a diagnosis tree that finds the root cause in a defined order instead of guessing, covering every major symptom — blank checkout page, endless spinner, dead "Place Order" button, orders stuck on processing, and the worst one: orders that just silently stop.
After maintaining WooCommerce stores for over a decade, we can tell you where the bodies are buried: roughly in this order, it's plugin conflicts → caching → payment gateway → theme → JavaScript errors → server. That's exactly the order we'll work through.
Emergency triage: the first 5 minutes
Before any deep debugging, three fast checks that solve a surprising share of cases immediately:
1
Clear every cache. Caching plugin (WP Rocket, LiteSpeed, W3TC), server cache (Plesk/hosting panel), and Cloudflare if you use it. Then test again in a private/incognito window. If the checkout works now, your problem is caching — jump to Step 3.
2
Check for a recent change. Did a plugin, theme or WooCommerce update run in the last 24–48 hours (including auto-updates)? Check Dashboard → Updates and your host's activity log. A checkout that worked yesterday and is broken today was almost always broken by something — find the something.
3
Check WooCommerce status. WooCommerce → Status: red warnings, outdated database, template overrides flagged as outdated? Screenshot it — you'll need it.
Store live and losing money right now?
If you have recent orders in the database and the failure started after an update: restore last night's backup or roll back the updated plugin first, debug afterwards on staging. Revenue beats root cause analysis.
Debugging without evidence is guessing. Five minutes of setup saves hours:
Reproduce in incognito, logged out, ideally on a second device and network. Admin sessions bypass caches and can mask the problem — many "broken" checkouts work fine for the shop owner and fail for every real customer.
Open the browser console (F12 → Console) and the Network tab before you load the checkout. Red console errors and failed (red) network requests are your two most valuable clues.
A blank white page will name its fatal error here, usually with the exact plugin path in the stack trace. That can identify the cause in one step.
Also check WooCommerce → Status → Logs: the fatal-errors log and your payment gateway's log (e.g. stripe) often contain the answer verbatim.
Step 2 — Plugin conflicts: the #1 checkout killer
In our agency experience, a plugin conflict — usually triggered by an update — is the single most common reason a WooCommerce checkout stops working. The classic diagnostic is brutal but definitive:
The deactivation test (on staging if possible)
1
Deactivate every plugin except WooCommerce and your payment gateway plugin.
2
Test the checkout. Works now? A plugin is the culprit — guaranteed.
3
Reactivate plugins one by one (or in halves, binary-search style, if you have many), testing the checkout after each activation.
4
The activation that breaks it names your offender. Roll it back to the previous version, check its changelog/support forum, and report the conflict.
Two ways to do this without nuking your live store:
1
Health Check & Troubleshooting plugin: its troubleshooting mode disables plugins only for your session — real customers see the normal site while you test.
2
Staging site: most hosts offer one-click staging. This is where the deactivation test belongs. (And where every future update should be tested before production — more in Prevention.)
Usual suspects, from years of incident reports: optimization/caching plugins, security plugins with aggressive firewall rules, multi-currency and B2B/pricing plugins, checkout-field editors, quantity-discount plugins, and — ironically — outdated payment gateway plugins themselves.
Step 3 — Caching & optimization: how "faster" breaks "working"
Caching plugins are essential for performance — and the most common non-obvious cause of a broken checkout. Two separate failure modes:
3a. Page caching on cart & checkout
Cart and checkout pages are dynamic per customer and must never be page-cached. WooCommerce also protects checkout submissions with nonces — security tokens with a limited lifetime. If a page cache serves a checkout that's hours old, the embedded nonce is expired, and customers get "session expired" or nonce verification errors while everything looks fine to you.
Verify your caching plugin excludes /cart, /checkout and /my-account. WP Rocket and LiteSpeed do this automatically for standard setups — but custom checkout URLs, translations (e.g. /kasse/) or landing-page checkouts fall through the cracks.
Using Cloudflare APO or "cache everything" rules? Confirm WooCommerce cookies (woocommerce_cart_hash, session cookies) bypass the cache.
Full deep-dive: our guide on how caching breaks WooCommerce checkouts and the companion piece on fixing "invalid nonce" errors.
3b. JS/CSS minification, combination & delay
Features like "combine JavaScript", "defer JS" or "delay JS execution" routinely break checkout scripts and payment gateway iframes (Stripe Elements, PayPal buttons). The symptom is usually a spinner that never stops or payment fields that never render.
1
Temporarily disable all JS optimization and retest the checkout.
2
If it works: re-enable features one at a time, and add the checkout scripts (and gateway domains like js.stripe.com) to the exclusion list.
Step 4 — Payment gateway problems
If the checkout page itself is healthy but payment fails or fields don't appear, the gateway layer is your suspect:
API keys: expired, revoked, or — the classic — test keys on the live site (or live keys on staging). Reconnect the gateway in its plugin settings. If you're testing, use the proper Stripe test cards in test mode, never real cards.
Webhooks: orders stuck on "pending payment" almost always mean the gateway's payment confirmation (Stripe webhook, PayPal IPN) never reached your site. Check the webhook delivery log in your Stripe/PayPal dashboard for failed attempts — and whether a security plugin or server firewall is blocking the callback URL.
SSL: gateways require valid HTTPS. An expired certificate or mixed-content warnings can kill payment fields silently.
3D Secure: if EU customers specifically fail to pay, test the SCA flow — an authentication modal blocked by JS optimization (see Step 3b) declines every European card while US test purchases pass.
Gateway status: rule out an outage on the provider's status page before debugging your own site. It's rare — but it happens, and it's the one cause you can't fix.
Step 5 — Theme & template issues
The fastest theme test takes two minutes:
1
Switch to Storefront or a default theme (Twenty Twenty-Four) — on staging, or briefly at night, or per-session via the Health Check plugin.
2
Checkout works under the default theme? Your theme is the problem.
Outdated WooCommerce template overrides. Themes that override checkout templates (yourtheme/woocommerce/checkout/…) break when WooCommerce updates its template structure. WooCommerce → Status → Templates lists every override and flags outdated ones — that list is your to-do.
Bundled/outdated jQuery or JS libraries conflicting with checkout scripts (this hands over to Step 6).
Checkout Block vs. classic shortcode: since WooCommerce 8.3, new installs use the Checkout Block, but many plugins and themes only support the classic [woocommerce_checkout] shortcode properly. If the checkout broke after a redesign or Woo update, test the other checkout type on a draft page — if that one works, you've found a compatibility gap.
Step 6 — JavaScript errors: when the button just… does nothing
A "Place Order" button that does nothing — no error message, no spinner, no request — is a JavaScript failure until proven otherwise. The checkout's validation and submission are JS-driven; one fatal error higher up the page stops everything below.
1
Open DevTools → Console (F12), reload the checkout, click Place Order.
2
Red errors? Read the file path in the error — it names the plugin or theme responsible. Uncaught TypeError / $ is not a function point to jQuery conflicts; errors in minified bundles like min.js files point back to Step 3b.
3
Check the Network tab: does clicking the button fire a ?wc-ajax=checkout request? If it returns 403, suspect a security plugin/WAF; 500, read the debug log (Step 1); if no request fires at all, the JS error above is your cause.
4
Also test with browser extensions disabled — ad blockers occasionally kill gateway scripts, which matters if only some customers report the problem.
Step 7 — Server-side causes
If everything above is clean, go one level down:
PHP memory & fatal errors: checkout is the most expensive page in the shop. Allowed memory size exhausted in the debug log → raise memory_limit (256M+) in your hosting panel.
ModSecurity / WAF rules: server firewalls sometimes block checkout POST requests as "suspicious" — visible as unexplained 403s in the Network tab. Your host can check and whitelist the rule.
PHP version jumps: after a PHP upgrade, older plugins throw fatals precisely on checkout. The debug log names them.
Emails not arriving (orders fine, confirmations missing): wp_mail() without SMTP is unreliable. Install an SMTP plugin with a transactional provider and check WooCommerce email settings.
Timeouts: slow external calls during checkout can exceed max_execution_time — visible as intermittent failures under load.
Verify the fix properly (not just "it loads")
A checkout that renders is not a checkout that works. After any fix, run the full flow:
1
Enable test mode in your payment gateway (or use staging).
2
Complete a purchase with Stripe test card4242 4242 4242 4242 — verify order created, stock reduced, confirmation email received, webhook delivered.
3
Run one decline test (customer must see a clear error) and one 3D Secure test (the authentication modal must open and complete).
4
Repeat once logged out, in incognito, with all caches warm — the exact conditions of a real customer.
Prevention: never find out from a customer again
Here's the pattern behind almost every case in this guide: the checkout didn't break while anyone was watching. A plugin auto-updated at 3 a.m. A cache rule changed. An API key expired. And WooCommerce's failure mode is silence — no error email, no dashboard warning. Orders just stop, and the first alert is a customer complaint or a suspiciously quiet sales day. (We've seen stores lose a full weekend of revenue this way — it's why "orders suddenly stopped coming in" gets its own guide.)
1
Update on staging first. Every plugin, theme and WooCommerce update runs on staging, checkout gets tested, then production. No exceptions for "minor" updates — those break checkouts too.
2
Test after every change — the full flow from the section above, not a page-load glance.
3
Automate the watching. Nobody manually tests their checkout every hour, at night, on weekends. That's a robot's job.
Know within the hour — not when a customer complains
ShopMonitor runs a real test purchase through your WooCommerce checkout around the clock, verifies every step visually with AI, and alerts you the moment anything breaks — plugin update, cache rule, expired key, whatever the cause. Every troubleshooting step in this guide gets easier when you know exactly when it broke.
No credit card required. Set up in 5 minutes, no code changes.
The five most common causes, in order of likelihood: a plugin conflict (usually after an update), caching or JS optimization on the checkout page, a payment gateway problem (keys, webhooks, SSL), a theme incompatibility (outdated template overrides), or a JavaScript error blocking the checkout scripts.
A white screen is almost always a fatal PHP error. Enable WP_DEBUG_LOG, reload, and read the debug log below.
wp-content/debug.log
The stack trace usually names the responsible plugin or theme directly.
That's a JavaScript failure in nearly every case. Open the browser console (F12) and look for red errors — typical culprits are JS minification/combination by a caching plugin, a jQuery conflict from the theme, or a blocked payment gateway script.
The payment gateway's confirmation callback (webhook/IPN) isn't reaching your site. Check the delivery log in your Stripe or PayPal dashboard and make sure no security plugin or server firewall blocks the callback URL. Orders on "processing" are different — that status means payment succeeded.
Use your gateway's test mode with proper test card numbers: one successful purchase, one decline, one 3D Secure run — verifying order creation, stock, emails and webhooks each time. Then repeat after every future update, because that's when checkouts break.
Because you're testing as a logged-in admin, which bypasses page caches and behaves differently. Always test logged out, in an incognito window, ideally on another device — that's the version of your store customers actually see.
About the author
Written by the Winning Solutions team — the agency behind ShopMonitor. ShopMonitor is built by founders who have been building and maintaining WooCommerce stores for over a decade. Every step in this diagnosis tree comes from real client emergencies — and ShopMonitor is the tool we built so the emergency call comes from a robot, not a customer.
WooCommerce Checkout Not Working: The Complete Troubleshooting Guide (2026) | ShopMonitor
