WooCommerce checkout not working
WooCommerce checkout is not working when the page stays blank, the spinner never stops, the cart arrives empty, or Place order never creates a paid order. Open the browser's network log and read the failing request's status, exclude cart and checkout from cache, then test with Storefront and only WooCommerce active.
For WooCommerce store owners losing orders at checkout who need to find the failing request and fix it without risking live payments.
knowledge
- Read time
- 6 min
- Sections
- 9
- Updated
- 14 Nov 2026
- Written by
- WebJi® team
Last editorial update: 14 November 2026.
What is a broken WooCommerce checkout actually doing?
A WooCommerce checkout is "not working" in one of four distinct ways — a blank page, a spinner that never clears, a cart that arrives empty, or a payment that never marks the order paid — and each points to a different cause. Name the symptom before changing any setting.
Test with one in-stock product and no coupon, and note the browser, whether you are logged in, and the time. If Place order was already clicked, check WooCommerce › Orders before clicking again; a second click can create a duplicate order.
| What you see | What usually failed | Fixed when |
|---|---|---|
| Blank or half page | A PHP fatal error or a script that stopped the form | The form renders and a reload shows no new console error |
| Spinner never stops | The update request hangs, is refused, or returns an HTML page | Totals and payment methods load and the request completes |
| Empty cart at checkout | The session or a cached cart dropped the items | The product is still in the cart in a private window |
| Payment never completes | Gateway keys, the gateway's callback to the store, or a request that dies after Place order | Test mode creates one order and the gateway shows that payment |
Is your store using classic checkout or the Checkout block?
Check the page set under WooCommerce › Settings › Advanced: a Checkout block talks to the Store API under /wp-json/wc/store/, while a shortcode or Classic Shortcode block uses wc-ajax calls such as update_order_review and checkout.
Do not swap one type for the other as a first test. A plugin may support only one, so switching hides the clash you are trying to find.
- Checkout block: the editor shows the Checkout block; failed calls appear under the Store API.
- Classic checkout: the page holds
[woocommerce_checkout]; failed calls include?wc-ajax=update_order_reviewor?wc-ajax=checkout. - Either way: save the request URL, HTTP status and the first console error.
In what order should you troubleshoot checkout?
Work on a staging copy where possible, switch the gateway to test mode so retries cannot charge a card, and change one thing between tests.
- Note the checkout type and the symptom; do not swap the checkout type yet.
- In the browser's Network panel, filter Fetch/XHR, reproduce once, and save the URL, status and response type.
- Exclude Cart, Checkout and My Account from every page cache, purge, and retest in a private window.
- On staging, switch to the Storefront theme with only WooCommerce active, then re-enable plugins one at a time.
- Match the request host to the HTTPS checkout URL, then place one gateway test-mode order before restoring live keys.
- If the cart empties, clear that browser's site cookies and the store's customer sessions, then add one product.
- If the same request still returns 403, 406, 500 or a security page, stop retrying live payments and contact the host with the details.
What does the checkout request status tell you?
The HTTP status of the failing checkout request usually names the culprit: pending means something is slow, 500 means PHP crashed, 403 or 406 means a security rule refused it, and 404 means the URL or rewrite rules are wrong.
| Status | Meaning | Look next |
|---|---|---|
| Pending | Waiting on PHP, the database or an external service | Slow queries, gateway or shipping API timeouts |
| 500 | PHP stopped with a fatal error | WooCommerce fatal-errors log and the host error log for that minute |
| 403 | Refused by a security plugin, firewall or stale nonce | Security plugin logs; reload checkout for a fresh nonce |
| 406 | Refused by a server firewall rule (often ModSecurity) | Host firewall log for the request |
| 404 | Wrong request URL or broken rewrite rules | Settings › Permalinks › Save to flush rules |
| 200 with an HTML body | A cache, login page or PHP warning replaced the expected JSON | Cache exclusions and WP_DEBUG_DISPLAY off |
A response body of just -1 usually means a stale nonce: reload checkout and try again.
Why does caching break the cart and checkout?
Cart, Checkout and My Account change for every visitor, so a cached copy can freeze a nonce, show another customer's cart, or return a stored page to a request that expected live data. Exclude those pages from page cache and let WooCommerce AJAX and Store API requests pass through any CDN or firewall uncached.
After setting exclusions, purge every cache layer — plugin, server and CDN — and retest in a private window. Routine purging is covered in clear the WordPress cache. A store that outgrows a shared cache setup fits WooCommerce hosting that already bypasses those URLs.
How do you confirm a plugin or theme clash?
On staging, activate Storefront and deactivate every plugin except WooCommerce; if checkout now works, re-enable plugins one at a time until the failure returns, and that last one is the clash.
If checkout still fails with only WooCommerce and Storefront, the cause is outside that set: the request URL, an unexcluded cache, the gateway or the server. Read the first console error and the file under WooCommerce › Status › Logs. Fatal errors also land in the WordPress error log. If the break followed an update, roll that one plugin back on staging to confirm.
When are HTTPS or the payment gateway the problem?
Compare the checkout URL in the address bar with the request URL: an old domain, a www mismatch or an http call from an https page is blocked by the browser before WooCommerce even runs. Do not force WordPress Address and Site Address to match if WordPress lives in its own directory; check with the host first.
If no payment method appears, confirm the certificate is valid and there is no mixed content. If only one method fails, put that gateway in test mode and place one order; it is fixed when both the store and the gateway dashboard show that payment. UPI and card set-up for one Indian gateway is in Razorpay for WooCommerce.
Why is the cart empty at checkout?
An empty cart right after adding a product is a session problem, not a payment problem: a cached cart page, a blocked cookie or an oversized sessions table drops the items on the next page load.
Clear the site cookies in your browser, or use WooCommerce › Status › Tools › Clear customer sessions where available, then retest as a guest with one product. If the sessions table keeps growing, ask the host to check its size. Clearing sessions does not delete orders.
When should you contact WebJi® support?
Contact support when the same request keeps returning 403, 406, 500 or a security page, because that is a server rule, a PHP fatal error or a resource limit that more clicks will not clear.
Email support@webji.services with the checkout type, request URL, status, time and the first log line, and say whether it affects guests, logged-in customers or both. Support answers 24/7 in Hindi and English with an average first reply under 60 minutes. Never send card numbers, cookies or gateway secret keys.
Frequently asked questions
Why did checkout break after a plugin update?
An update can change a checkout script, a template override or a gateway callback. Note what changed, then run the Storefront test on staging or roll that plugin back. Check WooCommerce › Status for outdated template overrides in your theme.
Can a shipping plugin break checkout?
Yes. Live-rate shipping plugins call courier APIs while totals update, and a slow or failing API leaves the spinner running. Test with a flat-rate method; if checkout then works, check the shipping plugin's logs and API keys.
Why do orders stay "Pending payment" after customers pay?
The gateway's notification back to your store (webhook or IPN) is not arriving or is being blocked. Check the webhook URL and secret in the gateway dashboard, confirm a firewall is not blocking it, and look for failed deliveries in the gateway's webhook log.
Where are the WooCommerce logs?
In wp-admin, go to WooCommerce › Status › Logs and choose the file from the minute the order failed; fatal PHP errors have their own log there. For a 500 error, also check the host's PHP error log for the same time.
Last editorial update: 15 November 2026.
Ready to get started with WebJi®?
Join 12,000+ businesses across India and overseas. INR pricing, 18% GST shown before payment and 24/7 email support in Hindi and English — average first reply under 60 minutes.