An abandoned cart stings the most, because it is a customer who already wanted to buy. They added the product, sometimes typed in half their details - and disappeared on the last screen. It is easy to blame the price, or to say they were “just browsing”, but when I start digging under the bonnet at a client’s store, in half the cases the reason is technical. Something on the road to “Buy now” is slow, odd or alarming.
I leave the marketing reasons for abandonment (too expensive, no trust in the brand, I will buy later) to one side - that is a separate subject. Here I break down seven things that happen inside the store itself and that can genuinely be fixed. First I measure what is dropping off, then I fix whatever costs the most carts. Not the other way round.
For each cause I write how to remove it - so a store owner knows what to ask for, even if they never look at the code themselves.
Checkout loads too slowly
That is the first suspect. The cart and checkout pages in WooCommerce are dynamic - they cannot be served from a pre-built file like an “About us” page, because they are calculated live: cart contents, shipping, taxes, discounts. If the server responds slowly (high TTFB, the time to the first response), the customer stares at a blank page at the worst possible moment - when they have already got their card out.
According to Google’s data, the probability of abandonment rises by 32% when load time goes from 1 to 3 seconds. At checkout that second weighs double, because the customer is already impatient and ready to change their mind.
The usual culprits: cheap shared hosting, no object cache (Redis), an old PHP version, and plugins that add database queries on every cart recalculation.
What helps: measure checkout TTFB separately on a phone and on a desktop, switch on object cache (Redis) and OPcache, and keep the cart and checkout themselves excluded from page cache. If the server still answers in seconds, the problem is the hosting - that is where I start. More on what chokes a store I wrote up in the piece on a slow WooCommerce store. This kind of repair is exactly what I do as part of development and optimisation.
No BLIK, Apple Pay or Google Pay
In Poland, BLIK - the dominant local mobile payment method, run through the banking apps - is now the default way to pay. If all I see at checkout is “bank transfer” and a card, for a large share of customers that means an interruption: they have to leave for their banking app, retype the details, come back. Every one of those steps is an opportunity to abandon the cart.
Apple Pay and Google Pay go further still - a one-touch payment, with the details already stored on the phone. On mobile, where typing a card number is a chore, that can be the difference between a sale and an abandonment.
What helps: enable BLIK through a gateway the customer trusts (Przelewy24, PayU, Stripe, Autopay - the first, second and fourth are the payment gateways Polish stores use most), plus Apple Pay and Google Pay - both methods usually need nothing more than HTTPS and a few settings at the payment provider. How to wire them into WooCommerce properly, I covered separately in the piece on Apple Pay and Google Pay.
The order form is too long
The default WooCommerce checkout can show more than a dozen fields: first name, surname, company, address, postcode, city, country, phone, email, notes, a separate billing address. For a customer who wants to buy one product, that is a wall to fill in. The more fields, the more chances to give up or make a mistake.
Most of those fields are pointless for a given store. You only sell within one country - the “country” field is unnecessary. You ship by courier to a parcel locker - half the address fields fall away.
What helps: cut every field you do not genuinely need to fulfil the order, and order the rest logically. Switch on city autofill from the postcode and browser autocomplete, so the customer types as little as possible by hand. Fewer fields is not cosmetics - it is fewer places where the cart falls apart.
Error validation pushes the customer out
Nothing throws a customer out of checkout as effectively as an “an error occurred” message with no indication of what to fix. The classics I see: a phone field that will not accept a number with spaces or a country prefix, a form that wipes all the data after one mistake, an error appearing at the very top of the page while the customer is looking at the bottom, or a message in English in a store that is otherwise in Polish.
From the customer’s point of view it looks like this: they did everything right and the store still shouts “no”. They will not type the same details a second time.
What helps: validate fields as they are filled in and under the specific field (not in one lump at the top), accept different phone and card number formats, never clear a filled-in form after an error, and keep the messages in the customer’s language and in plain words - “Enter a valid email address”, not “Validation error”.
The store does not look safe
On the last screen the customer hands over money and personal data. If anything raises distrust, they back out - and they will not tell you why. The most common jarring notes: no padlock (no HTTPS, or “mixed content”, where part of the page loads over an unsecured connection and the browser shows a warning), an ugly, bolted-together checkout that looks nothing like the rest of the store, no payment logos, no returns information and no company details.
This is not a soft “image” subject. It is a hard signal: can I safely pay here.
What helps: force HTTPS across the whole store and remove mixed content, show the payment gateway logos and a padlock next to the card field, add a short note about secure payment and returns under the order button, plus visible company details. A consistent, clean checkout builds trust more effectively than any “100% secure” banner.
The cart refreshes over and over (cart fragments)
This one is specific to WooCommerce and often invisible to the naked eye. WooCommerce has a “cart fragments” mechanism - a script that refreshes the cart counter in the header over AJAX on every page view. On a slow server that script can block clicking: you add a product and the “Add to cart” button grinds for several seconds before anything happens. The customer clicks again, and again, and eventually gives up.
The same applies to the cart page, which recalculates after every quantity change - if each recalculation takes noticeably long, the customer loses patience before reaching payment.
What helps: disable cart fragments on pages where the cart is not needed anyway (the product page outside the add-to-cart action, the blog, the contact page), and where they are needed - speed up the server so AJAX answers in hundreds of milliseconds, not in seconds. The effect: the cart reacts immediately on click.
The shipping cost appears too late
This is one of the most common reasons for abandonment I see - and a purely technical one to fix. The customer sees the product price, adds to cart, gets through half the form and only at the end finds out that shipping costs 19 PLN. They feel cheated and leave. The later the shipping cost appears, the more carts drop off.
Add to that the lack of real courier integrations: the customer cannot pick a parcel locker from a map, shipment details have to be retyped by hand, and the delivery methods do not match what the customer actually wants.
What helps: show the shipping cost as early as you can - in the cart at the latest, and ideally as a calculator on the product page. Wiring in an InPost parcel locker integration (InPost runs the parcel locker network most Polish shoppers default to) with point selection on a map, plus real free-shipping thresholds (“you are 23 PLN away from free delivery”), removes the uncertainty and raises cart value at the same time.
Measure first, fix second
These seven things do not get fixed all at once and blind. In every store a different one costs the most carts. So I always start with measurement:
- Funnel analytics (GA4 or the gateway’s built-in reports) - at exactly which step people drop out: cart, details, payment.
- A real checkout run on a phone - I click through the whole purchase like a customer, on a weak connection, and note every place where something takes too long or looks suspicious.
- PageSpeed Insights and the Network tab - is checkout loading fast and what is blocking the render.
Only with those numbers do you know whether to start with payments, with speed or with the form - and which single change to make first to recover the most carts at the lowest cost. I use the same approach when I build a WooCommerce store from scratch: I design checkout for conversion, not for the number of fields.
If you can see people adding to cart while orders stay thin - send me a link to the store. I will walk your checkout like a customer, measure what drops off, and tell you in writing what to fix first. Free of charge.
Frequently asked questions
How many abandoned carts is normal? There is no single figure that fits every store - it looks different on a 40 PLN purchase and on furniture costing several thousand. Instead of comparing yourself to somebody else’s statistics, measure your own funnel in GA4 or in the payment gateway reports and watch the change over time. More important than the percentage itself is which step people drop out at: the cart, the details or the payment.
Can an abandoned cart be recovered by email? Partly - WooCommerce plugins can send a reminder to a customer who left an email address. But a reminder only works if the customer left out of hesitation, not because checkout would not load or the form rejected their phone number. If the reason is technical, the email will lead the customer straight back to the exact spot where they got stuck the first time.
How do I tell whether the reason is technical or about price? Walk the whole purchase on your own phone, on a weak connection, and note every place where something takes too long, looks suspicious or throws an error. Then put that next to your funnel analytics: a sudden drop at one specific step is almost always technical, an even fall-off is more likely the offer and the price. Only with that data do you know what to fix first.
Does adding BLIK and Apple Pay require rebuilding the store? No. It is usually configuration on the payment provider’s side plus a gateway plugin, and the main technical requirement is correct HTTPS across the whole store. The checkout itself stays the same, one more payment method simply appears in the list.
Sitting on this yourself and unsure where to start? I speed up and repair existing sites and stores - Core Web Vitals, outages, the features that are missing. Tell me what is happening and you will get a concrete quote with a date.