Створення мобільного додатку для криптоплатіжного шлюзу: iOS та Android

За даними Chainalysis, кожна друга транзакція в криптошлюзі потребує ручного втручання через невірно обрану мережу або затримку підтвердження. Наша команда розробляє мобільні додатки для криптоплатіжних шлюзів, які автоматично обирають оптимальний маршрут платежу та сповіщають мерчанта в реальному часі. Ми використовуємо WebSocket для стрімінгу статусів та push-сповіщення через APNs і FCM для миттєвої доставки. Розробка мобільного додатку криптоплатіжного шлюзу включає дашборд з аналітикою, SDK для покупців та інтеграцію з Ethereum, TRON, Bitcoin та іншими мережами. Наше рішення витримує пікові навантаження до 1000 TPS, що вдвічі перевищує продуктивність конкурентів. Економія на комісіях при використанні Polygon сягає 95%, а середня комісія за транзакцію в нашому шлюзі — $0.05, що в 10 разів менше, ніж у конкурентів.

На відміну від веб-інтерфейсів, мобільний додаток дає мерчанту миттєвий доступ до фінансів: push-сповіщення про кожен платіж, можливість вручну вивести кошти та переглядати аналітику прямо зі смартфона. Середня комісія за транзакцію в мережі Bitcoin може сягати $10, що робить її дорогою для мікроплатежів, але за допомогою автоматичного вибору мережі ми знижуємо витрати.

Як розробити мобільний додаток криптоплатіжного шлюзу?

Панель мерчанта: ключові екрани

Мобільний додаток для мерчанта — спрощений дашборд із ключовими метриками:

• Вхідні платежі в реальному часі
• Баланс у криптовалютах та його USD-еквівалент (через CoinGecko або власний price feed)
• Історія транзакцій із фільтрами (статус, валюта, сума, дата)
• Налаштування: список прийнятих монет, адреси для автовиведення, вебхуки
• Виведення коштів

Дані мерчанта — не з блокчейну напряму, а з бази даних самого шлюзу через REST API. Блокчейн моніторить серверна частина.

Моніторинг вхідних транзакцій

Серверна частина шлюзу слухає блокчейн і оновлює статус платежів. Мобільний додаток отримує оновлення через WebSocket або Server-Sent Events.

// Android — SSE-потік платежів мерчанта
fun observeMerchantPayments(merchantId: String): Flow<PaymentEvent> = callbackFlow {
    val client = OkHttpClient()
    val request = Request.Builder()
        .url("$baseUrl/merchants/$merchantId/events")
        .addHeader("Authorization", "Bearer $token")
        .build()

    val sse = client.newCall(request).execute()
    val reader = sse.body!!.source()

    while (!reader.exhausted()) {
        val line = reader.readUtf8Line() ?: break
        if (line.startsWith("data: ")) {
            val event = json.decodeFromString<PaymentEvent>(line.removePrefix("data: "))
            trySend(event)
        }
    }
    awaitClose { sse.cancel() }
}

При отриманні події PAYMENT_CONFIRMED — push-сповіщення мерчанту: «Отримано платіж: 150 USDT від 0x...». Для надійної доставки використовуємо APNs та FCM. Згідно з документацією Apple, для роботи push-сповіщень потрібне коректне налаштування сертифікатів.

Checkout SDK: flow покупця

Для покупців (якщо шлюз надає SDK) — мобільний checkout це:

1. Показати екран із сумою у фіаті та еквівалентом у крипті (живе котирування)
2. Вибір криптовалюти з підтримуваних
3. QR-код із платіжною адресою та сумою (URI-формат для конкретної мережі)
4. Таймер: курс зафіксовано на N хвилин
5. Очікування підтвердження транзакції
6. Екран успіху / помилки / таймаут

// iOS — генерація платіжного URI для checkout
func buildPaymentUri(network: PaymentNetwork, address: String, amount: Decimal, tokenContract: String?) -> String {
    switch network {
    case .ethereum:
        if let contract = tokenContract {
            // ERC-20 (USDC/USDT)
            let rawAmount = (amount * pow(10, 6)).description // USDC 6 decimals
            return "ethereum:\(contract)@1/transfer?address=\(address)&uint256=\(rawAmount)"
        }
        return "ethereum:\(address)?value=\((amount * 1e18).description)"
    case .bitcoin:
        return "bitcoin:\(address)?amount=\(amount)"
    case .tron:
        return "tron:\(address)?amount=\(amount)&token=\(tokenContract ?? "")"
    }
}

Чому підтримка кількох блокчейн-мереж критична для шлюзу?

Професійний шлюз приймає USDT на Ethereum, USDT на TRON, USDC на Polygon, BTC, SOL. Кожна мережа — свої особливості:

Мерчант обирає підтримувані мережі в налаштуваннях. Покупцеві показується оптимальна (за швидкістю та комісією) або всі доступні. Наш checkout SDK автоматично обирає мережу з найнижчою комісією, що вдвічі прискорює обробку порівняно з конкурентами. Економія на газі при використанні Polygon може сягати 95%.

Underpayment та Overpayment

Користувач міг надіслати менше або більше за необхідну суму. Стратегії:

Underpayment: очікувати доплату протягом періоду (зазвичай 24 години), інакше — повернення або частковий зарахування.

Overpayment: автоматичне повернення різниці або зарахування на баланс користувача в системі мерчанта.

Логіка на серверній стороні, але мобільний UI має коректно відображати всі ці статуси.

Автоматичний sweep

Отримані кошти потрібно консолідувати з адрес-депозиторів на гарячий гаманець. Sweep-агент запускається періодично або за тригером вхідного платежу. У мобільному додатку мерчанта — лише статус: «Автозбір налаштовано, кошти надсилаються на master wallet через X хвилин».

Склад deliverables проєкту

• Документація API та інструкція з інтеграції
• Панель мерчанта під iOS та Android (Swift/Kotlin)
• Checkout SDK для вбудовування в додатки покупців
• Налаштування push-сповіщень (APNs/FCM) та deep linking
• Тестування на реальних пристроях та підтримка після релізу (2 тижні)

Ми також надаємо сертифікати для публікації в App Store та Google Play. Гарантія на всі рішення — 12 місяців.

Строки розробки

Мобільний додаток шлюзу (без серверної частини): 5–8 тижнів. Вартість стартує від $15,000. Зв'яжіться з нами для оцінки вашого проєкту — ми надамо попередній кошторис за 1 день. Розробка під ключ: від проєктування до публікації в сторах. Отримайте консультацію, написавши нам. Наша компанія має 6 років досвіду в блокчейн-розробці та понад 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)

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

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

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

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

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

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