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 →