“Orders stopped” is a symptom, not a diagnosis — the actual break is somewhere in a funnel with four or five stations, and the fix depends entirely on which one. This lesson is the walk down that funnel, in order. You’ll want to know how to run a test order and how to find your error logs — both get used below. Works the same on WooCommerce, Drupal Commerce, or anything else with a cart.
Confirm the symptom with a test order
Before touching anything, be your own customer: private browser window, real product, walk the whole funnel with a test card. Half the “checkout is broken” calls we get are one customer’s declined card or a checkout that’s merely slow. If your test order goes through, the problem is narrower than you feared — and if it fails, you now know exactly where, which is worth more than an hour of guessing.
Find where in the funnel it dies
The funnel has stations: product page → add to cart → cart page → checkout form loads → payment submits → confirmation page. Note the last station that worked. Each failure point has its usual suspects — add-to-cart that does nothing is usually JavaScript or caching; a blank checkout page is usually a PHP fatal; a spinner that never resolves after “Place order” is usually the gateway or a fatal during submission; payment taken but no confirmation is usually the return/webhook leg. Open your browser’s console (F12) while you do this — a red JavaScript error at the moment of failure is a gift.
Check the gateway’s dashboard and status page
Log into Stripe, PayPal, or whoever moves your money. If their dashboard shows recent charge attempts, the site is reaching them and the answer to what happened next — declined, blocked, errored — is right there in the event detail. If the dashboard shows nothing arriving, the break is on your side, before the request leaves. Check the gateway’s status page too (status.stripe.com and kin) — every so often it’s simply their outage, and your afternoon is suddenly free.
Read your logs at the failure timestamp
Take the exact time of your failed test order and go
log-reading. On
WooCommerce, start with WooCommerce → Status → Logs, where gateways
write their own diaries, then the PHP error log; on Drupal Commerce, it’s
watchdog (drush watchdog:show). A fatal error at your timestamp names the
file and line — and usually the plugin or module — that killed the order.
Rule out caching of cart and checkout pages
A cached checkout serves customer A’s session to customer B, and the classic tell is an “expired session” or invalid-token error on a page you just loaded. Check response headers on the checkout URL:
curl -sI https://YOUR-STORE.com/checkout/ | grep -iE "cache-control|cf-cache-status|age"You want no-cache (or a Cloudflare status of BYPASS/DYNAMIC) and no
Age header. A HIT on a cart or checkout page is your culprit — exclude
those paths from every cache layer you run.
Roll back the last change if the dates line up
Ask the oldest question in maintenance: what changed right before it broke? Compare your plugin/module update history and deploy log against the first failed order. If a checkout-adjacent update landed the same day, roll it back on staging and test there. When the rollback fixes it, you’ve traded a mystery for a known-bad version — pin it, report it, and update when the fix ships.
Verify with a clean test order
Whatever you fixed, prove it the same way you confirmed it: fresh private window, full funnel, test card, and check that the order shows up in both your admin and the gateway dashboard. Then keep an eye on the order feed for the next few hours — a checkout isn’t fixed when your test passes, it’s fixed when strangers’ orders start landing again.