Розробка екрану оформлення замовлення (Checkout) у мобільному додатку
Checkout — екран, на якому користувачі йдуть найчастіше. Довга форма з полями адреси, вибором доставки та введенням картки на мобільному екрані перетворюється на випробування, якщо її не проектувати спеціально під touch interaction. Наша команда розробляє такі екрани з урахуванням усіх платформових особливостей — від правильної обробки KeyboardAvoidingView до інтеграції Apple Pay та Google Pay. Як показує практика, до 60% користувачів кидають оформлення при невдалій формі. Технічно це найскладніший екран в e-commerce додатку: платіжна інтеграція, валідація в реальному часі, робота з клавіатурою, управління кількома scroll-зонами. За 5 років на ринку ми реалізували понад 50 checkout-екранів для iOS та Android, знижуючи відсоток покинутих кошиків у середньому на 30-40%. Наш досвід дозволяє гарантувати дотримання всіх вимог App Store та Google Play.
Чому checkout — найскладніший екран?
Комбінація платіжних вимог, UX-нюансів та перформансу робить checkout вузьким місцем. Наприклад, на iOS потрібно коректно обробляти PKPaymentAuthorizationViewController в main thread, інакше додаток падає. На Android — перевіряти IsReadyToPayRequest перед показом Google Pay. При цьому всі поля повинні валідуватися без блокування введення, а клавіатура — не перекривати активне поле. Ми вирішуємо ці проблеми за допомогою перевірених патернів.
Як ми забезпечуємо безпеку платежів?
PCI DSS забороняє передавати raw дані картки через власний бекенд. Тільки tokenization на стороні SDK провайдера. За це Apple App Review відхиляє додатки з self-hosted card forms. Ми використовуємо готові SDK: stripe-react-native або нативний Stripe SDK, CloudPayments SDK, ЮKassa. Для кожного провайдера налаштовуємо токенізацію та 3D Secure. В результаті дані картки ніколи не потрапляють на ваш сервер.
Платіжні інтеграції
Це найбільш трудомістка частина. Кожен провайдер — окремий 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(). Економія на розробці з використанням готових SDK становить до 20%.
| Провайдер | SDK | Особливості |
|---|---|---|
| Stripe | stripe-react-native | PaymentSheet, CardField, 3D Secure |
| CloudPayments | CloudPayments SDK | Криптограма, рекурентні платежі |
| ЮKassa | YooKassa | Яндекс.Каса, Apple Pay на iOS |
Як платіжні інтеграції впливають на архітектуру?
Кожен провайдер вимагає свій сценарій: для Stripe потрібен PaymentIntent, для CloudPayments — криптограма, для ЮKassa — токен. Ми проектуємо шар платежів з абстрактним протоколом, щоб перемикання між провайдерами не зачіпало UI. Наприклад, в React Native використовуємо патерн Provider з загальним інтерфейсом processPayment(token: String). Це знижує вартість доробок при зміні платіжного шлюзу.
| Платформа | Особливості реалізації checkout |
|---|---|
| iOS | PKPaymentAuthorizationViewController, Core Data для кешування адрес, SwiftUI або UIKit |
| Android | Google Pay API, Room для зберігання даних, Jetpack Compose |
| Cross-platform | Єдина логіка валідації, нативні bridge для платежів |
Управління формою
Форма 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 рази та помилки доставки. Автозаповнення скорочує час заповнення форми з 3-4 хвилин до 30 секунд та знижує кількість помилок доставки на 25%.
З практики: додаток доставки, React Native + Stripe. При оплаті Apple Pay на фізичному iPhone XR додаток падав з NSException одразу після авторизації. Причина — PKPaymentAuthorizationController викликався з background thread. Перенесення в DispatchQueue.main в нативному модулі вирішило проблему. React Native bridge не гарантує main thread для callback'ів.
Чому валідація в реальному часі критична?
Користувач чекає миттєвого зворотного зв'язку. Якщо помилка показується тільки після натискання «Оплатити», він змушений виправляти кілька полів одразу, що збільшує ймовірність відмови. Ми реалізуємо валідацію по мірі введення для полів з чітким форматом, а для інших — після втрати фокусу. Це покращує конверсію на 10-15%.
Багатокроковий checkout
Для довгого checkout використовуємо stepper (кроки: адреса → доставка → оплата → підтвердження). Кожен крок — окремий компонент з власною валідацією. Стан зберігаємо в одному store, не передаємо через пропси між екранами. ProgressBar зверху показує поточний крок.
Кнопка «Назад» повинна зберігати вже введені дані — не скидати форму при поверненні до попереднього кроку.
Що входить в роботу
- Форма з полями адреси (з автодоповненням через Places API)
- Вибір способу доставки з розрахунком вартості та термінів
- Список збережених адрес користувача
- Інтеграція платіжного провайдера (Stripe, CloudPayments, ЮKassa та інші)
- Apple Pay / Google Pay з перевіркою доступності
- Валідація в реальному часі + обробка помилок API
- Екран підтвердження замовлення з номером та деталями
- Зберігання останньої використаної адреси та картки
- Документація з інтеграції та підтримка після релізу
Терміни та вартість
3–5 робочих днів — залежить від кількості платіжних провайдерів, складності логіки знижок та вимог до валідації адреси. Інтеграція одного провайдера з Apple Pay/Google Pay — 2–3 дні. Вартість розраховується індивідуально. Ми оцінимо ваш проект безкоштовно — напишіть нам, щоб обговорити деталі. Отримайте консультацію інженера та точну оцінку термінів вже сьогодні.