Ручне введення номера картки — часта причина помилок і відмов від оплати. Сканування через камеру скорочує час введення до 1–2 секунд і знижує відсоток покинутих кошиків на 15–20%. Ми у своїй практиці використовуємо перевірені рішення: Stripe CardScan (Bouncer) або нативні OCR-фреймворки. Розповімо, який варіант підійде під ваші завдання та як уникнути типових проблем. Впровадження такого функціоналу окупається за рахунок підвищення конверсії — економія може сягати десятків відсотків виручки.
Як обрати інструмент для сканування?
| Бібліотека |
Підтримка |
Точність |
Складність |
Ціна |
| Card.io (PayPal) |
Не оновлюється з 2018 |
Середня |
Низька |
Безкоштовно |
| Stripe CardScan / Bouncer |
Активна, Apache 2.0 |
>95% |
Середня |
Безкоштовно |
| Vision (iOS) + ML Kit (Android) |
Apple/Google |
~90% (потребує фільтрації) |
Висока |
Безкоштовно |
Card.io історично популярний, але давно не оновлюється — на сучасних версіях iOS спостерігаються збої AVCaptureSession. Не рекомендуємо для нових проєктів. Stripe CardScan (колишній Bouncer) — нейромережеве рішення на TFLite/CoreML, працює офлайн. На iOS підключається через SPM: https://github.com/stripe/stripe-ios, на Android — через Gradle: com.stripe:stripecardscan. Його код відкритий, що дозволяє адаптувати під специфічні вимоги. Нативні OCR-фреймворки (VNRecognizeTextRequest, ML Kit Text Recognition v2) не потребують сторонніх залежностей, але потрібно самостійно реалізувати детекцію зони картки та стабілізацію результату (підтвердження через 3–5 послідовних однакових результатів).
Як забезпечити точність розпізнавання?
Точність розпізнавання залежить від умов зйомки. При гарному освітленні Stripe CardScan дає 97% правильних номерів. В умовах слабкого освітлення або відблисків точність падає до 85–90%. Ми рекомендуємо реалізувати перевірку за алгоритмом Луна та підсвітку кадру при нестачі світла. Для стабілізації результату використовуйте підтвердження через 3 послідовних збіги.
| Умова |
Stripe CardScan |
Vision/ML Kit |
| Гарне освітлення |
97% |
92% |
| Слабке світло |
85% |
78% |
| Відблиски |
80% |
72% |
Чому варто використовувати нативні фреймворки, а не готовий SDK?
Готовий SDK (Stripe CardScan) дає високу точність з коробки та скорочує час розробки. Але якщо вам потрібна повна кастомізація інтерфейсу або робота в специфічних умовах (нестандартні картки, погане освітлення) — нативні Vision/ML Kit надають повний контроль. Ми комбінуємо підходи: для MVP використовуємо Stripe CardScan, для production з унікальними вимогами пишемо свій модуль на нативних API.
Які дані можна і не можна розпізнавати?
Номер картки — основна мета, точність >95%. Термін дії (MM/YY) розпізнається впевнено. Ім'я власника — OCR справляється гірше через варіативність шрифтів та тиснення. Рекомендуємо: номер + термін скануємо автоматично, ім'я — заповнювати вручну як необов'язкове поле. Ніколи не розпізнаємо та не зберігаємо CVV/CVC — він на звороті, і його зберігання порушує вимоги PCI DSS. Це не просто правило, а обов'язкова умова для проходження аудиту безпеки.
Реалізація на Flutter
Пакет card_scanner на pub.dev працює через Platform Channels до нативних SDK. Альтернатива — google_mlkit_text_recognition з власним парсером. Для production-додатку переважніший Stripe CardScan через FFI: точніше та надійніше в нестандартних умовах (погане освітлення, нестандартний дизайн карток). Flutter-розробникам слід враховувати, що деякі методи стабілізації потребують нативного коду — ми допомагаємо з обв'язкою.
Дозволи та приватність: що важливо для App Store?
iOS: NSCameraUsageDescription в Info.plist з формулюванням «для сканування картки при оплаті». Android: uses-permission android:name="android.permission.CAMERA" + runtime request через ActivityResultContracts.RequestPermission. Кадри з камери обробляються тільки в пам'яті — не зберігаються на диск, не відправляються на сервер. Це критично для проходження рев'ю App Store та Play Market. Докладніше про вимоги можна прочитати в документації Stripe CardScan.
Що входить у роботу?
- Аналіз вимог та вибір оптимального стеку (Bouncer, Vision/ML Kit, Flutter-пакет).
- Інтеграція SDK з кастомним UI (прев'ю камери, рамка картки, анімація).
- Реалізація логіки стабілізації та фільтрації хибних спрацьовувань.
- Тестування на різних пристроях та в умовах слабкого освітлення.
- Документація з інтеграції та підтримка при публікації в стори.
Орієнтовні терміни та як ми працюємо
Інтеграція Stripe CardScan з базовим UI: 1–2 дні. Кастомний UI + нативний Vision/ML Kit з власною логікою стабілізації: 2–3 дні. Повний цикл — від аналітики до деплою — займає від 3 до 5 днів залежно від складності. Вартість розраховується індивідуально.
Хочете прискорити прийом платежів та знизити відсоток відмов? Отримайте консультацію щодо вашого проєкту — проаналізуємо вимоги та запропонуємо оптимальне рішення. Наш досвід: 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 місяці.
Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.
