Mobile checkout optimisation: a UK retailer's checklist

What to take away

Mobile checkout losses cluster around typing: card entry, address entry and consent boxes.
Apple Pay and Google Pay remove most of that typing when the button sits above the card form.
Postcode lookup against Royal Mail's Postcode Address File is the biggest keystroke saving for UK shoppers.
A change counts only when you hold a dated baseline and compare like-for-like device classes.

Where UK mobile checkout actually breaks

Shoppers rarely abandon a phone checkout because they changed their mind. They stall where the screen asks for something a phone makes awkward: a 16-digit card number, an expiry date, a postcode.

If your drop-off sits at one step rather than evenly across the journey, checkout abandonment in UK shops sets out the causes worth testing first, from delivery cost surprises to forced account creation.

Compare your own step-level drop-off before copying a rival. Their wallet placement tells you nothing about your traffic mix.

The Consumer Contracts (Information, Cancellation and Additional Charges) Regulations 2013 require the trader to give set information, including the total price and delivery arrangements, before the order is placed. On a phone, that information has to sit above the fold of the payment step, not in a footer.

Payment routes worth testing first

Wallet payments change the shape of the step. Apple Pay and Google Pay pass a stored card, name and address to the merchant after a device check, so the shopper types nothing.

Payment routes compared

Apple Pay

What shopper types: Nothing
Where it fits: iPhone and iPad

Google Pay

What shopper types: Nothing
Where it fits: Android shoppers

Saved card

What shopper types: Security code
Where it fits: Signed-in accounts

Manual card

What shopper types: All card details
Where it fits: Guests, no wallet

Put both buttons at the top of the payment step. A wallet button placed below the card fields is a button most shoppers never reach.

What the shopper types

Apple Pay in Safari: Nothing beyond a face or fingerprint check
Google Pay in Chrome: Nothing beyond a device unlock
Saved card on a signed-in account: Security code only
Manual card entry: Number, expiry, security code, name
Provider instalments: Depends on the provider's flow

Where it fits

Apple Pay in Safari: iPhone and iPad shoppers
Google Pay in Chrome: Android shoppers
Saved card on a signed-in account: Returning customers
Manual card entry: Guests and browsers without a wallet
Provider instalments: Larger baskets

A guest checkout option matters too, since forced account creation is a recurring cause of abandoned baskets on phones.

Test each route on completion rate for its own device class rather than on a blended average.

Address entry is the longest step on a phone

A UK postcode plus a house number is a compact key to a full address. Lookup tools built on Royal Mail's Postcode Address File return a short list, and the shopper confirms one line instead of typing four.

Keep manual editing available. A lookup that fails on a new-build property or a flat above a shop will lose the sale it was meant to save.

Every extra field carries a cost, and the ICO's UK GDPR guidance on data minimisation gives a defensible reason to delete fields the order does not need.

If the form still feels long on a phone, ecommerce form optimisation covers label placement, error copy and field order for UK stores.

A seven-point mobile checkout checklist

Open the checkout on a mid-range Android phone over 4G and time each step.
Put wallet buttons above the card form, and test them in Safari and Chrome.
Offer postcode lookup, then allow manual edits to the found address.
Label the remaining steps and show how many are left before payment.
Use input types that open the right mobile keyboard, and never block paste.
Check target sizes, focus order and error text against the WCAG 2.2 quick reference, which lists the target size and error identification criteria most teams test to.
Record the drop-off point for each step so every change has a measured starting point.

Measuring mobile ecommerce CRO properly

Report mobile and desktop separately. A blended figure hides the case where mobile improves while desktop support contacts rise.

Agree the comparison window before launch and keep the same traffic sources on both sides. Seasonal UK peaks, from Black Friday to the January sales, can distort a short test.

Call it an improvement only when the comparison was planned, the sample held and the release can be reversed.

Common questions

Do UK shoppers prefer Apple Pay or Google Pay?

It depends on the device in their hand. iPhone shoppers in Safari get Apple Pay, and Android shoppers in Chrome get Google Pay, so offer both and let the browser decide.

Is address lookup worth paying for?

It carries a licence cost, so compare that cost with the completion gain at your own mobile order volume. Stores that handle a lot of address corrections in support usually build the case first.

How long should a mobile checkout test run?

Long enough to cover a full purchase cycle for the products in the test. Agree the end date before launch so nobody extends it after a good week.

Does a shorter form always convert better?

No. Removing a field that answers a real question pushes the query into support or the returns process, which costs more than the field did.