An emptied cart is one of the most frustrating checkout failures because the store can look healthy until the buyer reaches the critical step. Cache configuration, cookies, session handling, Store API behavior or plugin conflicts can all produce the same visible symptom: the cart disappears before payment.
The useful proof does not store a real customer's cart. It shows the step, the expected signal, the observed signal and the timestamp.
Recognize the symptom
A cart emptied failure can appear as a redirect to an empty cart page, a checkout message saying the cart is empty, shipping totals disappearing, or payment methods vanishing because WooCommerce no longer sees anything to pay.
This is different from a WooCommerce checkout stuck, where the cart exists but the order never reaches a final state. It is also different from WooCommerce payment failed, where the payment step is reached but abnormal.
Verify in the right order
Start with a simple synthetic product. Avoid coupons, logged-in accounts and complex variations while isolating the cart state. The expected result is stable: the item appears in the cart, remains visible at checkout and keeps a coherent total.
Then compare the journey with cache active and after cache purge. If the issue disappears after purge, cache becomes the leading track. If it stays identical, inspect cookie domain, HTTPS redirects, language or currency routing and consent rules.
Check the Store API too. A modern checkout may render while `/wc/store/v1/cart` returns an empty state, malformed JSON or an unexpected status. A 200 response is not enough; the synthetic cart must still exist functionally.
Interpret the result
If cached HTML is served for cart or checkout, fix cache exclusions across plugin, server and CDN layers. If the cookie changes or disappears, investigate session domain, HTTPS, consent settings and redirects. If Store API becomes empty while cookies remain stable, review cart, shipping, taxes, coupon, currency and Checkout Blocks plugins.
| What you observe | Where to look | Likely lead |
|---|---|---|
| The cart reappears after a cache purge | Plugin, server and CDN cache layers, exclusions for cart, checkout and account pages | Cached HTML was served and ignored the real cart |
| The session cookie changes or disappears while browsing | Session domain, HTTPS, redirects, consent settings | Session continuity breaks before payment |
| `/wc/store/v1/cart` returns an empty cart while cookies stay stable | Cart, shipping, taxes, coupon, currency and Checkout Blocks plugins | A 200 status is not enough: the functional state is empty |
The goal of the first proof is not to name a perfect root cause. It is to reduce the search area without exposing customer data.
Controlled lab example
Starting point: a test store with a new full-site page cache plugin enabled. Reproduced failure: the synthetic product is added correctly, the cart page shows one line, then checkout redirects to an empty cart. The home page, cart URL and checkout URL all answer HTTP 200, but the business signal fails.
Ruled-out hypotheses: it is not a blocked session cookie (the cart existed before checkout), not a Store API outage (it responds, but with an empty cart served from cache), not a domain problem (a single origin in the journey). The report then keeps the journey, time window, failing step, observed signal and recovery proof after the checkout is excluded from the cache rule. It does not keep customer identity, card data or real cart contents.
Confirm recovery
Do not close the incident after one lucky page load. Replay the same path with a clean session, verify the cart reaches checkout, then make sure expected payment methods remain visible.
Prevent recurrence
Most cart-emptied incidents follow a change: a new cache layer, a consent or domain change, a WooCommerce update. Never cache cart, checkout and account pages publicly, re-check cookies after any domain or consent change, test the Store API after each WooCommerce update, and keep a monitor on the product-to-checkout transition so a relapse is caught before the customer.
The broader monitoring model is explained in features. For a first diagnosis, ask for a free audit, then compare cadence and history in plans.