I would like to setup subscription based billing for an app that will be sold through Google Play. Is it possible to sell the same subscription to the same user but on a different devices? So that every device that user tries to use the app on would need an active subscription?
I was thinking I could store the device id and user id on my own server and authenticate it that way, but is it correct that a user can't purchase the same subscription more than once? So would I need a pool of basically the same subscriptions if the user wishes to purchase multiple "licenses"? Can Google Play Billing handle any of this natively?
Thanks
The documentation from Google initially seems to make this impossible to achieve but digging deeper, I uncovered the following...
In the Google Play API version 2.0, you could create what was called an "unmanaged" product type that allowed the user to purchase the same thing multiple times. That seems to have partly disappeared in API 3.0 although the Gooogle Developer Console clearly supports this. I assume it's still supported because apps that used the 2.0 API are still out there and Google just can't drop support for that.
In 3.0 however, the "unmanaged" product type is not listed in the API docs but the docs state the following about making multiple purchases for the same product type (one-time purchase or subscription):
If you are using the Version 3 API, you can also consume managed items
within your application. You would typically implement consumption for
items that can be purchased multiple times (such as in-game currency,
fuel, or magic spells). Once purchased, a managed item cannot be
purchased again until you consume the item, by sending a consumption
request to Google Play. To learn more about in-app product consumption,
see Consuming Items
http://developer.android.com/google/play/billing/api.html#consume
IMPORTANT: Subscriptions CANNOT be consumed which means that if you want the customer to periodically renew their license, you will have to contact them and tell them that they must purchase the license again. That's a downside if your service requires a periodic renewal.
To obtain what you are after, you will need a backend server to handle the registration of devices and store tokens the apps receive from Google Play when purchasing. When a user wants to purchase your license, feature, service (or whatever) from another device, the other device MUST first release its "ownership" of the product with Google Play, through a process known as "consuming". It would work something more or less like this:
The first device makes a purchase and receives a purchaseToken
string from Google Play.
The purchaseToken along with the device ID is sent from the app to your server and stored.
The user goes to the second device and wants to purchase the license as well for that device. The app first needs to go to your server and obtain the purchaseToken (that the first device uploaded) and then call Google Play with consumePurchase which releases the "ownership" of the product from the user.
The app then purchases the new license (or whatever) from Google Play, gets a new purchaseToken and stores it on your server along with its device ID.
In essence, Google Play won't keep track of which device has the product. It only associates the Google Account with the product being purchased. It's up to your app and server to manage the licenses.
There is one potential problem I see that you need to address. If for some reason the app fails to send the purchaseToken back to your server (your server is down, the user dropped their device and broke it, your app crashes before it saves the token on the device, etc.), then you may not know if the user paid for the service. Google does provide a server API that lets your backend server query Google Play on Google's server for information about purchases, but I'm not familiar with it nor its limitations.
You will need to implement in app purchases as you would for any other in app item.
Make sure when you create your item in the Dev Console, it is unmanaged, as managed items can only be purchased once per account.
When you receive a confirmation on purchase of your unmanaged item, send the details like the unique ID to your server and store them there.
Now whenever your app starts, check with your server if it is an authorized device. If it isn't, prompt the user to buy it. If it is, let them continue to the app.
This only works if you need a one time payment. If you need a subscription, you will have to make it up of multiple one time payments, as subscriptions are like managed purchases and can only be paid for once by any account.
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 it possible to check what date the app was actually purchased, Not the in-app purchases, the actual date the user purchased the original application from the google store. I have found things like packageInfo.firstInstallTime, but that changes if you clear the device and reinstall etc.
I'm not sure if this is on-topic, but the only way to store data across installations is to persist it somewhere (like a server). You would have to get the gmail account associated with the purchase, associate a purchase ID and then check purchase date.
This is flawed because a re-install on a new device would look the same as a re-install on an existing device. It's also possible for a user to have two devices with the same gmail account, and therefore two (or more) active, valid installs and a single purchase. Most, but not all devices have a unique device ID.
And while there is no Official Google Play API (to request the data from Google), here is a good link for unofficial/creative options for search and content, but nothing for transaction data (which would probably lead to security risks without an official API):
how to get information of google play store in my android application?
I use Google LVL and Google Inapp Billing API ver 3 in my java application for Android. Of course I use (slightly modified) LVL library project from Google extras and IAP jar that Google suggests.
LVL library LicenseValidator in verifyLicense receives ResponseData with user-id in it.
It is said in Google docs that it is an unique user ID, representing user's google account used for purchase.
So I assumed (and made sure in tests) it is the same string (for example, "ANlOH<...>ppA==") on all devices where user has logged in with the same Google account.
So here is my iap purchase protection scheme in short.
Before the purchase app sends user-id to my server. It generates an encrypted payload from user-id and sends it back. App makes a purchase request and puts payload in it. App receives a receipt signed by Google, that holds the same payload. App sends this receipt to my server with the current user-id. Server makes signature and other checks, compares user-ids from payload and from sender and if everything is fine sends files of iap item to the app.
In another scenario, when the user reinstalls the app to this or another device, app gets receipts belonging to him from InAppBilling, sends them to my server with the current user-id. Server performs the same checks and - if everything is fine - sends all needed files to the app.
This approach with small differences works well on other platforms. But I have experiencing some strange glitches recently on Android app.
My server logs receipt check issues and I have found strange errors: user with one user-id sent correctly signed receipts belonging to another user-id (payload in receipt holds that another user-id). When I started to investigate I've found that one of such strange "hacker attack" messages belongs to
one of my test devices while other belong to real users (according to order-ids in receipts).
This test device with Android 4.4.2 has several google accounts added in Settings.
Previously I was sure that Google uses the first account. I saw such log messages:
InAppBillingUtils.getPreferredAccount: com.mypackage.appname: Account from first account - [jbC...FgH]
But now I see that sometimes LVL uses not the first account, but another one. I see such messages in LogCat:
InAppBillingUtils.pickAccount: smpxg.mythdefdf: Account determined from library ownership - [boL...M5E]
Moreover, after fresh installation of my app InAppBilling returned receipts for one account, but LVL gave user-id of another! But this behaviour is not stable. For example, now I see that LVL and InAppBilling both think that second account is my primary and work with it as expected.
I assumed that both libraries will work side by side but it looks like I was wrong. Obviously when the app sends receipt belonging to user-id "...yUQ" along with current use-id "...ppA" to server it refuses to send purchased content. And he is right.
If user could change current account used for purchases, I'd just added this trick in FAQ. BUT I can't see a way to select it manually in settings. In addition, system somehow selects it in a random way! The only way to make things work is to ask a user to delete all accounts from the device except his primary, but it's a bad solution.
When user purchases iap item being logged into one account and then switches to another account he should expect not to see purchased item. It's a predictable behaviour, just like with purchasing apps. But he doesn't even know what account is used in the moment!
AFAIK, there's not way to get from InAppBilling service google user-id it selected for purchases.
But even if I could - having user-id changed randomly by system makes iap items to appear and disappear from time to time :)
Looks like Google advises to use developer payload for protection, but doesn't give any stable ID which can be used to identify particular account.
So my questions are:
Does anybody experience this strange account switching?
How can I be sure which account is current?
Is there any way to synchronize LVL and InAppBilling account
selection? Any workarounds?
Thank you in advance!
I havent had an exact experience with your issue, but this might be somewhat relevant
According to the In app billing documentation
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.
is that OK and safe to set a value in SharedPreference to flag that the user have purchased this item? What if user hack this value in SharedPreference. Or I need to connect IAP service everytime to check that before user can use it?
(1) What is the best practice when I use Google Android IAP V3?
(2) And also if user's device have no Google Play installed, I may want to use paypal to make the payment, but how to track the purchase and unlock the features for users if I ask user to use simple paypal payment to get a license key? I do not want to use any other billing SDK, if with Paypal web page to buy the license, How to implement this?
(1) What is the best practice when I use Google Android IAP V3?
--> official document says that only payment transaction will be handle by google play itself, but in the application you have to set your business logic how you handle UI integration and other things after product purchase. You can also go with the in app purchase v3.
(2) And also if user's device have no Google Play installed, I may want to use paypal to make the payment, but how to track the purchase and unlock the features for users if I ask user to use simple paypal payment to get a license key? I do not want to use any other billing SDK, if with Paypal web page to buy the license, How to implement this?
--> You can ask user to update google play version dynamically. Google developer doc says more than 90% device using 2.2 os with installed google play store. I could not say any thing about paypal transaction because I haven't use it before, but yes in app purchase using v3 is very simple to implement and understand the payment process.
How to use in your application
Three way to manage your application's product data.
1) SharedPrefrence:
you can use the share prefrence value and check whether it is purchased or not. if in case user uninstalled the app and then re-install the app then you can check whether user has purchased or not, at this you get the item is already purchased. And you have to manage the user to access your application data.
2) local database:
you can also use local sqlite database to store the purchase detail and purchase status. and same as above if user clear data or uninstall the app then request for the purchase item again and check whether user purchased item or not.
or
2) Server database:
It is the better way compare to above if you are using web server to store the user data. In this type, you doesn't even need to manage for the second time for the case if user uninstall the app or clear the application data.
3) obfuscation: (Most efficient way compare to shared prefrence)
EDIT:
is that OK and safe to set a value in SharedPreference to flag that the user have purchased this item? What if user hack this value in SharedPreference. Or I need to connect IAP service everytime to check that before user can use it?
While I am searching on internet I found Nikolay Elenkov's answer like below:
If you just save a flag in shared preferences, any user with a rooted
device can flip the flag at will and be 'subscribed' without paying.
So you should at least do some obfuscation. Here's a sample way to do
it. Additionally, there is an API to check for subscription state, so
you should check periodically to make sure the subscription is valid.
more information check Nikolay Elenkov's answer
What is the best for billing Either In app purchase or Paypal?
It is depends on the product type,
--> In app billing: Best for google in app billing,
For the digital products including downloadable content such as media
files or
photos, virtual content such as game levels or potions, premium
services and features, and more.
http://developer.android.com/google/play/billing/index.html
--> Paypal: Best for Paypal billing,
For physical content or product do you want to share. You are not
permitted to sell physical goods or services using 'In-App Purchasing'
since the goods purchased via this method must relate directly to the
app using them.
Purchase physical product from iPhone app without Apple in app purchase
Hope it will help you.
from the documentation:
Because the Google Play client now caches In-app Billing information
locally on the device, you can use the Version 3 API to query for this
information more frequently, for example through a getPurchases call.
Unlike with previous versions of the API, many Version 3 API calls
will be serviced through cache lookups instead of through a network
connection to Google Play, which significantly speeds up the API's
response time.
Which basically means you can look up the purchase each time and the Play Store app will respond pretty much right away.
From my experience I can assure you of one thing.
** In fact it's bad to put a flag with a bool saying if it's premium or not **.
What I do is obfuscate the shared code
After I create some strange strings or numbers that only identify through the code inside the app if the user is a premium user.
Along with this, except for a numeric code within the database that identifies the type of purchase. So by checking both I can make sure the user is premium.
At this point if they want to cheat me with the root of the phone they should first understand how the code of my app works and then understand where to interact, because if only the shared preferences change, nothing will change and they will be whipped.
** This doesn't translate to high security, but at least the security level is higher and the root won't be able to get a reward that easily. Also because they should understand what are the exact codes to insert in the shared, in the database and look for them by removing the obfuscation. I honestly don't think it's worth it for them. **
As what Kuffs has mentioned, it is best to query the app-side implementation of the In-App Billing library which in turn queries the device's Google Play client. This will ensure that the purchase history most recently obtained from the Google Play servers would be reliable and relatively fresh information.
Also, keep in mind that if you are distributing the app on Google Play you MUST use the Google Play payment mechanism via In-App Billing. As it stands, Google Play and Wallet do NOT yet support Paypal or wire/bank transfer methods so you should not integrate the option if you are releasing it on Play.
http://play.google.com/about/developer-content-policy.html#payments
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.