Мобильный банк — приложение, которое не прощает ошибок. Неправильно отображённый баланс, завершённый перевод без подтверждения, потеря сессии в момент транзакции — каждый из этих сценариев стоит доверия пользователя и потенциально денег. Архитектурные решения здесь диктует безопасность, а не удобство разработки. Мы разрабатываем мобильные банковские приложения с 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 месяцев. Инвестиции в MVP стартуют от 2 млн рублей, точная стоимость — после анализа требований и 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: две платформы, два разных API
Если приложение продаёт цифровой контент или подписки — Apple и Google требуют использовать их платёжные системы. Обойти это нельзя: нарушение правил 3.1.1 App Store или Google Play Developer Policy приводит к удалению приложения. Физические товары и сервисы, оказываемые офлайн, — другая история.
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: платный (бесплатно до $2.5k MRR, дальше процент от дохода), не подходит для очень сложных flow с несколькими storefront-ами или кастомными bundle-ами. Однако для типового SaaS-приложения экономия на собственной разработке составляет $15–30 тыс. — интеграция окупается за 2 месяца.
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 — срабатывают реальные списания.
Стоимость рассчитывается индивидуально исходя из набора инструментов и сложности серверной логики. В среднем мы укладываемся в бюджет $5k–15k на типовую интеграцию, но экономия от предотвращения ошибок и churn окупает эти вложения за 2–3 месяца.
Получите консультацию по вашему проекту — свяжитесь с нами. Мы поможем выбрать оптимальную архитектуру платежей, которая пройдёт ревью сторов и не сломается при пиковых нагрузках.
