Checkout not working and customers cannot pay

Before opening a single log, answer four questions, because each answer removes whole families of causes. You can answer all four in fifteen minutes with your own devices and a colleague's phone. The pattern is diagnostic on its own. A failure that hits everyone points at something global: a script error, an expired credential, a broken deploy. A failure confined to one payment method points at that gateway and nothing else. Mobile-only failures usually mean a JavaScript error that fires only on a touch layout, or a script that behaves differently below a breakpoint. Logged-in customers succeeding while guests fail points almost immediately at page caching, since logged-in sessions normally bypass the cache. Write the answers down before you start changing things — you will need them if you end up briefing someone else, and memory degrades under pressure.

• Every customer, or a subset you can describe?
• One payment method, or all of them?
• Mobile only, desktop only, or both?
• Guests only, or logged-in customers as well?

Open the store in a private window, put developer tools on the console, and run a checkout attempt until it fails. Two panes matter. The console shows JavaScript errors, and an uncaught error thrown before the checkout script binds its handler is the classic cause of a place-order button that does nothing at all: you click, and no request is ever sent. The network tab shows whether a request was made and what came back — a 500 from admin-ajax.php or the Store API, a 403 from a firewall or bot filter, a timeout, or a clean response the page then fails to act on. That distinction between no request, failed request and ignored response splits the remaining possibilities into three separate investigations. Mixed content belongs here too: a script or payment iframe loaded over http on an https page is blocked outright by the browser.

• Console: an uncaught error before the handler binds
• Network: was a request sent, or none at all
• Status codes: 500, 403, or a silent timeout
• Mixed-content warnings on an https page

Now compare two sources of truth. Order status in WooCommerce tells you what your store believes happened; the gateway dashboard tells you what happened to the money. Four combinations, four different faults. No order and no transaction means the request never reached the gateway at all. An order stuck on pending alongside a successful charge means the webhook or return URL that confirms payment is not arriving — the most common gateway fault after credentials. A decline visible in the gateway is not your code, and the reason is written down for you. An order marked failed with no gateway record usually means authentication. Credentials expire quietly: API keys get rotated, a certificate lapses, a live key is swapped for a test key during unrelated work, an account is put under review. Check key age, mode and account notices before blaming your site.

Checkout is not a single request. It recalculates shipping rates, taxes and sometimes address validation on every meaningful change, and those calls frequently go to third parties: a carrier rate API, a tax service, an address lookup, a fraud check. When one of them is slow or down, the calculation never resolves and the order cannot be submitted. The button spins or does nothing, no payment is ever attempted, and the whole thing reads as a broken interface rather than an integration outage. The same category covers validation that rejects legitimate input: a phone field refusing international formats, a postcode pattern that excludes a valid region, a required state field for a country without states. Test deliberately outside your usual pattern. In a rebuilt storefront this surface can stay native WooCommerce through a hybrid handoff, which keeps the payment step exactly where it is.

WooCommerce keeps the cart in a session, so pages that display cart state must be excluded from full-page caching. When a caching plugin, a CDN or a new server-level cache starts serving cached cart, checkout or account pages, customers see an empty basket they just filled or somebody else's state, and the nonces embedded in that cached HTML expire — producing an error that wipes the form and looks random. The signature is what you established in step one: logged-in customers fine, guests broken. Check the cache exclusion rules for cart, checkout and my-account, then check whether a recent plugin update or host-level change quietly reset them. Cart fragments are the other half of this story, since the AJAX call keeping the mini-cart current is a frequent casualty of aggressive optimisation plugins, and plugin conflicts are worth mapping properly once the fire is out.

Two rules that cost people real money when ignored. First, do not debug a live checkout by editing production. Deactivating plugins one at a time on a store that is taking orders breaks the site for whoever is mid-purchase, and a theme file edited under pressure is how a one-hour incident becomes a three-day one. Reproduce on staging, or on a clone with the gateway in test mode. Second, when payments are down the priority is restoring service, not understanding it. Roll back the last change — the update, the plugin, the tracking script marketing added yesterday — before you form a theory. The explanation can wait until money is moving. There is also a case where this is not your problem at all: gateway-wide outages happen, so check the provider's status page early. If it is their incident, the correct action is to tell customers and wait, not to buy engineering work.

Failed payments leave a trail, and some of that revenue is recoverable. Start in WooCommerce with every order in pending, failed and on-hold status across the outage window, then reconcile each one against the gateway. Charges that succeeded while the order stayed pending should be completed manually, because the customer has paid and is waiting for a confirmation that never arrived. Authorisations that were never captured need a decision before they expire. Then look at people who never reached an order record at all. Abandoned cart data, plus checkout attempts recorded in your logs, give you a list worth an honest email: a short note saying checkout failed for a period, that it is fixed now, and here is your cart. That message tends to outperform a discount, because the objection was never price. Separate genuine card declines first so you are not chasing them.

Almost every checkout outage is caused by a change, which makes prevention mostly a matter of process. Three things carry the load. A staging environment that mirrors production, so updates land there first and checkout is exercised before customers meet it. A checkout smoke test after every update — plugin, theme, WordPress core, PHP version — where a human places a genuine order end to end and confirms it appears in both the store and the gateway. And monitoring that places a test order on a schedule rather than pinging the homepage, because the homepage stays cheerfully up while checkout dies, and that gap is exactly where silent revenue loss lives. None of this is exotic, and it is what an ongoing maintenance arrangement exists to cover. If nobody owns it, it does not happen, and the next update finds the same weakness.

• Apply every update on staging before production
• Place one real test order after each update
• Monitor checkout itself, not just the homepage
• Keep a rollback path to the last known-good state