I'm not specifically looking to have the option to refund a user for an in app purchase of a consumable, but just in the odd case that a user asks for a refund, either through google, or through the developer of an in app purchase of a consumable.
There does not seem any way of handling refunds through the In App Billing api V3. All documentation points to V2 of the api using broadcast receivers. This does not help me in least bit.
So how are refunds handled in the In App Billing v3 api? I'm assuming for a non consumable, the refund is processed, and then google handles the processing through their backend, and then when a getPurchaseState() is conducted, it would return a value of 2 (refunded). If so, this works great for a NON CONSUMABLE product.
When a getPurchaseState() call to a consumable purchase is made, it returns null. That's assuming if the purchase was previously successful, and that the item was consumed and provisioned. I figure I could store the purchase items locally within the app, but then there is still no way of receiving a refund notification for that product. I can check for purchase state, but again, it will return null, as long as it was consumed and provisioned already.
A slight workaround I can think of right now, is to not consume the purchase on provisioning. So that it remains "unconsumed" according to google, and remains in their database. Now, if a refund is requested, I am assuming a call to getPurchaseState() for that consumable will return refunded, thus the application logic can then subtract/deduct the provisioned consumable from user's inventory. If a user would want to repurchase that consumable again, then before the IAB api call is made for the purchase, get the purchaseState() and/or hasPurchase(), and if there is already a purchase there, consume that item without provisioning, this will let the user repurchase that consumable. Only issue with this workaround, is that if A user wants to re purchase the same consumable product, as soon as the select the option to repurchase, the item must be consumed regardless of whether they successfully repurchase the product or not. So if the user does not complete the purchase, the product is already consumed, and I end up back where I am now with inability to check for refund state on the consumable.
I can't think of any other way to do a refund for a consumable in app product, and that is what I ask here. Is the way I thought of sufficient, or is there a proper way to handle refunds using IAP v3 on consumables?
I was thinking I have 3 options:
Don't offer refunds for consumables, no/little exceptions, but the issue with this is if a user requests refund through google, and not through developer, leading to option 3 below)
Find a workaround (either properly through the api, or with my proposed workaround)
Offer refunds, but have no application logic to subtract/deduct the consumable. In this scenario, users could end up taking advantage of free purchases.
I know this is a super late response to this issue, but it took me quite some time to track down info on this issue, so hopefully it can help someone else out. There are a few ways of doing this... In the Google Play Developer console you can click on the left nav saying "Order Management" which will bring up a list of all recent orders though your app. If you need to refund one you can click on it, or multi select them and refund them in this view. Just a heads up... you will most likely need permissions from your account admin to see this view and refund users.
Your other option is though the API docs here. You will need to set up your API account though the Android console, which I will say is a massive pain and not clear. But once that's set up and your "Server Applications" is set up you will need to make sure it has proper permissions as well. Then you should be able to use a library such as this to do the heavy lifting for you, because from what I've read the JWT auth process though the google API is not super straightforward, and their docs are a mess. I hope this helps someone and comment if you have questions... I will do my best to answer.
This same API also can be used to find items that were purchased by users and then refunded, so you can remove these items from those users' apps. Also you can do server side purchase validation through this as well, which is highly recommended, because rooted phones can inject fake purchase requests making your app believe that it's hearing back from the google play store, but in reality it's not. You then send back to your server the purchase token and SKU of the item being purchased and then on your server you just run this. This will give you back a 400 error if it's invalid, and a 200 with a some JSON data if it's a successful purchase.
Related
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
Most of our purchases keep getting canceled after 3 days 30 minutes exactly, which I presume is the result of pending purchase state. However, there is so little documentation about how to handle pending purchases exactly. And, for some reason, even though I am a tester myself, I cannot test it because there is no "Slow card" option on purchase methods. Also, we do not have a backend server to well, back us up.
This is the explanation I've found from the official documentation:
void handlePurchase(Purchase purchase) {
if (purchase.getPurchaseState() == PurchaseState.PURCHASED) {
// Acknowledge purchase and grant the item to the user
} else if (purchase.getPurchaseState() == PurchaseState.PENDING) {
// Here you can confirm to the user that they've started the pending
// purchase, and to complete it, they should follow instructions that
// are given to them. You can also choose to remind the user in the
// future to complete the purchase if you detect that it is still
// pending.
}
}
Look at the explanation on the PENDING state. What does "To complete the purchase, they should follow instructions that are given to them" mean? What are these instructions exactly? Do we need to redirect the user to Google Play or what? It is not specific about what to do and is bugging me out because purchases are getting cancelled for no reason, or for this reason. How does one complete a pending purchase? There is nothing about it, or I cannot find it, hence I ended up here.
I hope you can help me figure this out. Thanks.
I agree the documentation is poor, especially since the one time you want to know exactly what's happening is when you're handling other people's money!
It looks like a 'slow card' transaction is actually a 'pending purchase', something Google have been rolling out in 2019. Here's the probable flow...
In your app the user taps 'Buy now'
They see the Google checkout overlay
They choose "Pay at Freddina's Grocery, Accra" (a local store that's signed up to deal with Google pending purchases)
Google checkout displays a code to show to Freddina
User pays Freddina in cash and Freddina processes the payment using that code
10 mins or so later, the purchase update will land in your app
As for handling unpredictably timed update events, we have an app with a handlePurchaseUpdated method listening out from the moment the app starts, and makes changes based on the Purchase object that comes with it. Here's an example flow:
We listen for purchase updates as soon as the app starts up
User makes a slow purchase
We get a purchase update
The passed Purchase object has purchase state PENDING
We tell the user that we'll notify them when the purchase is complete
At some point in the future (e.g. next day after an app restart) the purchase update comes in
If the purchase state is now PURCHASED we finalise the purchase and tell the user
Note: Ours is a ReactNative app, not native java, but the flow should be the same.
It's complicated to implement because you have to pick your time to make your purchase changes and display the purchase result at a time that makes sense, not necessarily when the purchase update arrives 5 secs after startup (or any other weird time). And it gets more complicated if there are errors during your grant-entitlement or acknowledgement steps, urgh.
Also, you might not be seeing the 'slow card' tester option because you didn't allow it?
Update for 2022: Personally I feel the documentation is still so poor, and the complexity so great, that I would recommend using a service like IAPHUB to manage iaps and subscriptions.
It sounds like you are not acknowledging the purchase. See below from the Google Play Billing documentation:
If you use the Google Play Billing Library version 2.0 or newer, you must acknowledge all purchases within three days. Failure to properly acknowledge purchases results in those purchases being refunded.
According to Google's documentation (https://developer.android.com/google/play/billing/integrate#pending), you need to call enablePendingPurchases() and then your PurchasesUpdatedListener will be notified when the state changes from PENDING to PURCHASED.
i offer 1 in app purchase (full functionality). I save the result of the purchase in a boolean variable in sharedpreference and also use queryPurchases on app start, so if someone deleted and reinstalled the app, he gets his full functionality back.
That works properly, but i also would like to block full functionality, if it turns out, that someone did NOT purchase the full functionality (and cheated the app with a rooted device). That would also include deleting some data that he is not supposed to have without the in app purchase.
However, i am confused about the description of queryPurchases. It says
"Upon a successful purchase, Google Play's In-app Billing service caches the user's purchase data locally."
How long does it store that information? Does it update it automatically if an internet connection is available? How can i avoid getting no purchase even though the user bought the in app purchase and falsely blocking his full functionality? What is there
Is there a way to get the clear information, that the user in fact did NOT purchase a certain item, rather than just no information about a possible purchase? I really want to avoid blocking features if the user paid.
Anything else wrong with my approach (Saving the purchase in sharedpreferences
to have the information available immediatly and additionaly query purchase)
Edit: I also noticed, that if i refund an in app purchase, de- and reinstall the app, queryPurchases still finds that purchase. There must a way to avoid that?
Don't bother storing purchases in shared preferences. They are already on the device via the billing library. The purchases are stored in the Play store data which the billing library retrieves for you.
You can work by assuming that full functionality is enabled until you receive the result of query purchases which will tell you definitively whether the user has bought it or not. If you prefer, you can do that backwards and assume trial mode until you know a purchase exists.
Either way, the query for purchases will return quickly as no network connection is required because billing library simply connects to play store on the device for the data.
If you refund in the developer console, it may take a while for that to filter to the users device but it will eventually. It isn't a real time system and a purchase will remain cached on the device until the refund is fully processed and sent to the users device.
You can consume a purchase directly on a device which removes it instantly from the user account.
I have working app that sells in-app products (InApp billing v3).
Recently I've made an update for this app and made a terrible mistake there: I consumed some of purchases I didn't want to consume.
I issued an update and users updated the app and then wrote me they have no purchased access. (As I found later, I consumed wrong items).
So I have some questions now:
Is there a way to restore consumed purchases or I should return payments to my users?
Is there a way to find out how many and which purchases were consumed?
If returning payments, is there a way to find out if user still has the product or is it consumed with out changing the app (through google services)?
Thanks.
According to what I have understood from your question, It seems like you want to purchase product only once.
What I wished to ask: is there a way to request information about consumed products like about owned products.
you can get response or it's information in any type(Managed Product, Unmanaged Product, Subscription) in the onActivityResult method() check my below link.
In-app billing-v3 error in activity result
but I would not prefer you to manage it customly as you told for one time purchase product(not consumable product). You should go with the Manage product.
Managed In-app Products:
Managed in-app products are items that have their ownership
information tracked and managed by Google Play. When a user purchases
a managed in-app item, Google Play stores the purchase information for
each item on a per-user basis. This enables you to later query Google
Play at any time to restore the state of the items a specific user has
purchased. This information is persistent on the Google Play servers
even if the user uninstalls the application or if they change devices.
for more information about product type
you can query any time you want and you will get the product information, and even you don't need to manage if user has already purchase this product or not.
Is there a way to restore cnsumed purchases or I should return payments to my users?
Better option is you should give the payments back to the user and for the next time check the whole app once using dummy product "android.test.purchased" and update your app.
Is there a wat to find out how many and which purchases were consumed?
You have to check in the Google wallet because all transaction should be handle by the it, check if it gives you product type or not. Using your google developer console credential you can signed into google wallet.
If returning payments is there a way to find out if user stil has the product or is it consumed with out changing the app (through google services)?
as per above answer you have to check in google wallet, according to my knowledge they are provide us all of information about product type with user detail.
Let me know if I have not properly understood your question.
Hope it will solve your problem.
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.