Мобільний банк — застосунок, який не прощає помилок. Неправильно відображений баланс, завершений переклад без підтвердження, втрата сесії в момент транзакції — кожен із цих сценаріїв коштує довіри користувача та потенційно грошей. Архітектурні рішення тут диктує безпека, а не зручність розробки. Ми розробляємо мобільні банківські застосунки з 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 дні. Замовте консультацію, і ми підготуємо комерційну пропозицію з детальним планом робіт та термінами.