What a broken checkout is doing
Checkout is not working when the customer cannot finish an order. A blank page, a spinner that never clears, a cart that arrives empty, and a payment that never marks the order paid are different failures. Name which one you see before you change a setting.
Use one in-stock product and no coupon. Write down the browser, whether the customer is logged in, and the time. If Place order was already clicked, open WooCommerce then Orders before you click it again. A second click can create a second order.
| What you see | What usually failed | It worked when |
|---|---|---|
| Blank or half page | PHP stopped, or a script stopped the form | The form renders and a reload adds no new console error |
| Spinner never stops | The update call hangs, is refused, or returns a web page | Totals and payment methods load, and the call finishes |
| Empty cart at checkout | The session or a cached cart dropped the items | The same product is still in the cart in a private window |
| Payment never completes | Gateway keys, a notice back to the store, or a call that dies after Place order | Test mode creates one order and the gateway shows that payment |
Is this classic checkout or the Checkout block?
Open the page set as Checkout under WooCommerce, then Settings, then Advanced. A Checkout block means the browser talks to the Store API under /wp-json/wc/store/. A shortcode, or a Classic Shortcode block, means classic checkout. That page calls wc-ajax, including update_order_review while totals load and checkout after Place order.
Do not replace one type with the other as the first test. A plugin can support only one of them, so a swap hides the clash you are trying to find. Stay with the checkout the store already uses until you have the failing request.
- Checkout block: the editor shows the Checkout block, and failed calls sit under the Store API.
- Classic checkout: the page holds the checkout shortcode, and failed calls include update_order_review or wc-ajax=checkout.
- Either type: save the request URL, the HTTP status, and the first console error.
Work through the checks in this order
Do this on a staging copy when you have one. Switch the live gateway to its documented test mode so a retry cannot charge a card. Change one thing between tests, then repeat the same product, address, and payment method.
- Note whether checkout is a block or a shortcode, and which symptom you see. Do not swap the checkout type yet.
- In the browser Network panel, filter Fetch/XHR, reproduce once, and save the URL, status, and response type.
- Exclude Cart, Checkout, and My Account from page cache, purge, and retest in a private window.
- On staging, use Storefront with only WooCommerce active, then enable other plugins one at a time.
- Match the request host to the https checkout URL. Place one gateway test-mode order before you restore live keys.
- If the cart is empty, clear that browser's site cookies and the store's customer sessions, then add one product.
- If the same call still returns 403, 406, 500, or a security page, email the URL, status, and time. Stop retrying live payments.
What the request status means
On classic checkout, find wc-ajax=update_order_review while totals load, or wc-ajax=checkout after Place order. On the Checkout block, find the cart or checkout route under /wp-json/wc/store/. Save the status and whether the body is data or a web page.
A call that stays pending is waiting on PHP, the database, or a service outside the store. 500 means PHP stopped. Open the fatal log for that same minute. 403 means the call was refused by a security plugin or a stale nonce.
406 is the same family of refusal, often from a firewall rule on the server. A 404 means the request URL or the rewrite rules are wrong. If the body is a web page, a login screen, or a redirect, a cache or a warning replaced the data checkout expected.
Why cache breaks cart and checkout
Page cache must not store Cart, Checkout, or My Account. Those pages change for each visitor. A stored copy can freeze a nonce, show someone else's cart, or return a web page to a call that expected data. Let the cache and any firewall pass WooCommerce AJAX and Store API requests instead of saving them.
After the exclusions, purge every cache layer and retest in a private window. A response that is only -1 usually means the nonce was stale. Reload checkout and try the same product again. A normal page purge is covered in clear the WordPress cache. A store that outgrows a shared cache fits WooCommerce hosting that already skips those URLs.
How to tell a plugin or theme clash
On staging, activate Storefront and deactivate every plugin except WooCommerce. Open checkout with the same product. If the request now finishes, the theme or a plugin was involved. Turn plugins back on one at a time until the failure returns, and leave that one off.
If it still fails with only WooCommerce and Storefront, look outside that set. The request URL, a cache you have not excluded, the gateway, or the server is still in play. Read the first console error and the file under WooCommerce, then Status, then Logs. Fatal errors also land in the WordPress error log.
When HTTPS or the gateway is the break
Compare the checkout URL in the address bar with the request URL. An old domain, a www difference, or an http call from an https page fails in the browser before WooCommerce runs. Do not force the WordPress Address and the Site Address to be identical if WordPress lives in its own directory. Ask the host before you edit those fields.
If no payment method appears, confirm the certificate is valid and the page has no mixed content. If only one method fails, open that gateway in test mode and place one order. It worked when the store and the gateway both show that payment. Card and UPI setup for one Indian gateway is in Razorpay for WooCommerce.
Why the cart is empty at checkout
An empty cart, right after a product was added, is a session problem. The payment button is not the first place to look. A cached cart page, a blocked cookie, or a sessions table that has grown huge can drop the items on the next load.
Clear the site cookies in your browser, or use WooCommerce, then Status, then Tools, and clear customer sessions when that tool is there. Retest as a guest with one product. If the sessions table keeps growing, ask the host to check its size. Do not delete orders while you clear sessions.
When to email WebJi
Stop when the same request still returns 403, 406, 500, or a security page. That is a server rule, a PHP fatal, or a resource limit, and another click will not clear it. Email support@webji.services with the request URL, the status, the time, and the fatal line. Replies are in Hindi or English, and the average first reply is under 60 minutes.
The office number +91-141-4941811 is not a support line. Do not send card numbers, cookies, or gateway secrets. Say whether the failure hits guests, logged-in customers, or both, and whether the page is classic checkout or the Checkout block.
Frequently Asked Questions
Why is my WooCommerce checkout page not loading?
The page stays blank or keeps spinning because a script stopped, a cached copy was served, or the update request never finished. Open the network log, exclude cart and checkout from cache, and reload in a private window. If it still fails, open WooCommerce Status logs for a fatal error at that time.
How do I fix a blank checkout page?
A blank checkout is usually a PHP fatal error or a theme script that stops the page. On a staging site, switch to Storefront and leave only WooCommerce active. If the form appears, turn plugins back on one by one until the blank page returns.
Why does Place order spin and never finish?
The spinner means the browser is still waiting on the checkout update. Save the status code of that call. A call that never completes points at a slow server or a remote service. 403 or 406 means the call was refused. 500 means PHP failed and the log has the line.
How do I test plugin conflicts in WooCommerce?
Use a staging copy. Activate Storefront, turn off every plugin except WooCommerce, and open checkout with one in-stock product. If the form works, enable plugins one at a time. The plugin that brings the failure back is the clash.
Where are WooCommerce error logs?
In wp-admin open WooCommerce, then Status, then Logs, and pick the file from the minute the order failed. Fatal PHP errors may sit in a fatal-errors log. For a 500, send that same minute from the host error log as well.
Why did checkout break after a plugin update?
An update can change the checkout script, a template override, or the gateway callback. Note what changed, then run the Storefront test on staging or roll that plugin back. Leave it off if it is the only change that breaks checkout.
Why is the cart empty at checkout?
The items were dropped by a cached cart page, a blocked cookie, or a bad session. Exclude cart and checkout from cache, purge, and clear customer sessions. Add one product in a private window. That product should still be in the cart when checkout opens.
What should I send if the server blocks checkout?
Email support@webji.services the checkout type, the failing URL, the HTTP status, the time, and the first log line. Remove card numbers and cookies. The phone number on the site is the Jaipur office, not a support queue.