Mobile checkout optimization: making your store thumb-friendly

Last updated: June 2026.

Watch a customer check out on a phone and you see things you'd never notice on a 27-inch monitor: a thumb stretching across the screen to reach a "Continue" button, a numeric postcode field that pops a full QWERTY keyboard, a card number that has to be typed one digit at a time on a moving train. Mobile is now where most PrestaShop checkouts happen, and it punishes friction far harder than desktop does. A misplaced field that costs a desktop shopper two seconds costs a mobile shopper their patience. This post is specifically about the mobile layer: the tap targets, input types and wallet payments that decide whether a thumb-driven checkout finishes or gets abandoned at a red light.

It is the mobile companion to the broader cluster. We won't re-argue guest checkout, the one-page-versus-stepped question, or cart-recovery emails here. Those have their own homes, linked below. The focus is the part that's genuinely mobile-specific.

Why mobile is a different problem, not just a smaller screen

A desktop shopper has a mouse, a keyboard, and a saved-password manager. A mobile shopper has one thumb, a soft keyboard that covers half the screen, a flaky connection, and a strong instinct to bail the moment typing feels like work. The same PrestaShop checkout that converts fine on desktop can quietly leak orders on mobile for reasons that never show up in a desktop test. Which is why testing on a real phone (not your browser's responsive mode) is the single most useful habit in this whole post.

PrestaShop's classic theme is responsive out of the box, so the checkout doesn't break on a phone. But "doesn't break" and "thumb-friendly" are different bars. The default theme makes a handful of choices that are fine on desktop and costly on mobile, and most of them are fixable from your theme and a small CSS file rather than a developer invoice.

Input types: the highest-return ten minutes you'll spend

This is the most overlooked mobile win in PrestaShop, and it's almost free. On a phone, the keyboard that appears depends on the field's type and inputmode attributes. Get them right and the customer's keyboard pre-arranges itself for the field; get them wrong and they hunt for the "@" symbol or the number row on every single field.

• Email field → type="email" gives an on-screen keyboard with "@" and "." visible without switching layouts.
• Phone field → type="tel" opens a numeric dial pad instead of a full keyboard.
• Postcode / ZIP → inputmode="numeric" (for numeric-only formats) opens a number pad. Use this carefully: UK, Dutch and Canadian postcodes contain letters, so set it per-country, not blindly.
• Autofill → autocomplete attributes (email, given-name, family-name, address-line1, postal-code, tel) let the phone offer the customer's saved details in one tap. This is the closest thing to a free conversion increase in mobile checkout.

Put together, the mobile-correct version of the four fields most people get wrong looks like this. Each attribute does one job: type and inputmode pick the keyboard, autocomplete lets the phone offer saved details in a tap:

<!-- Email: keyboard with @ and . visible, offers saved address -->
<input type="email" name="email" autocomplete="email" inputmode="email">

<!-- Phone: numeric dial pad, not a full QWERTY keyboard -->
<input type="tel" name="phone" autocomplete="tel">

<!-- Postcode: number pad ONLY for numeric-format countries -->
<input type="text" name="postcode" autocomplete="postal-code" inputmode="numeric">

<!-- Street: lets the phone autofill the saved address line -->
<input type="text" name="address1" autocomplete="address-line1">

The postcode is the one to handle with care: leave inputmode="numeric" off (or switch it per-country) for the UK, Netherlands, Canada and anywhere else postcodes contain letters, or you'll trap those customers on a number pad with no way to type a letter.

Here's the PrestaShop-specific catch: the classic theme's address and personal-information fields are generated server-side from formatter classes, CustomerAddressFormatter and the customer-form rendering in the order controller's steps, and they do not reliably set the optimal mobile keyboard attributes on every field. The country select drives the address format, but the postcode input won't carry inputmode="numeric" by itself. So what does that mean for you? On a stock store, the postcode field likely pops the wrong keyboard on mobile right now, and nobody's noticed because nobody tested on a phone. The phone field is usually safer. Modern PrestaShop sets it to type="tel", but it's worth verifying that any child theme or form override you're running still retains type="tel" rather than dropping it. The fix is a child theme override of the relevant form templates (the address form template under themes/your-theme/templates/checkout/_partials/) adding the attributes above, or a checkout module that ships them already set.

Tap targets: built for thumbs, not cursors

A mouse pointer is a single pixel. A thumb is roughly a 7–10mm pad that can't see what's directly under it. Apple's Human Interface Guidelines call for a minimum 44×44pt touch target; Google's Material guidance says 48×48dp. PrestaShop's default buttons are usually fine, but the danger spots on a real store are the small ones: the quantity steppers, the "edit address" pencil, radio buttons for carriers, and the coupon-toggle link.

• Primary actions go full-width and tall. "Continue" and "Place order" should span the screen width and stand at least 48px high, easy to hit without aiming.
• Form fields need height too. A 30px-tall input is a precise target on a phone; 44px+ lets a thumb land first time and reduces the dreaded "tapped the wrong field" backtrack.
• Space tappable things apart. Carrier and payment radio rows packed tight cause mis-taps; ~8px of breathing room between targets fixes it.
• Make the whole row tappable, not just the dot. For carrier and payment selection, the label and its container should be the tap zone, not the tiny radio circle.
• Consider a sticky order button. On a long mobile checkout, a "Place order" bar pinned to the bottom of the viewport means the customer never has to scroll to find it. (Keep the running total beside it, see the next section.)

None of this needs core edits. Touch-target sizing and spacing live entirely in CSS, which means a shop-specific stylesheet in your child theme. Never a hacked core file that an upgrade would wipe.

Keep the total honest and on-screen

Unexpected cost at the final step is one of the oldest abandonment causes, and it's worse on mobile, where the order summary often gets pushed far below the fold. On a phone the customer can't glance up at a sidebar total the way they can on desktop, it's either on screen or it's a scroll away. Two mobile-specific moves:

• Keep a visible running total as the customer enters their address and picks a carrier, so the shipping number never arrives as a surprise on the payment step. PrestaShop recalculates the cart total server-side when the carrier changes; the job is making sure that updated total stays in the customer's eyeline on a small screen.
• Show shipping cost as early as the address allows. The faster the real total appears, the fewer customers reach payment, see a new number, and bail. The full anatomy of why checkouts lose sales lives in why your checkout page is losing you sales; here we just note that on mobile the surprise-cost problem is sharper because the total is harder to keep in view.

Mobile wallets: the fastest checkout is no typing at all

The single biggest mobile lever is letting the customer skip the form entirely. Apple Pay and Google Pay turn the entire address-and-card sequence into one biometric tap, the wallet hands over name, shipping address and payment token in a single confirmation. For a returning mobile shopper, that's the difference between a 90-second form and a three-second purchase.

In PrestaShop, you don't add these as standalone modules, they ride on your payment processor's module. Both Stripe and PayPal (and PrestaShop's own PrestaShop Checkout / PS Checkout module, which is powered by PayPal) expose Apple Pay and Google Pay as express buttons once enabled:

• Apple Pay requires a domain-verification file hosted on your store (the processor's module walks you through placing it). It only appears in Safari on Apple devices, that's an Apple platform rule, not a PrestaShop limit.
• Google Pay appears in Chrome and Android with no separate verification step on most processors.
• Placement matters more than presence. A wallet button buried under the card form does little; surfaced at the top of the payment step, or as an express button on the cart, it gets used. Enable wallet display in your Stripe or PS Checkout module settings and put it first on mobile.
• PayPal remains the no-typing fallback for shoppers without a wallet set up: they're often already logged in on their phone, so it's a tap rather than a card entry.

Wallets are mobile's edge; the broader case for one-tap purchase paths, express buttons on product and cart pages, reorder flows, is its own topic in express checkout.

Speed: every script on the checkout costs you mobile orders

A phone on a cellular connection is the slowest, least forgiving environment your checkout runs in, and it's exactly where weight hurts most. The checkout is the wrong page for chat widgets, social embeds, review carousels or marketing pixels, strip them to the essentials here even if you keep them elsewhere. PrestaShop's caching and asset settings (Advanced Parameters → Performance: combine, minify, and use a CDN) help across the store, and the checkout is where the payoff per millisecond is highest because everyone on it has already decided to buy. The store-wide picture is in our checkout optimization guide.

What's mobile-specific vs what's just good checkout

It's worth being honest about the line, because a lot of "mobile checkout" advice is really just "good checkout" advice that happens to matter more on a phone. Here's the split:

Where a checkout module fits

You can do most of the above with a child theme and a stylesheet, and if you've got a developer, that's a clean route. The reason merchants reach for a module is that the mobile wins are scattered: keyboard attributes in the form templates, touch sizing in CSS, a sticky total in the layout, wallet buttons in the payment settings. Our Checkout Revolution module ships these defaults already set, correct input types and autocomplete on the fields, touch-friendly sizing, a persistent order summary, and wallet-ready payment placement, on PrestaShop 1.6 through 9, without theme surgery or core edits, so an upgrade doesn't undo it. So what's the benefit? You get a mobile-tuned checkout from the back office instead of a per-field theme audit, and it survives the next PrestaShop update. The rebuild story is in Checkout Revolution 3.0.

FAQ

Why does the postcode field pop the wrong keyboard on my mobile checkout?

Because PrestaShop's classic theme generates the address fields server-side and doesn't reliably set inputmode="numeric" on the postcode input. The fix is to add the attribute, but only for countries with numeric postcodes. Set it per-country, since UK, Dutch and Canadian postcodes contain letters and a number pad would trap those customers. Do it in a child theme override of the address form template, never in a core file an upgrade would wipe.

How big should checkout buttons and fields be on mobile?

Apple's guidance is a minimum 44×44pt touch target; Google's Material guidance says 48×48dp. In practice: primary actions like "Continue" and "Place order" go full-width and at least 48px tall, form inputs want 44px+ of height, and tappable rows (carrier and payment options) should be the whole row, not just the radio dot. Leave around 8px between targets so thumbs don't mis-tap. All of this is CSS, no core edits.

Do I need an Apple Pay module, or is it part of my payment gateway?

It's part of your gateway. Apple Pay and Google Pay aren't standalone PrestaShop modules, they're express buttons exposed by Stripe, PayPal, or PS Checkout once you enable them in that module's settings. Apple Pay also needs a domain-verification file (the module walks you through it) and only appears in Safari on Apple devices. Google Pay shows in Chrome and Android with no separate verification on most processors.

Is testing in my browser's responsive mode good enough?

No, and this is the single most common mistake. Responsive mode won't show you the wrong keyboard popping up, a thumb missing a radio button, or a wallet button that fails to render. Run a full test order on a real phone, ideally the oldest device your customers use, and watch which keyboard appears for email, phone and postcode. That's how you find which field has the wrong attribute.

I improved mobile checkout but overall conversion didn't move. Did it work?

You're probably reading the wrong number. Mobile and desktop convert very differently, so an aggregate figure hides whether the mobile work moved the needle. Pull mobile-specific conversion, mobile cart-to-order rate and mobile checkout abandonment, before and after, over at least 30 days and a meaningful order count. The mobile line is the one that should improve; desktop staying flat is fine.

Test it on a real phone, then measure

Responsive mode in a desktop browser will not show you the wrong keyboard popping up, a thumb missing a radio button, or a wallet button that fails to render. Once, on an actual device, run the full flow:

• Complete a real test order on your oldest supported phone. The experience is only as good as the worst device your customers use.
• Watch which keyboard appears for email, phone and postcode. Wrong keyboard = wrong attribute, and now you know which field to fix.
• Try every payment method, especially Apple Pay in Safari and Google Pay in Chrome, confirm the buttons actually appear.
• Test with the phone's autofill on, then off, so you see both the returning and first-time experience.
• Time it. From cart to confirmation should be comfortable one-handed; if it drags, find the field or tap that's slowing it.

Then measure properly. Pull mobile-specific conversion from your analytics before you change anything, mobile cart-to-order rate and mobile checkout abandonment, and compare the same numbers over at least 30 days and a meaningful order count after. Mobile and desktop convert differently, so an aggregate figure will hide whether the mobile work actually moved the needle. The mobile checkout doesn't need to be pretty. It needs to let a distracted person finish buying with one thumb before the moment passes, and most of the gap between "responsive" and "thumb-friendly" is the handful of fixes above.