Development of Checkout Screen in Mobile Application
Checkout is screen where users abandon most. Long form with address fields, delivery choice and card input on mobile turns into ordeal if not designed specifically for touch interaction. Technically most complex screen in e-commerce app: payment integration, real-time validation, keyboard work, multiple scroll zones management.
Payment integrations
Most labor-intensive part. Each provider — separate SDK with own requirements.
Stripe — stripe-react-native or native Stripe iOS/Android SDK. CardField component handles card input with auto-formatting and validation. PaymentSheet — ready bottom sheet from Stripe, minimal customization maximum reliability. For custom UI — useStripe().confirmPayment() with PaymentIntent client secret from backend.
Apple Pay / Google Pay. On iOS — PKPaymentAuthorizationViewController, in React Native via @stripe/stripe-react-native with useApplePay(). On Android — PaymentsClient from Google Pay API + IsReadyToPayRequest. Show both buttons only if payment method available on device — stripe.isApplePaySupported() / paymentsClient.isReadyToPay().
Important: PCI DSS forbids raw card data through own backend. Only tokenization on SDK provider side. Apple App Review rejects apps with self-hosted card forms.
Form management
Checkout form usually contains 10–15 fields. Without proper field navigation (returnKeyType="next" + ref.focus() on next input) unbearable. In React Native Hook Form — Controller + useRef array for fields + auto setFocus on error after submit.
Keyboard — main pain. KeyboardAwareScrollView from react-native-keyboard-aware-scroll-view works better than standard KeyboardAvoidingView: auto scrolls to active field and correctly handles height change on orientation change.
On iOS numeric fields (postal code, CVV) should open UIKeyboardType.numberPad. decimalPad for amount. emailAddress for email. Wrong keyboardType — trifle, noticed by all users and not mentioned.
Validation and UX
Real-time validation only for fields with deterministic format: phone, email, postal code, card number. For text fields (name, address) — only after blur (onBlur), else error "wrong name" appears on third letter.
Address autocomplete via Google Places Autocomplete API or Dadata API (for RU) — mandatory element. Manual street, building, apartment entry in separate fields increases fill time 3–4x and delivery errors.
Case from practice: delivery app, React Native + Stripe. On Apple Pay payment on physical iPhone XR app crashed with NSException right after authorization. Reason — PKPaymentAuthorizationController called from background thread. Moving to DispatchQueue.main in native module fixed. React Native bridge doesn't guarantee main thread for callbacks.
Multi-step checkout
For long checkout use stepper (steps: address → delivery → payment → confirmation). Each step — separate component with own validation. Store state in one store, don't pass through props between screens. ProgressBar top shows current step.
Back button must preserve entered data — don't reset form returning to previous step.
What's included
- Form with address fields (with autocomplete via Places API)
- Delivery method selection with cost and timeline calculation
- List of user's saved addresses
- Payment provider integration (Stripe, CloudPayments, YooKassa etc)
- Apple Pay / Google Pay with availability check
- Real-time validation + API error handling
- Order confirmation screen with number and details
- Storage of last used address and card
Timeline
3–5 working days — depends on number of payment providers, discount logic complexity and address validation requirements. Single provider integration with Apple Pay/Google Pay — 2–3 days. Cost calculated individually.