Розробка мобільної програми для банкінгу (FinTech)
Мобільний банк—програма, яка не прощає помилок. Неправильно відображений баланс, завершений переведення без підтвердження, втрата сесії в момент транзакції—кожен із цих сценаріїв коштує довіри користувача та потенційно грошей. Архітектурні рішення тут диктує безпека, а не зручність розробки.
Аутентифікація та біометрія
Почнемо з того, що відбувається при кожному запуску програми. Класика: 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 або SafetyNet Attestation API / Play Integrity API (актуальна). При виявленні root—програма не запускається або працює в обмеженому режимі.
Переводи та транзакції
Форма переводу—технічно проста, але UX-критична. Після введення суми й отримувача—екран підтвердження з повними деталями перед відправкою. Кнопка підтвердження—з штучною затримкою 1–2 секунди (запобігає випадковому double-tap). Повторна біометрична/PIN авторизація для крупних сум.
Idempotency переводів: кожен запит переводу містить унікальний idempotency_key (UUID, генерується на клієнті). При втраті мережі та повторі запиту сервер повернеме результат першого, не створить дубліват. Критично—без idempotency користувач з нестабільним інтернетом може відправити переведення двічі.
Історія транзакцій—пагінований список, cursor-based. Групування за датою. Пошук за описом, сумою, отримувачем. Детальна сторінка транзакції: всі деталі, статус, квитанція в PDF (генерація на сервері, завантаження на пристрій).
PCI DSS та захист даних
Мобільна банківська програма не зберігає 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 оновлюємо при ротації сертифіката через 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).
Рахунки та карти
Екран головного дашборду: список рахунків з балансами. Віджет карти (фізичне або візуальне представлення). Управління картою: блокування, ліміти, перегляд реквізитів (CVV—тільки після біометрії, не зберігається в пам'яті програми довше 30 секунд).
Apple Pay / Google Pay токенізація: для додавання карти в Wallet—PKAddPaymentPassViewController (iOS) / PushProvisioningActivity (Android). Це не стандартна платіжна інтеграція—потребує спеціального agreement з Visa/Mastercard та сертифікації. Процес займає місяці, починати заранше.
Чат з підтримкою
In-app chat з сотрудником банку. Stream Chat SDK або Sendbird—enterprise-ready рішення з історією, пошуком, push при новому повідомленню. Повідомлення шифруються в транзиті й зберігаються на серверах провайдера—уточнюємо відповідність вимогам регулятора.
Архітектура
Нативний 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 → дизайн → аутентифікація та biometrics → рахунки та баланс → переводи з idempotency → історія транзакцій → карти та Apple/Google Pay → push-сповіщення → security audit → регуляторне узгодження → публікація.
Орієнтири за часом
MVP FinTech-програми (аутентифікація, рахунки, переводи, історія): 8–12 тижнів. Повнофункціональний мобільний банк з картами, Apple/Google Pay provisioning, чатом підтримки, інвестиційним модулем: 4–8 місяців. Вартість—після аналізу вимог та security scope.