Ecommerce App Design: Mobile Checkout Flow

Ecommerce app design should reduce checkout to guest entry, an express wallet choice, only the fields required for delivery and payment, and one final review with shipping and tax included. Put Apple Pay and Google Pay at the top of the payment choice before manual card entry; keep account creation after a successful order. Use platform autofill hints and field-blur validation so people correct one field at a time. Show the payable order total before the final Place Order or wallet authorisation action.

Key takeaways

•Offer guest checkout before sign-in; ask to create an account after a successful order.
•Place Apple Pay and Google Pay above manual card entry in the payment section.
•Use autocomplete="cc-number" and Android AUTOFILL_HINT_CREDIT_CARD_NUMBER for card numbers.
•Validate a field on blur, then identify the error next to that field.
•Show item total, shipping, tax, discounts, and the final order total before authorisation.

This guide is for mobile product designers, founders, and engineers who already understand iOS and Android screen patterns.

Time: 45 minutes · You'll need: A current iPhone and Android device or platform simulators, Your checkout API’s required address, shipping, tax, and payment fields, Apple Pay and Google Pay sandbox or test merchant configuration, A prototype tool with iOS and Android component libraries

What's on this page

•Start with guest checkout before account creation
•Put wallets first in the app payment flow
•Configure checkout screen design fields for autofill
•Validate mobile checkout UX on field blur
•Reveal the full payable cost before authorisation
•Reference table

•Common mistakes
•FAQs

Designing an ecommerce app design checkout flow

1. Start with guest checkout before account creation

Make the first checkout decision Guest checkout and Sign in, with guest as the visually primary route when the customer has not authenticated. Do not place account registration between the cart and delivery details. A customer who needs a shipment should provide a delivery address; a customer buying a digital item may need only an email address and a payment method.

Collect an email address when it is required for the receipt, delivery updates, or recovery, then continue to shipping or payment. After payment succeeds, offer account creation using the email already collected and an OS-supported credential method where available. This preserves the order confirmation as the completion point rather than turning registration into a checkout gate.

The result is a flow with no compulsory password field before purchase. Signed-in customers can still receive saved addresses and payment methods, but an anonymous customer reaches the same payable order without a forced identity task.

Tip: If saved order history is your reason for gating checkout, attach the completed guest order to the account created on the confirmation screen instead.

2. Put wallets first in the app payment flow

Put Apple Pay on iOS and Google Pay on Android at the top of the payment method area, before the manual card form. Present the applicable branded button at its approved size and appearance; do not redraw the Apple Pay or Google Pay mark as a custom primary button. If both options can be available in the same cross-platform checkout, show the wallet supported by the current device first and retain manual card entry below it.

Show the wallet button only after the customer has selected the purchasable items and any choices that change the total, such as delivery speed. The button must lead directly to the platform payment sheet, where the customer confirms the payment method and authorises the transaction. Keep the order total near the button and pass the same final amount to the payment request.

Do not put an Apple Pay button inside a card-number field or after a lengthy manual form. Wallet payment is the shortest path because the platform can provide a selected payment credential and, when requested, contact and shipping information.

Tip: If a shipping address changes the price, collect or select shipping before exposing a wallet button that displays a final payable total.

3. Configure checkout screen design fields for autofill

Use the keyboard and autofill metadata that match the value, not a generic text field. For an embedded web or hybrid checkout, use type="email" with autocomplete="email" for email, autocomplete="shipping street-address" for a complete shipping street address, shipping address-level2 for city, shipping address-level1 for state or region, shipping postal-code for postal code, and shipping country for country. Use type="text" inputmode="numeric" autocomplete="cc-number" for a card number, autocomplete="cc-exp" for expiry, and autocomplete="cc-csc" for the security code.

For native Android fields, supply Autofill Framework hints such as AUTOFILL_HINT_CREDIT_CARD_NUMBER, AUTOFILL_HINT_CREDIT_CARD_EXPIRATION_DATE, and AUTOFILL_HINT_CREDIT_CARD_SECURITY_CODE. On iOS, use the matching UITextContentType values where the platform exposes them, including creditCardNumber, rather than relying on a placeholder such as “1234 5678”.

Keep card number, expiry, and security code as separate controls when manual entry is necessary. Preserve the value formatting users expect, but send only normalised values to the payment provider.

Tip: Do not use type="number" for card numbers: numeric controls can alter input behaviour and do not describe a payment-card identifier.

4. Validate mobile checkout UX on field blur

Run required-field and format checks when a field loses focus, commonly called the blur event, after the user has had a chance to enter a value. Put the error text next to the affected control and programmatically associate it with that field. For example, after a customer leaves the postal-code field, show “Enter a valid postal code” only if the selected delivery country requires one and the supplied value fails your delivery rules.

