Mobile App Checkout Screen Design
Checkout is the most responsible UX screen in eCommerce. Up to 70% of users who already decided to buy are lost here. Almost always the reason is not technical payment issues, but how the form is designed: how many steps, field order, how clear validation errors are.
Single-Page or Multi-Step: Not a Matter of Taste
The main architectural choice sets everything else. Single-page checkout (all-in-one scroll)—faster for user, but requires smart keyboard focus management. When user taps "Street" field, keyboard rises and hides next fields—need KeyboardAwareScrollView (iOS) or WindowSoftInputMode.ADJUST_RESIZE with proper scrollTo (Android). If this is not refined in design, developer does it their way, and UX suffers.
Multi-step checkout (Step 1: address → Step 2: shipping → Step 3: payment) reduces cognitive load. Progress indicator is mandatory—user must know where they are and how much is left. Back navigation must preserve entered data—data loss on "Back" press kills conversion.
Fields and Validation: Where Everything Breaks
Phone number field: mask, format, validation—three separate tasks. Mask formatting +7 (___) ___-__-__ is implemented via PhoneNumberKit on iOS or libphonenumber on Android. Design should show: how field looks focused, how filled, how with validation error, how with successfully confirmed number.
Inline validation (error message below field while typing) vs validation on blur—this is a design decision with real consequences. Inline annoys if it triggers too early. Optimal pattern: show error only after user touched field and left it (onBlur in React Native / Flutter terms).
Typical fields and their nuances:
- Email:
keyboardType = .emailAddress, auto-capitalization disabled - Card number: grouped by 4 digits,
keyboardType = .numberPad, input mask - CVV:
isSecureTextEntry = true, 3–4 characters max - Card date: mm/yy formatting, auto-advance between fields
- Cardholder name:
autocorrection = false,autocapitalization = .words
Each field is a component with explicit states in Figma: empty, focused, filled, error, disabled.
Shipping and Payment Method Selection
Shipping methods—radio-list with price and delivery time for each option. If many options (>4), need dropdown or separate selection screen. Pickup point cards—separate story: need either a map or list with addresses and hours.
Payment methods on iOS in 2024: Apple Pay via PKPaymentAuthorizationController, cards, SBP (for Russian market), buy-now-pay-later (services like Dolami). Apple Pay should be first in list and have separate button—per Apple HIG. On Android—Google Pay via PaymentsClient, same logic.
Saved user cards: display masked number **** 4242, card type (Visa/Mastercard icon), selection and deletion options. Tokenization happens on payment provider side (Stripe, CloudPayments, Yookassa), design must reflect this correctly.
Order Confirmation Screen
The final step is often made carelessly. Yet it is the last thing user sees in the session—it forms purchase impression. Mandatory: order number, brief contents, amount, shipping method and time, "Continue shopping" button and tracking link (if applicable). Success animation—Lottie with simple checkmark icon, no overload.
Process and Timeline
Design of full checkout flow: requirement analysis → step prototyping → screen design with all states → Figma Dev Mode handoff.
| Scope | Timeline |
|---|---|
| Single-page checkout, basic fields | 1–1.5 days |
| Multi-step, shipping + payment selection | 2–3 days |
| Full flow with pickup map and native Pay | 3–4 days |
Cost is calculated individually after reviewing requirements.