Does InApp billing (V2 or V3) works for a user who uses several accounts and makes the purchase with an account that isn't the primary one?
PD: Some explanation required, no simple Yes/No
In App Billing support multiple accounts reported as a bug in code.google, have a look at it
According to Mr.Sergej (posted in G+ android dev community) in-app products purchased with the first account won't be active anymore while using multiple user accounts!.
InApp billing just charges the user and tells your app whether it was successful or not. It is up to you to figure out how to give the user what they purchased.
You can...
toggle the SharedPreferences of the app to save their purchase. Obviously multiple people can use the same app on the same device with the purchase.
provide login functionality to save a purchase to a server, in case the user deletes the app or gets a new device.
Use one-time purchases to check whether the user has purchased previously. This won't carry over to several accounts on different devices/multiple-accounts-per-device.
Related
I have developed an app in which I want to give a premium version of an app with ad removal and some extra features in-app products.
So, my question is how to verify if a user had purchased already; Then, when a user opens the app, I know if I should give them a premium interface.
Here's the documentation overview for In App Billing, where it says:
Google Play tracks and manages the ownership information of managed products. When a user purchases a managed product, Google Play stores the purchase information for each product on a per-user basis. This enables you to later query Google Play at any time to restore the state of the products a specific user has purchased. This information is persistent on the Google Play servers even if the user uninstalls the application or if they change devices.
To provide premium content, you'll need to create a managed product that doesn't get consumed in the app when the user purchases it. In order to query the user's in-app purchases, send a getPurchases() request, that will return all the current un-consumed products owned by the user.
If you find the premium content in this response, you know the user has purchased it and can grant them the premium interface.
Google Play Billing AIDL is now deprecated and will be removed in a future release. To implement Google Play Billing features, use the Google Play Billing library and to get purchases details for all the items bought within your app use: queryPurchases(skuType).
I have an application which supports in-app billing. However a user can login to this app using multiple accounts or he can even register a new account.
Can I somehow use in-app billing, so that the purchases would be linked not to the google id, but exactly to the account which made the purchase.
For example:
User downloads the app to his phone and does the actions described below only on this device.
User logins using 123#gmail.com account.
He purchases subscription1 and proceeds with the payment.
He logs out.
Now he logins using 456#gmail.com account.
He can also purchase subscription1, as 456#gmail.com never purchased it. So he purchases subscription1 one more time.
He logs out.
Now both 123#gmail.com and 456#gmail.com accounts own this subscription.
Profit.
In-app-billing works through google services and all purchases will be verified for a current user. Starting from Android 4.2 you can create multiple user profiles on one device and in-app-billing will work as you described.
You may just log out/in but it takes time to synchronize some information and you may experience some glitches.
I have working app that sells in-app products (InApp billing v3).
Recently I've made an update for this app and made a terrible mistake there: I consumed some of purchases I didn't want to consume.
I issued an update and users updated the app and then wrote me they have no purchased access. (As I found later, I consumed wrong items).
So I have some questions now:
Is there a way to restore consumed purchases or I should return payments to my users?
Is there a way to find out how many and which purchases were consumed?
If returning payments, is there a way to find out if user still has the product or is it consumed with out changing the app (through google services)?
Thanks.
According to what I have understood from your question, It seems like you want to purchase product only once.
What I wished to ask: is there a way to request information about consumed products like about owned products.
you can get response or it's information in any type(Managed Product, Unmanaged Product, Subscription) in the onActivityResult method() check my below link.
In-app billing-v3 error in activity result
but I would not prefer you to manage it customly as you told for one time purchase product(not consumable product). You should go with the Manage product.
Managed In-app Products:
Managed in-app products are items that have their ownership
information tracked and managed by Google Play. When a user purchases
a managed in-app item, Google Play stores the purchase information for
each item on a per-user basis. This enables you to later query Google
Play at any time to restore the state of the items a specific user has
purchased. This information is persistent on the Google Play servers
even if the user uninstalls the application or if they change devices.
for more information about product type
you can query any time you want and you will get the product information, and even you don't need to manage if user has already purchase this product or not.
Is there a way to restore cnsumed purchases or I should return payments to my users?
Better option is you should give the payments back to the user and for the next time check the whole app once using dummy product "android.test.purchased" and update your app.
Is there a wat to find out how many and which purchases were consumed?
You have to check in the Google wallet because all transaction should be handle by the it, check if it gives you product type or not. Using your google developer console credential you can signed into google wallet.
If returning payments is there a way to find out if user stil has the product or is it consumed with out changing the app (through google services)?
as per above answer you have to check in google wallet, according to my knowledge they are provide us all of information about product type with user detail.
Let me know if I have not properly understood your question.
Hope it will solve your problem.
I am developing an application with subscription feature using Inapp Billing v3.There is login mechanism to access the application. If a user 'X' subscribes to a feature and logs out. If user 'Y' logs into application in same device and if the user attempts to subscribe, Google play tells that product is already bought. Are the subscriptions based on account synced in the device and not based on the user who logged onto the application? If so how is it possible to implement my scenario?
Google Play in-app billing subscription is bound to Google Play account. So as long and Google account is not changed the subscription is considered valid for this account and you cannot purchase it one more time.
If you want to substitute Google account system with your own accounts you need to "cheat" Google Play. What you can do is to create a pool of several different in-app billing subscriptions (like subscription #1, subscription #2, etc). When you subscribe you pass your own login as an additional parameter in developerPayload field.
Now when you enumerate all available subscriptions you check if there is one with current user account in the developerPayload field. If not, then you consider that current user has no subscription and allow to subscribe using the first not used yet subscription from the pool of subscriptions (subscription #1, subscription #2, etc) you generated. Just make sure that there is number of subscriptions in your pool is bigger than number of users on the same device you could have.
It is not a straightforward way, but rather a cheat to find a workaround for your situation.
Currently google IAB supports only one account(Primary gmail account on device) on one device. But from Android 4.2 multiuser feature is available and google is working on giving same support for IAB.
During our efforts to design InApp Billing for our Android App, we came up with the following scenario;
Customer has rooted/manipulatable device (so Market app + my app can't be trusted)
Customer purchases a product
Purchase state 0 (purchased) is send to our backoffice (all is checked and ok), we give credits.
Customer refunds that purchase
Customer has manipulated our app or the market app to locally confirm the refund and thereby prevent the refund notification to reach our backoffice server.
Is this scenario possible? How can we fix this?
It's been 7 years since this questions was asked but still I will provide an answer as it might be useful to some.
The part that is missing in your diagram is your BackOfficeServer to perform server side validation before granting the credits (goods) to the user. As nothing on the client side can be trusted (neither your app nor the app store) your only solution is to integrate your BackOfficeServer with the Purchase Verification API that Google provide. Only when you receive a response from them stating that the purchase is valid should you grant the goods.
The same would apply for refunds. If the user issues a refund you would need to revoke the goods. For this you again can only trust your BackOfficeServer. Google provide Real time Developer Notifications and Void API that can fulfill that requirement.
First: if the user asks for a refund you receive also an email.
Second: the purchases on in-app billing are not refundable directly by the user. If a user wants a refund, he must contact you and then you can proceed manually to refund with your google wallet account.
So i think that your scenario neve happen.
Secondly if possible i suggest you to use managed purchases, in that case if the user asks for a refund, google market will remember it, and you can use a RESTORE_TRANSACTION to check if some refunds occurred (but again: you must grant a refund).