Checkout optimisation isn’t about every abandoned cart. Many shoppers add items to save them for later or to compare the total with another shop, and no redesign changes that.
It is about the shopper who has started typing an address and still leaves. The cause is usually something the store did: a delivery charge revealed at the last step, a demand to create an account, a form that fought the phone keyboard. This guide takes those causes in the order shoppers meet them, without promised uplift figures: what each fix is worth depends on your store.
Checkout optimisation: the short answer
Checkout optimisation removes the friction that makes ready-to-buy shoppers leave. Show the full cost, including delivery, before checkout starts. Make guest checkout the default, ask only for the fields the order needs, and code them so phones can autofill them. Explain errors beside the field, keep the total in view, offer the payment methods your customers already use, and recover abandoned carts with saved carts and properly consented reminders.
Why shoppers abandon carts, and which reasons are yours to fix
Baymard Institute’s long-running surveys of US online shoppers, with those “just browsing” set aside, keep finding the same store-made reasons: the percentages shift, but the list barely does. Notice how many fixes sit before checkout begins.
| Reason for leaving | Where the fix lives |
|---|---|
| Extra costs too high, or no total shown up front | Product page and cart |
| Being asked to create an account | The start of checkout |
| Slow delivery or an unsatisfying returns policy | Delivery options, product page and cart |
| Not trusting the site with card details | The whole site, then the payment step |
| A long or complicated checkout | The checkout form |
| Site errors and declined cards | Testing, validation and the payment step |
| Not enough payment methods | Payment options |
Find your own leak first
A general list tells you what to look for; your data tells you where. GA4’s recommended e-commerce events include view_cart, begin_checkout, add_shipping_info, add_payment_info and purchase, and a funnel exploration built on them, broken down by device, shows where people drop out. A big drop before checkout points at cost or trust; one between shipping and payment points at delivery options or payment. E-commerce conversion rate and GA4 conversion tracking cover the measurement. Then watch a few people buy on their own phones; they’ll find what no report shows.
Fix what happens before checkout
- Show the total early. Put the delivery cost, or a range and any free-delivery threshold, beside the price, and say whether taxes and duties are included for buyers abroad. E-commerce product page design covers all-in pricing.
- Answer delivery and returns in a line beside the Checkout button, such as “Delivered by Thursday. Free returns for 30 days.” if those are your terms, linked to the full policy.
- Make the shop visibly real. A business address, a phone number or chat route, familiar payment marks and plain policies give shoppers something concrete to check; a “100% secure” badge you designed yourself proves nothing. Website credibility explains how visitors make that judgement.
Design the checkout form itself
A checkout is a form with money at the end, so everything in web form design applies.
Make guest checkout the default
Put “Continue as guest” first, with sign-in as a clear second option. Ask for an email to send the receipt, and say so. Offer an account on the confirmation page, where it takes a single password field.
For returning customers, never block paste or password managers in sign-in fields: WCAG 2.2’s Accessible Authentication (Minimum) criterion (3.3.8) says signing in mustn’t rely on memory or retyping without help. autocomplete="one-time-code" lets many phones offer codes sent by text message.
Ask only for what the order needs
Keep a field only if fulfilment, payment or the law needs it; move the rest after the purchase or drop it.
- Name. One full-name field fits more of the world’s names; split it only if your courier or payment provider requires it.
- Phone. Couriers often need one. Say why: “For the courier, only if there’s a delivery problem.”
- Company and second address line. Put them behind “Add company” and “Add apartment or unit” links.
- Billing address. Default it to the delivery address. WCAG 2.2’s Redundant Entry criterion (3.3.7) asks that details already given are filled in or selectable, not retyped.
- Marketing consent. An unticked box, worded plainly. Under the EU and UK GDPR, a pre-ticked box isn’t consent.
Let the browser fill it in
Correct autocomplete values let a phone fill a whole address in one tap, and they are the usual way to meet WCAG’s Identify Input Purpose criterion (1.3.5). The HTML standard lets you prefix them with shipping or billing so the browser offers the right saved address.
| Field | Input | Autocomplete |
|---|---|---|
type="email" |
email |
|
| Full name | type="text" |
shipping name |
| Street | type="text" |
shipping address-line1 |
| Postcode | type="text" |
shipping postal-code |
| Country | select |
shipping country |
| Phone | type="tel" |
shipping tel |
| Card number | type="text", inputmode="numeric" |
cc-number |
- Ask for the country first if you sell abroad. It decides the address format, and not every country uses postcodes, so don’t require one everywhere.
- Don’t use
type="number"for card numbers or postcodes. MDN recommends number inputs only for values you step up or down, like a quantity, and names both as poor fits; many postcodes contain letters anyway. - Check your payment provider’s card fields support autofill and a number pad; you can’t fix them yourself.
- Offer address lookup, never impose it. Keep “Enter address manually” for new buildings and unusual formats, and make sure it doesn’t fight the browser’s autofill.
Write errors that fix things
- Check a field when the shopper leaves it, not on every keystroke.
- Put the error beside the field and explain the fix: “Enter an email address in the format name@example.com” beats “Invalid input”. WCAG’s Error Identification (3.3.1) and Error Suggestion (3.3.3) ask you to identify the field, describe the error in text and suggest a fix where you can.
- Accept spaces and dashes in card and phone numbers, then tidy them in code.
- Never clear what someone typed. The card security code is the one field a provider may reasonably ask for again.
How to design accessible forms covers labels, error summaries and screen reader announcements in depth.
One-page vs multi-step checkout
The choice matters less than it seems: shoppers feel the number of fields and decisions more than the number of screens.
| At a glance | One-page checkout | Multi-step checkout |
|---|---|---|
| Suits | Short checkouts, digital products | Physical goods with delivery choices, international orders |
| Risk | A long page looks like hard work | Unclear progress, or Back losing data |
| Must have | A clear order and a visible total | A progress indicator, editable steps, a working Back button |
Either way, keep the order summary (items, delivery, taxes and total) in view, collapsed under a bar showing the total on phones. For purchases, WCAG’s Error Prevention criterion (3.3.4) asks that an order can be reversed, checked and corrected, or reviewed and confirmed before it’s final; showing the whole order before payment is the simplest way. Cut fields first, then test the layout on your own store.
Payment: familiar methods and visible security
Offer the methods your customers already use
Payment habits vary by country: cards lead in some markets; bank transfers, QR payments, wallets or cash on delivery in others. Ask your provider which matter where you sell.
Express wallets such as Apple Pay, Google Pay and PayPal can skip address and card entry, which matters most on phones. Offer them at the top of the checkout and in the cart, but keep the row short: six branded buttons become a decision of their own.
Keep card data off your server
Use your provider’s hosted payment page or embedded payment fields, so card numbers go straight to the provider and your obligations under PCI DSS, the card industry’s security standard, stay much smaller. Card-skimming code injected into checkout pages is a well-documented attack, and version 4 of PCI DSS added requirements to authorise and monitor scripts on payment pages. Load as few third-party scripts there as you can.
Plan for authentication and declines
In the EEA and the UK, many online card payments need strong customer authentication, often through 3-D Secure, such as an approval in the shopper’s banking app. Test that round trip on a phone: it should end on your confirmation page, not a blank screen. When a payment is declined, keep the cart and every detail, say plainly what happened and offer another method.
Mobile checkout design
Beyond the keyboard-friendly input types above, a few rules are specific to phones.
- Thumb-reachable actions. Make Continue and Pay full width and low on the screen. WCAG 2.2 sets a minimum target of 24 by 24 CSS pixels (2.5.8); aim nearer 44 by 44, its stricter AAA level.
- Sticky bars that don’t hide focus. A fixed Pay bar or cookie banner must never completely hide the field with keyboard focus, which is WCAG 2.2’s Focus Not Obscured (Minimum) criterion (2.4.11); ideally it covers none of it.
- No pop-ups or detours. Switch off newsletter overlays and chat prompts, and show delivery, returns and terms in an expandable panel rather than on another page.
- Speed on mobile data. Checkout pages are personal, so they can’t be cached like the rest of the store. Test on a mid-range phone: page speed affects conversions at every step.
Recover the carts people still leave
Recovery means making it easy to come back, not applying pressure.
- Save the cart with the customer’s account so it follows them between devices, and in the browser for guests.
- Send abandoned cart emails only on a proper footing. The EU and UK, for example, generally require consent before sending marketing email to individuals, with a narrow “soft opt-in” exception built around existing customers. Capturing an address someone typed but never submitted, then emailing it, is the hardest practice to justify.
- Make the reminder useful. One reminder or a short series, with the items, a link that restores the cart exactly and an answer to the likely doubt. Automatic discounts risk teaching regular customers to wait for a code.
A checkout audit you can run this week
Place a real order on your own phone, over mobile data. Then place another and make mistakes on purpose: a wrong postcode, a skipped field, a declined card in your provider’s test mode. Tick off what passes:
Frequently asked questions
What is a normal cart abandonment rate?
There isn’t a useful universal figure: published averages mix in shoppers who were only saving or comparing, and stores differ widely. Track your own rate over time, by device and step, and watch drop-off after begin_checkout most closely.
Do abandoned cart emails need the shopper’s consent?
Often, depending on the law in each market and whether the message counts as marketing. Take advice for the countries you sell to rather than relying on your email tool’s defaults.
How much will checkout optimisation increase sales?
Nobody can honestly promise a figure in advance. Record drop-off at each step, change one area at a time and compare the same steps afterwards.
What to do next
A checkout people finish is where content, UX, development, performance and security have to work together; a weakness in any one shows up as an abandoned cart. E-commerce website design places the checkout in the context of the whole store.
Start with your own test order and the audit above. For an outside view of what a checkout depends on, such as speed, the mobile experience and security, ask for a free website audit.