About seven in ten carts are abandoned — Baymard Institute puts the documented average at 70.22% across 50 studies. Most advice about that number is marketing advice: recovery emails, exit popups, free-shipping thresholds. That advice targets the single biggest reason people leave, which is cost. It does nothing for the slice of abandonment that is an engineering fault.
That slice is larger than most store owners assume. In Baymard’s survey of US shoppers who abandoned during checkout (excluding the 42% who were just browsing), 17% left because the site had errors or crashed, another 17% because the checkout was too long or complicated, 10% because their card was declined, and 9% because there were too few payment methods. None of those are fixed by a discount code.
So before you buy another abandoned-cart plugin: the five technical causes below account for most of the checkout failures we see on WooCommerce stores, they are all detectable in under an hour, and none of them show up in your analytics as an error. They show up as a shopper who quietly left.
How much of WooCommerce checkout abandonment is technical?
Here is Baymard’s breakdown of abandonment reasons, separated by who owns the fix. Percentages exceed 100% because respondents could pick more than one reason.
| Reason given | Share | Owned by |
|---|---|---|
| Extra costs too high (shipping, tax, fees) | 40% | Pricing / merchandising |
| Delivery was too slow | 20% | Fulfilment |
| Didn’t trust the site with card details | 19% | Design + technical (TLS, gateway UI) |
| Site wanted an account created | 18% | Configuration |
| Checkout too long or complicated | 17% | Technical |
| Site had errors or crashed | 17% | Technical |
| Unsatisfactory returns policy | 13% | Policy |
| Couldn’t see total cost up front | 12% | Configuration |
| Card was declined | 10% | Technical (gateway config) |
| Too few payment methods | 9% | Technical |
The honest reading is that cost dominates, and no amount of engineering fixes a £9 shipping surcharge revealed on step three. But the four technical rows are the ones nobody audits, and unlike shipping cost they are free to fix. Below is what actually goes wrong on WooCommerce specifically.
Cause 1: your checkout page is being served from cache
This is the most common and the most damaging, because it fails silently for some shoppers and works perfectly when you test it yourself while logged in.
WooCommerce builds the checkout form with a nonce tied to the shopper’s own session. If a page cache — a plugin, your host’s server cache, or a CDN — stores that HTML and serves it to the next visitor, that visitor gets a form built for somebody else. When they submit it, the nonce check fails. WooCommerce then checks the cart; if the cart also looks empty, the shopper sees “Sorry, your session has expired.” If items are still in the cart, they get “We were unable to process your order, please try again.”
Both messages read, to a shopper, as “this store is broken”. They leave. Your logs record a 200.
Test it in one command. Request the checkout with no cookies at all:
curl -sI https://yourstore.com/checkout/ | grep -iE 'HTTP/|cache-control|cf-cache-status|x-cache|^age:'A healthy store returns a 302 to the cart (because an empty cart redirects) with headers like cache-control: no-cache, must-revalidate, max-age=0, private. If instead you see a 200 alongside cf-cache-status: HIT, x-cache: HIT, or an age: header above zero, a cache answered and you have found your problem.
The fix is to exclude the right paths from every cache layer — plugin, host, and CDN, not just the one you remember configuring:
/cart/
/checkout/
/my-account/
*wc-ajax*
Any request carrying a wp_woocommerce_session_ cookieThen purge. The last line matters most and is the one usually missed: a visitor who has a WooCommerce session cookie should bypass the cache everywhere on the site, not only on those three pages.
Cause 2: cart fragments make the store feel broken before checkout
WooCommerce keeps the mini-cart count current with an AJAX request to ?wc-ajax=get_refreshed_fragments. It is uncached by design, so every call is a full PHP and database round trip, and on a default install it fires on page loads across the site — including pages with no cart on them at all.
On a small store that costs a few hundred milliseconds. On a large catalogue it has been measured at up to ten seconds, and because the request is what updates the cart counter, the visible symptom is a shopper clicking “add to cart” and watching the counter sit at zero. Many of them click again. Some end up with duplicate line items; others conclude the button is broken and leave — abandonment recorded before checkout was ever reached. This is the same class of problem behind WooCommerce slowing down once a catalogue passes 10,000 products.
Two realistic options:
- Disable fragments outside cart and checkout. Perfmatters, WP Rocket and most performance plugins have a toggle. The caveat is real: themes with a sliding mini-cart or an AJAX add-to-cart button often depend on fragments, and disabling them breaks the counter outright.
- Delay
cart-fragments.min.jsuntil first interaction. Safer on theme-dependent stores — the counter still works, it just stops blocking the initial load.
Check which applies before flipping the switch. A broken cart counter is a worse outcome than a slow one.
Cause 3: the checkout form responds too slowly to be trusted
Interaction to Next Paint (INP) is the Core Web Vitals metric that measures how long the page takes to visibly respond after a tap or click, assessed at the 75th percentile of real page loads. Google’s thresholds:
| INP at p75 | Rating |
|---|---|
| 200 ms or less | Good |
| 201–500 ms | Needs improvement |
| Above 500 ms | Poor |
Checkout is the worst INP page on most WooCommerce stores, and for a structural reason: it is the page carrying the most third-party JavaScript. Gateway SDKs, address autocomplete, analytics, consent banners, chat widgets and conversion pixels all fire on the same thread that has to repaint the form when someone selects a shipping method.
Above roughly half a second, a shopper stops believing the click registered. They click again — which on a payment button can mean a duplicate authorisation, and a gateway that declines the second attempt. That is one route by which a technical problem shows up in your dashboard as the “card declined” row from the table above.
Measure the checkout page specifically rather than the homepage, and measure it in the field, not in Lighthouse. A lab score says little here: we wrote about that gap in why a PageSpeed score of 95 can still feel slow, and the full metric set is covered in what Core Web Vitals measure in 2026.
If your checkout INP is above 500 ms at p75 and you don’t know which script is responsible, that is a two-hour audit, not a rebuild. Send us the store URL and we’ll tell you what’s blocking the thread.
Cause 4: gateway scripts load everywhere, then fail where it matters
Both the Stripe and PayPal integrations for WooCommerce ship their JavaScript on every page of the site by default, not only on cart and checkout. That is wasted bandwidth on your product pages, but the checkout-abandonment consequence is subtler.
Aggressive optimisation plugins react to that waste by deferring, delaying or combining those scripts site-wide. When a delay rule catches the gateway SDK on the checkout page, the payment fields are rendered by a script that hasn’t run yet. The shopper sees an empty card field, or a payment method that silently never appears, and the store looks like it takes no money.
The correct configuration is conditional, not global:
- Dequeue gateway scripts on pages that are not cart, checkout, or the order-pay endpoint.
- Exclude every gateway script from delay-JS and combine-JS rules rather than deferring them globally.
- Test with each payment method enabled, in an incognito window, as a logged-out guest.
Then verify the obvious thing nobody verifies: place a real test order through each enabled gateway, on a phone, on mobile data rather than office wifi. Most stores have never done this since launch, and gateway plugins update monthly.
Cause 5: sessions expiring in the middle of a long checkout
WooCommerce stores the cart for guests in the wp_woocommerce_sessions table, keyed to a wp_woocommerce_session_ cookie. The defaults, from the core session handler:
| Setting | Default | Filter |
|---|---|---|
| Guest session lifetime | 172,800 s (48 hours) | wc_session_expiration |
| Logged-in session lifetime | 604,800 s (7 days) | wc_session_expiration |
| “Expiring” threshold (triggers renewal) | 86,400 s (24 hours) | wc_session_expiring |
| Cleanup task interval | Every 12 hours | woocommerce_cleanup_sessions |
| Maximum permitted lifetime | 2,592,000 s (30 days) | — |
Two things break this. First, the cookie is bound to the exact host that set it, so a store reachable at both the www and non-www hostnames can lose a session when a shopper crosses between them — make one canonical and 301 the other. Second, regenerating the salts in wp-config.php invalidates every live session cookie at once; do that during a busy hour and you have just emptied every cart on the site.
The related issue is table size. On a store with meaningful traffic the sessions table accumulates rows faster than the twice-daily cleanup removes them, particularly if bots are adding to cart. A sessions table in the hundreds of thousands of rows makes every cart read slower, which pushes the whole checkout toward the INP problem above. Check it:
SELECT COUNT(*) AS total,
SUM(session_expiry < UNIX_TIMESTAMP()) AS expired
FROM wp_woocommerce_sessions;If the expired count is a large fraction of the total, the cleanup task is not running — usually because WP-Cron is disabled without a real cron replacement having been set up.
Audit your own checkout in about an hour
- Cache check (5 min). Run the
curl -sIcommand above. Anything other than a 302 with private, no-cache headers is a finding. - Guest order (15 min). Incognito, mobile device, mobile data, each enabled payment method. Note every field that behaves oddly.
- Field INP (10 min). Pull the checkout URL’s real-user data and compare against 200 ms / 500 ms at p75.
- Script inventory (15 min). Open DevTools on the checkout page and list every third-party domain loading. Anything that is not the payment gateway is a candidate for removal from that page.
- Sessions table (5 min). Run the query above.
- Error log (10 min). Grep the PHP error log for the checkout window. Fatal errors during
woocommerce_checkout_processare abandonment that looks like indifference.
What you will not find in this audit is the 40% who left over shipping cost. That is a pricing conversation. What you will find is the overlapping 17% who hit an error, the 17% who found it too slow and complicated, and some share of the 10% whose card “declined” after a double-submit.
What to measure afterwards
Checkout-to-order completion rate is the number to watch — not overall conversion, which moves with traffic quality and campaigns. Segment it by device, because almost every technical cause here hits mobile hardest: slower CPUs make INP worse, mobile networks make delayed scripts worse, and mobile sessions are more likely to span the hours over which a session can expire.
Give it a full purchase cycle before judging the change. On a store doing a few hundred orders a month, anything less than four weeks of data is noise.
If you would rather have the audit done than do it — including the part where someone places test orders through every gateway on real devices and reads the error logs — tell us what your store sells and where checkout feels wrong. We will come back with the specific causes, in priority order, and what each one costs to fix.