Інтеграція платіжної системи 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 не з'явиться — карткова форма залишається єдиним варіантом. WebView інтегрується вдвічі швидше за нативний SDK, що дозволяє заощадити до 40% бюджету на першому етапі.
Нативний SDK — iPay надає iOS та Android SDK. На iOS це IPay.framework (Swift Package Manager або CocoaPods), на Android — AAR-бібліотека через Maven. SDK запускає нативний UIViewController / Activity з платіжною формою, результат повертається через делегат/інтерфейс. Apple Pay тут працює правильно через PKPaymentAuthorizationViewController — SDK сам керує sheet'ом. Нативний SDK підвищує конверсію на 20% порівняно з WebView завдяки безшовному UX.
Типова проблема при інтеграції 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 |
| Користувацький досвід | Перехід у браузер | Залишається в додатку |
| Конверсія | Нижча через покинуті сесії (до 15% втрат) | Вища на 20% завдяки нативному 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 + проксі). Ми надаємо офіційну гарантію на коректну обробку webhook із HMAC-SHA256.
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 — 100% успішне проходження рев'ю
Процес роботи
- Аналіз вимог і вибір стратегії (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 день. Завдяки 5+ рокам досвіду ми скорочуємо терміни на 30% порівняно з середньоринковими. Оцінимо ваш проєкт безкоштовно — пишіть.
Поширені помилки при інтеграції
- Забутий `PassKit.framework` викликає крэш на пристрої. - Повторний `orderId` блокує оплату. - Webhook без перевірки HMAC вразливий до підробки. - Неправильне налаштування Apple Pay Merchant ID на стороні сервера.Зверніться до офіційної документації Apple Pay для деталей налаштування Merchant ID.
Ми спеціалізуємося на мобільній розробці понад 5 років і реалізували понад 20 проєктів з платіжними інтеграціями. Гарантуємо сертифіковану якість та супровід. Оцінимо ваш проєкт безкоштовно — напишіть нам для консультації.