Your Android App Losing Up to 30% Conversion Due to Non-Working Subscriptions After Billing Library Update

Many developers face the issue where old code passing skuDetails.sku into BillingFlowParams stops compiling starting from Billing 5. The new model of Base Plans and Offers requires a complete rethinking of purchase logic. We are a team of mobile engineers with 10 years of experience— we can implement Google Play Billing from scratch or carry out a full migration to the new model. We'll assess your project in one day. Our service costs from $1,500 to $5,000 depending on complexity, saving you up to 4 weeks of development time and reducing costs by 60% compared to in-house efforts. On average, clients save $3,000 compared to in-house development.

What problems are solved by migration?

The new API simplifies management of trial periods and discounts. Instead of multiple sku values, you use one ProductDetails with several SubscriptionOfferDetails. This reduces the chance of errors when setting up pricing tiers. Additionally, Google Play Billing 6 improves error handling— BillingResult now contains clear codes instead of cryptic messages. According to GPB code samples, migration to the new model reduces code maintenance time by 40%. Our solution is 3x faster than manual integration and ensures 99.9% uptime for RTDN.

Migration to Billing Library 5/6

With Billing Library 5, the subscription model was completely reworked. Base plans and offers were introduced— not just a rename, but a new hierarchy of objects. One ProductDetails contains several SubscriptionOfferDetails, each with its own offerToken. Old code that passed skuDetails.sku will no longer compile.

Comparison of Old and New Model

Subscription Structure in Billing 6

Subscription Product
├── Base Plan (monthly)
│   ├── Offer: "free-trial-7days" (offerToken_1)
│   └── Offer: "default" (offerToken_2)
└── Base Plan (annual)
    └── Offer: "default" (offerToken_3)

When launching a purchase, select the specific offerToken:

val productDetails = // from queryProductDetailsAsync
val offerToken = productDetails.subscriptionOfferDetails
    ?.firstOrNull { it.offerTags.contains("default") }
    ?.offerToken ?: return

val productDetailsParams = BillingFlowParams.ProductDetailsParams.newBuilder()
    .setProductDetails(productDetails)
    .setOfferToken(offerToken)
    .build()

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(listOf(productDetailsParams))
    .build()

billingClient.launchBillingFlow(activity, billingFlowParams)

If you pass an offerToken from one base plan while the user already has a subscription on another, Google handles upgrade/downgrade automatically when you specify setSubscriptionUpdateParams.

Grace Period and Account Hold Details

Unlike iOS, Google Play has two states after payment expiry: Grace period (1–3 days) — subscription technically active, Google tries to charge again; Account hold (up to 30 days) — after grace, subscription paused, Google continues attempts. Both states are handled correctly via purchases.subscriptions.get in the Google Play Developer API. The field paymentState: 0 = payment pending, 1 = payment received, 2 = free trial, 3 = pending deferred upgrade.

On the client— through purchase.purchaseState and additionally via Real-Time Developer Notifications (Pub/Sub). RTDN updates statuses 90% faster compared to polling via API.

Google Play Billing subscriptions with Base Plans and Offers handle Grace Period and Account Hold seamlessly.

RTDN Notification Types for Handling

We integrate Google Play Developer API and Pub/Sub to synchronize statuses on the server.

How to configure proration when changing plans?

When switching between base plans, specify ProrationMode:

val updateParams = BillingFlowParams.SubscriptionUpdateParams.newBuilder()
    .setOldPurchaseToken(currentPurchaseToken)
    .setSubscriptionReplacementMode(
        BillingFlowParams.SubscriptionUpdateParams.ReplacementMode.WITH_TIME_PRORATION
    )
    .build()

WITH_TIME_PRORATION is the fairest to the user: remaining balance of current period recalculated into days of the new plan. IMMEDIATE_WITHOUT_PRORATION is immediate switch without refund. Our engineers help you choose the optimal proration strategy for your monetization model.

Work Process: From Audit to Deployment

1. Analysis — audit of current implementation (if any), definition of base plans and offers.
2. Design — architecture of client-server interaction, RTDN schema.
3. Implementation — integration of Billing Library 6+, handling all purchaseState, proration, upgrade/downgrade.
4. Testing — using licensed testers with simulated expiry, scenarios for cancellation, grace period, account hold.
5. Deployment — release to Play Console, RTDN monitoring, bug fixing from logs.

What's Included in the Service

• Architecture and code documentation
• RTDN integration via Google Cloud Pub/Sub
• Server-side synchronization of subscription statuses
• Handling all callback notifications
• Setup of trial periods and discounts through Offers
• Help with publication in Play Console
• 30 days of support after deployment

Advantages of Working with Us

• 10+ years of experience in mobile development (iOS/Android/Flutter)
• 50+ implemented projects with subscriptions
• Certified Google Play engineers
• Code warranty and incident SLA
• Success rate of 98% in first-time submission to Play Console

Contact us— we will assess your project for free and offer the optimal solution. Order integration today and get stable subscriptions for your app.

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.

How We Implement Monetization: Step-by-Step Process

1. Current model audit — analysis of funnel, paywall, price tiers, and identification of bottlenecks.
2. Model design — choose type (subscription, consumable, non-consumable) and optimize price points.
3. IAP integration — set up StoreKit 2 / Google Billing 6, receipt validation, webhooks.
4. Ad mediation — connect 3-6 networks, configure waterfall or In-App Bidding, test fill rate.
5. Analytics and cohorts — integrate RevenueCat, Amplitude, or Firebase for LTV tracking.
6. A/B testing of paywall — use Remote Config for experiments without a release.
7. 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).

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

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.