On submit, keep the same inline errors and move focus to the first invalid field. Do not replace the screen with a summary such as “Please fix 6 errors”; that makes the customer hunt through a long mobile form. WCAG 2.2 Success Criterion 3.3.1 requires input errors that are automatically detected to be identified and described to the user.

Avoid validating while the customer is still typing a card number or address. Network checks, including address normalisation and card authorisation, belong after a complete value is available or after the customer submits the payment action. Keep error copy specific enough to correct the value without exposing sensitive payment details.

Tip: Reserve vertical space below each field for an error message so a late error does not make the primary button jump under the user’s thumb.

5. Reveal the full payable cost before authorisation

Before the final Place Order action, show a compact order summary with line items for merchandise subtotal, discounts, shipping, tax, and the final order total. Use the same currency and amount that the payment request sends to Apple Pay, Google Pay, or the card processor. If delivery method changes shipping or tax, recalculate the summary immediately after that selection and before the user reaches authorisation.

Keep the final total adjacent to the action that commits payment. A sticky bottom action can work on long review screens, but it must display the payable total or remain paired with a visible total summary. For Apple Pay, provide the final total to the Apple Pay payment sheet; do not treat the wallet sheet as a substitute for showing price changes caused by your own checkout choices.

If you cannot calculate tax until an address is known, say so before payment and collect the minimum address needed to calculate it. Do not label a pre-tax subtotal as “Total.” The final screen should allow the customer to edit delivery, payment, or promotional choices without restarting checkout.

Tip: For an order with free shipping, retain a shipping row labelled “Free” rather than removing it; the customer can verify that shipping was considered.

Reference table

Minimum checkout control target sizes

Platform	Minimum target	Checkout use
iOS	44 × 44 pt	Apple minimum tappable target
Android	48 × 48 dp	Material touch target
WCAG 2.2 AA	24 × 24 CSS px	Minimum target-size criterion

Common mistakes

Showing “Create account” as the only primary action before checkout.

Make guest checkout available at the same decision point and defer password creation until the order confirmation screen.

Displaying Apple Pay or Google Pay below three manual card fields.

Put the supported wallet button at the top of payment methods. Manual card entry is the fallback path.

Using placeholder text as the only field label.

Keep a persistent visible label and add the relevant autocomplete or native Autofill Framework hint. Placeholder text disappears during entry.

Showing every validation error only after Place Order is tapped.

Check completed fields on blur, show the error beside its field, and focus the first invalid control if submission still fails.

Frequently asked questions

Should an ecommerce app require users to create an account before checkout?

No, an ecommerce app should offer guest checkout before account creation. Require only information needed to fulfil the order, take payment, and send a receipt. Offer account creation after a successful purchase, when the customer can save their details without blocking the transaction.

Where should Apple Pay and Google Pay go in a mobile checkout UX?

Apple Pay and Google Pay should appear at the top of the payment-method section before manual card fields. Show the supported wallet’s approved branded button after the customer has made choices that determine the final amount. The wallet action should open the platform payment sheet directly.

What autocomplete attributes should I use for a checkout screen design?

Use autocomplete="cc-number", cc-exp, and cc-csc for manual card fields, plus shipping address tokens such as shipping street-address and shipping postal-code. In native Android apps, provide equivalent Autofill Framework hints. Use a visible label as well as metadata because autofill metadata does not replace field comprehension.

When should a mobile app validate checkout fields?

A mobile app should validate completed checkout fields on blur and show the error beside the field. Recheck all required fields on submission and move focus to the first invalid one. Avoid format warnings while someone is still entering an address or payment-card number.

Where this leaves you

A short checkout is not one with the fewest visible controls; it is one that asks only for data needed to price, fulfil, and authorise the current order. Guest entry removes an avoidable identity task. Wallet-first payment removes manual credential entry on supported devices. Autofill metadata, blur validation, and a complete total make the remaining fields faster to finish and easier to trust. Build one test order for iOS and one for Android now, then remove every screen or field that neither changes fulfilment nor changes the final payable amount.

Design the screens first

Describe the screen you need in plain English and floow.design generates production-ready iOS and Android layouts you can iterate on by chat, then export to Figma or code. Design your mobile app screens in floow.design first, then build.

Start designing free →

•Color Picker from Image — Pull a palette out of any image, assign it to screen roles, and export it as tokens or native code.
•Aspect Ratio Calculator — Work out the missing width or height for any ratio, with the common phone and store ratios one click away.
•Empty State Design for Mobile Apps — Empty state design for iOS and Android: classify zero-data screens, choose one action, and
•Mobile App Navigation Design: A Practical Guide — Build mobile app navigation design that keeps primary destinations within two taps, with i
•Gemini 3.1 for Mobile App UI Design: 4 Real Prompts Tested Hands-On (2026) — I tested Gemini 3.1 Pro with 4 real mobile app UI prompts — fitness tracker, food delivery