Qonversion Integration for Subscription Management
Struggling with yet another SDK? Subscription integration often turns into a headache: sandbox testing, receipt validation, handling Apple and Google errors, setting up push for trial reminders. We've faced this dozens of times and chose Qonversion — a platform that combines subscription management, analytics, and CRM in one SDK. With extensive experience, we've completed over 200 mobile projects involving subscription SDKs, and 8 out of 10 clients who switched to Qonversion cut their infrastructure costs in half.
Why Qonversion if RevenueCat and Adapty Exist?
Qonversion sets itself apart with built-in Automations — not just push triggered by events, but a full CRM engine. You can set up a chain: 3 days before trial ends — push reminder; on cancellation — in-app offer with 50% discount; after successful payment — welcome screen. With RevenueCat, you'd need to integrate Braze or OneSignal — extra work and cost. Additionally, Qonversion predicts user LTV based on behavioral patterns, helping optimize UAC campaigns.
How Does Qonversion Integration Improve Retention?
Subscription retention depends on timely communications. Automations let you react to events in real time: trial conversion, cancellation, refund, renewal. For example, on cancellation you can immediately show a win-back offer or send a push with a survey. Predictive LTV helps segment users: target high-predictive-LTV users with more expensive plans, offer discounts to those about to churn.
SDK Integration
We integrate Qonversion via Swift Package Manager or CocoaPods for iOS, Gradle for Android. Configuration is minimal:
// iOS
let config = Qonversion.Configuration(projectKey: "xxxxx", launchMode: .subscriptionManagement)
config.setEnvironment(.production)
Qonversion.initWithConfig(config)
// Purchase
Qonversion.shared().purchase("premium_monthly") { entitlements, error in
if let premium = entitlements["premium"], premium.isActive {
self.unlockPremium()
}
}
// Or async/await with iOS 15+
let entitlements = try await Qonversion.shared().purchase(id: "premium_monthly")
// Android
val config = Qonversion.Configuration.Builder(projectKey = "xxxxx")
.launchMode(LaunchMode.SUBSCRIPTION_MANAGEMENT)
.environment(Qonversion.Environment.PRODUCTION)
.build()
Qonversion.initWithConfig(config)
// Purchase
Qonversion.purchase("premium_monthly") { entitlements, error ->
entitlements?.let {
if (it["premium"]?.isActive == true) {
unlockPremium()
}
}
}
The entitlements concept is the same as in RevenueCat and Adapty. Setup in the dashboard: create an entitlement → link products → in code only check the entitlement ID. This simplifies product reassignment without code changes.
Why Qonversion Beats RevenueCat + CRM?
For small teams, Automations inside Qonversion save integration time and the cost of an external CRM subscription. For example, RevenueCat + OneSignal costs $200–500/month at $10k revenue, while Qonversion is free at the same volume (up to $10k tracked revenue). In our experience, 8 out of 10 clients who moved to Qonversion halved their monthly subscription infrastructure costs.
Remote Config and Paywalls
Qonversion supports A/B testing of paywalls via Remote Config — similar to Adapty Paywall Builder but less visual: configuration is passed as JSON, rendering is done on the developer side. This gives flexibility: you can change text, colors, promotions without updating the app.
let config = try await Qonversion.shared().remoteConfig()
let paywallVariant = config.payload["paywall_variant"] as? String
// Choose the appropriate paywall variant from local templates
Comparison: Qonversion, RevenueCat, Adapty
| Criterion |
RevenueCat |
Adapty |
Qonversion |
| Paywall Builder |
No |
Yes |
Partial (JSON) |
| CRM / Automations |
Via integrations |
No |
Built-in |
| Predictive LTV |
No |
Basic |
Yes |
| Free tier |
Up to $2.5k/month |
Up to $10k tracked |
Up to $10k tracked |
Integration Steps and Timeline
| Stage |
Actions |
Estimated Time |
| Analytics |
Review subscription model, set up entitlements |
4–6 hours |
| SDK Integration |
Connect libraries, configure purchase flow |
8–12 hours |
| Automations |
Design trigger chains |
4–8 hours |
| Remote Config |
Set up paywall A/B tests |
4–6 hours |
| Testing |
Sandbox + production, purchases, refunds, push |
8–12 hours |
| Deployment |
Release to stores, 48-hour monitoring |
2–4 hours |
Example Remote Config JSON
{
"paywall_variant": "v2",
"trial_duration": 7,
"price_anchor": 9.99
}
Work Process: From Request to Deployment
- Analytics — review current subscription model, products in App Store/Google Play, configure entitlements in Qonversion dashboard.
- SDK Integration — connect library, set up purchase flow, receipt validation, pass attribution (AppsFlyer/Adjust).
- Automations — design trigger chains: trial reminders, cancellation win-back, post-refund survey.
- Remote Config — set up paywall A/B tests, integrate with app code.
- Testing — full cycle in sandbox + production (purchases, cancellations, refunds, push).
- Deployment — release to App Store/Google Play, monitor for the first 48 hours.
What's Included
- Integration documentation (configs, sequence diagrams)
- Setup of all required SDKs (Qonversion, push, attribution)
- Creation and linking of entitlements to products
- Implementation of basic Automations (up to 5 scenarios)
- A/B test of one paywall via Remote Config
- Support for 30 days after delivery
Timeline and Cost
Standard integration takes between 2 and 5 business days depending on the complexity of Automations and number of products. Cost is calculated individually based on the scope of work — contact us for an accurate estimate. We have extensive experience with subscription SDKs (RevenueCat, Adapty, Qonversion) and over 200 completed mobile app projects.
Order Qonversion integration — get a consultation on subscription optimization and retention improvement.
Mobile App Monetization: IAP, Subscriptions, and Ad Mediation
An app with poorly implemented purchases loses money not because users don't want to pay, but because a StoreKit transaction hangs, Receipt Validation fails with an error, or restore purchases doesn't work — and the user writes to support or leaves a 1-star review. Our experience (over 7 years in mobile development) shows that proper monetization increases LTV by 30–60% within the first three months after implementation. Get a consultation on monetizing your app — we'll analyze the current model and find growth points.
Why StoreKit 2 is the Best Choice for IAP?
StoreKit 2 (iOS 15+) is a modern API with async/await and device-side verified transactions without a server. Transaction.currentEntitlements returns all active purchases. Key change compared to StoreKit 1: JWS signature verification on device via VerificationResult<Transaction> — no need to send receipt to server for basic validation.
But server-side validation is still needed for consumable purchases and fraud prevention. App Store Server API replaces the old /verifyReceipt endpoint. Webhooks via App Store Server Notifications v2 provide real-time events: SUBSCRIBED, DID_RENEW, EXPIRED, REFUND — without polling.
A typical mistake: not handling paymentQueue(_:updatedTransactions:) in the background for unfinished transactions. User bought a consumable, app crashed before finishTransaction — purchase remains in queue, restores on next launch and requires reprocessing on server. Without server idempotency — double crediting.
How Not to Lose Revenue on Subscriptions?
The subscription model requires tracking states: trial → active → grace period → expired → refunded. RevenueCat is the de facto standard for managing subscriptions in production. It abstracts StoreKit and Google Play Billing, providing a unified API, webhooks, cohort analytics, and A/B testing of paywalls.
Alternatives to RevenueCat include custom implementations with Adapty or Qonversion. Fully custom only if data must not leave the infrastructure or there is non-standard logic. We guarantee that webhook setup and subscription lifecycle event handling is done without losses — verified on projects with over 500k DAU.
Google Play Billing Library 6+ requires handling PurchasesUpdatedListener and explicitly calling acknowledgePurchase() or consumePurchase() within 3 days — otherwise Google automatically cancels the purchase and refunds. The average cost of such an error is a significant loss per user per month (based on our project data).
Ad Mediation: Boosting CPM via Bidding
Showing ads from a single source means losing revenue. Mediation (waterfall or bidding) requests ads from multiple networks and displays the best bid. Google AdMob is the foundation for banner, interstitial, rewarded ads. Mediation via AdMob Mediation or MAX (AppLovin) is the second de facto standard. MAX uses In-App Bidding — a real-time auction without waterfall. In practice, MAX yields significantly higher CPM than classic waterfall (depending on geo and audience). For example, for rewarded video in the US, the improvement can be substantial. With 100,000 rewarded video impressions per day, switching from waterfall to In-App Bidding can generate additional daily revenue.
ironSource (Unity Ads) has a strong position in the gaming segment, especially rewarded video. Mintegral covers the Asian audience well.
Setting up mediation requires ATT (App Tracking Transparency) on iOS 14+. Without requestTrackingAuthorization, ad CPM drops by 3-5 times for non-consenting users. SKAdNetwork and Privacy Manifest (iOS 17) are mandatory requirements; without them, review fails.
| Network |
Ad Type |
Feature |
| AdMob |
banner, interstitial, rewarded |
Wide network, easy start |
| MAX (AppLovin) |
rewarded, interstitial |
In-App Bidding, high fill rate |
| ironSource |
rewarded video |
Best for games |
| Mintegral |
rewarded, native |
Asia, programmatic |
How We Implement Monetization: Step-by-Step Process
- Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
- Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
- IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
- Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
- A/B testing of paywall — use Remote Config for experiments without a release.
- Launch and monitoring — 2 weeks of free support after launch, bug fixes by 24-hour SLA.
How to Design a Freemium Model and Paywall?
Freemium works when the boundary between free and paid is properly drawn. Too strict a paywall at the start — users delete. Too generous a free tier — no incentive to pay.
A technically sound pattern: server-side feature flags (Remote Config in Firebase or LaunchDarkly) control access to features. This allows A/B testing of paywall without a release, changing trial conditions, and running promotions.
Implementation at the code level: EntitlementManager — a single point for checking access to features, aware of subscription status, flags, and promos. No scattered isPremium checks throughout the code. Experience shows this approach reduces paywall-related bugs by 80% (confirmed on 30+ projects).
Checklist of Typical Monetization Mistakes
- Missing handling of
unfinished transactions — revenue loss of 5-10%.
- No server-side idempotency for consumable processing — double crediting.
- Forgot to call
acknowledgePurchase() on Android — purchase cancelled after 3 days.
- Not handling
REFUND and DID_RENEW events — incorrect subscription status.
- Paywall without A/B testing — leaving 20-40% of monetization potential.
- Ads from a single source (e.g., AdMob without mediation) — CPM 15-30% lower.
Scope of Monetization Work
- Current model audit — analysis of funnel, paywall, price tiers.
- IAP integration — StoreKit 2 / Google Billing 6, receipt validation, webhooks.
- Ad mediation — configure MAX / AdMob, connect 3-6 networks, test fill rate.
- Analytics setup — RevenueCat, Amplitude / Firebase, cohort analysis.
- Documentation — description of entitlements, restoration procedure, review checklist.
- Team training — analysis of typical mistakes, support recommendations.
- Guarantee — 2 weeks free support after launch, bug fixes by 24-hour SLA.
Estimated Timelines
| Stage |
Duration |
| Basic IAP (one store) |
1–2 weeks |
| Subscription system + RevenueCat + paywall |
3–5 weeks |
| Ad mediation (MAX + 3 networks) |
1–2 weeks |
| Full cycle (IAP + ads + analytics) |
4–8 weeks |
Cost is calculated individually. We have been working in this field for over 8 years and have implemented monetization in over 40 projects — many of which passed App Store Review without a single rejection. Contact us for an audit or order a consultation — we'll tell you what growth points exist in your app.