I am working on an app that'll be available to specific customers, after figuring out that this approach does not work, I am switching to pushing it to the public as a free app but give login credentials to specific users. Would that violate any of the subscription rules by android? would the app be taken down if people can't sign up, knowing I will charge for the account personally?
You can do this easily using Firebase Authentication. Here is the documentation for it.
Just connect your app to Firebase, create login screen with Activity and create accounts with the usernames and passwords for your users and give them the credentials.
As for the Google Play billing policies, I believe this violates their rule that you should only get paid through Google Play so they get 30% of the income, however, if it all happens outside of the app, and there are no platforms to get paid through (like PayPal) integrated in the app itself, it shouldn't be a problem as far as I know.
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.
I didn't find any definitive answer for my situation as all of this kind of questions revolve around server-side verification, which is irrelevant to me.
I'm trying to implement in-app billing in my app in order to offer the option of a premium upgrade. I've followed the guides in the developer documentation and done most of the work.
The problem is purchase verification:
The documentation suggests I shoud pass a developer payload to each purchase to uniquely identify the user - but my app doesn't have or need a user system - how can I uniquely identify a user without requiring user input or extra permissions?
Further and more important problem:
When the user makes a purchase, or opens the app after making a purchase in a different time, I need to verify this purchase - I don't have a server where I can send the purchase data to so it can verify it itself or using the Google Developer API.
It is my understanding that I shouldn't verify the purchase locally on the device (using the Google Developer API).
What is the best way for my situation to verify in-app purchases?
Is there a way to do it without a server? (I do not have the knowledge nor resources to have my own server)
I do not know how you would go about verifying a digital purchase without a network connection. Thankfully though, you do not need a user account system nor do you need the knowledge and resources to have a dedicated server because that is what Google Play services is meant for.
After setting up Google Play services; each user will be signed in through their Google Play account and be able to use their registered payment methods within your app when you implement the In-app Billing API. And you can test and manage all of this information from the Google Play Developer Console.
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
Say a company would like to purchase my app for each of its employees. Each employee has their own Google account. But, in order for the company to pay for the app for their account, they need to log in with their account, and have access to the company's credit card information. Is there any convenient way for a company to purchase an app for its employees?
You may have to implement a licencing system. Have the market version of the app require a key be entered before it starts working. You'll need a backend system to manage the creation and usage of these keys that will also provision the app on the phones.
There may be a better way but I've never heard of a "gifting" mechanism for the Android market.