I'm stuck with Google In App v3 - I tested a purchase without consumption (e.g. when app crashes between buying and consuming) - now I don't find a way out.
If I try to buy again, it says 'you already own that item'. But when I test for ownership, it says I don't own it:
Inventory inv = mHelper.queryInventory(false, null);
inv.getPurchase(sku); // null
inv.hasPurchase(sku); // false
I can't consume something either, as I don't have a purchase to consume. How to proceed here?
EDIT
Reproduce it like the following: purchase in-app consumable, then disable internet connection. After that, you're not able to purchase the product again for some hours. Just tested with a popular app from the play store (Diamond Digger Saga), I had the exact same behaviour. Is there really no possibility to avoid/solve this?
I ran into this exact problem. I had two Google accounts on the phone, one which was the developer account (which I foolishly used my personal account for) and another which was the test account I registered in the developer console. I had removed and re-added the developer account from my accounts on the phone, which allowed me to make test-purchases from my app, thinking if the developer account was the second on this list it would use the first for purchases.
Alas, after a couple of runs of the app I ran into your issue. I gave up trying to have both and removed the developer account from my phone. While incredibly inconvenient, this got rid of this problem and allowed me to test purchase, consume, query, etc.
If you are doing everything correctly and your code is ok - most likely the problem is in cached Google Play Services data.
For example when you make a test purchase on your device A - on your device B (with the same Google account logged in) you will keep receiving inventory without your purchase for some time. And your inventory.getPurchase(sku) will return null and inventory.hasPurchase(sku) will return false;
To fix this try to open Google Play and close it using Recent Apps button (click it and then swipe the app away) this will terminate the app faster than usual "back" button. Then turn your device off for couple of minutes.
Our goal here is to make Google Play to update it's cache.
Be sure that you're on wifi because it may update rarely if you're on mobile data.
Eventually data will be updated and you will get your purchase.
In my case it happened after 5 minutes or smth.
Related
I'm developing a react-native app that targets Android TV and tvOS. Using react-native-iap I've have successfully added support for Google Play inapp products and latest subscription model (billing API 5.0.0).
Purchase updates are received and handled perfectly well in all test scenarious except when I'm testing the "More payment options" flow, which expects the user to continue the purchase flow an another device. In this scenario the user is able to pick up the purchase flow from a desktop browser, or on an Android mobile device, and then choose to pay with "Slow test card approved after a few minutes". However, after completing the payment I can't see that we ever receive updates on PurchasesUpdatedListener. Calling RNiap.getAvailablePurchases() (equivalent to BillingClient.queryPurchasesAsync()) also returns an empty list!
Has anybody come across this issue before? Is it a development environment problem or does it happen for real/end users as well?
Worth mentioning is that meanwhile the "slow card payment" is being processed I'm also exiting the purchase UI on Android TV (by pressing back button), in order to re-activate the app so it can check for purchase updates.
I was able to reproduce this problem with Google's sample app TrivialDriver, https://github.com/android/play-billing-samples/tree/main/TrivialDriveKotlin, so I don't think there's an issue with react-native-iap.
Thanks!
I have an Android app and I also offer 1 inapp purchase to unlock such app to the Pro version.
I know how to do use the inapp purchase API and such but I found discordant ways on how to check if the app should start as Free or Pro.
Many people suggest that after a successful purchase the app should store the Google Play receipt or other information in a local database and let the app check the presence of that information at startup (in order to start properly as Free or Pro)
My question is, instead of bothering saving the purchase information and retrieving it from a local database why not calling the restore purchase API RestorePurchases(), have a look at the returned object if the InApp item is present and unlock the app accordingly?
As far as I know the call doesn't require internet connection, it's just a local call to the local Google Play authority... am I missing something?
Let me explain how we manage it at QuitNow!, an app with the same behavior than yours.
We only have one SKU called unlock_all_pro_features. If the user has it, it means that the user bought the PRO features before.
So, in the Android side, everytime the app is started we try connecting to IInAppBillingService. When onServiceConnected() is called, we ask it for all the user owned SKU's. If it has our lovely SKU, we store in a SharedPreference that the user was a PRO one. And then, if it wasn't PRO before doing all this magic, we update the screen to show the brand new features.
Bad things there: the user can return the SKU!
To face that, when we consider that a user was a PRO one, we also ask if the user has the needed SKU. If that check fails 20 times, we reset the features to the FREE version.
Why checking it 20 times instead of just one time? Sometimes, we found that the service said that the user had any SKU, while he actually had the PRO one. Why? Don't know. So, checking it 20 times is a simple way to assure that we don't kick PRO users when unneded.
With version 3 of the Billing API, Google has removed the distinction between consumable and non-consumable products. Both have been combined into a new type called "managed" and behave somewhat like a hybrid: Your app needs to actively call a method to "consume" the items. If that is never done for a set of skus, those items basically behave as if they were non-consumable.
The documentation describes the intended purchase flow as follows:
Launch a purchase flow with a getBuyIntent call.
Get a response Bundle from Google Play indicating if the purchase completed successfully.
If the purchase was successful, consume the purchase by making a consumePurchase call.
Get a response code from Google Play indicating if the consumption completed successfully.
If the consumption was successful, provision the product in your application.
I see two problems with this approach. One is fairly obvious and more a "bug" in the documentation than the API, but the other is rather subtle and I still haven't figured out how to best handle it. Let's start with the obvious one for completeness:
Problem 1: Lost purchases on single device:
The docs say that an app should call getPurchases every time it is launched to "check if the user owns any outstanding consumable in-app products". If so, the app should consume these and provision the associated item. This covers the case where the purchase flow is interrupted after the purchase is completed, but before the item is consumed (i.e. around step 2).
But what if the purchase flow is interrupted between step 4 and 5? I.e. the app has successfully consumed the purchase but it got killed (phone call came in and there wasn't enough memory around, battery died, crash, whatever) before it had a chance to provision the product to the user. In such a case, the purchase will no longer be included in getPurchases and basically the user never receives what he paid for (insert angry support email and one-star review here)...
Luckily this problem is fairly easy to fix by introducing a "journal" (like in a file system) to change the purchase flow to something more like this (Steps 1 and 2 same as above):
If the purchase was successful, make entry into journal saying "increase coins from 300 to 400 once purchase <order-id here> is successfully consumed."
After journal entry is confirmed, consume the purchase by making a consumePurchase call.
Get a response code from Google Play indicating if the consumption completed successfully.
If the consumption was successful, provision the product in your application.
When provisioning is confirmed, change journal entry to "purchase <order-id here> completed".
Then, every time the app starts, it shouldn't just check getPurchases, but also the journal. If there is an entry there for an incomplete purchase that wasn't reported by getPurchases, continue at step 6. If a later getPurchase should ever return that order ID as owned again (e.g. if the consumption failed after all), simply ignore the transaction if the journal lists this order ID as complete.
This should fix problem 1, but please do let me know if you find any flaws in this approach.
Problem 2: Issues when multiple devices are involved:
Let's say a user owns two devices (a phone and a tablet, for example) with the same account on both.
He (or she - to be implied from now on) could try to purchase more coins on his phone and the app could get killed after the purchase completed, but before it is consumed. Now, if he opens the app on his tablet next, getPurchases will report the product as owned.
The app on the tablet will have to assume that the purchase was initiated there and that it died before the journal entry was created, so it will create the journal entry, consume the product, and provision the coins.
If the phone app died before it had a chance to make the journal entry, the coins will never be provisioned on the phone (insert angry support email and one-star review here). And if the phone app died after the journal entry was created, the coins will also be provisioned on the phone, basically giving the user a purchase for free on the tablet (insert lost revenue here).
One way around this is to add some unique install or device ID as a payload to the purchase to check whether the purchase was meant for this device. Then, the tablet can simply ignore the purchase and only the phone will ever credit the coins and consume the item.
BUT: Since the sku is still in the user's possession at this point, the Play Store will not allow the user to buy another copy, so basically, until the user launches the app again on his phone to complete the pending transaction, he will not be able to purchase any more virtual coins on the tablet (insert angry support email, one-star review, and lost revenue here).
Is there an elegant way to handle this scenario? The only solutions I can think of are:
Show a message to the user to please launch the app on the other device first (yuck!)
or add multiple skus for the same consumable item (should work, but still yuck!)
Is there a better way? Or am I maybe just fundamentally misunderstanding something and there really is no issue here? (I realize that the chances of this problem ever coming up are slim, but with a large enough user-base, "unlikely" eventually becomes "all-the-time".)
Here's the simplest way to fix all this, that I have come up with so far. It's not the most elegant approach, but at least it should work:
Generate a globally unique purchase ID and store it locally on the device.
Launch a purchase flow with getBuyIntent with the purchase ID as the developer payload.
Get a response Bundle from Google Play indicating if the purchase completed successfully.
If purchase was successful, provision the product and remember the purchase ID as completed (this must be done atomically).
If the provisioning was successful, consume the purchase by making a consumePurchase call(I do this in a "fire-and-forget" manner).
Every time the app is launched, go through the following:
Send a getPurchases request to query the owned in-app products for the user.
If any consumable products are found, check if the purchase ID in the developer payload is stored on the device. If not, ignore the product.
For products with a "local" purchase ID, check if the purchase ID is included in the completed-list. If not, continue at step 4 above, otherwise continue at step 5 above.
Here's how things can go wrong on a single device and what happens then:
If the purchase never starts or doesn't complete, the user doesn't get charged and the app goes back to the pre-purchase-state and the user can try again. The unused purchase ID still is in the "local"-list, but that should only be a fairly minor "memory-leak" that can be fixed with some expiration-logic.
If the purchase completes, but the app dies before step 4, when it gets restarted, it finds the pending purchase (the product is still reported as owned) and can continue with step 4.
If the app dies after step 4 but before the product is consumed, the app finds the pending purchase on restart, but knows to ignore it as the purchase ID is in the completed-list. The app simply continues with step 5.
In the multiple-device-case, any other device will simply ignore any non-local pending purchases (consumables reported as owned) as the purchase ID is not in that device's local list.
The one issue is that a pending purchase will prevent other devices from being able to start a parallel purchase for the same product. So, if a user has an incomplete transaction stuck somewhere between step 2 and 5 (i.e. after purchase completion, but before consumption completion) on his phone, he won't be able to do any more purchases of the same product on his tablet until the app completes step 5, i.e. consumes the product, on the phone.
This issue can be resolved very easily (but not elegantly) by adding multiple copies (5 maybe?) of each consumable SKU to Google Play and changing step 2 in the first list to:
Launch a purchase flow for the next available SKU in the set with getBuyIntent with the purchase ID as the developer payload.
A note on hackability (in order of increasing difficulty for the hacker):
Completing fake purchases via Freedom APK or similar:These apps basically impersonate the Google Play Store to complete the purchase. To detect them, one needs to verify the signature included in the purchase receipt and reject purchases that fail the check, which most apps don't do (right). Problem solved in most cases (see point 4).
Increasing in-app account balance of consumable via Game Killer or similar:These apps will try to figure out where in memory (or local storage) your app stores the current number of coins or other consumable products to modify the number directly. To make this harder (i.e. impossible for the average user), one needs to come up with a way to store the account balance not as a "plain-text" integer, but in some encrypted way or along with some checksums. Problem solved in most cases (see point 4).
Killing the app at the right time and messing with its local storage: If someone purchases a consumable product on their phone and manages to kill the app after the product has been provisioned but before it has been consumed (likely very difficult to force), they could then modify the local storage on their tablet to add the purchase ID to the local list to have the product awarded once on each device. Or, they could corrupt the list of completed purchase IDs on the phone and restart the app to get the award twice. If they again manage to kill the app after provisioning but before consumption of the product (easy now by simply setting the phone to airplane mode and deleting the Google Play Store Cache), they can keep stealing more and more product in this way. Again, obfuscating or checksumming the storage can make this much harder.
Decompiling and developing a patch for the app:This approach, of course, allows the hacker to pretty much do anything they want with your app (including breaking any countermeasures taken to alleviate points 1 and 2) and it will be extremely hard to prevent entirely. But it can be made harder for the hacker by using code obfuscation (ProGuard) and overly complex logic for the critical purchase-management code (might lead to buggy code, though, so this is not necessarily the best idea). Also, the code can be written in a way that its logic can be modified without affecting its function to allow for regular deployment of alternate versions that break any available patches.
Overall, signature verification for the purchases and some relatively simple but non-obvious checksumming or signing of the relevant data (in memory and in the local storage) should be sufficient to force a hacker to decompile (or otherwise reverse-engineer) the app in order to steal product. Unless the app gets hugely popular this should be a sufficient deterrent. Flexible logic in the code combined with somewhat frequent updates that break any developed patches can keep the app a moving target for hackers.
Keep in mind that I might be forgetting some other hacks. Please comment if you know of one.
Conclusion:
Overall, this is not the cleanest solution as one needs to maintain multiple parallel SKUs for each consumable product, but so far I haven't come up with a better one that actually fixes the issues.
So, please do share any other ideas you might have. +1`s guaranteed for any good pointers. :)
First of all I want to say I agree with everything you wrote. The problem exists and I would try to solve it similarly to how you did it. I would really suggest to find someone from Google Play relation team and make them aware of it.
Now back to your solution. This is probably the best standalone solution involving no server I could think about. It's simple but fairly good. One place where it can be misused would be when attackers would fake journal file and "buy" whatever they want, because getPurchases won't return anything from a manipulated journal file.
Otherwise, what else I would try to do is to reduce a probability the app gets killed by the system. For that you might extract purchasing and consumption logic into a smaller foreground service running in a separate process. This will increase probability the service finishes its work, even when Android will kill the bigger game application. More complex, but also a more reliable solution would be to implement journal on the server and share it between devices. With this solution you can always check whether someone is cheating with the purchases and even solve the issue when multiple devices are involved.
Some people trying to do in-app purchase within my Android game report that they can never complete the purchase -- that they always get an error message. (I.e., The market app reports an error to my application, and I show the user this error.)
Unfortunately, I don't have any real log data for this one, because it only happens for certain customers of my game, not for me.
What's strange is that after updating to a new version of the app, for some users the problem goes away, and for some users the problem starts. So user A might have the problem in version 1 of the app, but it clears up when they update to version 2. User B might not have the problem in version 1, but it appears when they update to version 2.
I say "intermittent" above, but by that I mean that it only seems to affect a small number of users. But for any given user, once they get in this state, they seem to get the message all the time. HOWEVER, I have had some cases where the problem does clear up suddenly, without an app update. I'm not sure if, for instance, power cycling, or, say, making an in-app-purchase in another app is away to "break out" of this state.
I realize that without a specific error message or API call to name/blame, this question is difficult to answer. I'm just trying to understand if this pattern -- of some users mysteriously getting stuck in a state where they are unable to make any in-app-purchase within a given app -- sounds familiar to anyone for Google Play in-app-purchase.
Also, I build my apps on top of Marmalade, so it's possible that the problem is in the Marmalade layer, not in my app or in the Google Play market itself.
The same problem here: a lot of users can buy items in my app but some users send me emails complaining why they can't buy considering that they can successful purchase items in other apps. I think it occurs because of a temporary problem on the Google Play server or is something to do with the service on Android. I am still looking for an answer to this weird problem...
I have an app that uses in-app purchasses. I have integrated all the code from the Dungeons example except for the UI components. I have submitted my draft apk, activated it, created my in-app purchases, all of which are managed, and published them.
I am successfully able to purchase my in-app items and unlock the corresponding content without issue. The problem I am running into is that whenever I call to restore transactions, I get back the error code RESULT_SERVICE_UNAVAILABLE. I know that the result code means that the app can't access the store, but that makes no sense seeing as I can purchase items just fine.
I am running on an HTC Nexus One with Android v2.3.6 and Google Play v3.5.16. I am connecting over WiFi because there is no data plan for the device. The apk installed is exactly the same as the draft apk submitted. I am installing the apk via adb -d install command.
Any suggestions of what might cause this or where to look would be greatly appreciated.
Thanks
if you find similar message in the log:
05-30 09:28:23.760: E/Volley(4636): [13] BasicNetwork.performRequest: Unexpected response code 429 for https://android.clients.google.com/vending/api/ApiRequest
it can mean that you've send too much RESTORE_TRANSACTIONS request in certain amount of time. Google has clearly some throttling on request. It happened to me during testing in-app billing, approx. 20-30 restore transactions request went ok, and then - exactly the same problem - service unavailable response.
Check logcat output, maybe there are some warnings there. Other than that, not 100% sure that RESTORE_TRANSACTIONS works with unpublished apps and test accounts. Maybe 'service unavailable' simply means 'not supported' in this case?
I had this same problem, and it turned out that the password on the primary gmail account on the device was wrong. So when I checked if billing was supported, I got RESULT_OK, but for restore purchases, I got RESULT_SERVICE_UNAVAILABLE.
Go into your gmail or any google apps and refresh. Double check that the account password is correct and try again.
This problem also shows up in logcat as
NotifyingErrorListener.onErrorResponse: Server error on InAppPurchaseInformationRequest: com.android.AuthFailureError: User needs to (re)enter credentials
This does mean that you've done too many RESTORE_TRANSACTIONS and the service won't be available for X number of days unfortunately, as I hit the same issue.
BUT... It is device specific, so if you start testing again on another device or factory reset your device, you should be able to avoid it.