Migrating off of InAppProducts for subscription management in Play

Migrating off of InAppProducts for subscription management in Play

RevenueCat simplifies Google’s prepaid plans: An opportunity to expand your global subscriber base
Rik Haandrikman

Rik Haandrikman

PublishedLast updated

Everything you need to know about the new monetization.subscriptions APIs and 2024 migration deadline

Still not done migrating from InAppProducts to the monetization.subscriptions APIs? RevenueCat’s Android and cross-platform SDKs are maintained to keep you ahead of Google platform changes. Move to RevenueCat today and save yourself the deprecation stress: Click here for our Android docs, or talk to us if you need help migrating

At Google I/O 2022 the Google Play Team unveiled one of the biggest updates to their in-app billing and subscriptions library yet: Google Play Billing Library 5.

The May 2022 Google Play subscription structure

With that new version of Play Billing Library (PBL), Google introduced a separation between what you sell (a subscription) and how you sell (a base plan and offers). At the same time, a new set of APIs to manage this new subscription structure was added to the Google Play Developer API: the monetization.subscriptions APIs

As of January 1, 2024 new apps must use these monetization.subscriptions APIs to manage their subscription catalog, instead of the InAppProducts API previously used, with a (very short) extension to May 1 of that same year for existing apps to migrate over.

In this blogpost, we’ll share:

  • Everything you need to know about the monetization.subscriptions APIs;
  • Determining if the deadline affects you;
  • An inappproducts to monetization.subscriptions migration guide;
  • An update on our support of the new APIs, and;
  • A list of resources to help answer any remaining questions and support your migration

How the monetization.subscription APIs replace InAppProducts

Google’s monetization.subscriptions APIs replace part of the InAppProduct API, which – historically – was used to manage the full product catalog for your application (the things you’re selling in the Play Store), encompassing both consumables / one-time purchases and subscriptions.

Doing this via API, rather then the Console UI, is useful in a number of specific instances, for example when there is a need to create a large number of unique subscriptions (to subscribe to individual creators in an app), or when an app does a lot of pricing and packaging segmentation and testing.

Going forward, inappproducts is solely used to manage one-time purchases, while the monetization.subscriptions APIs were introduced to manage the new subscription structure (subscription, base plan, and offer).

To manage these three objects, Google added three endpoints to the Google Play Developer API:

  • monetization.subscriptions to manage subscriptions
  • monetization.subscriptions.basePlans to manage base plans
  • monetization.subscriptions.basePlans.offers to manage offers

Managing subscriptions via monetization.subscriptions

monetization.subscriptions is how your subscriptions are created and managed. Because a subscription can no longer be a single entity (it always includes – at least – one base plan), this same endpoint creates and updates additional base plans for your subscriptions.

The monetization.subscriptions endpoint allows developers to list (list), read (get), create (create), update (patch), archive (archive), and delete (delete). In case of read and update, there are methods available to batch multiple subscriptions together: batchGet and batchUpdate

Find a full overview of this new endpoint here, in Google Play’s Developer API docs

Managing base plans via monetization.subscriptions.basePlans

monetization.subscriptions.basePlans is how you manage which base plans are active at any given time.

The monetization.subscriptions.basePlans endpoint allows developers to activate (activate), deactivate (deactivate), or delete (delete). It also allows for migration to a current price for users on legacy pricing (migratePrices and batchMigratePrices), or activate and deactivate multiple base plans together (batchUpdateStates)

Find a full overview of this new endpoint here, in Google Play’s Developer API docs

Managing offers via monetization.subscriptions.basePlans.offers

monetization.subscriptions.basePlans.offers is how offers are created and managed. It allows you to define both the specific details of an offer, as well as its targeting rule set.

The monetization.subscriptions.basePlans.offers endpoint allows developers to list (list), read (get), create (create), activate (activate), update (patch), deactivate (deactivate), or delete (delete). It also allows updates to multiple offers in one go (batchUpdate), as well as activating / deactivating offers in bulk (batchUpdateStates).

Find a full overview of this new endpoint here, in Google Play’s Developer API docs

When do you need to migrate from inappproducts to the monetization.subscription APIs?

The likelihood of this specific deadline impacting your app are slim, as you would exclusively use InAppProduct API to manage product catalogs remotely, without interacting with the Play Console UI.

This might be (but isn’t necessarily) the case if you see the following warning in your Google Play Console:

InAppProducts deprecation and monetization.subscriptions migrations notice, as shown in Google Play Console

“You’re using the InAppProduct API to manage subscriptions, which is now deprecated and will stop being supported for new apps in January 2024, and for all apps in May 2024. Start using the new Subscriptions API to get new features including multiple base plans and offers, as well as prepaid plans.”

