The new subscription model and Google Play Billing Library 5.0 overview

Throughout the annual I/O convention, Google launched its new main model of the Google Play Billing Library. Apart from traditional technique deprecations and removals, there was additionally huge details about the brand new structure of subscriptions, which goals to simplify the best way you’ll be able to create, handle and promote in-app purchases. On this article, I’ll discover the updates to Google Play Billing Library 5.0 and dig deeper into essentially the most attention-grabbing ones.



The brand new subscription mannequin

Google Play Billing System is the principle instrument that lets you monetize your software with subscriptions. Should you’re not aware of this service but, please learn this article. With the most recent model of its library, Google has modified the construction of how subscription merchandise are outlined, and this has led to modifications in how they’re bought in-app and managed in your backend.

With Google Play Billing Library 5.0. Google has launched new subscription structure, which provides such entities as base plans and offers. Let’s have a look.

Let’s say you’ve got a premium subscription in your app and supply your purchasers weekly, month-to-month and annual subscriptions. Earlier than these updates, you’ll have wanted to create three totally different subscriptions – one per interval. Then think about that you just needed to supply a free trial to customers who’ve left your app to steer them to return. So, then you definitely would additionally have to create yet one more annual subscription with a free trial.

These are simply two of the commonest instances, inflicting the creation of plenty of subscriptions with the earlier subscription mannequin – there could possibly be many extra examples.

However to any extent further, you’ll be able to deal with all of those situations with only a single subscription. Google has divided a subscription mannequin into three entities – subscription itself, base plans, and provides.

The brand new subscription entity contains:

  • an identifier
  • title
  • description
  • taxes info

The remainder of the data is ready up by way of base plans and provides.

A base plan comprises:

  • its identifier
  • renewal sort (auto-renewing or pay as you go)
  • length
  • grace interval
  • costs and availability for various areas
  • and a few much less necessary settings

You’ll find the entire checklist of particulars in the official documentation.

A proposal comprises:

  • its identifier
  • eligibility standards – an possibility figuring out which customers can entry this supply (first-time subscribers, those that improve from one other subscription, or developer decided),
  • phases together with free trials and single or recurring funds (phases utilization is proven within the screenshot beneath)
  • and a worth low cost – both mounted quantity or proportion or absolute low cost relying on the bottom plan worth

Subscription phases

Every subscription can comprise a number of base plans, which in flip might comprise a number of provides (see the scheme above). So, for the instance above you’ll be able to create one premium subscription with three base plans – one per interval, and a suggestion with a free trial for the annual base plan.



Buying new subscriptions

Talking of code, in Google Play Billing Library 5.0, the SkuDetails class is deprecated in addition to each different entity or technique containing Sku in its identify. Now it’s best to think about using ProductDetails for that objective. Product particulars comprise details about a subscription, together with its base plans and provides.

Earlier than, you requested subscription particulars like these beneath:

val params = SkuDetailsParams.newBuilder()
    .setType(BillingClient.SkuType.SUBS)
    .setSkusList(listOf("premium"))
    .construct()

billingClient.querySkuDetailsAsync(params) { 
        billingResult, skuDetailsList -> // Course of the consequence
}
Enter fullscreen mode

Exit fullscreen mode

Now, it’s best to do the next:

val productList = listOf(
    QueryProductDetailsParams.Product.newBuilder()
        .setProductType(BillingClient.SkuType.SUBS)
        .setProductId("premium")
        .construct()
)

val params = QueryProductDetailsParams.newBuilder()
    .setProductList(productList)
    .construct()

billingClient.queryProductDetailsAsync(params) {
    billingResult, productDetailsList -> // Course of the consequence
}
Enter fullscreen mode

Exit fullscreen mode

And, for launching the acquisition circulate, you used the next constructions:

val billingFlowParams = BillingFlowParams.newBuilder()
    .setSkuDetails(skuDetails)
    .construct()

val billingResult = billingClient.launchBillingFlow(exercise, billingFlowParams)
Enter fullscreen mode

Exit fullscreen mode

Whereas now they need to seem like those who observe:

// Be aware that `subscriptionOfferDetails` will be null whether it is an in-app product, not a subscription.
val offerToken = productDetails.subscriptionOfferDetails?.get(selectedOfferIndex)?.offerToken ?: return

val productDetailsParamsList = listOf(
    BillingFlowParams.ProductDetailsParams.newBuilder()
        .setProductDetails(productDetails)
        .setOfferToken(offerToken)
        .construct()
)

val billingFlowParams = BillingFlowParams.newBuilder()
    .setProductDetailsParamsList(productDetailsParamsList)

val billingResult = billingClient.launchBillingFlow(exercise, billingFlowParams) 
Enter fullscreen mode

Exit fullscreen mode

