In May 2022, we introduced changes in the way subscription products are defined and managed in the Play Console. These changes provide you with greater flexibility in how you sell subscriptions, and reduce the complexity of managing subscriptions. Once you’ve upgraded your app and backend integrations to use the new subscription APIs, you can sell:
- Prepaid plans: Users purchase a specific period, and can top-up to extend their access.
- Upgrade offers: Users receive a discount for upgrading their subscription tier, lengthening their billing period, or moving from prepaid to an auto-renewing plan.
- Custom eligibility: you decide the business logic and determine eligibility in your app
Once you’ve upgraded, it’s also easier to create and manage multiple offers per subscription. If you haven’t already, read this article to understand how subscriptions now work.
All your existing subscriptions, apps, and backend integrations function as they did before these updates. There’s nothing you need to do immediately – you can adopt the new subscription features over time.
If you previously used the Play Console, you’ll notice there’s many changes on the Subscriptions page (Monetize > Products > Subscriptions). Most of these changes allow you to create and manage subscriptions, base plans, and offers. There’s also a few different ways to do things:
- Price changes: When changing the price of a subscription, it only applies to new purchases. You change the price existing subscribers are paying by using legacy price cohorts.
- Regional availability: You can choose the regions where your subscription can be purchased. You can also create regional offers in a subset of those regions.
- Regional pricing: You can specify prices for each region. You can also select multiple (or all) regions, provide a single price in a currency of your choosing, and Play will do a one-time currency conversion to all the selected regions. You can update prices when desired.
Subscriptions created before May 2022 included the subscription description, benefits and a single billing period, price, and free trial/intro price setting. Additional subscriptions were required if you wanted multiple billing periods or pricing.
Starting in May 2022, a subscription’s benefits (in other words, “what” the subscription provides) are defined separately from its base plans and offers (“how” the subscription is sold). This new model makes it easier to sell your subscriptions in various ways.
In the below image, the left side shows how subscriptions were previously defined as fully independent objects. If multiple “subscriptions” provided the same benefits with different billing periods or pricing, this could become complex. For instance, you needed to make sure the user-facing description and benefits were the same across subscriptions, and that your app did not allow users to purchase redundant subscriptions.
The right side shows how subscriptions are now structured. Each subscription can have multiple base plans, each with multiple offers.
When these changes launched in May 2022, any existing subscriptions were converted into the new model. The results are:
- Subscriptions retain information unrelated to how the subscription is sold, such as their user-facing name, description and benefits.
- Each subscription has a single base plan with the old subscription’s billing period and auto-renewing price.
- If a subscription had a free trial or intro price, the base plan has a single offer with new subscriber eligibility criteria (for example, only for users who have never purchased a subscription in this app), and pricing (the free trial duration, or the intro price and duration).
The resulting subscriptions, base plans, and offers have the same functionality as before. For instance, you can change the length of a free trial, update a subscription’s description, or change your grace period length.Example 1: Conversion of a legacy SKU with an introductory price
This is how a legacy monthly subscription with the name “Basic Plan”, product ID basic1 and a one month intro price was converted to the new model:
When legacy subscriptions were converted into the new model, they remained separate subscriptions. The conversion didn’t merge any SKUs into subscription products.
For example, a common use case in the legacy system was that a developer could have multiple subscriptions for a single subscription entitlement. In this case, a “Basic Plan” SKU with product ID basic1 with no special pricing and a “Basic Plan” SKU with product ID basic2 with a free trial for users who never purchased any subscription in the app. The conversion results in two subscriptions with the same title or name, “Basic Plan”, and each their product ID.
Both have a single basic plan (monthly, auto-renewing), and the legacy SKU with a free trial resulted in a subscription with one offer.
Previously, Play Console and the developer APIs defined a subscription as having a single pricing plan. Now, Play Console and the developer APIs allow a subscription to have multiple base plans and multiple offers.
Since apps and backend integrations using older developer APIs expect a subscription to include a single pricing plan, in Play Console each subscription has a single “backwards compatible” offer or base plan.
When your app or backend uses older API methods, this base plan or offer is used for the billing period, price, and any free trial or intro price. If a subscription has other base plans or offers, they are only available to apps using the newer API methods.
Marking a base plan or offer as backwards compatible
When older subscriptions were converted into the new model, if the subscription contained a free trial or intro price, the resulting offer and base plan was marked as backwards compatible. Otherwise, just the base plan was marked as backwards compatible.
If needed, you can change which base plan or offer is the backwards compatible one. Before changing the backwards compatible base plan or offer, consider carefully what impact that could have on versions of your app that use older API methods, and on any other features that use it.
You can only mark an offer or base plan that contains functionality previously available. For example, prepaid plans, upgrade offers, developer-determined offers, and tags are not supported.
You can now control availability and pricing individually for each country or region, and configure whether your base plan or offer should be made available to any new locations which Google Play may support in the future.
We’ve back-filled all your existing subscriptions so that if you previously targeted “Other countries/regions,” you’ll continue to target all countries within this group. If you didn’t previously make your base plan or offer available in “Other countries/regions,” nothing has changed.
When creating or editing base plans or offers, you can select Manage country / region availability and make your base plan or offer available in all locations, or configure them individually. You’ll also see the “New countries / regions” option. If you specify “New countries / regions,” when Google Play adds support for additional countries/regions, we will use these availability and price settings. If support for these new countries/regions includes a local buyer currency, we’ll do a one-time currency conversion. If you do not specify “New countries / regions,” by default your subscription will not be available in these countries/regions. After new countries/regions are supported, you can edit your subscription in Play Console to make them available if desired.
When editing prices, you can select all locations, price locations individually, and set the price for any countries/regions Google Play supports in the future.
Currently, several subscription features only support the backwards compatible offer. These features are:
- Subscription promo codes
- Featured subscriptions
- Subscribe with Google
In Play Console, these features only allow you to select a subscription, not a base plan or offer. When you select a subscription, that subscription’s backwards compatible offer will be used.
Important: For any subscriptions in which you’re using these features, we recommend you do not change the backwards compatible offer without carefully considering how it affects your use of these features.
Making changes to your subscription products
You can add base plans and offers to an older, converted subscription. While you can change which offer is the “backwards compatible” one, consider the impact on older versions of your app. Alternatively, you can keep old and new configurations separate by leaving the older, converted subscriptions as they are and creating a new subscription with its own base plans and offers. This clearly separates the older, converted subscriptions used by older apps and integrations. Whether you decide to alter your converted legacy subscriptions or not, keep them with their backwards compatible offers active so they can be purchased by users on older versions of your app.
New subscriptions can be configured with multiple base plans and offers, prepaid plans, upgrade offers, and other new features. Read this article for details on how to do this.Example 3: Creation of new subscription with multiple base plans and offers
In this example, there is a new subscription product for “Basic plan”, with product ID basic_new. There are two base plans under this subscription: a monthly recurring plan and an annual recurring plan. Each plan has a basic price, which is the amount the user will pay in regular renewal cycles, and on their first purchase if they are not eligible for any special offers. The offers under each plan have different eligibility and discount criteria. This way the developer can represent all the different ways a user can acquire the “Basic Plan” in a single subscription.
When you configure your subscriptions with multiple base plans and offers, you will need to update your Google Play Billing integration so it uses the right API versions to handle these new functionality. For details on how to do that, you can see the migration guide.
Deactivating converted subscriptions
After you create a product catalog that leverages the new subscription-base plan-offer structure and you upgrade your integration to correctly handle these new products, you may want to deactivate your original converted subscriptions.
To stop new subscribers from purchasing a particular product you would deactivate all the subscriptions’ base plans and offers. Existing subscriptions will still auto-renew until they are canceled or expire.
We recommend waiting to deactivate your converted subscriptions until the amount of purchases happening in older versions of your app decrease. This will happen naturally as time goes on and users upgrade away from older app versions. These older versions that use deprecated APIs will gradually stop making purchases on the converted legacy subscriptions. At some point, you can stop selling legacy subscriptions by deactivating their base plans and offers.
Users with active subscriptions on those older plans will still be able to renew and enjoy their subscriptions, but no new purchases can be made from any version of the app.
If you manage your subscription catalog using the inappproducts API, you can continue to do so. However, this will result in subscriptions with a single backwards compatible base plan and offer, and you will not be able to use any of the new subscription features. Your subscriptions will still be available in the Play Console in a read-only mode.
We recommend you migrate to the new Monetization Subscriptions APIs and manage your subscriptions using the new monetization.subscriptions, monetization.subscriptions.baseplans and monetization.subscriptions.offers endpoints. These new APIs will allow you to manage all available base pans and offers (instead of backwards compatible only).
If you wish to edit your subscriptions in Play Console, you can click Make subscription editable under the message displayed at the top of each subscription.