Why Shoppers Abandon Checkout on Mobile: 9 UX Mistakes to Fix

Mobile checkout abandonment happens when a shopper starts checkout on a phone and leaves before paying, usually because the form is hard to use rather than because the price changed. UXFix audits checkouts against 9 mobile-specific rules covering viewport, autofill and tap target size, separate from the payment and shipping problems that hit desktop and mobile equally.

What mobile checkout abandonment actually means

"Cart abandonment" is the umbrella term everyone reaches for. Baymard's long-running research puts the average online shopping cart abandonment rate at around 70%, across every device combined. That number gets quoted so often it has stopped being useful to a store owner trying to fix something specific.

Mobile checkout abandonment is narrower. It is the slice of that abandonment that happens because a checkout built for a desktop screen and a mouse got squeezed onto a phone with minimal rework. The shopper does not leave because they changed their mind about the product.

They leave because the CVV field opened a full text keyboard instead of a number pad, or the pay button sat below a footer they never scrolled to. Neither of those is a pricing decision. Both are markup decisions someone made without testing on a real phone.

That distinction matters because the fixes are different. Desktop-shaped problems, like hidden shipping costs or forced account creation, get solved by rewriting copy and policy. Mobile-shaped problems get solved by rewriting markup: input types, autocomplete attributes, viewport meta tags and button sizing.

UXFix scores these separately for exactly this reason. A store can pass every payment-trust rule in the book and still lose half its mobile checkouts to a keyboard mismatch nobody noticed.

If mobile checkout completion on your store lags desktop by more than a few points, the gap is rarely about price. It is more often one of the nine issues below, and most of them take an afternoon to fix once you know which rule is failing. For the cost-related side of abandonment, see Why Do Shoppers Abandon Checkout at Payment? 8 Rules to Fix It.

The 9 mobile checkout mistakes we flag most often

These are the nine mobile-specific rules UXFix checks most often, in roughly the order our audits find them broken. Each one is a specific markup or layout failure, not a vague usability complaint, which is why they are fixable in isolation.

• Pinch-to-zoom is required to read the form. No viewport meta tag, or one set to a fixed width, forces the shopper to zoom in to see field labels and zoom back out to see the button. Every zoom is a chance to give up.
• Tap targets smaller than 44x44 CSS pixels. Checkboxes, radio buttons and stepper icons built for a mouse cursor are too small for a thumb. WCAG's target size guidance sets 44 by 44 as the enhanced benchmark for exactly this reason.
• Autofill is broken or missing entirely. Fields without autocomplete attributes, or with the wrong values, force the shopper to retype a name and address they have already saved in their phone.
• The wrong keyboard shows up. An email field that opens the standard alphabet keyboard instead of one with @ and .com keys. A card number field with no numeric pad. Small friction, repeated on every field, adds up fast.
• The primary button is not sticky. "Continue" or "Pay now" sits at the bottom of a long form, off-screen, with no fixed position. The shopper finishes typing and has no idea what to do next.
• A desktop layout survives onto mobile unchanged. Two or three columns get squeezed into a 375px viewport, sometimes with horizontal scroll, sometimes with text so small it fails basic legibility checks.
• Error messages appear off-screen. Validation fires above the field the shopper has already scrolled past, so they see a red border with no visible explanation of what to fix.
• No address autocomplete. Full manual entry of a street address, city, state and postcode on a phone keyboard, field by field, when a single autocomplete lookup would do it in one tap.
• Card fields are unformatted. No digit grouping, no visual separation between number, expiry and CVV, tiny font size, so the shopper cannot glance-check what they typed before hitting pay.

Why is my mobile checkout conversion rate low?

If mobile conversion is low relative to desktop, the honest way to find out why is to stop looking at the overall rate and look at step-by-step completion instead. A funnel where mobile drop-off at the shipping step badly outpaces the same step on desktop is not a demand problem.

It is a specific, fixable rendering problem on that one screen, and it usually shows up clearly once you split the funnel by device rather than looking at the blended number.

Session recordings are the fastest diagnostic. Watch for "rage taps," repeated taps on an element that is not responding, which NN/g's research on touch targets treats as a reliable signal of a frustrated user hitting a target that is too small or not actually interactive.

Field-level form analytics are the second tool: if one field has a completion time noticeably longer than the rest, that is usually the field with the wrong keyboard or a validation message the shopper cannot see.

Worth checking specifically:

A mobile conversion rate that trails desktop by a wide margin is common enough that it should not be treated as normal. It is a signal to open the recordings, not a fact of life to accept.

Mobile form autofill and tap targets: the two rules stores skip

Of the nine, these two account for most of the gap we see in audits, and both are markup fixes rather than redesigns.

Autofill depends entirely on the autocomplete attribute matching the field's actual purpose, using the exact token names from the WHATWG autofill spec. A field can look correct and still fail autofill silently if the attribute is missing, misspelled, or set to a value the browser does not recognise.

<input type="text" name="full-name" autocomplete="name">
<input type="tel" name="phone" autocomplete="tel" inputmode="tel">
<input type="text" name="address1" autocomplete="address-line1">
<input type="text" name="postcode" autocomplete="postal-code" inputmode="numeric">
<input type="text" name="card-number" autocomplete="cc-number" inputmode="numeric">

A pattern we see repeatedly in audits: the card number field has type="text" with no inputmode set at all, so the browser offers no numeric keypad. The shopper has to switch keyboards manually, on every digit, on every order, and never notices that this is why checkout feels slow.

One edge case worth checking directly: some stores still set autocomplete="off" on payment fields, a habit left over from older PCI guidance that no longer requires it. That single leftover attribute disables autofill for the whole form, not just the card field it was meant to protect.

Test all of this on an actual phone, not a resized browser window. iOS Safari and Chrome on Android both render autofill suggestions differently, and a field that autofills on one can silently fail on the other. Web.dev's guidance on form autofill is the clearest reference for getting the attribute values right.

Tap targets are the second recurring failure. WCAG's Target Size criterion recommends 44 by 44 CSS pixels as the enhanced benchmark, with a 24 by 24 minimum in the newer 2.2 criteria. Below that, thumbs miss, and every miss is a chance to abandon rather than retry.

Fixing it this week

None of the nine require a checkout rebuild. Most are attribute and CSS changes that a front-end developer can ship in a single sprint, tested against real phones rather than a resized desktop browser.

If checkout falls apart at one specific step rather than across the whole flow, the fix is usually somewhere other than these nine rules. Forced account creation is its own failure mode, covered in Why Shoppers Abandon Checkout at Account Creation. If the drop-off happens before checkout even starts, that is a product page problem, covered in Why Shoppers Leave Your Product Page Without Buying: 12 Fixes.

Questions we get asked