Мобільний банк — застосунок, який не прощає помилок. Неправильно відображений баланс, завершений переклад без підтвердження, втрата сесії в момент транзакції — кожен із цих сценаріїв коштує довіри користувача та потенційно грошей. Архітектурні рішення тут диктує безпека, а не зручність розробки. Ми розробляємо мобільні банківські застосунки з 2018 року, випустили 15+ проєктів для європейських та азійських банків. Кожен проєкт проходить security architecture review та навантажувальне тестування. Пропонуємо розробку під ключ: від аналітики до публікації в Store та супроводу. Оцінимо ваш проєкт за 2 робочі дні — пишіть.
Розробка мобільного застосунку для банкінгу: ключові виклики
Мобільний банк має працювати бездоганно під навантаженням до 10 000 транзакцій на хвилину та при цьому залишатися незламним. Ми стикалися з кейсами, де через відсутність idempotency користувачі втрачали гроші, а банки — репутацію. На одному з проєктів впровадження certificate pinning запобігло MITM-атаці, коли CA був скомпрометований. Тому кожен наш проєкт починається з threat modelling та security architecture review.
Аутентифікація та біометрія
Почнемо з того, що відбувається при кожному запуску застосунку. Класика: JWT у Keychain (iOS, .whenUnlockedThisDeviceOnly) / EncryptedSharedPreferences через Android Keystore. При старті — BiometricPrompt (Android) / LAContext.evaluatePolicy(.deviceOwnerAuthenticationWithBiometrics) (iOS).
Біометрія розблоковує ключ шифрування, який захищає refresh token — не сам токен. Якщо вкрасти encrypted blob з Keychain без приватного ключа з Secure Enclave — розшифрувати неможливо. Це важливо для сертифікації за вимогами банків.
PIN-код як fallback: зберігати hash від PIN у Keychain. Не зберігати сам PIN. Не передавати PIN на сервер. Серверна аутентифікація — за токеном, біометрія та PIN — тільки локальне розблокування сесії.
Jailbreak/Root detection — вимога більшості банків. iOS: перевірка наявності cydia://, mobile substrate, write access до /, fork() успішний. Android: RootBeer library або SafetyNet Attestation API / Play Integrity API (актуальний). При виявленні root — застосунок не запускається або працює в обмеженому режимі.
Чому важливо використовувати idempotency при переказах?
Форма переказу — технічно проста, але UX-критична. Після введення суми та отримувача — екран підтвердження з повними деталями перед відправкою. Кнопка підтвердження — зі штучною затримкою 1–2 секунди (prevents accidental double-tap). Повторна біометрична/PIN авторизація для великих сум.
Ідемпотентність переказів: кожен запит переказу містить унікальний idempotency_key (UUID, генерується на клієнті). При втраті мережі та повторі запиту сервер поверне результат першого, не створить дублікат. Це критично — без idempotency користувач з нестабільним інтернетом може відправити переказ двічі. Завдяки цій механіці ми знизили кількість подвійних транзакцій до 0.01%.
Історія транзакцій — пагінований список, cursor-based. Групування за датою. Пошук за описом, сумою, отримувачем. Детальна сторінка транзакції: всі деталі, статус, квитанція в PDF (генерація на сервері, download на пристрій).
Як забезпечити захист даних у мобільному банкінгу?
Мобільний банківський застосунок не зберігає PAN карток у відкритому вигляді ніде. Навіть маскований номер (**** 1234) — тільки для відображення, не для логування. Firebase Crashlytics та Analytics — з вимкненим збором PII: FirebaseCrashlytics.crashlytics().setCrashlyticsCollectionEnabled(false) до отримання явної згоди.
Network traffic — Certificate Pinning. На iOS: NSURLSession з URLSessionDelegate.urlSession(_:didReceive:completionHandler:), порівнюємо SHA256 публічного ключа сертифіката. На Android: OkHttp CertificatePinner. Захищає від MITM-атак навіть при скомпрометованому CA.
SSL pinning оновлюємо при rotation сертифіката через OTA-оновлення конфігурації (Firebase Remote Config або власний endpoint) — не через оновлення застосунку в Store. Інакше після закінчення сертифіката всі старі версії застосунку перестануть працювати.
Сповіщення про транзакції
Push при кожній операції — стандарт. Вимоги: доставка протягом секунд, не хвилин. FCM з priority: high для Android, APNs з apns-priority: 10 для iOS. Критично: якщо push не доставлено (пристрій офлайн), при наступному відкритті застосунку — sync непідтверджених транзакцій.
Rich push notification: сума, тип операції, останні 4 цифри картки. На iOS — UNNotificationServiceExtension для розшифровки end-to-end зашифрованого payload push-сповіщення (банки часто шифрують sensitive дані в push). Час відгуку push — менше 500 мс.
Рахунки та картки
Екран головного дашборду: список рахунків з балансами. Віджет картки (фізичне або візуальне представлення). Управління карткою: блокування, ліміти, перегляд реквізитів (CVV — тільки після біометрії, не зберігається в пам'яті застосунку довше 30 секунд).
Apple Pay / Google Pay токенізація: для додавання картки в Wallet — PKAddPaymentPassViewController (iOS) / PushProvisioningActivity (Android). Це не стандартна платіжна інтеграція — вимагає спеціального agreement з Visa/Mastercard та сертифікації. Процес займає місяці, починати завчасно.
Чат з підтримкою
In-app chat з співробітником банку. Stream Chat SDK або Sendbird — enterprise-ready рішення з історією, пошуком, push при новому повідомленні. Повідомлення шифруються в транзиті та зберігаються на серверах провайдера — уточнюємо відповідність вимогам регулятора.
Архітектура: нативне vs кроссплатформенне
| Критерій |
Нативний (Swift + Kotlin) |
Flutter |
React Native |
| Доступ до Secure Enclave / Hardware |
Повний |
Через абстракцію (потрібен аудит) |
Через bridge (дод. верифікація) |
| Продуктивність |
Максимальна |
Висока (90%+) |
Середня (60-80%) |
| Security audit |
Простіше — нативні API |
Вимагає додаткових перевірок |
Вимагає додаткових перевірок |
| Термін розробки |
Довше (дві кодові бази) |
Швидше (одна кодова база) |
Швидше (одна кодова база) |
Нативний Swift (iOS) + Kotlin (Android) — переважно для фінтеху. Причина: максимальний контроль над security, нативний доступ до Secure Enclave, BiometricPrompt, Apple Pay provisioning. Додатково — простіше проходити security audit.
Clean Architecture: Domain (Use Cases) / Data (Repository, API) / Presentation (MVVM, ViewModels). Тестуємість кожного шару обов'язкова — unit tests на Use Cases, integration tests на Repository.
Flutter — прийнятний для фінтеху за наявності хороших Flutter-розробників. Обмеження: flutter_secure_storage використовує Keychain/Keystore, але через рівень абстракції, який потрібно аудитувати. local_auth для біометрії працює коректно.
Етапи розробки та терміни
| Етап |
Тривалість |
| Security architecture review |
1–2 тижні |
| Дизайн та UI |
2–4 тижні |
| Аутентифікація, біометрія |
2 тижні |
| Рахунки, перекази, історія |
4–6 тижнів |
| Картки та Apple/Google Pay |
3–4 тижні |
| Push-сповіщення, чат |
2 тижні |
| Security audit та регуляторне узгодження |
2–4 тижні |
| Публікація в Store |
1 тиждень |
Приклад структури проєкту
```
Project/
├── app/
│ ├── src/
│ │ ├── main/
│ │ │ ├── kotlin/com/bank/
│ │ │ │ ├── domain/
│ │ │ │ ├── data/
│ │ │ │ └── presentation/
│ │ │ └── res/
│ └── build.gradle
├── domain/
├── data/
└── presentation/
```
Що входить у роботу
- Security architecture review та threat modelling
- Дизайн-система під ваш бренд
- Аутентифікація: біометрія, PIN, JWT, root detection
- Рахунки та баланси, перекази з ідемпотентністю
- Інтеграція платіжних систем: Apple Pay, Google Pay
- Push-сповіщення з rich content
- Chat SDK для підтримки
- Документація: архітектурна, API, security policies
- Доступи до репозиторіїв, CI/CD, Store акаунтів
- Навчання команди замовника
- Підтримка після релізу: гарантія 3 місяці
Процес
Security architecture review → дизайн → аутентифікація та biometrics → рахунки та баланс → перекази з idempotency → історія транзакцій → картки та Apple/Google Pay → push-сповіщення → security audit → регуляторне узгодження → публікація.
Орієнтири за термінами
MVP фінтех-застосунку (аутентифікація, рахунки, перекази, історія): 8–12 тижнів. Повноцінний мобільний банк з картками, Apple/Google Pay provisioning, чатом підтримки, інвестиційним модулем: 4–8 місяців. Вартість визначається після аналізу вимог та security scope.
Зв'яжіться з нами для оцінки вашого проєкту — отримайте точний розрахунок за 2 дні. Замовте консультацію, і ми підготуємо комерційну пропозицію з детальним планом робіт та термінами.
Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat
У кожному нашому проєкті з монетизації додатку ми балансуємо між політиками App Store та Google Play, вимогами PCI DSS та логікою верифікації покупок на бекенді. Неправильно зроблена система платежів — це не просто баг, це фінансові втрати та можливий бан додатку. За 7 років ми розібрали понад 50 кейсів інтеграції платіжних SDK — від простої Stripe-форми до розподіленого біллінгу з власними серверними вебхуками.
Як вибрати між In-App Purchase та зовнішнім платіжним шлюзом?
Якщо додаток продає цифровий контент або підписки — Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення правил 3.1.1 App Store або Google Play Developer Policy призводить до видалення додатку. Фізичні товари та послуги, що надаються офлайн, — інша історія.
In-App Purchase: дві платформи, два різних API
StoreKit 2 (iOS 15+)
StoreKit 2 — повна переробка оригінального StoreKit з async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements — читабельно та передбачувано порівняно з чергою транзакцій через SKPaymentTransactionObserver.
Найважливіша зміна: транзакції в StoreKit 2 підписані JWS (JSON Web Signature) і верифікуються локально без серверного roundtrip. Transaction.verificationResult повертає .verified(Transaction) або .unverified(Transaction, VerificationError). Це не означає, що сервер не потрібен — він потрібен для зберігання статусу підписки, але локальна верифікація прибирає затримку при старті.
StoreKit.AppTransaction — верифікація самого факту завантаження додатку з App Store. Потрібна для додатків з платним завантаженням або безстроковими покупками, не підписками.
Складне місце в StoreKit 2 — обробка renewalState для підписок: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. Стан inGracePeriod означає, що Apple намагається відновити оплату (до 16 днів) — у цей час потрібно продовжувати надавати доступ. Не обробиш — втратиш лояльних користувачів, у яких тимчасово не пройшла картка. За досвідом, близько 5% підписок потрапляють у billing retry, і автоматичне відновлення доступу повертає до 80% з них.
Google Play Billing Library (v6+)
Google Billing — складніший за StoreKit за кількістю сценаріїв. BillingClient з PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync — обов'язково викликати при кожному старті додатку, не покладатися на PurchasesUpdatedListener як єдине джерело правди.
Підтвердження покупки: acknowledgePurchase() для non-consumables та підписок, consumePurchase() для consumables. Якщо не викликати acknowledge протягом 3 днів — Google автоматично зробить повернення. Це гарантована втрата грошей, якщо забути про acknowledge на бекенді після верифікації.
ProductDetails з SubscriptionOfferDetails — в Billing v5+ структура оферт ускладнилася: один продукт може мати кілька basePlanId та offerId (пробний період, знижка для нових користувачів, retention-офер). BillingFlowParams.SubscriptionUpdateParams для апгрейду/даунгрейду підписки з prorationMode.
Чому серверна верифікація обов'язкова?
Ніколи не довіряйте лише клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.
Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус у БД, віддає відповідь клієнту. RevenueCat робить це за вас — але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.
Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток — додаток не отримає про цю подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус. Ми використовуємо перевірку підпису вхідних запитів через Apple's signedPayload та Google's DeveloperNotification.
Як RevenueCat спрощує інтеграцію?
Підтримувати StoreKit 2 та Google Billing одночасно, з урахуванням промо-кодів, оферт, відновлення покупок та серверної верифікації — це кілька місяців розробки. RevenueCat закриває більшу частину цього шару.
RevenueCat — не просто SDK для платежів. Це:
- Єдиний API для iOS та Android (і Stripe для вебу)
- Серверна верифікація та зберігання статусів підписок
- Webhooks на події (покупка, відновлення, скасування, billing issue)
- Аналітика по когортам, MRR, churn
- A/B тестування оферт через Experiments
Purchases.configure(withAPIKey:) при старті, Purchases.shared.getCustomerInfo() для отримання поточних entitlements — мінімальний інтегрований шар. Purchases.shared.purchase(package:) замість прямого виклику StoreKit/Billing.
У документації RevenueCat сказано: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»
Обмеження RevenueCat: платний (безкоштовно до певного рівня MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами. Однак для типового SaaS-додатку економія на власній розробці є значною — інтеграція окупається швидко.
Stripe в мобільних додатках
Stripe — для оплати фізичних товарів, послуг, B2B-платежів де IAP не вимагається політикою платформи.
Stripe iOS SDK та Android SDK — PaymentSheet для готового UI оплати, PaymentSheetFlowController для кастомного UI зі збереженими картками. Payment Intent створюється на сервері, client secret передається в додаток — карткові дані ніколи не проходять через ваш сервер, лише через Stripe.
Apple Pay та Google Pay через Stripe: PKPaymentRequest (iOS) та GooglePayLauncher (Android) вже інтегровані в Stripe SDK. Конверсія у Apple Pay дає в 1.3–2 рази вищий результат, ніж форми з ручним введенням картки — це цифри, які ми підтвердили на десятці проєктів.
Збережені картки через SetupIntent + Customer API — користувач платить в один тап при повторному візиті. Compliance: PCI DSS SAQ A — найлегший рівень compliance, оскільки Stripe Tokenization прибирає потребу зберігати карткові дані на своїй стороні. Згідно з PCI DSS, передача токенів звільняє від необхідності сертифікації рівня 1.
3DS2 (Strong Customer Authentication) — обов'язковий для платежів у ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно коректно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.
Що входить в роботу (deliverables)
| Документація/Артефакт |
Зміст |
| Архітектурна схема біллінгу |
Діаграма потоків: клієнт → SDK → сервер → store/webhook |
| Інтеграція SDK |
Підключення та конфігурація StoreKit 2, Google Billing, RevenueCat або Stripe |
| Серверна верифікація |
Реалізація ендпоінтів та обробка webhook (Apple/Google/RevenueCat) |
| Тестовий стенд |
Sandbox Apple, License Testers Google, Stripe Test Mode |
| Документація по запуску |
Опис ключів, provisioning profiles, TestFlight |
| Навчання команди |
Сесія з підтримки платіжного модуля |
Процес та терміни
Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.
Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.
Як налаштувати тестове середовище для платежів?
| Сценарій |
Інструмент |
Час реалізації |
| Підписки iOS + Android |
StoreKit 2 + Google Billing + RevenueCat |
2–3 тижні |
| Підписки з кастомним бекендом |
StoreKit 2 + Google Billing + власний webhook |
4–6 тижнів |
| Оплата карткою (фізичні товари) |
Stripe PaymentSheet |
1–2 тижні |
| Apple Pay / Google Pay |
Stripe або нативні SDK |
+ 3–5 днів |
| Повний платіжний стек |
Все вищеперераховане |
6–10 тижнів |
Розгорнути типові помилки при інтеграції
- Забули викликати
acknowledgePurchase() на Android — гроші повертаються через 3 дні.
- Не обробили
inGracePeriod — лояльні користувачі блокуються без доступу.
- Поклалися лише на Pushtokens при відновленні підписок — пропускаєте state оновлення.
- Використовували production-ключі в TestFlight — спрацьовують реальні списання.
Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.
Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.
