Уявіть: користувач відкриває додаток гаманця, щоб поповнити рахунок, а бачить помилку «Service Unavailable». Або ще гірше — після переказу баланс не оновлюється, а гроші вже списалися. Такі сценарії — головний біль будь-якого fintech-продукту. Ми розробляємо мобільні гаманці так, щоб транзакції проходили надійно і користувачі не втрачали кошти. Наша команда має сертифікованих розробників із 5+ років досвіду у fintech, що дозволяє уникнути типових помилок.
У цій статті розберемо ключові технічні аспекти: від вибору архітектури (BaaS або власний бекенд) до інтеграції KYC, обробки транзакцій та безпеки. Ви дізнаєтеся, як ми підходимо до проєктування і які підводні камені трапляються на шляху.
Ми працюємо з різними платформами: нативний Swift/Kotlin для швидкості обробки (у 2 рази швидше за крос-платформу в KYC-завданнях), Flutter і React Native для крос-платформної розробки. Вибір залежить від вимог до безпеки та бюджету. Зв'яжіться з нами для консультації — ми безкоштовно оцінимо ваш проєкт і запропонуємо оптимальне рішення.
Як вибрати архітектуру для електронного гаманця?
Два підходи: BaaS (Banking-as-a-Service) і власний бекенд. BaaS-провайдери (Treezor, ClearBank, Railsbank) надають готові API для створення гаманців, IBAN, переказів, випуску карток. Мобільний додаток виступає фронтендом. Це швидкий запуск (2-3 місяці) і мінімальна regulatory burden, але менше контролю над даними. Власний бекенд дає повний контроль, але вимагає ліцензії та складніший у реалізації — потрібна подвійна бухгалтерія (double-entry accounting) і gapless transaction log. Транзакції проходять через ваш сервер, тому навантаження на нього зростає. Наприклад, при 1000 транзакцій на день сервер може обробляти 99.9% без збоїв.
| Критерій |
BaaS |
Власний бекенд |
| Швидкість запуску |
2-3 місяці |
6-12 місяців |
| Контроль даних |
Обмежений |
Повний |
| Ліцензування |
Не потрібна |
Потрібна ліцензія |
| Вартість |
$5,000–$20,000/рік |
$50,000–$200,000+ |
Для мобільного додатка різниця непомітна — в обох випадках використовуємо REST API. BaaS-провайдери часто пропонують SDK для емісії карток і KYC, що спрощує інтеграцію.
Що включає KYC-інтеграція?
Без верифікації гаманець працює з лімітами (до $500/день). Після проходження KYC відкривається повний функціонал (до $10,000/день). Ми інтегруємо Sumsub SDK (SumSubMobileSDK для iOS/Android): нативний SDK, liveness check, document scan, anti-spoofing. Sumsub SDK для iOS — документація. Альтернативи — Onfido, Jumio. Всі три мають нативні Flutter SDK.
Процес у додатку: вибір документа → фото паспорта → liveness selfie → очікування перевірки (від 1 хвилини до кількох годин). Push при зміні статусу. Важливо: Sumsub SDK на iOS додає ~15–20 MB до розміру додатку через CoreML-моделі anti-spoofing. Враховуємо це під час планування.
KYC-етапи:
| Етап |
Опис |
Тривалість |
| Вибір документа |
Користувач вибирає тип посвідчення |
10 секунд |
| Фото документа |
Сканування з автозахопленням |
5 секунд |
| Liveness selfie |
Відеозапис обличчя |
15 секунд |
| Перевірка |
Обробка Sumsub |
1-60 хвилин |
Після перевірки статус оновлюється через push-сповіщення.
Поповнення, виведення та P2P-перекази
Поповнення рахунку: банківська картка (Stripe, Checkout.com — комісія 2.9%+$0.30), банківський переказ (SEPA, SWIFT), готівка через партнерську мережу. Карткове поповнення — стандартний SDK платіжного шлюзу. SEPA-переказ — користувач отримує IBAN гаманця і переказує через свій банк.
Виведення коштів: на картку (Stripe Payouts — $2.00 за виведення) або IBAN. Верифікація реквізитів — IBAN checksum validation (Luhn-подібний), BIC lookup. Ліміти за рівнями KYC: базовий $500/день, верифікований $10,000/день.
Всі операції — асинхронні. UI показує: «Запит прийнято, очікуйте» і push при зарахуванні. Не оновлюємо баланс синхронно — банки та блокчейн не миттєві (затримка до 30 секунд).
P2P перекази реалізуємо трьома способами:
- QR — генеруємо QR з userId і сумою. Формат EMV QR або кастомний deeplink
wallet://pay?to=...&amount=.... Сканування через AVFoundation (iOS) / ML Kit Barcode Scanning (Android). Після сканування — екран підтвердження.
- За номером телефону — введення номера, пошук, екран підтвердження. Показуємо тільки масковане ім'я (Іван В.) для приватності.
- За username — аналогічно.
Підтвердження переказу — біометрія або PIN. Використовуємо LocalAuthentication / BiometricPrompt. Гарантуємо, що кожна операція підтверджується двома факторами.
Безпека та push-сповіщення
Сесійні токени: short-lived access token (15 хвилин) + long-lived refresh token у Keychain/EncryptedSharedPreferences. Refresh token rotation при кожному оновленні — попередній інвалідується. Ліміти за сумами та частотою — на сервері. Anomaly detection: кілька переказів за хвилину → тимчасове блокування + push + email. Certificate pinning обов'язковий. Jailbreak/root detection — опціонально. Наші сертифіковані фахівці з безпеки перевіряють код на відповідність OWASP.
Кожен рух грошей — push протягом секунд. FCM priority: high / APNs apns-priority: 10. Тихі push для синхронізації балансу в фоні (content-available: 1). Користувач відкриває додаток — бачить актуальний баланс без підвантаження.
Що входить у роботу: повний список deliverables
Ми надаємо:
- Документацію API та SDK
- Доступ до середовищ (dev, staging, prod)
- Навчання вашої команди (2 дні онлайн)
- Підтримку після релізу протягом 1 місяця (гарантія безперебійної роботи 99.9%)
- Вихідний код мобільних додатків
Процес роботи та орієнтири за термінами
Наш процес включає кілька етапів:
- Юридична структура та вибір BaaS (якщо застосовно)
- Інтеграція KYC
- Реалізація гаманця та балансу
- Поповнення та виведення
- P2P перекази
- Історія та виписки
- Security audit
- Публікація
Орієнтовні терміни: MVP (реєстрація + KYC + поповнення карткою + P2P + історія) — 10–14 тижнів, вартість $20,000–$40,000. Повноцінний гаманець з емісією карток, SEPA, currency exchange — 4–7 місяців, від $80,000. Ціна розраховується індивідуально після аналізу вимог.
Приклад інтеграції KYC SDK
```swift
// Ініціалізація Sumsub SDK
SumsubSDK.setup(clientId: "client_id")
let config = SumsubSDKConfig(flowType: .kyc)
SumsubSDK.launch(with: config)
```Ми на ринку більше 5 років, виконали 30+ проєктів у фінансовій сфері. Звертайтеся — оцінимо ваш проєкт безкоштовно.
Платежі в мобільних додатках: 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 місяці.
Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.
