It's a widely sought issue among those who implement In-app billing in Android, that how multiple accounts are dealt with. If a user has multiple accounts configured, which one will be used for in-app billing (as there is no option to let the user select an account)? After digging a lot, following paragraph here seems to explain it..
Note: To make test purchases, the license test account must be on the user’s Android device. If the device has more than one account, the purchase will be made with the account that downloaded the app. If none of the accounts has downloaded the app, the purchase is made with the first account.Users can confirm the account that is making a purchase by expanding the purchase dialog.
I create a developer payload using the account that is involved for in app billing, so that it can be restored properly at a later point in time or on some other device. But since Honeycomb, there is no such thing as Primary Account. A user can delete any account, may be the one with which the app was purchased, in which case, the first account from list of accounts will be used for billing. Now, if i know which account was used and if it occurs to be 'not the account with which app was installed', I can at least inform the user that the following purchases will not be restored later.
So, my question is..
Is there a way to find which account was used for downloading the application?
Google Play does seem to use this information. Anyway we can interact with Google Play upto this level?
note: PackageManager doesn't seem to deal with this.
If you want to get the name of account mail id which is configured to play store account currently. Please use it .
I am putting here only for email name but you can get all information of account like type , descriptin from account object
Pattern emailPattern = Patterns.EMAIL_ADDRESS;
Account[] accounts = AccountManager.get(this).getAccountsByType("com.google");
for (Account account : accounts) {
if (emailPattern.matcher(account.name).matches()) {
primaryEmailID = account.name;
}
}
My gut feeling tells me to create your own AccountManager and SyncAdapter combo. In order to control the account associated with your in app billing.
You could then potentially support merging of accounts on your server (if the user takes action and decides to merge accounts) and handle billing to the same person or based on their accounts. As well as restore purchases to the same device if you want to allow that.
You could enforce device policies etc. using Google Play Licensing and eg. DeviceLimiter
If the user deletes the old account your AccountManager and SyncAdapter combo would create a new account and the user would then be forced to merge accounts on your server in order to restore previous purchases and you would have the new "Primary Account" information stored there.
Like Edison said in your comments. There has to be a way to record the account associated with the first purchase and go from there.
These are just my thoughts and I hope we could shed some light on this and figure out a "best practice" to support this.
Related
In my android application I want to let users to authenticate with google or facebook account.
I've implemented sign-in with google already.
I'll try to implement sign-in with facebook soon.
I've read about IAP in android:
https://developer.android.com/google/play/billing/billing_overview
https://droidmentor.com/inapppurchase-subscription/
at least what I understand it is about google account authentication.
So I wonder is it possible to make IAP in android application if the user is authenticated with facebook account ?
I cant find examples or explanations by now.
Any good examples/explanations about IAP with google is also very appreciated because I still don't have a clear vision on IAP.
fyi: In my app user will be able to buy "virtual tickets pack" (e.g.: 10, 15, 20 tickets) and to add them to their profile. and later they will "consume" tickets one by one.
Best Regards
My understanding is that you already have a user system that you are using to provide a Google login to your customers. When you add Facebook login, you'll probably want to match both Google and Facebook logins with your own custom user ID. It's always a good idea to have a custom ID of your own so that you can map it to different types of logins.
When purchasing through Google Play Billing, the purchase gets associated with the user's phone Google account and you can also provide an optional way of associating a purchase with your own user account system. In order to do that, when building the BillingFlowParams, call setAccountId and pass your account's system custom ID.
To provide the best experience persisting purchases during installs or across devices you should also be saving the purchases on your server's database. In order to do that in a secure manner, you will also have to implement server-side receipt validation. If you want to avoid most of these headaches, I recommend you to use a service like RevenueCat.
IAP can only be done through the user's google account, as that is what one needs to use any part of the Play Store. The user's google account is also where the credit card/other payment methods are stored for each user.
In spite of the above, the way users log into your app has nothing to do with them using the IAP system. When a user will choose to use an IAP, the google account data will be provided by the android device/Play Store, not by your app (Off subject:the process is similar on iOS if you ever get to try there).
What your app needs to do, is receive the confirmation of purchase from the IAP sdk and then mark on your server that this particular user has purchased this item. Basically for any purchases (no matter the payment provider) you would usually mark in your DB the following:
what the user has purchased
how much did he pay
when did he pay
provider's id of the purchase, so you can later match the accounting reports with the payment provider's report
where he payed from (IP can be a good indicator, although in the age of VPNs not necessarily 100% acurate)(this can be useful for your marketing decisions)
mark that this user now has access to the item he purchased and if it is a time limited item, mark when it expires, so you are able to later check if he still has the right to access it.
Disclaimer:
I have not used the android IAP system directly before. I have implemented mobile app payment systems before using iOS IAP and on android Braintree payments. But the process is most likely very similar with android IAPs as well.
Is there a way to check which users bought when a consumable of my app? Not in the app itself but in the developer console/order management. Currently I only see an order id and a token, but would need some custom information or at least the user's email address or sth like that...
Nope. You'll need to link purchases to userIds yourself. Google will link that purchase to the users Play Store account, so they can potentially restore the purchase if they've reinstalled the app or gotten a new phone.
If you don't want to manage your own server, it may be worth using a tool like RevenueCat, that offer a purchase/subscription backend-as-a-service.
How can I get the email/ID of the Google Play account associated with an app?
I need this to show the user which account is taken into consideration for in-app billing. As far as I understood, Google in-app billing uses the account which downloaded the app, but I need to find a way to display this to the user, in case he has more than one account configured.
This would prevent users to complain not having their purchases recognized, when they have another account associated with the app.
Actually is not possible to get from Google Play the account that downloaded the application.
The suggestion is to create your own application user's account and only allow purchases after user registration (you can use whatever method you want to use).
And, for each purchase you link in your backed to the user's account. And, if the users log into another device using another Google account, if he log into your application using the right account, the access will be granted.
Google Play team is aware that this is not the best solution, and as I commented on this question, we are improving the API and as soon as we have an update, I'll post here too.
There is no way to know the email which the user is buying.
Even using the Account Manager, returns you a whole list of all emails.
Pattern emailPattern = Patterns.EMAIL_ADDRESS; // API level 8+
Account[] accounts = AccountManager.get(context).getAccounts();
for (Account account : accounts) {
if (emailPattern.matcher(account.name).matches()) {
String possibleEmail = account.name;
...
}
}
It's not as simple as choosing the first of the list, since the user could buy with any email that is associated to the phone.
You can use the AbstractAccountAuthenticator#getAccountRemovalAllowed, to know that account can not be deleted, and know which is the main mail (since you cannot delete the main mail), but even this may change, the user can change the main mail in any time.
I would like to know how to do this, but unfortunately there is no way. In my case, it's not essential money, so I send me as "payload" all email accounts of the phone concatenated, and all of these which would allow unlock premium content in my application, what can I lose some sales? It is likely, but I prefer that to a negative score in the market because a user buy premium content and could not be unlocked because I chose the wrong mail.
I don't think there is a way to detect the account that the user will use during an in app purchase.
The only thing I can think of is querying the AccountManager to check if the user has more than one google account and show a msg saying something like: "You have more than one google account, make sure you are using the correct one before proceeding". The only problem with this approach is that you would need to add the required permissions to do this query.
I'm developing our first app that uses in app purchases, and need to test that it's working correctly.
Currently if I try to make a purchase on the "android.test.purchased" item, I get an error message back saying "invalidClient". I'm led to believe that this is because my account is not a test user.
I found this page:
http://developer.android.com/google/play/billing/billing_admin.html#billing-testing-setup
which tells me how to set up a test user. I could set up a new user account, but I only have the one Android device to hand, which means doing a factory reset to make this the primary account, and I'd rather avoid that if possible.
Alternatively, can I make my own personal account double up as a test user?
The link above says that test users have limitations, one of which is:
Test accounts can only be used to purchase items that are listed (and
published) in an application's product list.
That seems to imply that I could only use my account to buy things in my in-development apps, and not from other apps as normal.
So can I turn my own personal account into a test user, without any problems when using the account to purchase other apps as normal?
It won't affect your abilities to use the test account as a normal account for other apps on Google Play.
So simply you can use your own account as a test account. (Actually if your account is the publisher account, you don't need to add it as a test account.)
The limitations mentioned in the documentation is a comparison to the publisher account.
Unfortunately there's no way around it. If you just have one device you have to wipe the device and then first sign in with the email address that you want to use as a test account. Only then will you be able to test in-app billing. You can also download other items from the Google Play store. I've done this without any problems.
My app uses licensing and in-app billing for subscriptions. I was able to use
AccountManager manager = AccountManager.get(context);
Account[] accounts = manager.getAccountsByType("com.google");
but that gets a number of accounts. Currently I'm just using the 1st one. I don't know which one was used to purchase/download the app. I myself had up to 3 Google accounts (the GMail one dumb old Google forces you to sign up with to activate your phone, my real Google account, and my work account).
I don't really need the email address, just some way to acknowledge one user is the same even if they are on different devices. If they access the app from different devices, that is ok.
The app accesses a server in the background, so will send the user id to record.
None of the similar questions had an answer, or rather the answer was 'no way'.
Is the most proper solution to have a menu item to let the user chose the account? Or would it be better to save ALL of the user ids on the server and if the user matches one, let them in? Doesn't the license server API provide some kind of unique user hash? (I can't find one, but it's a little fuzzy to me.)
So I'll repeat what others have said: if the only reason you're concerned is to identify the user for licensing purposes, stop right now because the licensing library does not require you to read e-mail addresses in order for it to work. The Play app will be the man in the middle for you.
An app you buy is available to other devices just fine.
The other questions answered 'no way' for a reason.
edit: however, if you're concerned about "unmanaged" products and not just for licensing purposed (you didn't make that clear, only now I'm seeing), then you could pair the information to a given user account. You should use the Account manager and ask the user to select the account he/she thinks is fit. By all means do not arbitrarily select an account for the user. Do as other apps do. The user knows better about his/her own personal information. And please do it securely.
My reasonable opinion.