I have a question regarding in-app purchases in Android. But first off, a little bit of information about what I am trying to do...
My app has a collection of "modules" that are arranged in a SQLite database arranged like this. These modules are differentiated simply by a column that designates what module that particular entry belongs to. What I want to do, is create an in-app purchase system where the user can download additional "modules" of content.
What is the best way to arrange and handle this data? Is it a good idea to keep the database setup and somehow implement a system where the in-app purchase adds to the database? Is it possible to keep track of this in the case that the user deletes the app or app data? I want to make this system as dynamic as possible, so that the user is not shown a message saying there is additional content available if they have already purchased and installed it.
The development on my app has not begun yet, so any other arrangement of data can easily be explored. For reference purposes, each "module" will have about 50-60 entries, and the plan is to have anywhere between 5-20 "modules" so there will be a good chunk of data.
Sorry for the plethora of questions all at once. If you need any screenshots to get a better idea of the data, or if I didn't do a good enough job in explaining what I am trying to do, please let me know!
For me it sounds like you need user accounts serverside. There you keep track of the necessary things about the user, like what he/she has bought, etc. In other words, the database is in a remote place, not in the app, so you can delete and reinstall as you wish and the data is still available.
In order to identify the users, this will help: http://developer.android.com/training/id-auth/identify.html
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.
So I have a subscription-based model when the user can upgrade his plan from a different one (from small to large), what happens if the user changes his current in the middle of another subscription life span?
For iOS, you can get some additional explanations in:
https://qonversion.io/blog/ios-subscription-upgrades-downgrades-and-service-levels/
https://blog.apphud.com/subscription-levels/
https://www.revenuecat.com/blog/apple-subscription-notifications-are-almost-useless
In these articles you can learn about upgrades, downgrades and crossgrades, and how they are related to service levels and to server-to-server notifications.
In Android, you can read (or watch):
https://developer.android.com/google/play/billing/subscriptions
https://www.youtube.com/watch?v=D8i_-H64TN8
I'm making an Android application that uses a coin in-game currency (that can be bought using in apps billing) and with that virtual currency the user can buy items that can only be bought once.
To manage every purchase and how much coins each user has, I initially though of using a table for every purchase and user used in the application on the server where I keep my item list, but since my server is a low cost one and i think / hope there will be a lot of transactions, the server will not be able to deal with every user request in time (answering update lists, managing purchases, sending the items to user and so forth).
Recently I found out about BackupManager and I was thinking if I used a local file to save the user coins, the updated list of items and the purchases the user has done instead of using the server, and then when one of these changes (when purchasing a new item, when updating the list of items, etc) i would update the local file and the backup using BackupManager without even contacting my server. Is that doable, is the BackupManager designed to work with very frequent backups like this?
This is wrong approach as you are open to "frauds". On rooted devices people could easily replace or modify your "wallet" file and without own records you will not be able to catch that.
And BackupManager is well... for backups, so I am not really see a correlation between your needs and backups.
I ask this question expecting the answer to be 'not possible', as I have attempted to research this already and found no fruit! I thought that I would give the community a chance to weigh in however.
I have a working in-app billing system, but what I want is to be able to provide a little extra bit of infomation with the billing request. Something that would show up in my market place stats.
My users have the option of buying several different levels of product (sort of a Base, Premium and Gold-Star sort of thing). When they purchase the product they provide me with a string that represents the specific thing they want the product about (such as the house number and postcode if the product was about a house).
What I want is to be able to see that extra bit of information in my market place reports, so when I see someone who has requested a refund I can see on what exact item they purchased the product. I have looked at the DEVELOPER_PAYLOAD but I don't think that it will do what I want.
If I can't find a solution this way then I will end up performing a service call and storing the data myself, but I thought I would ask you guys first!
Sorry for being vague about my app and the products it returns but I don't want to expose my app yet (plus it holds no bearing on the question!).
EDIT
Now that I have added a bounty I would like to limit the answers. As I mentioned in my original question my backup plan will me a service call to my system registering the google reference and "data packet" for the purchase.
What I am most interested in is a way to do this where my information would end up in the my market place reports. For instance, if you were to offer a physical item with your in app purchase, how would a user record shipping instructions/etc. There is a place for this in the market reports, so surely there is a way to add the data?
You can certainly use DEVELOPER_PAYLOAD for this. However, Google doesn't process it in anyway and it won't show up in reports (not sure if they store it at all). So what you need to do is send transaction info (the JSON string you receive) to your own sever, parse it and store/process/whatever the developerPayload. You can combine this with signature verification and transaction reporting if you want to. One thing to beware of is that the size is limited to 512 bytes. If you send a request with a longer string, the whole transaction will fail, and the error message is not friendly at all ('IAB-DPTL' or some such).
Of course if you need more that this, you can simply build your own webservice and send whatever data you want. If it includes personal info, etc. make sure you let people know about it and/or they can turn it off.
In order to see this in the report, assuming you have a limited set of "dynamic" data, you would probably have to create a different set of in-app items per each "item" in your game.
Then, of course, you let the game handle which list the user sees according to the "dynamic" data.
That's the only way you would see it in the reports without your own web service handling it.
For those that may find this question via Google!
It seems that the easy answer to my question is NO. You can not add extra information to your market stats with regards to in app purchases.
As I mentioned in my question (and some answers said) the work around would be to upload the transaction string to your server and then compare it to market stats yourself (using the export function from the market perhaps).
I now intend to write a system to extract market stats (likely from the csv download feature) and match it up to the strings from the IAPs. If I ever get around to writing it I will share it with the community.
I would like to use in-app billing in my android application (instead of creation 2 versions of application - free and pro). If user paid, then additional options in Preferences should be available.
My application synchronizes data with website (not my).
Each time synchronization happens, I would like to check if user paid or not.
How should I do it?
I think the easiest means for you would be to use Managed purchase. More on it is at http://developer.android.com/guide/market/billing/billing_admin.html#billing-purchase-type
The "manage by user account" purchase
type is useful if you are selling
items such as game levels or
application features. These items are
not transient and usually need to be
restored whenever a user reinstalls
your application, wipes the data on
their device, or installs your
application on a new device.
Update: website and API updated refer this now https://developer.android.com/google/play/billing/api.html
There are to many ways to do that, i will try and give you some of the most used
what about user accounts? can your application support users? if it does, its practically solved with 1 user per 1 account. just add a flag to your DB for each user. this is the most secure way, its very easy to know if someone is stealing from you thats why all MMO's (like WOW) use this type of check. you can easily know if theres more then one user on an account as well
the downside is that it requires more processing and some support is case someone's account gets stolen or other user support of that kind.
you can save a sort of key inside your application. and some other key on the server. if the key matches (either 1 to 1 or after some manipulation) then you have yourself a paid user, other you dont.when someone buys the application then change the key on the device.
just do what you dont want to do and have 2 applications for free and paid it will probably be less work then the other 2 list above.
there are many ways of doing what you want. but i'll tell you this:
most applications use method 2 but on the opposite direction, meaning serial key.
i dont think your gonna create an mmo so theres no need for option 1 unless you really dont want anyone hacking your application (which i assume no matter what you do it will be hacked in todays world. i'll advice you to trust those who pay and accept those who dont)
method 3 is just easy in my opinion especialy when you want to just remove menu options, but it also creates duplicate repositories for code.
good luck. what ever you decide is good, make a theft protection, if someone wants to steal it, they will, dont fight it (even PS3 got hacked in the end)