What is the new "Resubscribe" feature found in Billing Library 2.0 and how is it different than the old Billing Library 1.2.2's?

Question

In the Android Developer Console, I saw this message

Resubscribe isn't currently available for your users because your app does not use Billing Library 2.0 in all active APKs

But, I was puzzled. Currently, we are using Billing Library 1.2.2.

This is how we decide, whether to show subscription button to user or not.

• During queryPurchases, We will perform List<Purchase> purchases = PurchasesResult.getPurchasesList(). If the subscription's SKU is not found in purchases, we will show the subscription button. If not, we will hide the subscription button.
• If this is a new subscriber, there will be no SKU in his purchases. Hence, he will see the subscription button, and allowed to subscribe again.
• If this is a previous subscribed, and already cancelled user, we assume there will be no SKU in his purchases too!!! Hence, he will see the subscription button, and allowed to subscribe to the same sku again.

As you can see, even with old Billing Library 1.2.2, we are still allow user to resubscribe to same SKU again, to his previous cancelled subscription.

If that is so, why there is a special feature called "Resubscribe" (https://developer.android.com/google/play/billing/subs#resubscribe) in Billing Library 2.0? How does it different from our current Billing Library 1.2.2 flow?

Answer 1

To be perfectly honest, there isn't any enormous difference between resubscribing to the same sku with old and new approach using the resubscribe feature. Why? (None of these are solidly tested by the way, this is a logical explanation.)

1. In both cases, the subscription elements will stay the same and they will both return in queryPurchases method as long as the subscription is active.
2. This relates to the queryPurchases method, I haven't tested this yet, but it is possible that, in the old way, multiple purchases with the same sku might return, which may create a confusion. After resubscribing while canceled subscription is still active, the queryPurchases method will return only 1 subscription, causing queryPurchaseHistoryAsync method to return nothing. In the old way, if queryPurchases method returns only 1 purchase after getting a subscription over a canceled subscription with same sku, queryPurchaseHistoryAsync might actually return the old subscription that was canceled for, even if it was still active in a canceled state.
3. On Google Play Developer API side, there is a method that links a purchase token to the older one. For this, the Purchase.getLinkedPurchaseToken() function might return different values after subscribing to same sku, between the old way and new way. I presume, resubscribing to an active canceled subscription with the old way will generate a new purchase token, and getLinkedPurchaseToken(). This does not affect the BillingClient itself since there is no getLinkedPurchaseToken() method but logically this should be the result.

Bottom line: The only difference I can say is that resubscribing with the new way might reduce confusions, while on the old way there might be unnecessary data that you want to avoid from. As long as you have a subscription that's returned from queryPurchases where it matches your sku, you can consider that the user has an active subscription.

Answer 2

https://developer.android.com/google/play/billing/subs#resubscribe

Users can resubscribe in a number of different scenarios:

• Before the subscription has expired, users can repurchase the same subscription in your app. This generates a new subscription and purchase token.
• Before the subscription has expired, users can restore the subscription in the Google Play subscriptions center. This keeps the same subscription and purchase token.
• After the subscription has expired, users can also repurchase the same SKU up to 1 year after expiration through the Google Play subscriptions center. This generates a new subscription and purchase token.

More details are provided in the release notes of 2.0 here: https://developer.android.com/google/play/billing/release-notes

I think the API is for subscriptions made outside your app (for example, from Google Play Subscriptions Center (mentioned in bullet point 3), or at a physical store).

Based on your question, it seems that you already handle the other scenarios regarding a user not having a subscription or having cancelled their subscription - but these flows apply to within the app, not outside. To gracefully handle purchases made outside the app you must use 2.x or higher.

The ability to process subscriptions outside the app, such as Google Play subscription Center or a physical store is not available in 1.x. It is available from 2.x+

Answer 3

Presuming you don't confuse the flow of subscriptions , that will remain as it is. Additional features have been added to Google play billing . As we talk , Google play billing 3.0 is up and ready. Follow this link

https://developer.android.com/google/play/billing/release-notes#3-0-0-summary-changes

Resubscribe feature will make restoring subscriptions easier.

There are scenarios where managing subscription should be made easy .

Subscription Restore and Resubscribe

Lets assume a user for some reason cancels the subscription renewals and before the subscription is expired and wants to subscribe it again. Now if user wants to resume it again. This newly feature will allow to resume the subscription as if they were never cancelled. For this the condition is that the subscription must not have expired . If it has expired , then here it is . Users will have to resubscribe instead. To resume any paused subscription users will need to resubscribe , you will have to treat this as you have been treating it.

Account hold feature

A user subscribes and sometimes users are unable to pay their subscription, whether due to financial woes or an expired credit card. In these cases, developers can initiate an Account Hold instead of cancelling it . This will allow users to manage the subscriptions until they fix the payment at their end.

Developers with existing apps will need to integrate Account Hold and Subscription Restore by November 1st. Unless they opt out, they’ll also need to integrate Subscription Pause and Resubscribe. If they fail to do so by the deadline, future updates may be rejected, thus delaying the launch of new features, bug fixes and metadata.