I'm writing an app that will support in-app subscriptions. The subscriptions will enable my users to use a number of services and benefits outside the Android world. I know that I can use Google Play Developer API to query the status of a subscription, but due to the nature of the offered services and benefits, it is not very convenient to do that. I was wondering if there is a way to get notified about the status of the subscription when it changes. Something like a web hook for example.
I wanted to post a comment in response to yours, but apparently this was too long. In addition to that, it is also kind of an answer to your question, so I thought this might be a good thing to just post it as an answer instead. Maybe it even solves your problem.
So, regarding your comment. You don't necessarily have to do it that way. Now, I don't know your system requirements, but I'll just share mine and hope it helps you out.
Save Users and Subscriptions on your server (database tables). Have a check_at column on the Subscriptions table, besides a renew_at one. Suppose the user has a monthly subscription created on the 1st of January. On that first day, you call your server from Android after the purchase is finished, save the subscription details, then set renew_at as February 1st and check_at as February 4th, considering you set 3 days as delay for transaction failure in Google Play Developer Console. This way, the user has time from 1st February to 3rd February to change credit card details if the payment fails on the 1st. Then on the 4th you will check the Google Play API for subscription details. But don't disable premium functionality during 1st-4th February. Disable it on the 4th if the subscription was canceled. This way, premium content is not delayed nor tampered with in any way. If the subscription end date returned by the API is in the future, then it was renewed, so you should keep premium activated. Now, how do you check it monthly on the 4th you may ask. Use some kind of scheduler to schedule tasks on the database.
This way you remove the need to rely on webhooks. Although I agree, webhooks would've been more efficient and probably even easier to implement.
Let me know if you have any questions or there are some flaws in the system I described.
Take a look at Real Time Notifications using Google Cloud's PubSub service. It sends notifications of payment/subscription events like: new buy, renewal, cancellation etc. It includes the token which can be used to retrieve additional info from the API like you do now.
You can also configure this PubSub Subscription to call a custom webhook (which still needs to query the PubSub) on each message that you receive.
Related
I am creating an app in which i need to update UI based on Google Play Subscriptions
I have two cases in which i have problem
is user used Free Trial Subscription
Is user used Introductory based Subscription or not
I know it will automatic adjust when user try to payment. But I need this in to update App UI
Google doesn't provide an API for this.
First option: If you're forcing users to sign in, then you can use Firebase RTDB to save the user's subscription/trail data and then you can listen to DB changes and update the UI on data changes.
Second one: You can use a service to track this data like Revenuecat. You can check Period Type from their API. I'm currently using it and it does the job.
Other than that, there's no way to get this information from Google yet.
Currently, I don't think there is a way to get the details of free trial subscriptions as per google play API. So as per your use cases, we can make a workaround it.
We can use purchases.subscriptions.get to get the timestamp when the subscription was taken and once that information is with us we can compare the subscription taken the time and we can compare it with the current time. If that time exceeds the Trial days limit we will know that its a Introductory based Subscription.
One of my Android apps has an in-app item that is essentially a token which people can buy and use at a later time.
I see that some people buy it and then refund it later. While implementing purchases I used the standard guide from Java section of the docs that Google provides on the topic, plus I do verify the purchases on my backend server.
All that said, I'm still not sure that it can't potentially lead to some kind of fraud. Generally speaking, is it possible for the user to buy this "token" use it and then refund it in a matter of few minutes? I didn't look into it yet, but it doesn't seem that Google would bother to send a refund callback to my backend..
Basically, how to handle these things correctly to prevent fraud?
Edit: to be more clear, I do the acknowledgePurchase() and I get valid sales that don't get refunded, not after a while, not ever. I just wonder how is it so happens that from time to time I see a purchase made, then after some time (which differs in length) it does become "refunded" (but not all of them, only some).
Please make sure after purchasing you did BillingClient.acknowledgePurchase() in your app. You can find details about this Here
If your code, when handling a purchase, does not call acknowledgePurchase() and neither call consumeAsync() then the purchase is refunded after a short time period
The only real way to verify the authenticity of a document is by verifying its signature, the same happens with in-app purchases.
A purchase token can be faked but a signature can not.
Look at this : https://stackoverflow.com/a/48531877/7690376
Reading the documentation for subscriptions and related SO questions/answers i am still confused what to do when i have to stop providing the subscription services and content:
https://developer.android.com/google/play/billing/billing_subscriptions.html#cancellation
In all cases, you must continue to offer the content that your
subscribers have purchased through their subscriptions, as long any
user is able to access it.
For example i am offering some content via my server to subscribed users in my app. At one point i am unable to offer that content and i want to cancel all subscriptions?
The users theoretically wont be able to access the content any more and i certainly dont want to charge them for it any longer. The proper use case for me would be to cancel the user subscriptions and refund the remaining money for them. But i am not sure that this is acceptable according to the available information in the docs...i guess that i can do the cancellation and refunds using the google play developer API (still reading the available options) if that will cover the policy requirements somehow?
I am just finding it hard to believe that if a user for ex. rejects app updates and stays on an old app version with an old subscription i have to support him for eternity :) ?
I know what you are suffering the only way around this is communicate to your users to update. Usually this case would mean a FORCE UPDATE so when they open your app they have to update. Your backend has to have a service like that. If user doesn't update they can't use the app. Also I pretty much believe that some subscriptions are auto renewal so that's one the reasons why deleting in the play store is not possible. Also take into account that change price would generate almost the same problem. Since you can't change a price of a subscription at least the base price, the country price you can.
thansk for reading
Context
We provide on-demand video streaming that user can purchase via monthly or yearly subscription on android, ios & web
Thus whenever purchases was made on Android, the app send our server a (purchaseToken, subscriptionID) pair, and we use this google developer API to persists the subscription info in our db
Problem
Recently, we added support for user to change their plan on Android. On Google side, the money is prorated and the new subscription is created. However, the old subscription's start and end time is still the same on the developer API.
We can't say for sure that the old subscription was cancelled and replaced with a new one because the payload (defined here) only tell you above auto-renew status. Plus the cancel reason of 1 is a blanket for anything that's not user-initiated, not just plan change.
I am making a work around, but it requires knowing a few things, like:
When you switch from a more expensive, longer plan (yearly) to a shorter one (monthly), will all the remaining money be prorated, effectively making your new subscription last longer than its normal duration?
which seems likely, based on this:
Google Play cancels the old SKUs and credits the user with the unused value of their subscription time on a pro-rated basis. Google Play applies this credit to the new subscription, and does not begin billing the user for the new subscription until after the credit is used up.
When you cancel the newer subscription, will it happen the same way as cancelling a normal subscription? (i.e, the subscription is not auto renewed, but should stay in effect till the end of its duration), or some credit will be stored with Google to be used later?
However, the old subscription's start and end time is still the same on the developer API.
This seems unexpected and could be a bug.
When you switch from a more expensive, longer plan (yearly) to a shorter one (monthly), will all the remaining money be prorated, effectively making your new subscription last longer than its normal duration?
Yes, the remaining balance of the original subscription is applied to the new subscription. The new billing period will start once that balance is used up. This is best explained in the docs here.
When you cancel the newer subscription, will it happen the same way as cancelling a normal subscription? (i.e, the subscription is not auto renewed, but should stay in effect till the end of its duration), or some credit will be stored with Google to be used later?
I believe what will happen is the subscription will not be auto renewed (as you said), but the subscription will remain active until the balance from the prior subscription is used up.
I've gotten IAB v3 working and I was able to make a purchase for a managed item. However, to continue developing and testing I wanted to refund the purchase so I could try making the same purchase again. I logged into my Google Checkout Merchant account and successfully refunded the purchase. However, the app still thinks that the user has the item purchased. It has already been several weeks since I made the refund so its not a delay issue.
Basically, in my QueryInventoryFinishedListener implementation, inventory.hasPurchase(SKU_REMOVE_ADS) always returns true, even after the refund (SKU_REMOVE_ADS is the SKU for item I'm selling). I was expecting it to return false after the refund had been processed.
If you look at the 'Handling Refunds' section of the IAB reference, it says that your app needs to be listening to the IN_APP_NOTIFY messages. However the documentation for IN_APP_NOTIFY is specific to v2 of in-app billing. It doesn't seem to be something that's available in v3 since its not mentioned anywhere in the v3 reference nor can I find any reference for it in the sample TrivialDrive app that they are using to demonstrate IAB v3.
So does v3 of IAB support refunds/cancelling purchases? Has any one tried it and got it working?
There really is no difference between a consumable item and a non-consumable item so far as Google Play is concerned; this distinction is entirely based on what you implement within your app. So even though the SKU you are testing is intended to be non-consumable (e.g., a permanent premium upgrade), for testing purposes, you can treat it as a consumable and consume it, so that it can be purchased again.
A convenient approach is to set up a temporary testing menu within your app (e.g., by adding a menu item during testing onto your app's main options menu), and then to have that item's handler invoke the consumeAsync() method of your IabHelper instance for the SKU that you want to test buying again. This will consume the item and thus make it immediately available for repurchase from your device.
You will, of course, still want to refund the purchase from Google Checkout, so that you won't be spending your own money just to test your app.
I would add that consumeAsync() also seems to work just fine for resetting the test SKU android.test.purchased, if you are testing using such static values.
Regarding the updating of purchase state to reflect a refund, I have personally experienced (and there are many similar reports posted by other developers) that manually initiating a refund via Checkout (e.g., for a test purchase from the TrivialDrive app) takes days to result in a change to the purchase state of the product (to INAPP_PURCHASE_STATE_REFUNDED).
(Knowing that misery loves company, some of those additional reports can be found on this discussion thread:
https://plus.google.com/+AndroidDevelopers/posts/R8DKwZDsz5m)
At least part of this is due to Google Play's caching of purchase data on the device.
In my experience, re-booting a device can sometimes cause Google Play to refresh its cache from the GP servers. So it may be that changes due to cancellation or refunding of an order via Checkout could also be detected after a reboot.
It might seem that such a long turnaround period would do you no good, since you can't know when users will reboot. But then again, you know that every device will, eventually, get rebooted, and so if your concern is that a user who receives a refund should eventually be blocked from using the refunded IAB product, a few days of delay may not matter much, so long as it eventually happens.
Of course, remember that this notion that cache will refresh on a reboot is undocumented and anecdotal (like quite a number of IAB3 and TrivialDrive behaviors, thus far). Folklore, they call it.
Another thing that triggers an update is when the user attempts to purchase the product. As soon as the purchase is launched, the system has to be sure that the product is not already owned, and so it updates the Google Play cache. In my personal experience, this has always occurred. But again, this is not a very practical way to check for a refund, because that would involve showing the purchase dialog unbidden, and also an error message that tells the user "you already own this, " (if they do own it).
Where this does come in handy is when the user pays for an IAB item on one of her devices, and then attempts to access that item on a different device that is owned by the same account as was used to buy it. The purchase information in that case has very often not yet been cached. But you can just put a little note in your purchase dialog that if the item has already been purchased, attempting a re-purchase should make it available on the present device at no additional charge. Sometimes it takes two (user-initiated) purchase attempts to finally get the IabHelper.BILLING_RESPONSE_RESULT_ITEM_ALREADY_OWNED response. Yes, a bit klugy, but I think in human terms it will work with appropriate highlighting of the message and apologetic wording of the confirmation dialog telling them that they own the item, etc. :-) ).
As a practical matter, you can see how Google might not want every instance of every IAB app in the world to access its servers every time the app's purchase data is being accessed, especially given that they are advising developers to do a check for what has been purchased each time the app is started. It's also a performance issue for your app - that's what caching is all about. So you need to be aware of the triggers for updating the cache, and I haven't found a single place where this is officially documented (except, we presume, in the code). So get ready to put your hands out in front of you and start feeling around in the dark.
For some additional information regarding Google Play buffering, see this page:
Under What Conditions are In-App Billing Version 3 Server Changes Made Available on Client Devices?
I would note that in your post's code snippet you are calling inventory.hasPurchase(SKU_REMOVE_ADS), but that will only tell you if the purchase is in the list of purchases returned in the inventory object; it will not tell you the state of the purchase for that SKU. I know that this is the approach used by the TrivialDrive app, but that app is not dealing with refunds and cancellations. To detect refunds and canceled orders, you'll need something like this:
Purchase removeAdsPurchase = inventory.getPurchase(SKU_REMOVE_ADS);
if(removeAdsPurchase != null) {
int purchaseStateForRemoveAds = removeAdsPurchase.getPurchaseState();
if(purchaseStateForRemoveAds == 1) {
//Do cancelled purchase stuff here
}
else if(purchaseStateForRemoveAds == 2) {
//Do refunded purchase stuff here
}
}
The good news about refunds and canceled orders is that both are, AFAIK, entirely at the option of the developer. So, if you find that users who get these are able to continue using your app for a long interval thereafter, and if you find that lots of users are taking advantage of this, then you can decide if you want to continue providing the refunds in all cases. My best guess is that it will not be a problem; even if some user who gets a refund gets to use your app for a while after that, that doesn't seen like a very big deal.
It is for testing that you need the ability to re-try a purchase very rapidly, and using consumeAsync() definitely works for that purpose.
I will suggest you to use static product ids while your app is in development phase.
Now make sure you are testing the app with same Gmail Id for which you have refund? To test the refund scenario I think you can use android.test.refundedas product id.
If this is not working then you can first check total purchased item(s) and Available item(s) in google play at first launch of your app and if you are getting same product id in both the calls(which should not be the case if this is the case please report this bug to google) then make api call to make same item as consumed.
Since posting this question, its been brought to my attention that I need to call getPurchase(...).getPurchaseState() and check for its value. Possible values are 0 (purchased), 1 (canceled), or 2 (refunded).
However, in my case its still retuning 0 (purhcased) even though the item is refunded. I'm posting this information here in case it helps someone else.