Платежі в мобільних додатках: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat
Монетизація через додаток—одна з найбільш технічно складних та юридично навантажених тем у мобільній розробці. Розробник балансує між політиками App Store та Google Play, вимогами PCI DSS для платіжних карток та логікою верифікації покупок на бекенді. Неправильно реалізована система платежів—це не просто баг, це фінансові втрати та можливий бан додатку.
In-App Purchase: дві платформи, два різних API
Якщо додаток продає цифровий контент або підписки—Apple та Google вимагають використовувати їхні платіжні системи. Обійти це неможливо: порушення Guideline 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 днів)—у цей час потрібно продовжувати надавати доступ. Пропустити—втратити лояльних користувачів з тимчасово не пройденою карткою.
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.
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: платний (безплатно до $2.5k MRR, далі відсоток від доходу), не підходить для дуже складних flow з кількома storefront-ами або кастомними bundle-ами.
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 на 30–50% вища форм з ручним вводом карти—реальна різниця, видна в цифрах.
Збережені карти через SetupIntent + Customer API—користувачі платять в один тап при повторному візиті. Compliance: PCI DSS SAQ A—найлегший рівень compliance, тому що Stripe Tokenization усуває потребу зберігати дані карток на своїй стороні.
3DS2 (Strong Customer Authentication)—обов'язковий для платежів в ЄС за PSD2. Stripe обробляє автоматично через PaymentIntent.confirmPayment, але потрібно правильно обробити .requiresAction статус та повернути користувача на потрібний екран після аутентифікації.
Серверна верифікація: обов'язковий крок
Ніколи не довіряйте тільки клієнтському коду при розблокуванні платного контенту. Клієнтська верифікація обходиться модифікацією додатку.
Для IAP мінімальна схема: додаток отримує receiptData (iOS) або purchaseToken (Android), відправляє на бекенд, бекенд верифікує через Apple App Store Server API / Google Play Developer API, зберігає статус в БД, відправляє відповідь клієнту. RevenueCat робить це за вас—але якщо у вас кастомний бекенд, потрібно реалізувати самостійно.
Webhook-и важливіші, ніж здається. Користувач може скасувати підписку через налаштування телефону, не через додаток—додаток не отримає про це подію в реальному часі. Тільки webhook від Apple/Google (або RevenueCat) дозволяє своєчасно оновити статус.
| Сценарій | Інструмент | Час реалізації |
|---|---|---|
| Підписки 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 тижнів |
Процес та графіки
Починаємо з уточнення бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-аккаунтів (Apple) та License Testers (Google)—окрема настройка оточення.
Sandbox Apple ведеться не як production: підписки поновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: істечення триалу, скасування, billing retry, refund.
Графік: від 2 до 10 тижнів залежно від набору інструментів та складності бізнес-логіки.