# Why the native PrestaShop checkout loses customers on mobile
> The native funnel was designed for a wide screen and keeps choices that cost orders at every step. The screen-by-screen analysis, the three most profitable fixes, and the ten-minute diagnostic method.
- Page:
- Language: en
- Published: 2026-09-27
- Last updated: 2026-09-27
- Other languages: [fr](https://www.datafirefly.com/2026/09/27/checkout-prestashop-mobile-abandons/index.md), [es](https://www.datafirefly.com/es/2026/09/27/checkout-prestashop-movil-abandonos/index.md), [de](https://www.datafirefly.com/de/2026/09/27/prestashop-checkout-mobile-abbrueche/index.md), [it](https://www.datafirefly.com/it/2026/09/27/checkout-prestashop-mobile-abbandoni/index.md), [pl](https://www.datafirefly.com/pl/2026/09/27/checkout-prestashop-mobile-porzucenia/index.md), [nl](https://www.datafirefly.com/nl/2026/09/27/checkout-prestashop-mobiel-afhakers/index.md), [pt](https://www.datafirefly.com/pt/2026/09/27/checkout-prestashop-mobile-abandonos/index.md)
- Index:
The PrestaShop order funnel was designed for a wide screen. On mobile, where most traffic now happens, it keeps interface choices that cost orders at every step.
Here is the screen-by-screen analysis, with what can be fixed without a redesign.
## Screen 1: the cart
Three recurring problems.
**The order button below the list.** On a five-item cart, it sits below a long scroll. The expected behaviour is a fixed button at the bottom of the screen, showing the total, permanently visible.
**Tiny quantity selectors.** The plus and minus buttons are often under thirty pixels. The accessibility recommendation puts the minimum touch target around forty-four pixels per side. Below that, the customer hits the wrong button, has to correct, and gets annoyed.
**Deletion without confirmation or undo.** An accidental tap on the bin empties a line with no recourse. A temporary undo option avoids the full mental reload of the cart.
## Screen 2: identification
This is the screen that produces the most abandonments on mobile, and two technical details are enough.
**The email field does not call the right keyboard.** A correctly typed field brings up a keyboard with the at sign accessible. Without it, the customer goes through the toggle key on every entry.
**Autofill does not work.** Browsers know how to fill email, name, address and card, provided the fields carry the expected autocomplete hints. A correctly annotated form fills in two taps. A form without annotation forces a full manual entry.
This is probably the most profitable fix in the whole funnel, and it only requires adding attributes to existing fields.
Third point: the password. If you require account creation, the absence of an option to show the typed password produces repeated errors on a touch keyboard.
## Screen 3: the address
The address form is the longest in the funnel and the least well adapted.
**Too many fields.** Many setups ask for company, address line 2, a second complement, landline and mobile phone. On mobile, every extra field is an obstacle. Reduce to the strict minimum and hide optional fields behind a link.
**The postcode does not call the numeric keyboard.** Same remark as for email: the field type determines the keyboard offered.
**The field order does not follow local logic.** In most European countries, the postcode is entered before the city, and the former should pre-fill the latter. This autocompletion removes an entire field and reduces errors.
**Errors appear after validation.** A form that reports five errors in a block after a button tap forces scrolling back up the page. Inline validation, field by field as the customer types, is far less frustrating.
## Screen 4: shipping
Two problems.
**Shipping options in cramped radios.** Three carriers presented as compact rows with small radio buttons produce wrong selections. Each option should be a fully clickable card.
**The pickup point in an unadapted map.** Pickup point modules often display a map designed for desktop, with tiny markers and capricious zoom. On mobile, a list ordered by distance, with the map as an option, works better.
## Screen 5: payment
This is the screen where a problem costs the most, since all the previous effort is lost.
**The numeric keyboard for the card.** The card number, expiry date and security code must call a numeric keyboard. This is still frequently misconfigured, including in recent payment modules.
**Card autofill.** Browsers and password managers know how to fill a saved card, provided the autocomplete hints are correct. Without them, the customer has to take out the physical card, which interrupts the journey and leaves time to give up.
**Redirection to an unadapted bank page.** Strong authentication sometimes opens a page with broken display on mobile. Test this journey in real conditions, with a real card: it is the least tested and most critical point of the funnel.
**The return after authentication.** If the customer switches to their banking app to validate, they leave the browser. The return must restore the session and continue the order, not restart from the cart.
## Cross-cutting problems
Four elements that affect every screen.
**Automatic zoom on focus.** On some mobile browsers, a field with a font size under sixteen pixels triggers an automatic zoom on selection, which shifts the whole page. The fix is to never go below that size in forms.
**The keyboard hiding the active field.** On a long form, the virtual keyboard sometimes covers the field being filled. Scrolling must adjust when the keyboard opens.
**Stacked fixed banners.** Fixed header, cookie banner, promotional banner: on a phone screen, sometimes only a third of the height remains for content. In the funnel, remove everything that is not necessary.
**Loading time between steps.** Every full reload is an opportunity to abandon. A one-page funnel, or transitions without reload, removes these break points.
## The diagnostic method
Three actions, in this order, before any modification.
**Place an order on your own phone**, in real conditions, with a real card and a mobile network rather than wifi. It reveals the bulk of the problems in ten minutes.
**Record the completion rate per step**, separately on mobile and desktop. The gap between the two locates the problem: if mobile drops at the address, there is no point reworking the payment.
**Watch recordings of mobile sessions** that did not complete. Hesitations, repeated corrections and manual zooms are immediately visible and point to the problematic fields.
## Where to start
If you can only do three things, take these.
**The autocomplete attributes** on every field in the funnel. Low cost, immediate effect, and it benefits every browser.
**The field types**, so each entry calls the right keyboard. Same logic, same effort-to-result ratio.
**The touch targets** raised to a minimum of forty-four pixels on every interactive element in the funnel.
These three fixes require no redesign and address the majority of measurable frictions.
The rebuilds this journey on PrestaShop 8 and 9: a one-page funnel with no reload between steps, a lightened address form with city pre-fill from the postcode, field types and autocomplete attributes correctly set, and touch targets sized for mobile.