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.
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 !
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 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.
I am looking for best practices while developing in-app payment apps on android?
How do you you store the data on android so that the information is not wiped off by an upgrade nor is it easily visibly to prying eyes? The data essentially says that this user has already paid for the app.
I have worked with many apps that does in-app billing, across other mobile platforms like Java ME, BlackBerry, BREW etc. The one sure way of doing this is to keep information on server. The app can do the processing, and/or any other kind of billing transactions, but the final authority for this should be server side. That way, app upgrades, uninstall etc, will not have an impact on billing (assuming we tie the user to a unique identifier like SubNo, client ID, Phone number, MEID etc).
How to get money from users phone using Java application?
So I want to create simple casual game, I want to charge users if they want to pass some extra layers. I want to create an app first of all for android, it'll be opensource. Than to port in on nokia and other Java enabeld devices. Are there any tutorials\matereals on how to do such thing? May be not on android on something else like Nokia? (BTW I want to transfer money to some banc account on PayPal visa or anething or to my own sim card at least...)
I think you can use the PayPal SOAP API if what you want is for users to buy something in-game.
As long as you can make web requests from your device it is easily portable.
I would start with The Developer's Guide for Android to get yourself acquainted with the platform and go from there. Making money from the product is a matter of pricing it on the Android Market.
Requiring a game to have an internet connection just for paypal could be a little annoying. Maybe consider a binary pricing model where you have a free version without some features and a premium version with all the bells and whistles. This would also make it so that users don't need to use alternative payment methods to what they are used to on the store.
For real JavaTM applications, The Java Store should be coming soon.
(I guess I should include disclosure/disclaimer here. I am an Oracle employee. The statements and opinions expressed here are my own and do not necessarily represent those of Oracle Corporation.)