You may as well take a look at the migration examples in the Google official migration steps. Be aware, that there are a number of typos of their examples that are mounted right here.

Let’s overview the modifications.

As I discussed, it’s best to now use ProductDetails for querying subscription particulars and buying circulate. As well as, it’s best to present an offerToken to billing circulate params as every ProductDetails might comprise a number of provides. Be aware, that the supply particulars array (productDetails.subscriptionOfferDetails) at all times comprises base plan particulars (if any base plan exists), so even when your subscription comprises solely a base plan with out provides it should nonetheless have offerToken for buy.

You could possibly discover that the brand new buy circulate accepts a number of ProductDetails as a substitute of 1 SkuDetails like within the earlier model. However when you present a couple of ProductDetails, the circulate will find yourself with an error. The official integration guide offers the flawed instance of utilizing the setProductDetails and setOfferToken strategies proper on the BillingFlowParams.Builder class, however there may be solely the setProductDetailsParamsList method available for these functions. It appears as if Google determined to modify from single product particulars to a number of fairly just lately with a imaginative and prescient for the longer term when Billing will help a number of totally different subscription purchases without delay.

The remaining circulate – specifically processing the acquisition – stays the identical as within the Google Play Billing Library 4.0.



Subscriptions backward compatibility

Nicely, every thing sounds good thus far, however what when you don’t need to migrate proper now? Google has taken care of it.

Regardless of Google Play Console already working solely with the brand new subscription mannequin, all of the previous subscriptions are transformed to the brand new format routinely, saving their backward compatibility. Because of this you see your subscriptions within the new format on Google Console however can nonetheless work with them as you probably did earlier than in your app.

Additionally, you will discover that every one the previous subscriptions are made read-only after migration. Google warns you that enhancing will disable InAppProducts API help for that subscription.

Read-only subscription editing warning
You could be utilizing this API in your backend for fetching some product particulars, so watch out – after making the subscription editable you’ll obtain errors (as proven beneath) from that API when you attempt to fetch transformed subscription data. The identical will occur to all new subscriptions created after Might, eleventh.

HTTP code - 422
Non-existent in-app product: com.qonversion.pattern/ProductId{productId=article_test_trial}
Enter fullscreen mode

Exit fullscreen mode

So, when you use InAppProducts API, take into account upgrading it earlier than creating new subscriptions or enhancing previous ones.

Whereas browsing by means of the brand new subscriptions UI in Google Play Console, you will discover “Backwards appropriate” tags close to base plans and provides of subscriptions. Because of this if you buy these subscriptions utilizing deprecated SkuDetails (as you do in Google Play Billing Library 4.0), you’ll purchase precisely these appropriate base plans/provides. If there may be solely a appropriate base plan, with none appropriate supply, then that base plan shall be bought. If there are each appropriate base plan and supply accessible then if the supply is eligible to the present person, will probably be bought, else – base plan. You’ll be able to select one other base plan/supply as backward appropriate if you need.

Choosing backward compatible base plan or offer
Be aware – this Backwards compatibility pertains to Google Play Billing Library however to not InAppProducts API. As talked about, when you start utilizing new options, for instance, a number of base plans or provides for one subscription or simply convert it from read-only to editable, that subscription can nonetheless be Backwards appropriate for an app, however not for API.



The opposite updates

There have been a number of minor updates within the Google Play Billing Library 5.0 that are price briefly mentioning.

  • The strategy queryPurchases deprecated in Google Play Billing Library 4.0 was eliminated – no extra synchronized requests, solely queryPurchasesAsync.
  • launchPriceChangeFlow has been deprecated – the new recommended price change flow requires purchasers’ affirmation by way of the Google Play subscriptions web page, so it’s best to use deep hyperlinks for navigation there as a substitute of calling the BillingClient technique.
  • Added the setIsOfferPersonalized technique to indicate a personalized price for EU purchasers following the Shopper Rights Directive. This feature provides a line to the underside of the Google Billing buy display screen noting {that a} worth is customized.



The brand new subscriptions mannequin and Qonversion

Whereas we’re engaged on Google Play Billing Library 5.0 help, you’ll be able to nonetheless use Qonversion SDK on your in-app purchases. We are actually utilizing Google Play Billing Library 4.0, which implies we will handle solely subscriptions with backward-compatible base plans and provides. You’re nonetheless capable of edit properties that have been accessible within the earlier subscriptions mannequin like a worth, grace interval, trial length, and so forth in addition to create new subscriptions. Simply ensure that after you continue to have at the least one backward appropriate base plan and, if wanted, a backward-compatible supply. And, we nonetheless require a complete subscription identifier for configuring merchandise on our Product Middle, not base plan or supply identifiers.

You probably have any questions, please tell us. We shall be pleased to help you.



Helpful hyperlinks

Add a Comment

Your email address will not be published. Required fields are marked *