A broken checkout is the most expensive bug a store can have, because it fails quietly. The site looks fine, products load, and revenue is zero. Most owners find out from a customer email or from noticing the order list went silent. We debug these for stores regularly, and the causes cluster into a short list. This checklist works through them in the order that finds the problem fastest.
Quick answer: Most checkout failures trace to a plugin conflict after an update, a caching layer serving stale checkout pages, or a payment gateway rejection. Reproduce the failure in a private window, read WooCommerce > Status > Logs and the browser console, then test with other plugins disabled and caching excluded from cart and checkout.
How do I see what customers see?
Open the store in a private browsing window, on your phone off wifi if possible, so no admin session or cached copy interferes. Add a product and attempt a full order. Note exactly what happens, because the symptom points at the cause: an endless spinner after clicking Place order suggests a JavaScript or AJAX failure, a payment error message points at the gateway, a blank page suggests a fatal PHP error, and an “empty cart” at checkout points at caching or sessions.
Where are the error messages?
- WooCommerce > Status > Logs. Look for fatal-errors logs and any log named after your payment gateway, dated today.
- The browser console (right click, Inspect, Console tab) on the checkout page. Red errors during Place order are the trail.
- Your host’s PHP error log, usually visible in the hosting control panel.
- The payment gateway’s own dashboard (Stripe, PayPal, Authorize.net). Failed attempts show there with a reason, and no attempts at all means the request never left your site.
What are the most common causes?
- A plugin or theme update that conflicts with checkout scripts. This is the leading cause, and the timing usually matches an update within the last few days.
- Caching on the cart or checkout pages. Cached checkout serves stale security tokens and other customers’ sessions, producing empty carts and failed orders.
- A JavaScript error from the theme or a marketing script that breaks the Place order button.
- Gateway problems: expired API credentials, a webhook change, or the processor declining in a way the page does not surface.
- An expired SSL certificate, which browsers and gateways both refuse.
- Silent blockers: a shipping zone with no methods for the customer’s address, or a minimum order rule that hides the button.
How do I run a safe conflict test?
On a staging copy if you have one. If not, install the Health Check & Troubleshooting plugin and enable troubleshooting mode, which disables plugins and switches the theme for your session only while customers see the normal site. Test checkout with everything off except WooCommerce and the payment gateway. If it works, re-enable plugins in small batches, testing between rounds, until the order breaks. The last batch contains the conflict. Switching temporarily to the Storefront theme rules the theme in or out the same way.
Why does it fail only for some customers?
Partial failures have their own pattern. Declines with a reason code are the processor rejecting specific cards, which is normal at a low rate. Failures tied to certain addresses point at shipping or tax calculation for that region. Failures on one browser or device point at a script conflict, sometimes with the customer’s own extensions. And a checkout that fails for logged-out visitors while working for you is caching or session handling, close to a certainty.
How do I keep this from happening again?
Update on a schedule against a staging copy instead of clicking update on production. Confirm your caching configuration excludes cart, checkout, and account pages. Keep a card on file with your gateway’s status page for outage notices. Set up an alert for the condition that matters: zero orders for a window where you normally always have some. That one alert converts a silent multi-day failure into a same-hour fix.
What if orders are stopped right now?
This is the kind of emergency we handle. Reach out through the contact form with your domain, what the checkout shows, and when it started, and we will dig in. If you have logs from the steps above, include them, because they usually cut the diagnosis time in half.
Frequently asked questions
Why do customers see an empty cart at checkout?
Almost always caching or sessions. A caching layer is serving a stored copy of the cart or checkout page, or cart session data is being lost between pages. Exclude cart, checkout, and account pages from every cache layer, including any CDN.
Should the checkout page ever be cached?
No. Cart, checkout, and my-account pages must be excluded from page caching. Most caching plugins exclude them by default, and the problem usually enters through a CDN or server-level cache configured separately from WordPress.
How do I test checkout without charging a real card?
Use the gateway’s test or sandbox mode with its published test card numbers. If the gateway lacks a test mode, place a real low-value order and refund it. Never leave test mode on afterward, since a store in test mode collects no real money.
Checkout broke after I updated plugins. Can I roll back?
Yes. Restore last night’s backup, or use the WP Rollback plugin to return the suspect plugin to its previous version. Then re-apply updates one at a time on staging to identify the one that breaks checkout, and hold it back until a fix ships.
Is the problem my site or the payment processor?
Check the gateway dashboard. Attempts arriving and failing with decline codes is a processor-side or card-side issue. No attempts arriving at all means the request never left your site, which makes it a site problem. The processor’s status page covers outages.
Can an SSL problem stop checkout?
Yes. An expired certificate triggers browser warnings that stop customers, and payment gateways refuse to hand off to an insecure page. Check the certificate’s expiry and confirm auto-renewal is working at your host.