Интеграция платежной системы 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 (Swift Package Manager или 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 на каждый старт платёжного flow.
На стороне сервера — 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 день.