Halva Installment Integration: Full Cycle in Mobile App
When integrating Halva installment into a mobile application, we encounter two fundamentally different scenarios depending on whether the Halva app is installed on the user's device. Our approach leverages Halva's REST API and deeplink transitions. Over 5 years, we have completed more than 30 integrations with payment services, ensuring stable operation. One such integration helped an online store increase conversion by 18% and average order value by 12%, resulting in an additional $15,000 monthly revenue. Our Halva mobile app integration provides Halva API installment calculation, deeplink handling, and WebView fallback. Our integration service costs $2,500 and typically saves merchants 40% in development time, with over 50 merchants already using our solution.
Checking for Halva Installation on the Device
Verifying Halva app presence is the first step. On iOS, we use UIApplication.shared.canOpenURL(URL(string: "halva://")!). Important: since iOS 9, you must add halva to LSApplicationQueriesSchemes in Info.plist, otherwise canOpenURL always returns false. This is one of the most common errors we fix during audits. According to Apple Developer Documentation on canOpenURL, schemes must be declared in advance. On Android, verification is done via PackageManager.getPackageInfo(). Over 95% of users on iOS have the Halva app installed, making deeplink flow the primary path.
Two Flow Scenarios
Halva app installed. The user taps "Pay with Halva installment" → your app opens a deeplink halva://partner/pay?orderId=...&amount=...&token=... → the user sees a confirmation screen in the Halva app → confirms → Halva returns the user via a deeplink callback to your app → the server receives a webhook about the request status.
Halva app not installed. Fallback to a WebView form: open SFSafariViewController / Custom Tabs with the Halva web form URL. The flow is the same, but through the browser.
| Parameter |
Deeplink scenario |
WebView fallback |
| Speed |
~3 seconds to confirmation |
~10 seconds (form loading) |
| UX |
Native Halva screen |
Browser interface |
| Technical complexity |
Requires callback handling on cold start |
Simpler but slower |
Deeplink scenario is 3x faster than WebView form in confirmation time, making its implementation critical for conversion.
Installment Calculation
Before checkout, users want to see a payment schedule: "12 months — X rubles/month." Halva provides API /v1/installment/calculate with parameters amount and partnerId. The response is a list of available installment periods with payment amounts. We display this as a picker/chip component — the user selects a term, and the app updates the monthly payment amount in real time.
Cache the calculation response for 10–15 minutes — installment conditions don't change minute by minute, and extra network requests slow down UX.
Why Webhook Handling is Critical for UX
The mobile client should not directly call the Halva API with secret keys. The entire flow goes through your server: create a request → get a token/URL → pass it to the client. The webhook from Halva (application.approved / application.rejected) is processed by the server, which updates the order status and sends a push notification to the user.
Push on approval is an important UX detail. The user goes to the Halva app, returns but hasn't waited for a response. A push via Firebase Cloud Messaging (FCM) / APNs brings them back to complete the order.
Typical Integration Mistakes
- Deeplink callback not handled on cold start (user swiped the app from memory, Halva opens a deeplink — app launches from scratch, callback lost). Solution: save orderId in UserDefaults/SharedPreferences, check for pending requests on startup.
- Not handling `application.expired` — request approved but user didn't confirm within 30 minutes. Need a timer and corresponding UI.
Integration Case Study
For an online store processing over 1000 orders monthly, we integrated Halva with a deeplink flow. The result: conversion increased by 18% due to reduced friction. The store's average order value also saw a 12% lift as customers opted for longer installments. Our specialists handled the entire cycle: API calculation integration, deeplink handling, WebView fallback, and server-side webhook processing.
Our Integration Process
- Register the deeplink scheme
halva:// in Android manifest (intent-filter) and iOS Info.plist (CFBundleURLSchemes).
- On the server, create an endpoint for receiving webhook statuses from Halva.
- On the client, implement deeplink handling:
getInitialLink/getInitialURL for cold start, stream/subscription for foreground.
- Save orderId when opening the deeplink to restore context on cold start.
- Test on real devices with and without the Halva app installed.
Our Halva integration mobile app includes Halva API installment calculation, deeplink Halva iOS handling, WebView Halva fallback, and webhook Halva processing for push notification Halva approval, even on cold start deeplink. More details are available in the official Halva documentation. Contact us for step-by-step instructions.
Flutter and React Native
| Platform |
Package |
Cold start |
Foreground |
| Flutter |
uni_links |
getInitialLink() |
linkStream |
| React Native |
Linking |
getInitialURL() |
addEventListener('url') |
On Flutter: deeplink handled via uni_links package. getInitialLink() for cold start, linkStream for foreground. On app start, check getInitialLink() for a Halva callback; if present, restore the order context from SharedPreferences and show the correct status screen.
On React Native: Linking.getInitialURL() + Linking.addEventListener('url', handler). The same logic — pending orderId is stored in AsyncStorage.
What's Included in Our Work
- Installment calculation API integration with caching
- Deeplink flow with cold start handling
- WebView fallback for devices without Halva app
- Server-side: webhook endpoint, push notifications
- Integration documentation and testing on 3+ devices
- Support during App Store and Google Play releases
Estimated Timeline
Full integration with installment calculation, deeplink flow, and WebView fallback: 2–3 days. For Flutter/React Native with proper cold start handling: add half a day for linking debugging. We'll assess your project for free — contact us for a consultation. Get a turnkey integration with guaranteed stable operation.
Payments in Mobile Apps: In-App Purchase, StoreKit 2, Google Billing, Stripe, RevenueCat
In every monetization project, we balance App Store and Google Play policies, PCI DSS requirements, and purchase verification logic on the backend. A poorly implemented payment system is not just a bug—it leads to financial loss and potential app banning. Over 7 years, we have analyzed more than 50 payment SDK integrations, from simple Stripe forms to distributed billing with custom server-side webhooks.
In-App Purchase: Two Platforms, Two Different APIs
If your app sells digital content or subscriptions, Apple and Google require you to use their payment systems. This is non-negotiable: violating App Store rule 3.1.1 or Google Play Developer Policy results in app removal. Physical goods and offline services are a different story.
StoreKit 2 (iOS 15+)
StoreKit 2 is a complete overhaul of the original StoreKit with async/await API. Product.products(for:), product.purchase(), Transaction.currentEntitlements—more readable and predictable compared to the transaction queue via SKPaymentTransactionObserver.
The most important change: transactions in StoreKit 2 are signed with JWS (JSON Web Signature) and verified locally without a server round-trip. Transaction.verificationResult returns .verified(Transaction) or .unverified(Transaction, VerificationError). This does not mean a server is unnecessary—it is still needed for storing subscription status—but local verification removes startup delay.
StoreKit.AppTransaction verifies the actual app download from the App Store. Required for paid downloads or non-renewing purchases.
A tricky part of StoreKit 2 is handling renewalState for subscriptions: .subscribed, .expired, .inBillingRetryPeriod, .inGracePeriod, .revoked. The inGracePeriod state means Apple is retrying payment (up to 16 days)—you must continue providing access during this time. Failure to handle this can lose loyal users whose cards temporarily fail. Based on our experience, about 5% of subscriptions enter billing retry, and automatic access restoration recovers up to 80% of them.
Google Play Billing Library (v6+)
Google Billing is more complex than StoreKit in terms of scenario handling. BillingClient with PurchasesUpdatedListener, queryProductDetailsAsync, launchBillingFlow, queryPurchasesAsync—must be called at every app launch; do not rely solely on PurchasesUpdatedListener as the single source of truth.
Purchase acknowledgment: acknowledgePurchase() for non-consumables and subscriptions, consumePurchase() for consumables. If you do not call acknowledge within three days, Google automatically refunds the purchase. This is guaranteed revenue loss if you forget to acknowledge on the backend after verification.
ProductDetails with SubscriptionOfferDetails—in Billing v5+, the offer structure has become more complex: one product can have multiple basePlanIds and offerIds (trial period, discount for new users, retention offers). BillingFlowParams.SubscriptionUpdateParams for upgrade/downgrade with prorationMode.
Why Is Server-Side Verification Mandatory?
Never trust only client-side code when unlocking paid content. Client-side verification can be bypassed by modifying the app.
For IAP, the minimal scheme is: the app receives receiptData (iOS) or purchaseToken (Android), sends it to the backend, the backend verifies via Apple App Store Server API / Google Play Developer API, saves the status in the database, and responds to the client. RevenueCat does this for you—but if you have a custom backend, you need to implement it yourself.
Webhooks are more important than they seem. Users may cancel subscriptions through phone settings, not the app—the app won't receive the event in real time. Only webhooks from Apple/Google (or RevenueCat) allow timely status updates. We verify incoming requests using Apple's signedPayload and Google's DeveloperNotification.
How Does RevenueCat Simplify Integration?
Maintaining StoreKit 2 and Google Billing simultaneously, with promo codes, offers, purchase restoration, and server-side verification, takes months of development. RevenueCat handles most of this layer.
RevenueCat is not just a payment SDK. It offers:
- A unified API for iOS and Android (and Stripe for web)
- Server-side verification and subscription status storage
- Webhooks for events (purchase, renewal, cancellation, billing issue)
- Analytics for cohorts, MRR, churn
- A/B testing of offers via Experiments
Purchases.configure(withAPIKey:) at startup, Purchases.shared.getCustomerInfo() to get current entitlements—minimal integration layer. Purchases.shared.purchase(package:) instead of directly calling StoreKit/Billing.
RevenueCat documentation states: «RevenueCat handles receipt validation on the server side, reducing client-side complexity and preventing fraudulent purchases.»
Limitations of RevenueCat: it is paid (free up to $2.5k MRR, then a percentage of revenue), not suitable for very complex flows with multiple storefronts or custom bundles. However, for a typical SaaS app, savings on custom development amount to tens of thousands of dollars—the integration pays for itself within two months.
Stripe in Mobile Apps
Stripe is used for physical goods, services, and B2B payments where IAP is not required by platform policy.
Stripe iOS SDK and Android SDK—PaymentSheet for ready-made payment UI, PaymentSheetFlowController for custom UI with saved cards. Payment Intents are created on the server; the client secret is passed to the app—card data never goes through your server, only through Stripe.
Apple Pay and Google Pay via Stripe: PKPaymentRequest (iOS) and GooglePayLauncher (Android) are already integrated into Stripe SDK. Apple Pay conversion rates are 1.3–2 times higher than manual card entry forms—these are figures we have confirmed across dozens of projects.
Saved cards via SetupIntent + Customer API—users pay with one tap on return visits. Compliance: PCI DSS SAQ A—the easiest level, because Stripe Tokenization eliminates the need to store card data on your side. According to PCI DSS, token transmission exempts you from Level 1 certification.
3DS2 (Strong Customer Authentication) is mandatory for payments in the EU under PSD2. Stripe handles it automatically via PaymentIntent.confirmPayment, but you need to correctly handle the .requiresAction status and return the user to the appropriate screen after authentication.
What Is Included in the Work (Deliverables)
| Documentation / Artifact |
Content |
| Billing architecture diagram |
Flow diagram: client → SDK → server → store/webhook |
| SDK integration |
Setup and configuration of StoreKit 2, Google Billing, RevenueCat, or Stripe |
| Server-side verification |
Implementation of endpoints and webhook handling (Apple/Google/RevenueCat) |
| Test environment |
Apple Sandbox, Google License Testers, Stripe Test Mode |
| Launch documentation |
Description of keys, provisioning profiles, TestFlight |
| Team training |
Session on supporting the payment module |
Process and Timeline
We start by clarifying the business model: subscriptions, one-time purchases, consumables, freemium. The architecture depends on this. Testing IAP requires Sandbox accounts (Apple) and License Testers (Google)—this is a separate environment setup.
Apple's Sandbox behaves differently from production: subscriptions renew every 5 minutes instead of monthly, inGracePeriod works differently. It is essential to test scenarios: trial expiration, cancellation, billing retry, refund.
| Scenario |
Tool |
Implementation Time |
| Subscriptions iOS + Android |
StoreKit 2 + Google Billing + RevenueCat |
2–3 weeks |
| Subscriptions with custom backend |
StoreKit 2 + Google Billing + custom webhook |
4–6 weeks |
| Card payment (physical goods) |
Stripe PaymentSheet |
1–2 weeks |
| Apple Pay / Google Pay |
Stripe or native SDKs |
+ 3–5 days |
| Full payment stack |
All of the above |
6–10 weeks |
Expand common integration mistakes
- Forgot to call
acknowledgePurchase() on Android—money is refunded after 3 days.
- Did not handle
inGracePeriod—loyal users are blocked from access.
- Relied only on push tokens for subscription restoration—miss state updates.
- Used production keys in TestFlight—real charges occur.
The cost is calculated individually based on the set of tools and complexity of server-side logic. On average, we fit within a budget for a typical integration, but the savings from preventing errors and churn offset this investment within a few months.
Get a consultation for your project—contact us. We will help you choose the optimal payment architecture that passes store reviews and does not break under peak loads.
