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.
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.
In my game I have InApp Purchases. I want to test my game before publishing, so I uploaded it to alpha. I would love to test it on my phone, but google refuse, saying a developer can't buy his own products. Google also refuse to allow emulators to purshase items.
Yesterday I added a google account to my phone, and added it to the list of people allowed to download my app (Gmail accounts with testing access).
My problem is that I can't access my game (We're sorry, the requested URL was not found on this server). My game is available (I checked it from another phone and its good). I simply can't access it from my test account.
What can I do? Should I do something, or I will not be able to test my game on my phone no matter what?
Here is the android developer help for testing in-app purchases. The second account you added should be able to access the game shortly. In my experience, it usually takes up to about 24 hours to access alpha/beta testing once a user has been added.
Here's some specific stuff from that post:
Test Purchases (In-app Billing Sandbox)
Test purchases offer a secure, convenient way to enable larger-scale testing of your In-app Billing implementation during development or in preparation for launch. They let authorized user accounts make purchases of your in-app products through Google Play without incurring any actual charges to the user accounts.
Once authorized for testing access, those users can make purchases without being charged. Test purchases are real orders and Google Play processes them in the same way as other orders. When purchases are complete, Google Play prevents the orders from going to financial processing, ensuring that there are no actual charges to user accounts, and automatically canceling the completed orders after 14 days.
We recommend that you first test your In-app Billing implementation using static responses from Google Play. This enables you to verify that your application is handling the primary Google Play responses correctly and that your application is able to verify signatures correctly. You can do this even if the app hasn't been published yet.
To test your implementation with static responses, you make an In-app Billing request using a special item that has a reserved product ID. Each reserved product ID returns a specific static response from Google Play. No money is transferred when you make In-app Billing requests with the reserved product IDs. Also, you cannot specify the form of payment when you make a billing request with a reserved product ID.
I have implemented In App Purchase in my android app for purchasing items using the help and sample app provided on Google developer site.
I have set the test account to check the transactions on goggle wallet account.
Can any one tells me how to identify test account purchase vs real purchase, beacuse i want to show only real purchase request and data in our customized analytic.
There is a way to identify the sandbox purchase vs real purchase in IOS, so is there any way or receipt data change so that i can separate out the test purchase and real one.
Test purchases have "Test:" prefixed in their description within the developer console.
Use this to filter your data.
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.
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.