iPay Payment System Integration in Mobile Application
iPay.ua is a Ukrainian payment gateway supporting Visa/Mastercard cards, Apple Pay, and Google Pay. For mobile app the choice between native SDK and WebView form is resolved not by "what's more convenient" but by "what passes App Store Review" and "where conversion losses are minimal".
Two Paths and Their Real Consequences
WebView path — faster on start. iPay returns payment form URL, app opens SFSafariViewController (iOS) or Custom Chrome Tab (Android). Minus: user sees browser transition, Apple Pay inside WebView in SFSafariViewController works, but only if domain properly configured in Apple Pay Merchant ID. If developer forgot to set paymentRequest.merchantCapabilities and supportedNetworks server-side, Apple Pay won't appear — card form remains only option.
Native SDK — iPay provides iOS and Android SDK. On iOS it's IPay.framework (SPM or CocoaPods), on Android — AAR library via Maven. SDK launches native UIViewController / Activity with payment form, result returns via delegate/interface. Apple Pay here works correctly via PKPaymentAuthorizationViewController — SDK manages sheet itself.
Typical iOS SDK integration issue: developer adds IPay.framework but forgets to add PassKit.framework in Link Binary With Libraries, and on device (not simulator) gets dyld: Library not loaded when opening payment screen. Simulator doesn't reproduce it — crash only on real hardware.
How We Implement
SDK initialization in AppDelegate/App passes merchant ID and environment (production/sandbox). Payment launches with order parameters — amount, currency (UAH), description, order ID. SDK returns PaymentResult with enum status: success, failure, cancelled.
Critical: orderId must be unique per payment attempt. If user clicked "Pay", got network error, and retried with same orderId — iPay rejects as duplicate. Generate new UUID for each payment flow start.
Server side — webhook handler for payment.success / payment.failed. Mobile client must not change order status based on local callback alone — only after server confirmation. Client callback can be spoofed (Jailbreak/Root + proxy).
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
For Flutter: native SDK wrapped in Platform Channel. Write MethodChannel('ipay'), on native side call SDK, return result via result.success(paymentResult).
Process
Get test credentials from iPay → sandbox testing with test cards → webhook handler configuration → Apple/Google Pay testing on real devices → production certificate → submit.
Timeline Estimates
WebView form integration: 1–2 days. Native SDK with Apple Pay + Google Pay + webhook: 2–3 days. If Flutter wrapper needed on top native SDK — plus 1 day.