What this message means is that, prior to May 2022, you or someone working on your app used inappproducts to manage subscriptions or one-time purchases. It does not mean that that is the case today:

When Google introduced PBL5 and converted all subscriptions to the new model featuring a single base plan and offer, it set all converted subscriptions to read-only in the Google Play Console. This is because once a converted subscription was edited in the Console, inappproducts would no longer work for subscriptions.

If there are still read-only subscriptions in your Console, and you haven’t used monetization.subscriptions yet, Play Console will assume that you might still use the InAppProduct API at some point. When you’re not using the API actively, you’re able to ignore the warning (and edit any of those read-only subscriptions).

If you’re on RevenueCat, you can ignore this issue: RevenueCat does not use the InAppProduct API for subscriptions. You are safe to make subscriptions editable and disregard this message, unless you or your team are using this API outside of RevenueCat.

If you’re part of a larger organization and aren’t sure if you’re using this API, check with your Android and / or platform team members.

Migrating to monetization.subscription from the InAppProduct API

Google converted your existing subscriptions to the new model:

A legacy subscription migrated to the May 2022 subscription structure

These converted subscriptions mimic their original version by having a single backwards compatible base plan and offer, which the InAppProduct API has been able to manage as before the introduction of PBL5.

Because the new model introduces features and functionality that you (should want to, but technically) don’t have to use, we’ll focus on replicating the soon to be deprecated InAppProduct functionality with single backwards compatible base plans and offers via monetization.subscriptions:

Using inappproductsUsing monetization.subscriptions
packageNamepackageName
skuproductId
statusbasePlans[0].state
pricesbasePlans[0].regionalConfigs.price
listingslistings
defaultPriceNo longer available
subscriptionPeriodbasePlans[0].autoRenewingBasePlanType.billingPeriodDuration
trialPeriodbasePlans[0].offers[0].phases[0].regionalConfigs[0].free
gracePeriodbasePlans[0].autoRenewingBasePlanType.gracePeriodDuration
subscriptionTaxesAndComplianceSettingstaxAndComplianceSettings

Replacing your existing inappproducts references to point towards these objects under monetization.subscriptions will allow you to switch over with a minimum amount of hassle.

One thing to keep an eye on is setting prices, which – previously – you could do via a single default price (through defaultPrice), but now *has* to be set per region. The Play Console offers a handy ‘check all’ box for this purpose, but you must set regional pricing individually via the API for each country or region where you want to sell your product.

Note that this ‘basic’ migration mimics Play’s old subscription structure, and therefore doesn’t allow you to benefit from most of the new features and functionality as outlined in this post about Play Billing Library 5 (we’re now on PBL 6, but there are no noteworthy changes to how any of the above functions between 5 and 6).

Also keep in mind that you’ll continue using inappproducts for one-time purchase management.

RevenueCat and Google Play’s subscription APIs

As pointed out earlier in this article, unless they built their own integration with the inappproducts API, RevenueCat customers are unaffected by any of these changes. As one of our engineers pointed out in a Slack thread about this latest deprecation:

Andy Boedo is a Slack-poet

We’re always happy to chat about how we can keep you ahead of Google (and Apple)’s platform changes. Reach out to us here

Useful resources

Start with RevenueCat 

Migrating your Android app over to RevenueCat will save you the trouble of figuring out support for new Google Play Billing Library versions and any future updates from Google and the other platforms. To start with RevenueCat, explore our migration guide docs. If you have more complex needs, we encourage you to request a custom migration plan from our team.

In-App Subscriptions Made Easy

See why thousands of the world's tops apps use RevenueCat to power in-app purchases, analyze subscription data, and grow revenue on iOS, Android, and the web.

Related posts

Engineering

Vision Pro apps powered by RevenueCat: What’s available on launch day

Over 160 of the first visionOS apps are powered by RevenueCat

Charlie Chapman

Charlie Chapman

February 2, 2024

Engineering

How I successfully migrated my indie app to RevenueCat Paywalls

And how a simple experiment increased my LTV by 33%.

Charlie Chapman

Charlie Chapman

January 3, 2024

StoreKit 2 tutorial: implementing in-app purchases in a SwiftUI app
Engineering

StoreKit 2によるiOSのアプリ内課金のチュートリアル

実際に動作するサンプルコードが付属したアプリ内課金のステップ・バイ・ステップ形式の解説です。

Josh Holtz

Josh Holtz

January 1, 2024

Want to see how RevenueCat can help?

RevenueCat enables us to have one single source of truth for subscriptions and revenue data.

Olivier Lemarie, PhotoRoomOlivier Lemarie, PhotoRoom
Read case study