[Feature Request] Ability to Upgrade/Downgrade Subscriptions

[maxsieben]

Feature Request:

I took a quick look at your code and didn't find anything with name "getBuyIntentExtraParams" like it is described in https://developer.android.com/google/play/billing/billing_reference.html#getBuyIntentExtraParams.

Is this correct?

I am asking as I want to provide upgrade and downgrade functionality for subscriptions.

Is it correct, that the only current possibility to up and downgrade Android subscriptions is to let the user manually cancel an old subscription and than let him buy a new one? The problem here would be that already paid money can't be prorated with the new subscription.

[jamesmontemagno]

It does not support this. i haven't ran into that scenario for subs

[muhaym]

@jamesmontemagno @prashantvc Is someone working on this feature? I guess this is important to have, any specific reason that it's not implemented yet?

I could try and implement it and send a PR

Reference:
https://stackoverflow.com/questions/43497934/xamarin-formsandroid-upgrade-and-downgrade-subscriptions

[jamesmontemagno]

Will re-open and change name.

[prashantvc]

I could try and implement it and send a PR

That would be awesome, please send a PR :)

[muhaym]

Before starting to implement, just want to review with @jamesmontemagno

Functionality planned to add
https://developer.android.com/google/play/billing/billing_reference.html#getBuyIntentExtraParams

• Will need to update .aidl file.
• The implementation is specific to Android, under the hood, it is a Bundle with
  • skuToReplace - List, but only one string should be in the list. This is to indicate from which existing sku we are planning to update.
  • replaceSkusProration - bool, if we are giving skuToReplace, whether we should allow proration of existing subscription.

There are other two properties, accountId, where the developer can add some hashed information about the user and vr which I believe not needed in the CrossPlugin scenario.

Now since this is Android only feature, what I am planning is to give these as optional properties in the call
await billing.PurchaseAsync(ProductId, ItemType, Payload,VerifyPurchase,UpgradeParameters);

UpgradeParameters will be a class with properties skutoReplace, replaceSkusProration and accountId.

Sounds okay?

[jamesmontemagno]

The .aidl file is already bound and is included in the library already. This is how I use the core apis.

This seems like it should be a completely different API call since it is only for subscriptions. I would create a new method with only the parameters that you need. This is very Android specific and honestly doesn't make any sense to actually be in the library since it can only be done in Android itself. We could make it an android specific call that is done in the Android library itself.

Perhaps we could expose the VendingLibrary there so you could do whatever you need. I need to think about it more probably. You are free to start initial work on it, but I can't gaurantee I wont ask for changes.

[muhaym]

Current .aidl file doesn't have The getBuyIntentExtraParams() method.
This method is available in version 6 and later of the in-app billing API. So will have to do Is Supported Check before using this or fallback to getBuyIntent.

[jamesmontemagno]

Let me first see if I can upgrade it.

[nexxuno]

Hello @jamesmontemagno @muhaym ,
any progress on this topic since February?

[nexxuno]

I'm working on this, please tell me if you had some progress to share on this one.

[muhaym]

Hey, I haven't started on it because we didn't finalise about .aidl file upgrade.

[mnxamdev]

Does the latest in-app billing plugin allow Android subscription upgrades? Did this ever get worked on? When I purchase a new subscription that is a different tier my account shows two active subscriptions.

[RadoslawKubas]

@mnxamdev I created this implementation today morning, tested in my solution and it seems to be fine, so I hope it will be merged soon.

[mnxamdev]

@mnxamdev I created this implementation today morning, tested in my solution and it seems to be fine, so I hope it will be merged soon.

You're awesome @RadoslawKubas ! I literally was typing that I'd be happy to contribute and was going to ask questions when I saw your status update come into my inbox! ty ty ty!

[RadoslawKubas]

@jamesmontemagno Hello :) Sorry for bother you from time to time and thank you for great plugin, but this is literally the oldest unsolved issue :) from 2017 :) with high chance of solving already 2 times :) First in 2018, now in 2021. :) Please, could you check the #350 pull request and merge if possible, or just provide any feedback? It would be amazing to have this feature included, before solution again become inconsistent with new code changes as it happened with solution from 2018. Please :)