I apologize in advance if this question is a duplicate. I did some search and didn't find what I was looking for. Suppose I make an Android app that had some sort of virtual currency (for example, coins in games) which can be purchased for real money via PayPal or CreditCard. Does Google offer me a way to store this information somehow or do i need to have a separate database server and keep such data in a separate database that has nothing to do with Google account. My app would not have any custom user accounts or anything of such ..The data stored would be dependant on Google user account.
Thanks.
The google TOS require you to handle every IAP over the play store and the google IAP APIs. To my knowledge, no app has ever been banned from the play store for using PayPal though.
The usual flow for buying in-app-coins is:
purchase via play store IAP
save amount of new coins to your own server
retrieve total amount of coins from your server
user server calls for adding/removing coins
Alternatively you can save the amount of coins on the device, this will get lost though if the user uninstalls the app or removes the app data.
Related
After hours reading documentation about android in-app product and subscription I am still stuck asking me about consumption process regarding in-app auto-renewing subscription.
What Google says about consuming
It's up to you to decide if you want to handle your managed products as non-consumable or consumable items
Non-consumable products
Typically, you would not implement consumption for managed products that can only be purchased once in your application and provide a permanent benefit. Once purchased, these products will be permanently associated to the user's Google account. An example of a non-consumable managed product is a premium upgrade or a level pack.
Consumable products
In contrast, you can implement consumption for products that can be made available for purchase multiple times. Typically, these products provide certain temporary effects. For example, the user's in-game character might gain life points or gain extra gold coins in their inventory. Dispensing the benefits or effects of the purchased product in your application is called provisioning the managed product. You are responsible for controlling and tracking how managed products are provisioned to the users.
In the other hand the Google Play Billing tell us that we have the following types of in-app products :
One-time products (managed products)
Rewarded products
Subscriptions
Reading this we could think that subscriptions aren't managed product..
I am trying to refacto a part of an app, at the moment the current version get the inventory (with an IabHelper), get the last monthly purchase (proceed automatically by google), send the information to our API to get user premium again and consume this last purchase after the API result.
Because I am now checking the monthly payments directly from our API, to remove this part from the Android app :
Do we absolutely have to consume the monthly purchase proceed automatically with the auto-renewing Google in-app ?
After working around in-app subscription (with our own API/Server) process for Android and iOS app, I think I found my answer.
When a Android or iOS user makes a subscription, my app (in my case) completes the transaction and sends it to our own API (through /android_purchase POST) with some parameters (see the workflow above).
Right after our API verifies the transaction with Google (through /verify) and sends back the answer to our apps (giving the user access to premium content or not depending on the /verify result)
But how your API can know if the user cancel the subscription or just know if the subscription has been renewed correctly ?
Actually (and a lot of developer reading this know that) Google and Apple allow you to give them an API endpoint to get notified (in my case /in_app_notifications).
Thanks to this feature, Google will notify us for each renewal or cancelation or even the first subscription action.
You can find some documentation about it here https://developer.android.com/google/play/billing/realtime_developer_notifications.html
This kind of workflow let us implement a clean workflow without any front-side check. Actually some apps check the last user payment at each app launch to notify the API and keep the user premium or not.
What if the user doesn't open your app for two months ?
Do you really think that the subscription is canceled by Google and Apple ?...
In my mind the answer is no. For me, this workflow demonstrates that it's not the case. In the same way, if your android app doesn't consume the item purchased (in my case of a monthly in-app subscription) it won't "break" the subscription. Android will renew it at the end of the month and notify your API.
I know that my answer is not complete, and may be some developers will share some others searches, but I was struggling with this question about in-app subscription process and I wanted to share my findings to save your time if you are in the same situation !
I have a question about android codes, I want to understand some developers use some codes to buy or active his app, for example, I have Dictionary and it is not free, but I want user full active dictionary by using a balance of phone number, when the user send me a balance I send to user number to active, please I want understanding that it how?!
It sounds like you are asking about how to bill an in-app purchase to a user's cellular provider.
This is not possible in any general fashion. Android runs on a wide variety of devices, many of which aren't even cell phones. If you want to support in-app purchases, you should probably use Google Play Billing.
My question is centered around handling in-app purchases for consumables with Google's In-App Billing API. (https://developer.android.com/google/play/billing/api.html#consumetypes)
Their documentation describes consumables as:
Consumable products
In contrast, you can implement consumption for products that can be made available for purchase multiple times. Typically, these products provide certain temporary effects. For example, the user's in-game character might gain life points or gain extra gold coins in their inventory. Dispensing the benefits or effects of the purchased product in your application is called provisioning the managed product. You are responsible for controlling and tracking how managed products are provisioned to the users.
A consumable item is something that could be purchased several times (like in game currency, an in game item or upgrade that is used, etc.), whereas a non-consumable can only be purchased once (no-ads, a skin / character, etc.)
In the documentation on consuming a purchase (https://developer.android.com/training/play-billing-library/purchase-iab-products.html), it also mentions:
How you use the consumption mechanism in your app is up to you. Typically, you would implement consumption for products with temporary benefits that users may want to purchase multiple times, such as in-game currency or replenishable game tokens. You would typically not want to implement consumption for products that are purchased once and provide a permanent effect, such as a premium upgrade.
It's your responsibility to control and track how the in-app product is provisioned to the user. For example, if the user purchased in-game currency, you should update the player's inventory with the amount of currency purchased.
My question is how to keep track of user inventory for consumable products? The documentation and various videos seem to quickly gloss over this, basically saying the app must apply the effects of the consumable when it gets confirmation of a successful purchase. But that isn't really the full picture. What if a user signs out and signs back in with a different account? Or they switch to a new phone, they should have the product on that phone.
You can't really save record of the purchase in SharedPreferences or a persistent cache because it is tied to the phone. If a user signs in on a different phone then they should have the benefits of all the purchases they made.
Take the following example:
A game starts players with 1000 gold. Player buys 500 more gold through an in-app purchase, then spends 200 gold. If player buys a new phone and installs that app on that phone, they should have 1300 gold.
How is this normally accomplished?
Do you need to run a private server that keeps track of purchases/consumption of such things separate from Google?
Thanks!!
I am implementing in-app purchase myself.
Do you need to run a private server that keeps track of purchases/consumption of such things separate from Google?
Yes of course as Google suggests in Security Best Practices
It's highly recommended to validate purchase details on a server that you trust. If you cannot use a server, however, it's still possible to validate these details within your app on a device.
Your second question
What if a user signs out and signs back in with a different account?
Tie the orderId to account or device.
In the first case, you can easily manage the purchase when the user switches the devices(another reason to get a private server).
While in the second case you can allow switching accounts on the same device.
So it's up to you which one to select.
You need to Synchronize local consumption to the server.
This is the flow for Verifying the purchase:
User clicks “BUY” button.
Makes payment with google.
App receives “receipt” from google and store it locally
Send this “RECEIPT” to the Server.
The Server sends the “purchaseToken” to Google Play Developer API for validation
The Google Play Developer API sends response with status code.
Store the RECEIPT in the server database (If we you to keep history of purchases by users).
This is the flow for Consuming the product:
The user opens the app.
App assigns values to the Resources by reading from local storage.
App tries to synchronize with the Server.(checks last updated timestamp)
Different scenarios:
Synchronization Successful: Assigns Resource values from the server. Set newly retrieved values in the local storage.
Synchronization Failed: Keep Resource values and try again.
User consumes the Resource.
App updates local values in Resource and sync with the server.(checks last updated timestamp)
I used Following articles:
Tutorial: How to Implement In-app Billing in Android LINK
Article on implementing InApp purchase LINK.
How to verify purchase for android app in server side (google play in app billing v3) LINK.
Another SO answer LINK.
Another SO answer LINK.
Code Project Sample LINK.
I'm very new to development and would like to create an app for an android TBS game that I would also like to build on later by developing a desktop application. I'd like to know how to go about storing user data in a secure way that would allow the user to be able to sign in on a possible future desktop application. From what I've read on data storage, I think what I need is to store a sheet containing fields for the user's email, password, username, and a class containing player specific stats on a web based service. How can I also take advantage of google play services to help me with this? Thanks in advance
You could start by looking into Firebase, a platform that was acquired by Google and has seen some great overhauls lately. It gives you free storage and database space (up to a certain level of usage of course) and works cross-platform for Web, Android and iOS.
Check out https://firebase.google.com/ for the docs and some quick-start guides as well as presentations from the latest Google IO: https://www.youtube.com/user/Firebase/videos
Android Game Services allows you to Store user data, to set achievements, to share informations with social medias, to make a leaderboard and to make a multiplayer game.
https://developers.google.com/games/services/
You should use them for cross platform purpose.
You can check Android Doc in storage options:
Data-Storage
If you want share in future the data with desktop, you will need the data in some online storage. Check Firebase, from Google, or Parse.
Firebase
Parse
For about 2 years I've been developing a business card reader application and I've published 2 versions of it on the Google Play Store (one paid and another free).
Recently I've decided to offer cloud storage for those business cards. I've created my PHP backend and it's almost contested, but I am facing one major issue.
I would like to offer the free users a chance to test my service and offer them a limited number of cloud cards, while the pro users would have unlimited number of cards to store.
I don't know what would be the best approach to accomplish this in order to offer my existing pro users this functionality while limiting them to only one account/app paid.
I was thinking about in-app purchases, but I don't see how I could unlock the purchase for the users who already both the app.
I am open to any suggestion!
In your MySQL database, add a column for cloud services expiry date. Now in PHP if your user chose try, store the date a month from now, and if they chose purchase, enter the date their purchase expires. Finally, before a user uses the service, check if the date has expired to determine whether to let them use the cloud service.