I have multiple items in my app. I have two devices. If I buy item on first of these devices and then try to buy on another one the same item, i can't.(Google play intent shows message - Item already owned! And then it crashes....:-( ) Items in google play are marked as "managed per user account". And I do not have any problem with buying items.
Another problem is, if I try RESTORE TRANSACTION ACTION - I got result_developer_error ( which is partly weird....):D
These issues tested on Android 2.2,4.1
My question is:
Is there any possibility to allow to buy this item multiple times without need that the item is marked as "unmanaged"? (I mean on different devices by the phrase multiple times)
If there is possibility? Can it be done without server side where the info will be stored?
I know that the simpliest solution is to change product_type - But then I will loose the chance for restore transaction action....
I followed google api on implementing the in-apps
http://developer.android.com/google/play/billing/billing_overview.html
note: implemented v2 in - apps
Managed items are tied to your account. So if you buy on a different device with the same Google account, you will get the 'already owned' error. If you use unmanaged items, you can buy the item as many times as you want. In this case you might need to track item state on your own server, if required. If you are using a test account to test this, restore transactions doesn't really work. Should work with a published app though.
In-app billing v3 handles this differently and should be slightly easier to manage. If this is for a new implementation, consider switching (or at least evaluating) v3. Not clear how stable (or not) it is though, since it is pretty new.
I have finally solved this issue by implementing new v3 in app billing. It's quite simple to implement version3 and it supports checking for transactions in very very better way. If I could i would send plus one to google for version3. If you are lookng for solution for this issue use this site "Google in app billing version 3"
Related
I know that they are possible since I implemented consumable purchases and they work but:
If I upload a new version of the app or re install it the consumable purchases are gone. Does not matter if for iOS or android. I used the device ID but that is not reliable and does indeed change in some scenarios
I would like to offer inapp purchases (consumable) and keep track how many a user has. Ideally over multiple devices but for sure for multiple installations (meaning they keep them after updates or reinstalls)
Is this even possible without some kind of login? Is it possible to implement subscriptions without this problem? I use revenuecat if that matters but asking more generally
In case of consumable in app purchase it is definitely lost and cannot be recovered across devices without saving them for the relevant user. You may have to create your own saving and recovery system if you wish to make it available across devices.. maybe you can take a look at non consumable products or subscription
Good afternoon
Theoreticaly Possibly, but there are several ways that you need to use all together in order for everything to work correctly.
For example - It is necessary to store the user_id in the keyChain, then the saved id will not change when reinstalling (this only applies to iOS). It is also necessary to get information from the Receipt for different users (with different devices) but having one check and merge them. Therefore, it is desirable to have 2 ids for the user user_id and device_id. You need to receive and process webhooks from Apple/Google to understand the current status of a particular product. Doing this on the client is not the most pleasant experience. Some of this is generally impossible to do only on the client side.
Better use the ready-made solution Apphud, RC ...
If you have a free time and a team of backend developers, then you can implement all this yourself.
Look at the internal implementation of the services above (the code is open) how they work with Receipts and ids. You will understand that without the usage of unique identifiers you will encounter a lot of problem cases.
I'm trying to implement the in app billing service in my app (for test-purposes currently). Have tried to check out resources and documentation but I haven't found any on what the status means and for what purpose.
This is what I'm talking about in the console:
If I set it as Active, does it mean that I can only make a real transaction?, where as I want to test only. Kindly help me understand this in detail.
If the status is inactive, it means that the item won't be available for purchase nor for testing. Whereas if the item is active, it means the product is available for purchase for testing purposes(not published on the play-store) and for commercial purposes(published).
Check out this link creating a managed product
I have 3 apps, that im now looking to merge into single one. Each app had its own set of IAB items. The new merged app will have all the IAB items aswell, however is it possible to tell if user has purchased given IAB item in the previous app so I can enable it in the new merge-app without paying again? Im looking for a solution different than handling sending the data to my own server, and downloading it in the new app etc. Ideally Google Play internally. Is this possible? Thanks
Is this possible?
No, You have to handle this with the help of your server. Google does not take care of what items you have bought from other app, if same item is available in different app then it would be consider a new different.
Simply, I guess that you have information of users who have bought items from your 3 apps, you can call web service, if user had bought then give all services to user otherwise ask for to pay.
Each app has its own product list. You cannot sell items that appear on another app's product list.
Google is not provding any way to do so.
I have a "Base", "Normal" and a "Deluxe" App. "Base" is free, "Normal" costs 1$ and "Deluxe" costs 2$.
The "Base" app holds the entire logic for all content and shows the trial content at the same time. The "Normal" and "Deluxe" are only unlocker apps without any logic.
The "Base" app simple checks if the "normal" or "deluxe" apps are installed as well and shows the corresponding content. ( This is no security question, I am doing this with certs compare ... )
I am looking for a way to allow the Users, who already payed the "Normal" App to only pay another 1$ to unlock the Deluxe content.
What I evaluated so far, which I don't like :
I don't like to use inapp payment for several reasons, which I do not want to discuss here please :-)
I could create a "upgrade2Deluxe" and in the "Base"-App I could check if "Normal" and "upgrade2Deluxe" is installed and show the Deluxe Content. But I also don't like that, because the User will see 3 Apps on his device.
Do anyone have a idea howto do this in another way ?
I'm faced with a similar choice, and I'm still exploring a number of ideas:
although I also don't want to have in-app purchases in my Base app (which currently needs no permissions at all), I'm thinking that having in-app purchases in the Normal app will be acceptable, so the user installs the Base app (which holds all the Base + Normal code), and the first upgrade is to install the Normal app, then future upgrades are achieved by running the very limited upgrade code from the Normal app.
I intend that the user does not see multiple apps on their device - the Normal app will not declare any launcher intent, so will be hidden from the user
I'm looking to have the Base app change it's declared launcher activity so that the icon changes from Base to Normal (or beyond)
By keeping in-app billing out of the Base app, I keep the ability of that app to work on Kindle Fire and other devices outside the Google Play ecosystem.
Refund users $1 if they buy both normal and deluxe.
You cannot manipulate prices on a per-user basis. There also isn't anything stopping users from buying both normal and deluxe versions from the play store.
If your problem with IAP is having a server side component, you could use something like http://doc.applicasa.com/docs/content/android/#monetization to help.
You can make two versions of the app - Free(Base) & Premium(Deluxe).
Although I understand you do not want to implement IAP, however you could provide them some of the additional features(after the trial) via the In-app purchases that would transform your app to the Normal version as it seems the only viable option.
Now for the Deluxe app you have to make another app with all the features you want to provide & provide the link in your app for the user to download. After the download of the Deluxe app the user can delete the Free app!
This is the norm that developers follow for trial & full version apps ( Example: The Dictionary.com app in iOS)
I've seen this question: Android - how to check if in app purchase has already been done?
It is not very clear to me however. I am using the AndroidBillingLibrary, mentioned in the answer, and I have a couple of questions.
When using restoreTransactions(), does that mean that at that point the purchases are stored on the device itself? Couldn't that be manipulated somehow?
And what if I buy an item on an other device, how does the first device know this? Do I need to restore again?
Thanks in advance
For the first question, every purchase is managed with an ID, thus only managed items work with restoreTransactions(). Also, restoreTransactions() does not work for reserved Product IDs. Thus it is still safe.
Ideally you should call restoreTransactions() every time the app runs. The Key thing is that all transactions are paired with the device/user ID (not sure how Google handles authentication on their server side but I assume it is using a combination of your Google account as well as the phones that the Google account is paired to).
So, if someone were to modify the transaction file, it will get invalidated when it is compared to the logfile on Google's side.
Hope this clarifies things :)