Mobile checkout design: fewer steps, faster forms and clearer errors

Checkout is the one part of a shopping app where people have already decided. They picked the product, the size and the color. All that's left is to say who they are, where it goes and how they'll pay. Every extra field or vague message at this point adds friction to a decision that was already made, and on a phone, with one thumb and a small keyboard, friction adds up quickly.

This guide is about the screens: steps, accounts, autofill, wallets, addresses, errors and the small signals that make people comfortable paying. The business side, meaning store rules for physical goods, payment providers and returns, is covered in our guide to app commerce.

Contains affiliate links. As an Amazon Associate I earn from qualifying purchases.

Map the steps, then remove some

Write your current checkout as a numbered list of screens and count the fields and taps on each. A typical first draft runs cart, sign-in, address, delivery method, payment, review and confirmation: seven screens before the thank-you. Most of them can merge.

1. Cart, with the delivery cost and the total already shown, not "calculated at checkout".
2. One details screen for contact, address and delivery method, prefilled wherever possible.
3. Payment, with wallet buttons at the top.
4. Confirmation, with the order summary and a delivery date.

A separate review screen earns its place only when the order is complex, for example with several delivery addresses. Otherwise, show the summary on the payment screen and make the pay button the final action, labeled with the amount: "Pay $42.50" leaves no doubt about what happens next.

Guest checkout first, account later

Forcing an account before the first purchase asks for a commitment people haven't decided to make. Apple's guidance for Apple Pay is plain about it: avoid requiring account creation before purchase, ask on the order confirmation page instead, and prefill the registration fields with what was entered at checkout. The same logic works for every payment method. A "Save your details for next time" offer with a passkey after payment turns a guest into an account holder at the moment they're happiest with you. Our guide to onboarding flows people finish covers deferred sign-up in more depth.

Put wallet payments up front

When someone has Apple Pay or Google Pay set up, checkout can shrink to one tap and Face ID, Touch ID or a fingerprint, because the wallet supplies the card, contact details and often the shipping address.

Apple's Apple Pay guidelines recommend assuming people want to use it when it's available: show the button as the first payment option, larger than the others, or set apart with a line. They suggest an Apple Pay button on product pages for single-item purchases and an express checkout for the whole cart. Don't hide the button or make it look unavailable when, say, a size hasn't been chosen. Let people tap it, then point out what's missing and move them to the field. The payment sheet can't collect optional extras such as a gift message or delivery instructions, so gather those before checkout or after the purchase.

Google's brand guidelines require the PayButton API for the Google Pay button in apps, forbid changing its font, color, corner radius or padding, and ask that it be at least as large and as prominent as the other payment buttons.

Autofill and the right keyboard

Typing an address on a phone is slow and error-prone, and the system usually knows most of it already. Tag every field so autofill can help. On iOS, set textContentType on each text field. In Jetpack Compose, set the content type through the semantics modifier, as described in Google's Compose autofill guide.

nameField.textContentType = .name
streetField.textContentType = .streetAddressLine1
postcodeField.textContentType = .postalCode
emailField.textContentType = .emailAddress
emailField.keyboardType = .emailAddress

TextField(
    state = emailState,
    keyboardOptions = KeyboardOptions(keyboardType = KeyboardType.Email),
    modifier = Modifier.semantics { contentType = ContentType.EmailAddress }
)

If part of your checkout runs in a web view, the HTML autocomplete attribute does the same job with values such as postal-code, email and cc-number. Match keyboards to fields as well: numeric for card numbers, an email keyboard for email, a phone pad for phone numbers. Don't force a numeric keyboard on postal codes, which contain letters in countries such as the Netherlands and the United Kingdom. And never block paste, since password managers and people copying a code from a message both rely on it.

Address entry without the pain

Addresses vary by country more than most forms assume. Ask for the country first, or take it from the device region, then show the fields that country uses in the order people there expect. Don't require a state or province where none exists. In the Netherlands, a postcode and house number are usually enough to look up the street and town, which turns five fields into two. Elsewhere, address suggestions as people type do a similar job; on iOS, MapKit's search completer can provide them.

Make the name a single field, long enough for real names, and accept characters beyond the basic Latin alphabet. Ask for a phone number only when the courier needs one, and say why next to the field: "For the courier, if they can't find your door."

Error messages that get people unstuck

Validate a field when people leave it, not on every keystroke, and keep everything they typed when something fails. Put the message next to the field, describe the problem in plain words, and say how to fix it. Don't rely on red alone: pair color with an icon and text, and move VoiceOver and TalkBack focus to the first error so screen reader users hear what went wrong. Our accessibility checklist covers how to test this.

That last case needs engineering as well as copy. Send each payment attempt with an idempotency key so a retry can't create a second charge. For declines, don't show raw codes, and don't spell out reasons such as suspected fraud. Offer a next step: another card, a wallet, or a bank payment.

Trust signals that earn their space

People pay when nothing surprises them. Show the full price, delivery included, before the final screen. Give the delivery date as a date, "Thursday, October 22", rather than a range of business days. Put the return policy one tap from the pay button, summed up in a sentence. Keep your branding consistent through the whole flow; Apple notes that opening new windows mid-checkout can make people think they've been handed to a different site. Make help reachable from every checkout screen.

Avoid the tricks that wear trust down: pre-ticked add-ons such as insurance, countdown timers that quietly reset, and decline buttons that mock the customer. Pre-ticked paid extras are also not allowed for consumers in the EU, where the seller needs express consent for any payment beyond the main purchase. Then measure completion per step and change one thing at a time, using the approach in our guide to A/B testing in mobile apps.

Questions

How many steps should a mobile checkout have?

As few as the order allows. For one delivery address and one payment, three screens after the cart (details, payment, confirmation) is a realistic target, and a wallet payment can fold the first two into a single sheet.

Should guest checkout be the default?

For first purchases, yes. Offer an account after payment, prefilled from the order. Returning customers who are signed in should see their saved details rather than the guest form.

Where should the Apple Pay and Google Pay buttons go?

At the top of the payment options, at least as large as the alternatives, and on product pages for quick single-item purchases. Use the official buttons as supplied and never draw your own versions.

What should we fix first in an existing checkout?

Look at completion per step and start with the screen where most people leave. A forced sign-in and a long address form are common culprits, and both have well-known fixes: guest checkout and autofill.