Google Play Billing Library: Determine base plan / expiry of subscription purchase

Question

I am using the Google Play Billing Library 5 and have a subscription product with different base plans.

When processing the purchases in the PurchasesUpdatedListener or in the callback of queryPurchasesAsync, I receive a list of Purchase objects which contain inter alia the product IDs, purchase time and whether it's auto-renewing.

But how do I know which base plan was selected by the user, and when it expires?

The PurchaseHistoryRecord returned from queryPurchaseHistoryAsync also seems not to contain this info.

I know the Play Developer API returns the expiry time with purchases.subscriptionsv2.get, but is the inconvenience of using the API directly necessary?

Popgun

Initially I also found this confusing/surprising/annoying, until I realised that (a) I already know what base plan the user selected (because I initiated the purchase workflow for that base plan) and therefore I still know what it is when the purchase workflow ends; and (b) anyway once the purchase is made I don't really need to know what base plan was selected because all base plans under the same subscription product unlock the same functionality... and that's all I really need to know. – Gilburt

@drmrbrewer: On (a): I don't have that info anymore when I must restore the purchase when the user opens/installs the app on another device or reinstalls / clears app data. On (b): how do I know when I have to check if the subscription is still valid (I could simply do this every day or so, but maybe the user doesn't connect to the internet for a longer time...) – Popgun

I use this API: developers.google.com/android-publisher/api-ref/rest/v3/…... using the token you got from purchase.getPurchaseToken()... the response from the API tells you if the subscription is still active: developers.google.com/android-publisher/api-ref/rest/v3/… – Gilburt

yes, this seems the only way apart from managing my own subscription database on a server. – Popgun

There are other scenarios where this info is needed - we wish to enable our users to SWITCH between base plans - like "Monthly" and "Yearly" plans of same subscription. To enable this we must know which base plan is currently owned. In the old Billing lib we had separate Subs for each duartion, but at least we could traverse HORIZONTALLY by prorating between known subs, as in 3rd scenario here: developer.android.com/google/play/billing/… – Succentor

Answer 1

The conclusion I am coming to is that it is best to ignore the whole multiple base plans feature.

Create the subscriptions individually instead so you have Silver_Plan_Monthly --> Silver_Monthly_Base --> Silver_monthly_free_trial_offer. Then a separate subscription. Silver_Plan_Yearly --> Silver_Yearly_Base --> Silver_yearly_free_trial_offer. And so on for however many subscription levels you want Silver, Gold, Platinum etc.

This way when you get the users purchases you can immediately tell what sub/level/renewal period they bought by the productId which will be the subscription name (Silver_Plan_Monthly).

This is annoying in having to create all these subs but the billing library doesn't give enough info otherwise.

And you should be able to now easily upgrade/downgrade user between these levels and the billing periods.

Overalls

Thank you for this suggestion @mbwasi, however for renewed subscription, how do you know if the user didn't cancel in between when you check after the expiration date you set yourself based on the applied plan? If user took 30 days subscription, I manually set expiration to "today + 1 month" => at the end of that month, from server I wanna check if user hasn't canceled still, but just like you couldn't get expiration date from base plans, we also cannot get isCanceled on that either right? – Law

@Law You have to implement Real Time Developer Notifications which will send your backend a notification every time something changes with a users subscription then you call the Play Developer Api (From your BE) to get the state of the subscription. I don't think it can be done on the client side only. – Overalls