How to fix cart not working: check in order

The cart page has to do three things at once: show what is in the cart, accept changes, and pass the shopper on. A cart that stops answering usually fails in one of those. The page may wait on a request that never returns, so the spinner keeps turning. A cached copy of the cart page may show another shopper's items, or an empty list while the header still shows one. A product that was unpublished or sold out can return an error the page never displays, so the quantity change simply does nothing.

• Change a quantity, then open the Network tab. Did a request leave, and how did it end?
• Compare the header count with the list on the cart page. Do they show the same items?
• Open the cart in a private window. Does the same item appear, or does the cart look empty?
• Remove an item and reload. Did the removal stick, or did the item come back?
• Read the console when the cart page loads. Does a coupon or shipping widget throw an error?

A shopper uses a cart through three actions, and each one leaves a different trace. Changing a quantity sends a request that should return the new totals. Removing an item sends a request that should return a shorter list. Going on to checkout usually sends the shopper to a new page, and a failure there looks like a button that does nothing. The shopper does not know which action failed, so they reload, see the old list and leave.

A cached cart page is one of the most damaging causes, because it looks like the cart works for the shopper who sees it. If the cache stored a cart page, a later shopper can receive that page with someone else's items, or with an empty list while the header shows a count. The fix is to mark cart pages as private and never cached, and to tie the cart identifier to one shopper. Check the response headers on the cart page: a cacheable cart page with a long lifetime is the fault to look for.

Some quantity changes fail on purpose. A product that is sold out, unpublished or limited to a lower quantity makes the server refuse the change and return an error. If the cart page only handles success, the refusal does nothing visible: the number snaps back, and the shopper assumes the site broke. Read the body of the refused response, which usually names the product and the limit, then show that message beside the item. A simulated visitor's report records the refused request and its status.

Checkout flow testing

A coupon box, a shipping estimate or a recommendation widget on the cart page can throw an error on load. When that happens, the script that wires up the checkout button may never run, so the button looks live and does nothing. Open the Console when the cart page loads and read the first red error, not the last one. Remove or defer the widget, then check that the checkout button works with the widget turned off. If it does, the widget was the cause.

Each new coupon, stock rule or caching change can bring the same stall back, sometimes only for shoppers who are not logged in. Rerun the same simulated visitor after each change, from a fresh private window and once on a phone. If the store sits behind a login, test with a test account, and check each preview deploy before the change goes live.