Интеграция платежной системы iPay в мобильное приложение
При интеграции iPay.ua в мобильное приложение наша команда всегда рассматривает два технических сценария: WebView-форма или нативный SDK. Выбор между ними напрямую влияет на пользовательский опыт и прохождение App Store Review. Мы накопили опыт более чем на 20 проектах с платёжными интеграциями и готовы поделиться деталями.
Как выбрать между WebView и нативным SDK?
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 при открытии экрана оплаты. Симулятор это не воспроизводит — крэш только на реальном железе.
| Аспект | WebView-форма | Нативный SDK |
|---|---|---|
| Скорость интеграции | 1–2 дня | 2–3 дня + 1 день если Flutter |
| Apple Pay | Работает при правильной настройке Merchant ID | Работает через PKPaymentAuthorizationViewController |
| Пользовательский опыт | Переход в браузер | Остаётся в приложении |
| Конверсия | Ниже из-за брошенных сессий | Выше благодаря нативному UI |
Почему важен уникальный orderId?
Инициализация 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-окружения
- Интеграция WebView-формы или нативного SDK (iOS, Android, Flutter)
- Настройка Apple Pay (Merchant ID,
PassKit.framework, provisioning profiles) - Реализация webhook-обработчика с HMAC-SHA256 верификацией
- Тестирование на реальных устройствах с тестовыми картами
- Документация по интеграции и руководство для разработчика
- Сопровождение при сабмите в App Store Connect и Google Play Console
Процесс работы
- Анализ требований и выбор стратегии (WebView vs SDK).
- Получение тестовых credentials от iPay.
- Настройка sandbox-окружения и тестирование с тестовыми картами.
- Интеграция платёжного модуля и настройка webhook-обработчика.
- Тест Apple Pay/Google Pay на реальных устройствах.
- Production-сертификация (обновление Provisioning Profile, code signing).
- Сабмит приложения в магазины приложений.
Ориентиры по срокам
| Вариант интеграции | Время |
|---|---|
| WebView-форма | 1–2 дня |
| Нативный SDK (iOS + Android) | 2–3 дня |
| Flutter-обёртка | дополнительно 1 день |
Интеграция WebView-формы: 1–2 дня. Нативный SDK с Apple Pay + Google Pay + webhook: 2–3 дня. Если нужна Flutter-обёртка поверх нативного SDK — плюс 1 день. Оценим ваш проект бесплатно — пишите.
Распространённые ошибки при интеграции
- Забытый `PassKit.framework` вызывает крэш на устройстве. - Повторный `orderId` блокирует оплату. - Webhook без проверки HMAC уязвим к подделке. - Неправильная настройка Apple Pay Merchant ID на стороне сервера.Обратитесь к официальной документации Apple Pay для деталей настройки Merchant ID.
Мы специализируемся на мобильной разработке более 5 лет и реализовали свыше 20 проектов с платёжными интеграциями. Оценим ваш проект бесплатно — напишите нам для консультации.