Is there a way to buy a multiple of an item (SKU)?
For example: I have an SKU named LifePoint, and i want to buy 100 LifePoint.
(in another word N * my_item).
I found this workaround, but am looking for something better.
PS: I'am using In-app Billing Version 3 and my item is Unmanaged (to buy my product many times).
Thanks in advance!
I'm pretty sure that it's been made deliberately impossible to do that to prevent apps from stealing large amounts of money from the user. Each purchase requires confirmation using the Google in-app billing popup which stops that kind of thing happening.
The way I've done something similar is to set up different SKU's (as in the answer you linked to) but to use the SKU 'title' field to decide how many items to award the player. If you do it that way you can easily change those values in the Google Play console without having to update your app.
Related
I've not built an android app for in app purchases before. I've been doing a bunch of reading and it looks like, there's two kinds of products: managed product and subscription.
I don't want to pick the wrong one because it looks like some of these are permanent, so I want to get it right out of the gate. The docs say that managed products are one time and belong to the user forever and so, I think maybe I need a subscription.
Subscription, though, would indicate renewal and that isn't right either. I did find some documentation that says you can mark a purchase as consumed. Is that for subscriptions or managed products?
This is common enough that I'm sure lots of people have solved it, but searches for in-app products currencies returns information about conversion to other currencies.
I'm working through the docs and currently here: https://developer.android.com/training/in-app-billing/list-iab-products.html and why doesn't that talk about managed products and subscriptions?
I finally found https://developer.android.com/google/play/billing/api.html after much searching. In it it indicates that you can only consume managed products, so that seems to be what I want.
I am having confusion choosing a suitable product type of a commodity in my utility android application.
My application is of a kind where the user is benefitted through the number of 'slots' that they own. Think of it like the length of a ListView. My free application will feature a maximum length of that ListView upto 5. But if a user needs more List Items, they can buy subsequent List Item slots. The user should be able to buy as many as they like at 0.50$ each.
The problem is that, my in-app product neither comes under the definition of a 'managed product' alone, nor does it come under the definition of a 'consumable product' alone. I need the 'slot' product able to be purchased as many times as the user likes. But at same time, i also want Google Play to keep track of the ownership of the amount of slots per user.
As the documentation (and several tutorials out there) suggest:
If i want Google Play to store the purchase information for each item on a per-user basis, i will have to declare my product as a managed (non-consumable) product.
If i want my product able to be purchased many times, i would have to implement consumption for items that can be purchased multiple times.
The predicament is that i want both the features.
One bad solution is that I feature several slot products as unique products (alpha slot, beta slot, ... and so on), and then treat them as the same thing. However, i'd like to know of a solution that's more correct and sensible.
Another solution could be to make use of a separate cloud service to keep track of the number of slots bought by users, but i don't want that. That would be overkill. Also, i'd like to make use of the 'local caching' feature of Google Play Store.
I asked Google Play Developer Support if there were any way that Google Play Store could keep count of consumable in-app products. Turns out, at the moment, it is not possible.
Here is the actual reply (Nov 3, 2016):
I wanted to know whether Play Store also keeps record of the count of a
CONSUMABLE in-app item that a user has bought even after the user
uninstalls and then reinstalls the app?
In short, after user reinstalls, is there any way of knowing as to how many
of a single in-app item has the user ever bought?
Hi,
Thanks for contacting Google Play Developer Support.
I checked into it and the Play Developer Console doesn’t currently
support tracking every individual users every IAP purchase for
developers to see. Luckily, we place a high value on developer
feedback, and I’ll be sure to pass along your specific feedback to our
product team. We’re continually adding new features and functionality,
so please stay tuned.
You can always check the Android Developers Blog for any new features
and updates: http://android-developers.blogspot.com/
Like the title says, how should I implement a currency system with Google's latest in-app billing v3.
The basics:
I have currency.
This currency is earned or purchased.
Currency is given to players periodically.
Currency can be purchased in lots (1,5,10,20,50,100) or atleast that is what I wanted.
Google Play v3 forces you to store ownership details of consumable items on their servers.
You can not purchase the same item over until it is consumed first, removed from ownership according to google, and therefore not possessed in your game any more.
This presents some really painful problems to resolve... if I am understanding this correctly.
Do you make a ton of "duplicate" store items to handle the players ability to make multiple purchases of the same item should he want to restock? Can you make free items that are tracked?
What if the player buys a 100 pack, uses 99. Then uninstalls and moves to another device? He'll get all 100 back. How do you handle that?
So how should I manage purchased currency? Can anyone suggest any decent strategies to handle this?
Thanks,
Gullie
By just using inApp Billing api you can't restore consumable items , which seems logical (you cannot restore something that doesn't exist). You only can restore an item which has not been consumed because of getPurchases(). If you want to be able to restore consummable, you need to handle that part in your app and with a server which gonna track who buy what and who use what.
In fact you're not restoring the purchase but the state that the purchase changed : If an user buy 100 golds , when he move to an other phone , he want to get back the extra gold , not the purchase.
After each action your app should send the user status to the server (currency amount , level, item purchased / used ...) and get everything back on startup.
Be aware that you communication between the app and the server must be secured if you want to prevent cheaters.
With inApp v3 you cannot buy an other item until the previous one has been consumed. So if the user buy 100 gold , he used 99. The last one can be restored if he haven't consumed it : http://developer.android.com/google/play/billing/billing_reference.html#getPurchases
I'm starting to make some in-app purchases on my future app, and i wish to ask some questions regarding the new API (3) of the in app billing library (shown here):
google says (here) that there are no more unmanaged items. this means that in order to have multiple consumable items, the play store cannot hold a counter, so you need to either consume the purchase right when you put it in the app, or only when you need it.
My question about it is how would you get the consumable items stay on multiple devices? for example, if the user purchased 2 health potions, and because of the new limitations, they both are stored only on the app itself of one device, how could the end user go to another device , run the app and see that he has 2 health potions?
is it possible to make some purchases for free on some cases, programmatically ?
it could be useful for testing or on some cases when i want to reward the user for something he has done . i might even want to do it completely transparent and without any dialogs.
i know that there is a sandbox mode but that's only available by adding specific accounts as test accounts .
the lecture speaks of a "developer payload" (here) that you can put on the purchases for better security. they said that the data should be an id of the user, but they don't say what id i should use (only gave an example of google plus , which many people don't have).
my question is: what should be used for the "developer payload" ? if i use the sample, what do they use, and is it safe to use it or should i change it ?
i also don't understand how could it be useful, since the play store should always hold data as to which user has which items, so how could the play store be fooled on this? or maybe they talk about protection from changing the apk of the app?
is it possible to make a transaction of multiple purchases ? if so, can i hide those that don't cost money ? and if all are for free, maybe not show anything at all ?
Answer 1)
The way I have found for the question 1 is given below.
if your application used server database(stored data on server using internet connection) then you can simply stored data for particular user,Like if user has purchased 2 health potions and when user trying to use that 2 health potion from the another device then simply checked it is purchased by that user previously or not. if it is already purchased by that user then simply restrict that user to purchase potions again.
Answer 2)
Google is provided trial period for the subscription product. so that user can purchase that item as $0.00 amount as a trial period and when time expired(time can be 7day or more) item can be changed it's type as subscription item with credit card information as like simple purchase flow.
but, you used word "pro grammatically and without any dialog" then according to my knowledge Google will not provide it for the single user or for the particular user. you can simply give trial period value in the Google console for the all application user.
check this link for more detail: "Free trials" http://developer.android.com/google/play/billing/billing_subscriptions.html#administering
Answer 3)
I would like to suggest you for the developer payload, first of all it is not mandatory you can pass either blank string or with developer payload. According to my knowledge it should be working like "security code" same as you given in the Google site while searching content "Some Random String".
how to use developer payload and what should be use for developer payload
check this link
Developer payload is useful for the application?
I think it is working like security code like Random String, and while you retrieve data you can verify that item that was purchased is same or not so that if in case some kind of hacker can be redirect to the other product then you can check it at response time, is it the same product as you are going to purchased or not and user can be protect from unnecessarily withdrawn money from his account.
and also check given link I have explained more for the developer payload.
I am very new to android.. I am working on In App billing.. My question is what is the main purpose of Managed and Unmanaged state while adding the In App product..
Can any one tell me what is the use of managed state and what is the use of unmanaged state..
The main difference between managed and un-managed is that a managed purchase can only be bought once and is tied to the Google account that purchases it.
Un-managed purchases can be bought multiple times and are intended for consumable items.
For more information, please see the Choosing a Purchase Type section of the Google in-app billing documentation.
As of Version 3 of Google's IAP Billing API this has changed. Both consumable (multiple purchase) and non-consumable items are "managed". Tf you want to use Version 3 of their API, all purchases must be created as "managed". You can then decide if the item should be consumed later.
Here's a link to their docs: http://developer.android.com/google/play/billing/api.html#consumetypes
UnManaged could be something like "Buy 50 points"
The 50 points would then be added to your account and you would store this on your accounts server, therefore the Android Market no longer needs to know that you purchased this product i.e. it will not remember your purchase and you can purchase it multiple times.
Managed could be "Buy this song"
In this scenario you do not have a server to record that they bought the song and so every time they reinstall you can query the market to see they bought the song and it will not let you download it more than once.
Managed is aimed at one time downloads then you 'own that object'.
UnManaged is for multiple downloads of the same thing to 'top something up'.
UnManaged could be something like "Buy 50 points"
The 50 points would then be added to your account and you would store this on your accounts server, therefore the Android Market no longer needs to know that you purchased this product i.e. it will not remember your purchase and you can purchase it multiple times.
Managed could be "Buy this song"
In this scenario you do not have a server to record that they bought the song and so every time they reinstall you can query the market to see they bought the song and it will not let you download it more than once.
Managed is aimed at one time downloads then you 'own that object'.
UnManaged is for multiple downloads of the same thing to 'top something up'.
Least thats my understanding.
Version 3 has the concept of 'consumables' and it works inline with the above. All products are managed but you can 'consume' a product.
i.e. "Buy 50 points" will give the user fifty managed points, the user will not be allowed to purchase that item again until you consume that product.
Therefore you can make unmanaged products by consuming instantly, or managed products by consuming when the user has "used" that product (i.e. never call consume for buying a song).