[Closed] [IAP] - How to test retrieving purchases in Google Play?

(I think this is the right forum for this)

Hi! I'm working on an Android game using the lastest Unity version and I'd like some help on literally the last step before I can take my apk to production state and publish my game.

My game offers the player the choice to purchase items (coins), so I'd like to include the option for said purchases to be retained if the player installs the game on a different device, or decides to uninstall and install it back after a while -that means, if he ever bought, say, 100 coins, the moment he installs the game back, I'd like him to have said coins again in his new game... and if he buys the same item twice, start with 200, etc-

> Here < I read the following:

On platforms that support it (e.g. Google Play and Universal Windows Applications) Unity IAP automatically restores any products the user owns during the first initialization following reinstallation; the ProcessPurchase method of your IStoreListener will be called for each owned item.​

Which, If I understood correctly, means that any purchase should be automatically retrieved every time you reinstall the game in any device (and the store controller is initialized for the first time in a new fresh installation) with the account you made the purchases from.

(In a former paragraph it says that this applies to "non-consumable and subscription items", but nowadays Google just allows microtransactions to be of two types: managed products -which I assume are non-consumable- and subscriptions, and you have to set them in the IAP code when calling Addproduct as ProductType.Consumable in order to make them so. I don't know if this is fine, but I managed to get it working via testing so I assume that's how it's supposed to be)

I've read I think everything there is to read about this subject and I'd like to know if there is a way for this to be tested, because I just couldn't. And if I'm supposed to do it easily, maybe I'm using the IAP services wrongly, so I don't know. My IAP code is pretty cookie cutter and there's nothing out of the ordinary.

How is one supposed to test this feature before publishing the game publicly and making real purchases? If it's possible, of course.

I've:
-Coded my purchases as 4 individual consumable items using the Unity IAP service from 5.2.3
-Correctly set up my app in the google developer console for this purpose (and published it in alpha state)
-Correctly set up said items in the microtransaction section in the google developer console
-Tested individual purchasing (it creates the transaction in both my testing account and the merchant account linked to my developer account, I can cancel them from the developer account if I wanted and the customer end gets the coins instantly)

Yet when I test-purchase and reinstall my game, I don't get anything when I initialize the store. Shouldn't it happen if the purchase is getting correctly processed? I go through the google popup, and it even tells me that the transaction was executed without any errors. It seems like a normal purchase at all levels.

The only clue I have is that when I test-purchase something, close the game and reopen it to initialize the store controller, logcat tells me that:

UnityIAP: Owned Items Response: 0
​

Is this normal? Does this mean my purchases don't get registered in my google testing account despite all this? Don't I "acquire" the product if it's on alpha testing?

Please, lend me a hand with this because I don't know what I'm failing at.

If code, logs or screenshots of any kind are needed I'll gladly provide them.

Thanks in advance!!

 

Hi @BSTCloud Your reasoning is clear, thank you for sharing the story of your process! (If you don't mind me saying, good for you also for diving into in-app purchase; it takes some effort to learn the "doors and corners" but it is rewarding!)

I've a question: Are your coins intended to be Consumable?

If yes then my first-blush solution to persisting across uninstallations is to work with Parse (sadly is being shut down soon) or some other Cloud Service to save your User's Virtual Currency level. One also needs to decide upon a way to uniquely identify Users for this Cloud Service to save / restore. Identity is not my forte but we can talk more if you decide to go that route. And naturally this client-server approach has a security angle whereby avoiding fraudulent Cloud saves is necessary, but it's a common way to transfer virtual currency inventories .. e.g. coins.

If no, and the coins are non-consumable, then let's chat more about this in this thread....

Other people might have other solutions, but I think that's the answer to your question: persist the consumable's remaining virtual Coins inventory in a cloud storage system, restoring it when the user "logs in" again. The rest of this post is optional reading for you.

A correction - "managed products" in Google's parlance means both non-consumable and consumable. It's just with ProductType.Consumable, Unity IAP will manage them by sending a "consume" message which frees them up for re-purchase on Google's side, whereas for ProductType.NonConsumable IAP won't "consume" which leaves them in Google's user inventory.

Also, do you mean 5.3.2 not 5.2.3? IAP is added for 5.3.

For Alpha / Beta testing of IAP - see this documentation offering a walk-through for using "Google Play Developer Console": http://forum.unity3d.com/threads/un...le-play-apple-app-store-windows-store.372647/

 

Hi nicholasr! Thanks for answering, really!

My pleasure! The more I write in my initial post, the clearer and more specific both my intentions and my case are.

I think the more realistic and pragmatic solution for this problem is for the coins to be consumable. I mean... as far as I know (and I may be wrong), non-consumable items are those which you can acquire just once, a one-time-purchase (for example a skin for a character in a game, you don't want the player to buy two of the same because there's no point on having the same item twice)

Coins however you want the player to buy and spend, offer them different options and invite them to buy again if they want because they want to support your game, they don't have any left, etc. In my game I offer 4 different options, each of them with increasing purchasing price and ingame reward (let's say 100, 300, 700 and 1500 coins respectively). With this distribution they can either buy "more for less" in proportion, or they can buy cheaper ones a few times if they have (or want) less to spend. I think the intention behind the design is clear enough, everybody does this the same way.

That being said...

If using a Cloud Service to keep track of how many coins have been purchased for each user is the best route to go, I'm all in into learning a new technology. So, let's discuss about this. Any ideas about where should I start/which services are recommended for working well and/or easily with Unity?

When it comes to having an unique ID per user the first thing that comes to my mind is using the e-mail associated with their GPlay account (since they will be downloading the game from the Play Store, they are bound to have one). If this is a good idea, how does one exctract their email from Unity, if it's possible? If it's not... then how would one approach this problem? I'm open to ideas.

Also, any idea as to why it's not re-purchasing or registering the purchases during the tests to redownload them as I specified in my previous post? Is it normal? Just out of the curiosity and to avoid conflicting technologies since it'd be ugly to implement a Cloud Saving service to retrieve my purchases in a fresh new installation/new game and then have Google suddenly doing their thing and retrieving the user's purchases AGAIN. Maybe that could be messy.

Okay, let's see what we can take out of this. I'll document everything that I go through and post it here, hopefully the solution as well, maybe this will be helpful for other people in my situation in the future.

My game detects whether or not you have a previously saved file, so it'd be as easy as, having the service configurated, if the game was not previously saved, create a new one and then connect to the Cloud Service and retrieve your purchases, if any. Since one can delete their game, this process can be easily repeated.

Thanks for the correction about the managed products! I didn't know. And yeah, it's 5.3.2, haha, my bad.

Last but not least, even though I have already read it in the past, that link in the end I HIGHLY recommend to anyone that ended up here (googling or something) having trouble implementing the IAP in the google-side because that very same doc is one I found a few weeks ago when I was taking my first steps with the system and it's very well explained.

Thanks again for answering!

 

@BSTCloud That debug log is irrelevant. You can check IStoreController.products to see if a product has a receipt, and then validate that receipt, to decide if a player owns a product.