Інтеграція Fondy в мобільний додаток: нативні SDK для iOS та Android

Ми маємо 5+ років досвіду інтеграції платіжних шлюзів та понад 30 успішних проєктів з Fondy. Ми виконуємо інтеграцію платіжного шлюзу в мобільний додаток під iOS та Android. Помилка при інтеграції — це не просто некоректна оплата, а ризик блокування в App Store через порушення Section 4.2 або Section 5.1. За 5+ років ми провели 30+ успішних інтеграцій і знаємо, як обійти типові пастки: неправильний підпис, збій 3DS, несумісність з Apple Pay. Використовуємо нативні SDK cloudipsp-ios / cloudipsp-android, що гарантує проходження рев'ю та максимальну конверсію (до 95%).

Кейс: виправлення підпису для великого e-commerce проекту

Наш клієнт — маркетплейс з мільйонною аудиторією — зіткнувся з помилкою Invalid signature при інтеграції Fondy. Ми з'ясували, що проблема в невірному сортуванні параметрів: сервер клієнта включав зайвий параметр merchant_data, який не повинен брати участь у підписі. Після виправлення логіки на стороні сервера платежі пішли без збоїв, а конверсія оплат зросла на 15%. Цей кейс показує, наскільки важлива автоматизація підписів.

Що таке двоетапна схема оплати і чому вона безпечніша?

Fondy використовує двоетапну схему: клієнт створює токен карти на мобільному пристрої, передає його на сервер, а сервер проводить платіж. Це безпечно і знижує навантаження PCI DSS. На відміну від WebView-інтеграції, нативний SDK не передає чутливі дані через ваш сервер, що мінімізує ризики витоку. Додатково ви отримуєте вбудовану підтримку 3DS 2.0, Apple Pay та Google Pay — все це без додаткових витрат на розробку.

Як уникнути типових помилок при інтеграції Fondy?

Підключення SDK (для обох платформ):

// Android, build.gradle
implementation("com.cloudipsp:cloudipsp-android:1.x.x")
// iOS, Podfile
pod 'Cloudipsp'

Отримання token для SDK (серверний endpoint)

POST https://pay.fondy.eu/api/checkout/token
{
    "request": {
        "server_callback_url": "http://localhost:3000/payment/callback",
        "order_id": "ORDER-1234",
        "currency": "UAH",
        "merchant_id": "1396424",
        "order_desc": "Замовлення №1234",
        "amount": "15000",
        "signature": "sha1_signature"
    }
}

Відповідь містить token — передається в мобільний SDK.

Android: CardInputView та оплата

// Токен отриманий від сервера
val token = "server_token"
val cardInputView = CardInputView(context)
val cardNumber = CardNumber("4111 1111 1111 1111")
val mm = ExpireMonth("12")
val yy = ExpireYear("2025")
val cvv = Cvv("123")

Cloudipsp.checkout(
    context = context,
    token = token,
    card = Card(cardNumber, mm, yy, cvv),
    email = "[email protected]",
    listener = object : Cloudipsp.PayCallback {
        override fun onPaidProcessed(order: Order) {
            if (order.status == Order.Status.Approved) {
                handleSuccess(order.transactionId)
            }
        }
        override fun onPaidFailure(e: Cloudipsp.Exception) {
            handleError(e.message)
        }
        override fun on3dsRedirect(request: Cloudipsp.Request3ds, webView: WebView) {
            webView.loadUrl(request.url)
        }
    }
)

iOS: CloudipspView

import Cloudipsp

let api = Cloudipsp(merchantId: 1396424, callbackUrl: "http://localhost:3000/payment/result")
let paymentController = PaymentController(token: serverToken)
paymentController.present(in: self) { [weak self] result in
    switch result {
    case .success(let order):
        self?.handleSuccess(order.orderStatus)
    case .failure(let error):
        self?.handleError(error.localizedDescription)
    }
}

Чому нативна інтеграція краща за WebView?

Нативний SDK Cloudipsp краще ніж WebView: він у 2–3 рази прискорює оплату і підвищує конверсію за рахунок вбудованого 3DS та push-сповіщень. WebView-обгортки часто блокуються App Store (див. Section 4.2) і не підтримують Apple Pay / Google Pay. Ми гарантуємо коректну роботу з APNs та FCM для сповіщень про статус платежу. Економія бюджету на доопрацювання після рев'ю — до 40% порівняно з WebView-рішенням.

Як підключити Fondy за 4 кроки

1. Отримайте merchant ID та пароль від Fondy через особистий кабінет.
2. Встановіть SDK: через Gradle для Android або CocoaPods для iOS.
3. Створіть серверний endpoint /api/token для генерації токена.
4. Реалізуйте UI з CardInputView (Android) або PaymentController (iOS) та обробку callback.

Підпис запитів та верифікація callback

Підпис формується через SHA-1 всіх параметрів запиту, відсортованих в алфавітному порядку, з додаванням password. Неправильне сортування — часта причина помилки Invalid signature. Ми автоматизуємо цей процес. Згідно з документацією Fondy, callback-запити від Fondy на server_callback_url верифікуються аналогічно: всі поля відповіді сортуються, підписуються. Це гарантує справжність транзакції.

Порівняння етапів на iOS та Android

Типові помилки та їх вирішення

Що входить в роботу

• Підключення Cloudipsp SDK (iOS / Android)
• Серверний endpoint для отримання token
• Реалізація UI з CardInputView або PaymentController
• Налаштування 3DS через WebView
• Верифікація callback-запитів
• Тестування в пісочниці та продуктивному середовищі
• Документація з інтеграції та передача доступів
• Навчання команди замовника роботі з платіжним модулем
• Пост-релізна підтримка на 2 тижні

Терміни та вартість

Інтеграція однієї платформи займає 2–3 дні. Для обох платформ — до 4 днів при паралельній розробці. Вартість інтеграції однієї платформи — від 400$ (від 700$ для обох). Вартість розраховується індивідуально і залежить від архітектури вашого додатку, але ми гарантуємо прозорий кошторис до початку робіт. Є досвід інтеграції з Firebase, Supabase та кастомними бекендами.

Замовте інтеграцію Fondy у ваш додаток — ми гарантуємо проходження App Store Review та високу конверсію платежів. Отримайте консультацію: ми оцінимо ваш проект безкоштовно. Зв'яжіться з нами — ми підкажемо, як краще інтегрувати платежі у ваш додаток.

Платежі в мобільних додатках: 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)

Процес та терміни

Починаємо з з'ясування бізнес-моделі: підписки, разові покупки, consumables, freemium. Від цього залежить архітектура. Тестування IAP вимагає Sandbox-акаунтів (Apple) та License Testers (Google) — це окреме налаштування середовища.

Sandbox Apple поводиться не так, як production: підписки відновлюються кожні 5 хвилин замість місяця, inGracePeriod працює по-іншому. Обов'язково тестувати сценарії: закінчення тріалу, скасування, billing retry, refund.

Як налаштувати тестове середовище для платежів?

Вартість розраховується індивідуально виходячи з набору інструментів та складності серверної логіки. У середньому ми вкладаємося в бюджет, який обговорюється окремо, але економія від запобігання помилок та churn окупає ці вкладення за 2–3 місяці.

Отримайте консультацію по вашому проєкту — зв'яжіться з нами. Ми допоможемо обрати оптимальну архітектуру платежів, яка пройде рев'ю сторів та не зламається при пікових навантаженнях.