RevenueCat Integration for Subscription Management
A user bought an annual subscription for $49.99 on iPhone, but it's not active on Android. The developer has to spend 2–3 weeks to fix it. Server-side receipt validation, Apple Server Notifications v2, and Google Play RTDN setup are required. We solve this in 2–3 days with RevenueCat — saving time and money.
RevenueCat provides a unified CustomerInfo with the actual subscription status for all platforms. The SDK wraps native StoreKit (iOS) and Google Play Billing (Android). On purchase, the receipt or purchaseToken is sent to RevenueCat servers, which verify it with Apple and Google and return a normalized status. All transaction history is stored on RevenueCat's side — this allows restoring access on new devices without calling native restore. According to RevenueCat official documentation, the SDK handles over 10,000 events per second for large clients.
How RevenueCat Solves the Synchronization Problem
If the user is authenticated in the app, we pass the same appUserID when configuring the SDK on iOS and Android. RevenueCat returns a CustomerInfo with the active entitlement regardless of the purchase platform. For anonymous users, $RCAnonymousID is generated, which does not transfer between devices — this is a limitation, but it can be bypassed by asking the user to log in after installation.
// iOS — AppDelegate или @main
Purchases.configure(
with: Configuration.Builder(withAPIKey: "appl_xxxxx")
.with(appUserID: currentUser.id) // nil = анонимный
.build()
)
// Покупка через RevenueCat
let (transaction, customerInfo, error) = await Purchases.shared
.purchase(package: package)
if customerInfo?.entitlements["premium"]?.isActive == true {
unlockPremium()
}
The key concept is entitlements. In the RevenueCat dashboard, we create a premium entitlement and link all products (monthly subscription, yearly, lifetime) to it. In the code, we only check the entitlement, not a specific product ID. When adding a new plan, just add the product to the entitlement in the dashboard — no code changes.
What Are Entitlements and Why Are They Needed?
An entitlement is a logical group of products granting the same access rights. For example, all premium subscriptions (monthly, yearly, lifetime) are grouped into the premium entitlement. The developer only needs to check isActive for this entitlement, without worrying about specific product identifiers. This allows flexible pricing changes without modifying the app code.
Why RevenueCat Is Better Than a Custom Implementation
| Aspect |
Custom Implementation |
RevenueCat |
| Server-side development time |
2–3 weeks |
2–3 days |
| Team load |
Requires server, support for two notification systems |
One SDK, one Webhook |
| Synchronization errors |
Likely, especially in edge cases (cancellation, billing issue) |
Tested by thousands of apps, 90% bug reduction |
| Scalability |
Refactoring needed as revenue grows |
1% commission after $2500/month, everything else out of the box |
What Events Does the RevenueCat Webhook Handle?
| Event |
Description |
| INITIAL_PURCHASE |
First subscription purchase |
| RENEWAL |
Automatic renewal |
| CANCELLATION |
User cancels subscription |
| EXPIRATION |
Subscription expires without renewal |
| BILLING_ISSUE |
Payment problem (card declined, etc.) |
All events arrive in a unified JSON format, simplifying server integration: one endpoint instead of two for Apple and Google. RevenueCat automatically retries delivery on errors (up to 3 times), reducing data loss risk.
To set up an entitlement in the dashboard, create an entitlement premium and link products with the corresponding productId from App Store Connect and Google Play Console. Code check: customerInfo.entitlements["premium"]?.isActive == true. When adding a new plan, no code changes are needed — just add the product to the entitlement.
What's Included in the Work
- SDK installation for iOS (Swift) and Android (Kotlin/Java) — with a wrapper for Flutter or React Native if needed.
- Products and entitlements configuration in the RevenueCat dashboard, linking to Google Play and App Store Connect.
- Integration of the existing authentication flow — passing appUserID.
- Paywall implementation using RevenueCat Offerings — A/B price testing.
-
Webhook setup for sending events to your backend — unified format.
- Testing in Sandbox (iOS) and Test environment (Android) — covering all scenarios: new purchase, renewal, cancellation, restoration.
- Dashboard access handover and full documentation.
- Post-launch support with analytics and report setup.
- A training session for your team to manage subscriptions independently.
Work Process: From Analysis to Deployment
- Analysis: Determine the current subscription model, user scope, and authentication requirements.
- Design: Entitlement schema, product mapping, Webhook integration with your API.
-
Implementation: SDK installation, app integration, dashboard configuration.
- Testing: Unit tests on the server endpoint, test purchases on both platforms.
- Deployment: Publish to App Store and Google Play, monitor first transactions.
Timeline and Guarantees
RevenueCat integration takes 2 to 5 days depending on authentication complexity and number of products. We guarantee stable subscription status synchronization across platforms. We have over 8 years of experience in mobile development and 30+ implemented subscription models. Our standard integration costs $1,500, saving you up to $2,000 compared to custom development. Contact us for a consultation and get a preliminary estimate.
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.