A checkout spinner that never finishes usually means the browser sent an order request but did not receive a response it could use. The cause may be a PHP error, a slow payment gateway, a blocked AJAX request, a broken WooCommerce session or JavaScript that fails while processing the response.
Do not keep pressing the button. First confirm whether WooCommerce created an order or the gateway took payment, because repeated attempts can produce duplicate orders or charges.
Preserve one failed attempt
Record the exact time, customer email, cart contents, payment method, browser and displayed total. Use a controlled test product and a gateway test mode when available. If the fault affects live customers, check recent orders and the payment provider before reproducing it.
Look for orders created at the test time, including Pending payment, Failed and Draft orders. A created order changes the investigation: the failure happened after WooCommerce began processing checkout.
Inspect the checkout request
Open the browser developer tools, select Network, submit once and inspect the request containing wc-ajax=checkout. It should finish with an HTTP response and usually returns JSON.
Request: /?wc-ajax=checkout
Useful evidence:
- status code
- response time
- response body
- redirect or blocked-request messageA 500 response points towards PHP or server failure. A 403 may come from a firewall or security rule. A request left pending suggests an upstream timeout, locked PHP worker or slow external call. A 200 response containing HTML instead of JSON often indicates a warning, login page or cached error contaminating the response.
Correlate PHP and WooCommerce logs
Check WooCommerce > Status > Logs and the hosting PHP error log for the same timestamp. Temporarily enable WordPress debug logging only if you can prevent public error display and personal data exposure.
Do not treat every old warning as the cause. Match the request time, file and call stack. Fatal errors in a payment plugin, checkout-field extension or theme override are stronger evidence than unrelated scheduled-task notices.
Separate gateway delay from checkout failure
Repeat in a safe test environment with an offline payment method such as Direct bank transfer. If offline checkout completes but the normal gateway spins, inspect gateway credentials, API reachability, web application firewall rules and the gateway log.
If every method fails, focus on WooCommerce, PHP, sessions and shared checkout customisation. Never switch a production gateway into test mode without understanding how it affects real customers.
Check sessions, cache and background calls
Exclude Cart, Checkout and My account from full-page cache. Confirm that WooCommerce cookies survive between the product, cart and checkout pages. Cloudflare and WordPress cache rules must not serve one visitor’s checkout state to another.
Use a private window for a clean session, but retain the failing session separately. Clearing every session immediately destroys useful evidence and logs out customers without proving the cause.
Test JavaScript without hiding the server problem
Inspect the Console for the first error, not the longest cascade. A consent tool, address autocomplete, analytics tag or checkout-field script may intercept submission. Test by disabling one suspected integration in staging or with a controlled request, never by deactivating random plugins on the live store.
The browser may show a script error because the server returned invalid content. Read the checkout response before concluding that JavaScript is the root cause.
Repair and verify the complete transaction
Apply the smallest evidence-backed correction: update or roll back one incompatible component, repair the fatal PHP path, correct caching, increase a genuinely exhausted resource, or fix the gateway connection.
Then verify guest and logged-in checkout, mobile and desktop, taxes, shipping, coupons, stock reduction, order emails, gateway status and the thank-you page. Confirm in both WooCommerce and the provider that the test produced exactly one order and one payment.
Urgent repair is complete only when ordering works and no uncertain transactions remain. Recurring monitoring should alert on checkout errors, gateway webhook failures and abnormal order-status patterns before another spinner becomes lost revenue.