Short answer: the checkout spans browser JavaScript, session and cart state, the server request, the payment gateway, and order creation. The same visible symptom can come from any of them, so identify the failing layer before touching configuration.
Protect the data first
Do not retry payment repeatedly with a real card, and do not delete failed orders to tidy up — those records and the gateway’s transaction log tell you whether money moved. Note the time, payment method, device and any transaction reference before changing anything.
Watch the failing request in the browser
Open developer tools, go to Console and Network, and attempt the checkout. A red JavaScript error points at a script conflict or a broken minify setting. The key request is ?wc-ajax=checkout: if it returns 500 or times out, the failure is server-side and its response often contains the PHP error itself.
Read the WooCommerce logs
Go to WooCommerce › Status › Logs for gateway logs and fatal errors with timestamps, and Status › System Status for an outdated database, a stale template override, or a plugin conflict. Match a failed test’s time against the log to see whether the order was created, whether payment was attempted, and where the chain broke.
The usual culprits
- Caching: the checkout page must never be cached — a stale page carries an expired nonce that blocks submission. Exclude cart, checkout and my-account from full-page cache and the CDN.
- JS optimisation: aggressive minify/combine breaks checkout scripts; exclude them.
- Plugin conflict: test on staging rather than deactivating payment or tax plugins on the live store.
- Gateway callback: an authorisation that succeeds without confirmation leaves the order stuck.
Verify the whole cycle
Use the gateway’s test mode or a controlled low-value order and walk product → cart → checkout → payment → confirmation. Then verify the order status, stock movement, confirmation email and webhook. A checkout is only repaired when the full cycle completes coherently, not when the visible error disappears.
WP REPAIR INCIDENT STANDARD
Safe intervention sequence
Checkout is a chain across browser JavaScript, session state, server validation, gateway communication, order creation, stock and notifications. The first broken transition identifies the layer to repair.
- Capture browser console and the wc-ajax checkout response for one controlled attempt.
- Match the attempt timestamp to WooCommerce fatal and gateway logs.
- Verify cart, checkout and account pages are excluded from full-page cache and CDN caching.
- Use gateway test mode or a controlled low-value order and record every state transition.
What must be verified
- A controlled order completes from product to confirmation.
- Gateway transaction and WooCommerce order reference each other.
- Stock, email and webhook outcomes are correct and repeatable.
Official technical sources
This guide explains the diagnosis. If the site is affected now, the intervention should preserve a rollback path and verify the real business journey.
See the emergency repair service →ABOUT THIS SYMPTOM
Frequently asked questions about this guide.
Should I retry a failed checkout with a real card to see if it works?+
No, avoid repeated real-card attempts and don't delete the failed orders either. Those records, along with the gateway's transaction log, are exactly what tells you whether money actually moved, and destroying them removes the evidence you need to diagnose the failure.
What single request should I watch in the browser to see where checkout actually breaks?+
Watch the ?wc-ajax=checkout request in the Network tab while attempting checkout. If it returns a 500 error or times out, the failure is server-side, and its response often contains the underlying PHP error directly.
Can caching really break checkout even if the rest of the site loads fine?+
Yes, and it's one of the most common causes. The checkout page must never be served from cache, because a stale cached copy carries an expired security nonce that blocks submission, so cart, checkout, and my-account pages need to be excluded from full-page caching and the CDN entirely.
How do I know if the problem is really fixed, versus just the visible error going away?+
Walk the full cycle end to end using the gateway's test mode or a controlled low-value order: product, cart, checkout, payment, confirmation. Then verify order status, stock movement, the confirmation email, and the webhook all completed coherently, not just that the checkout page stopped showing an error.