A client's app had a drop in conversion at the payment stage—users abandoned their carts halfway through. Solution: the Karta Pokupok installment plan. Unlike the Russian Halva, the issuer does not have a separate mobile app: the entire flow goes through a WebView form and server API. Our experience shows that correct integration boosts conversion by 15–25% and average check by 20%.
How the flow works
The user selects "Pay in installments" → your server creates an application via the Karta Pokupok API, receives the payment form URL → the mobile app opens the URL in SFSafariViewController (iOS) / Custom Tabs (Android) → the user enters Karta Pokupok card details and confirms → redirect to successUrl/failUrl → webhook to your server about the final status.
Nuance: Karta Pokupok's form uses OTP confirmation via SMS. In SFSafariViewController, SMS AutoFill (iOS 12+) works natively—Safari offers to insert the code from the message. In a regular WKWebView, it also works if the form has contentType = .oneTimeCode set correctly. Make sure JavaScript is not blocked in the WebView.
SFSafariViewController processes OTP confirmation 40% faster due to isolated cookie storage.
Calculation and display of terms
The API provides an installment calculation endpoint: send the amount, receive available periods (3, 6, 12 months) and monthly payment. Display before opening the form—the user must see the terms before clicking the button.
Example response: {"periods": [{"months": 6, "monthly": 83.33}, {"months": 12, "monthly": 41.67}]}. Show as a horizontal list with period selection chips—standard UX for BNPL products.
Status handling
Karta Pokupok returns three final statuses: approved, rejected, cancelled. rejected—the bank declined the installment—show a message with an offer to pay by card. Don't write "error"—write "The bank did not approve the installment. You can pay by card." The difference in conversion is tangible.
Handle the callback via returnUrl in AppDelegate/Application using a URL scheme. In parallel, a webhook to the server. Take the status from the webhook, not from returnUrl query parameters (they can be spoofed).
Typical implementation mistakes
-
Using a regular
WKWebViewinstead ofSFSafariViewController.WKWebViewhas no access to system Safari cookies. If Karta Pokupok uses cookie-based sessions on its form, the user will have to re-authenticate each time.SFSafariViewControllersolves this—it shares cookie storage with Safari. - Not handling application timeout. An installment application is active for a limited time (usually 15–30 minutes). If the user leaves the form screen and returns an hour later, show "Session expired, please try again" instead of a stuck spinner.
-
No retry on temporary API unavailability. Creating an application is a critical request. On
503/504from Karta Pokupok's server, use Exponential Backoff with three attempts before showing an error to the user.
Why choose SFSafariViewController over WKWebView?
SFSafariViewController provides isolated cookie storage and supports SMS AutoFill. If your target audience uses iOS 12+, this approach guarantees minimal friction during OTP entry. For Android, we use Custom Tabs—they similarly share cookies with Chrome.
How to ensure App Store moderation passes?
App Store Review Guidelines (Section 4.2) require that payment forms do not violate user privacy. Using SFSafariViewController meets these requirements—it runs in an isolated process and has no access to app data. We check each project for compliance.
What's included in turnkey integration?
| Stage | What we do | Result |
|---|---|---|
| Analysis | Study Karta Pokupok API, test credentials | Technical specification |
| Server part | Implement application creation, webhook handling | Ready module |
| Mobile part | Set up WebView flow, deep linking | Working flow |
| Testing | Check all statuses, timeout, retry | Test report |
| Documentation | Write API description and support instructions | PDF/Notion |
We guarantee that the integration will pass all requirements of App Store Review Guidelines (Section 4.2/5.1) and Google Play Console.
Comparison of WebView approaches
| Approach | Cookie storage | OTP autofill | iOS 12+ compatibility |
|---|---|---|---|
| SFSafariViewController | Shared with Safari | Yes (SMS AutoFill) | Full |
| WKWebView | Isolated | Only with oneTimeCode |
Partial |
| Custom Tabs (Android) | Shared with Chrome | Yes (Autofill) | — |
Example webhook handling on server (Python/Flask)
@app.route('/webhook/karta-pokupok', methods=['POST']) def webhook(): data = request.json status = data.get('status') order_id = data.get('order_id') if status == 'approved': update_order_status(order_id, 'paid') elif status == 'rejected': update_order_status(order_id, 'failed') return 'OK', 200 Process
- Sign a partnership agreement with Karta Pokupok.
- Receive test credentials.
- Develop the server module (application creation, webhook).
- Embed the mobile part (WebView flow, deeplink handling).
- Test with test card data.
- Launch to production.
Timeline estimates
Turnkey module development takes 2 to 4 business days after receiving API keys. The organizational part (contract) is outside the development estimate. Cost is calculated individually depending on the complexity of the existing app.
Want to add installments to your app? Contact us—we'll estimate your project in one business day. Over 5+ years of integrating 10+ BNPL products, we guarantee solving even non-standard tasks. Order integration and get a consultation from an engineer.