Інтеграція платіжної системи iPay в мобільному додатку
iPay.ua — український платіжний шлюз, який підтримує карти Visa/Mastercard, Apple Pay та Google Pay. Для мобільного додатку вибір між нативним SDK та WebView-формою вирішується не «що зручніше», а «що пройде App Store Review» та «де менше конверсійних втрат».
Два шляхи та їх реальні наслідки
WebView-шлях — швидше на старті. iPay відає URL платіжної форми, додаток відкриває SFSafariViewController (iOS) або Custom Chrome Tab (Android). Мінус: користувач бачить перехід у браузер, Apple Pay всередині WebView в SFSafariViewController працює, але тільки якщо домен правильно налаштований в Apple Pay Merchant ID. Якщо розробник забув прописати paymentRequest.merchantCapabilities та supportedNetworks на стороні сервера, Apple Pay не з'явиться — карткова форма залишається єдиним варіантом.
Нативний SDK — iPay надає iOS та Android SDK. На iOS це IPay.framework (SPM або CocoaPods), на Android — AAR-бібліотека через Maven. SDK запускає нативний UIViewController / Activity з платіжною формою, результат повертається через делегат/інтерфейс. Apple Pay тут працює правильно через PKPaymentAuthorizationViewController — SDK сам управляє sheet'ом.
Типова проблема при інтеграції iOS SDK: розробник додає IPay.framework, але забуває додати PassKit.framework в Link Binary With Libraries, і на пристрої (не симуляторі) вилітає dyld: Library not loaded при відкритті екрану оплати. Симулятор це не відтворює — крах тільки на реальному залізі.
Як реалізуємо
Ініціалізація SDK в AppDelegate/App передає merchant ID та середовище (production/sandbox). Платіж запускається з параметрами замовлення — сума, валюта (UAH), опис, order ID. SDK повертає PaymentResult з enum-статусом: success, failure, cancelled.
Критично: orderId повинен бути унікальним на кожну спробу оплати. Якщо користувач нажав «Оплатити», отримав помилку мережі, й повторив з тим же orderId — iPay відклонить як дубліката. Генеруємо новий UUID на кожен старт платіжного потоку.
На стороні сервера — webhook-обработчик для payment.success / payment.failed. Мобільний клієнт не повинен міняти статус замовлення на основі тільки локального callback — тільки після підтвердження від сервера. Клієнтський callback може обмануть (Jailbreak/Root + проксі).
iOS: SPM → iPay SDK → PKPaymentAuthorizationViewController (Apple Pay)
Android: Maven → iPay SDK → Google Pay API → Activity Result
Server: webhook → HMAC-SHA256 signature check → order status update
Для Flutter: нативний SDK оборачується в Platform Channel. Пишемо MethodChannel('ipay'), на нативній стороні викликаємо SDK, результат повертаємо через result.success(paymentResult).
Процес
Отримання тестових credentials від iPay → sandbox-тестування з тестовими картами → налаштування webhook-обработчика → тест Apple/Google Pay на реальних пристроях → production-сертифікат → сабмит.
Ориєнтири по терміам
Інтеграція WebView-форми: 1–2 дні. Нативний SDK з Apple Pay + Google Pay + webhook: 2–3 дні. Якщо потрібна Flutter-обёртка поверх нативного SDK — плюс 1 день.