E-commerce checkout: how to spot obstacles before payment

The number of cart abandonments, on its own, doesn't say anything: it includes people who were comparing prices and people who tried to pay you and couldn't. The first group isn't a problem. The second group is orders already won and lost in the last stretch. This guide helps you separate the two groups and find, one by one, the points where someone can't complete the process.

Checkout is the only place in the store where the customer has already decided to buy. Every obstacle there costs more than anywhere else, because it comes after everything else has already worked.

The final cost must not be a surprise

A surprise on the total is the obstacle you run into most often when testing a checkout, and it's also the easiest to remove, because it's almost always a choice of where to place the information.

• The shipping cost needs to be calculable before the last step, at least as an estimate by zone or country.
• If there's a threshold above which shipping is free, it needs to be stated when the customer is close to it, not after the order.
• Delivery times should be expressed in business days and refer to the moment of order, not to when the goods leave the warehouse.
• For orders outside the country, duties and taxes need to be flagged as possible even when you don't collect them yourself.
• The summary with the total needs to stay visible while filling in the details, not appear only at the end.
• If cash on delivery has a surcharge, the surcharge should be shown next to the payment method, not in the final total.

Fields, registration, and error messages

This part of checkout is where the company asks and the customer grants. Every unjustified request is a reason to stop, and the annoyance builds up.

• Requiring registration before purchase stops people who just wanted to place an order: guest checkout needs to be offered, with registration proposed after confirmation, once the data has already been entered.
• Every required field needs a statable reason. Asking for a VAT number from a private buyer, a date of birth for a product with no age limit, a phone number without explaining it's for the courier: either justify them or remove them.
• The error message needs to say which field, what's wrong, and how to fix it. "Error in the data entered" is a closed door.
• The error must not erase what's already been typed, and it needs to lead to the right field, not to the top of the page.
• Fields need to accept the formats people actually use: spaces in a card number, international dialing codes, addresses with a slash in the street number.

Phone, accessibility, and interruptions

A large share of orders start on a small screen, often on the move and with an unreliable connection. Checkout needs to be tested under those conditions, not on a big office monitor.

• Numeric fields need to bring up the numeric keyboard: postal code, card number, phone.
• Browser autofill shouldn't be blocked: it's what lets people finish an order in thirty seconds.
• The continue button needs to be reachable without hunting for it under a sticky bar or a consent popup.
• Text needs to be readable without zooming in, fields navigable by keyboard, and labels readable by a screen reader: someone who can't fill the form out doesn't complain, they leave.
• The session must not expire while the customer is digging their card out of their wallet or asking someone else for a piece of information.
• The return from the bank's authentication page needs to land on a sensible point even if the user presses back.

A testing protocol

Three tests, done by a person who didn't build the store, on an ordinary phone, over the mobile network. Note down the screens, not just the outcome.

1. An address that doesn't work: enter a postal code for an area that's not served, or an incomplete address. The system needs to say what's wrong and offer an alternative, rather than silently rejecting it or accepting it and letting delivery fail later.
2. Payment declined: use the payment provider's test tools to trigger a decline. The customer needs to return to a point where they can change payment method, with the order still intact, and needs to understand that nothing was charged.
3. Interruption and return: abandon checkout halfway through, close the browser, come back an hour later. Is the cart still there? Is the data still there? Do you start over?
4. Repeat the three tests with a different payment method and from a different device: obstacles often affect just one path.
5. Redo everything after any change to payment methods, shipping, or the store's theme.

Separating those who give up from those who can't get through

Each symptom maps to a few hypotheses, and for each one there's a way to tell apart voluntary abandonment, a technical error, and incomplete measurement.

What this guide doesn't cover

This guide looks at the purchase journey up to the moment of payment. What happens afterward — orders paid, failed, pending, and refunded, and how to keep them consistent across the store, the payment provider, and the business management system — is the topic of the guide on payment states. Which numbers to look at to understand whether the store as a whole is working has its own dedicated guide.