Розробка екрана оформлення замовлення (Checkout) в мобільному додатку
Checkout — екран, на якому користувачі йдуть чаще за все. Довга форма з полями адреси, виборомзбургоставки та вводом карти на мобільному екрані перетворюється на випробування, якщо її не проектувати спеціально під touch interaction. Технічно це найскладніший екран у e-commerce додатку: платіжна інтеграція, валідація в реальному часі, робота з клавіатурою, управління кількома scroll-зонами.
Платіжні інтеграції
Це найтрудомісткіша частина. Кожен провайдер — окремий SDK зі своїми вимогами.
Stripe — stripe-react-native або нативний Stripe iOS/Android SDK. CardField компонент берё на себе ввід карти з автоформатуванням та валідацією. PaymentSheet — готовий bottom sheet від Stripe, мінімум кастомізації, максимум надійності. Для кастомного UI — useStripe().confirmPayment() з PaymentIntent client secret з бекенду.
Apple Pay / Google Pay. На iOS — PKPaymentAuthorizationViewController, у React Native через @stripe/stripe-react-native з useApplePay(). На Android — PaymentsClient з Google Pay API + IsReadyToPayRequest. Показуємо обидві кнопки тільки якщо платіжний метод доступний на пристрої — stripe.isApplePaySupported() / paymentsClient.isReadyToPay().
Важливо: PCI DSS забороняє передавати raw дані карти через власний бекенд. Тільки tokenization на стороні SDK провайдера. Apple App Review відхиляє додатки з self-hosted card forms.
Управління формою
Форма checkout звичайно містить 10–15 полів. Без правильної навігації між полями (returnKeyType="next" + ref.focus() на наступному інпуті) це невиносимо. У React Native Hook Form — Controller + useRef масив для полів + автоматичний setFocus при помилці після submit.
Клавіатура — головна біль. KeyboardAwareScrollView з react-native-keyboard-aware-scroll-view працює краще за стандартний KeyboardAvoidingView: автоматично скроллить до активного поля та коректно обробляє зміну висоти при зміні орієнтації.
На iOS числові поля (індекс, CVV) повинні відкривати UIKeyboardType.numberPad. decimalPad — для суми. emailAddress — для email. Неправильний keyboardType — дрібниця, яку замічають усі користувачі та не говорять про неї вголос.
Валідація та UX
Валідація в реальному часі — тільки для полів з детерміністичним форматом: телефон, email, індекс, номер карти. Для текстових полів (ім'я, адреса) — тільки після втрати фокуса (onBlur), інакше помилка «неправильне ім'я» з'являється на третій букві.
Автозаповнення адреси через Google Places Autocomplete API або Dadata API (для РФ) — обов'язковий елемент. Ручний ввід вулиці, дому, квартири окремими полями збільшує час заповнення в 3–4 рази та помилки доставки.
Кейс з практики: додаток доставки, React Native + Stripe. При оплаті Apple Pay на фізичному iPhone XR додаток падав з NSException відразу після авторизації. Причина — PKPaymentAuthorizationController викликався з background thread. Перенос в DispatchQueue.main у нативному модулі вирішив проблему. React Native bridge не гарантує main thread для callback'ів.
Багатокроковий checkout
Для довгого checkout використовуємо stepper (кроки: адреса → доставка → оплата → підтвердження). Кожен крок — окремий компонент з власною валідацією. Стан зберігаємо в одному store, не передаємо через props між екранами. ProgressBar зверху показує поточний крок.
Кнопка «Назад» повинна зберігати вже введені дані — не скидати форму при поверненні до попереднього кроку.
Що входить у роботу
- Форма з полями адреси (з автодоповненням через Places API)
- Вибір способу доставки з розрахунком вартості та строків
- Список збережених адрес користувача
- Інтеграція платіжного провайдера (Stripe, CloudPayments, ЮKassa та ін.)
- Apple Pay / Google Pay з перевіркою доступності
- Валідація в реальному часі + обробка помилок API
- Екран підтвердження замовлення з номером та деталями
- Збереження останньої використаної адреси та карти
Строки
3–5 робочих днів — залежить від кількості платіжних провайдерів, складності логіки скидок та вимог до валідації адреси. Інтеграція одного провайдера з Apple Pay/Google Pay — 2–3 дні. Вартість розраховується індивідуально.