Shoppers fill the cart and then disappear

Two shoppers can abandon a cart for reasons that have nothing to do with each other. One is using the cart as a shortlist — comparing delivery cost, saving items until payday, checking whether the size is right. Nothing on your site failed; they were not buying today, and no amount of interface work converts them on this visit. The other reached the payment step, hit a surprise fee, a mandatory account, a form that rejected a valid address, or a page that stopped responding on a slow connection, and left with intent intact. Only the second is a defect. Treating both with the same tactic — usually a discount email — papers over the defect and pays people who were already going to buy. Before changing anything, work out which of the two is producing most of your losses, because the fixes point in opposite directions.

• Decision friction: comparing, saving for later, not ready to buy yet
• Mechanical friction: surprise costs, forced accounts, errors, slowness
• Discounts mask mechanical defects and pay off already-committed buyers
• The two groups need opposite fixes, so separate them before spending

Most reported abandonment rates are wrong in a way that either flatters or panics you. If every add-to-cart counts as a started purchase, bots, price-checkers and your own staff inflate the denominator. If checkout is a separate page that fires no events, drop-off looks like it happens in one place when it is actually spread across four. Instrument the funnel step by step: cart viewed, checkout started, address entered, payment method chosen, order placed. Split it by device, because desktop and mobile rarely fail at the same step. Then read the shape rather than the headline figure — a cliff between address and payment means something concrete broke, while a slow bleed across every step usually means the whole flow is heavy. Clean analytics is cheap compared with rebuilding the wrong thing.

Baymard Institute has assembled the most-cited body of research on checkout usability, combining large-scale surveys of why shoppers abandoned with usability testing of real checkout flows. The reasons that keep recurring are unromantic: extra costs — shipping, tax, fees — appearing too late; being forced to create an account; a checkout that is too long or asks for the same information twice; not trusting the site with card details; and a flow that errors, crashes or is simply too slow. Notice what is absent from that list. Almost none of it is about design taste, and none of it is solved by a bigger button. Each item is a concrete thing your storefront either does or does not do, which is the good news: they are auditable. Walk your own checkout on a mid-range phone over a throttled connection and you will usually find two or three of them on the first pass.

The complaint that repeats most in checkout research is cost that appears at the end. If shipping can only be calculated from an address, show a live estimate in the cart, state a clear rule such as free over a threshold and a flat rate below it, or resolve it from a postcode before the final step. The same goes for tax and any handling fee. Nobody abandons because shipping costs money; they abandon because the number changed after they had committed. Forced account creation is the other self-inflicted wound. Guest checkout is not a concession, it is the baseline expectation, and the account can be offered after the order is placed — at that point you already have the email address and the customer has an actual reason to save their details.

• Estimate shipping in the cart, not on the final review step
• State the free-shipping threshold where the shopper can still act on it
• Offer guest checkout first, propose an account after the order
• Never introduce a new charge after payment details are entered

Checkout is the slowest part of most WooCommerce stores because it is the least cacheable: sessions, shipping calculations, tax lookups and payment scripts all run per request. On a phone over mobile data that produces a page which appears and then refuses to respond — the shopper taps the order button, nothing happens, they tap again, and now they are worried about a double charge. Google's Core Web Vitals thresholds capture this as INP, interaction latency, and on checkout it matters more than raw load time; the felt failure is the tap that goes nowhere. Third-party scripts are the usual cause: chat widgets, heatmaps, ad pixels and review embeds all competing for the main thread at the worst possible moment. Auditing what actually runs on cart and checkout, and doing the storefront speed work around them, removes a class of abandonment that no copy change would have touched.

Three mechanical failures quietly account for a lot of lost orders. Error handling: a validation message stranded at the top of a long form, a card decline with no explanation, an address field that rejects a legitimate format — each one asks the shopper to debug your site for you. Payment choice: when the wallet a customer already trusts is missing, a share of them will not type a card number instead, and that share is larger on mobile. Persistence: a cart that empties on session timeout, or refuses to follow someone from phone to laptop, throws away demand you have already paid to acquire. None of the three are glamorous, all of them are testable in an afternoon, and repairing them costs less than the traffic you are currently buying to replace the orders they lose.

• Show validation errors inline, next to the field that failed
• Explain declines in language a shopper can act on
• Offer the wallets your audience already has set up
• Keep the cart alive across sessions and devices

The boundary matters here, because the riskiest part of checkout is the part we deliberately leave alone. WooCommerce keeps products, stock, pricing, coupons, tax and shipping rules, payment gateways, orders, and any abandonment-recovery email plugin you already run — all with the same admin screens and the same reporting your team uses now. What gets rebuilt is the customer-facing side: category and product pages, the cart and mini-cart, shipping estimates, error states, and the handoff into checkout, delivered as a Next.js storefront. Checkout itself can stay native through a hybrid handoff, so the payment flow that is currently compliant and tested stays exactly that. Recovery email is worth having, but treat it as a net under the fix rather than the fix: a good sequence catches genuinely distracted shoppers, and quietly subsidises the ones your checkout drove away.

If your store sees a few hundred sessions a month, your abandonment rate is noise and any change you make will be unmeasurable — fix acquisition first. If the drop-off is concentrated at the very first checkout field on paid social traffic, you probably have a targeting or expectation problem rather than a checkout problem, and a developer cannot help with that. If checkout is slow because of one misconfigured plugin, a caching rule or unoptimised images, that is an afternoon of work and a fraction of what a storefront rebuild costs; do the cheap thing and re-measure before considering anything larger. A rebuild earns its price when the funnel is instrumented, the volume is real, and the failures are structural rather than a single setting. If you cannot tell which case you are in, a short audit will, and the honest answer is sometimes that you do not need us.