Develop Reference

Can I get a Firebase/Google UID on an Android device without user interaction?

I am in the process of migrating two separate free/paid apps to an In-App-Purchase based payment model. I have 4000 existing paid users, and so I would need a way to know if they already bought the old paid app, and if so they should have access to the same functionality that newer users who paid via the new in-app-purchase model do.
I could ask existing users to register something like their email, store that on some server and make it possible to use that to validate their purchase if they reinstall the app. But I would ideally want to make the transition seamless for existing users, so I'm wondering if there are any methods that don't require any user interaction?
I was thinking that maybe I can get some kind of UID that is tied to their Google account (they must have one since they bought the paid app on Google Play). Can I for example use Firebase to retrieve such a UID without having to ask the user to sign in? Looking at the guide for Authenticating users with Firebase and Flutter, it seems that it's necessary to call SignInWithGoogle()
to get a UID, which I assume prompts the user to sign in with their Google account and password?
I have considered using the device ID, but that is not really an option since the purchase of an app should be tied to a user and not a specific device which will eventually be replaced.

Restore in-app purchases when same native (Apple/Google) account on device but different app accounts

You have a mobile app (Android/iOS) that requires the user to sign-in.
The mobile app offers in-app purchases.
A user makes an in-app purchase while
* signed in as X on the device (Google account/iTunes account)
* signed in as Y on the mobile app.
The user then
* uninstalls the app
* reinstalls it
* signs in as Z on the mobile app
* restores purchases.
What do the app stores (Apple/Google) expect us to do?
Do we have to restore the purchases to the Z app user even if the purchases were made by app user Y just because the native user is X?
We read the policies but can't tell for sure.
Can you help?

If you have your own account based system, you aren't required to restore purchases from the device receipt if they can be restored by logging in to their (your) account. Apple vaguely mentions this in their docs as do service providers.
From Apple (their example is iOS/macOS but might as well be iOS/Android):
You could let users who have a subscription in an iOS app access the
content from a macOS app (or vice versa), but implementing that
functionality is your responsibility. You would need a system to
identify users and keep track of the content they are subscribed to,
similar to what you would implement for an app that uses non-renewable
subscriptions.
From RevenueCat:
Using an externally managed App User ID also provides a mechanism by
which to restore purchases in a few scenarios:
...
When the user logs in on multiple devices - you can honor a subscription that was purchased on one device across any other
platform.
You'll notice large, cross-platform, subscription apps like Netflix don't have a restore purchases button anywhere. As you've pointed out, restoring purchases could allow a single purchase receipt to be shared across multiple users that log-in on the same device.
Disclaimer: I work at RevenueCat

From reading through the docs relating to in app purchases on iOS the purchase is always tied to the device account, or Apple ID in the case of iOS.
Restoring purchases prompts for the user’s App Store credentials
Source
That's just the way it is and we have to work with it.
One possible solution would be to mark users of your app who have bought an in app purchase as "members" or "subscribers" in your own back end.
I am simply assuming that you have your own back end because as far as I know you need to have one to verify the in app purchase, and you also mentioned logins.
Then when a user goes to reinstall the app after they have deleted it, they then sign into the app, your app checks with the back end to see if the current user is the one who purchased the in app purchase, if they are, then restore the purchase, if not then don't. Then going forward you just show and hide the paid content based on whether or not the signed in user is the one who made the purchase,

IAP in Cross Platform

I have integrated In App Purchase (Auto-Renewable subscription) in iOS & Android. Both are working fine. I have certain doubts about validating the IAP using cross platforms like:
How multiple user when login in one app, how does the subscription for one particular works? (For Example, if user A has standard plan & after logout from the app. If user B logins in the same plan who has premium plan. How the iTunes will manages plan of IAP for particular user?)
Also what if user's who has android device when switch to iOS, then how to validate the IAP from android to iOS or vice-versa? (Like Netflix)
What if user A who has purchased standard plan on android and now switch to iOS & upgraded to platinum plan. So at the end of the standard subscription plan , will the standard plan be stopped & platinum will continue.. or standard plan will be counted too??
Any help will be appreciated. Thanks

Like #Paulw11 said, you'll need to manage subscriptions on your own server. Any receipt validation will only validate against that users App Store or Play Store account on the device, not the logged in user of your app. Obviously, Apple can't validate a Google purchase or vis-versa.
To answer your questions directly:
Apple will only look at the App Store account on the device to see if that user has made a purchase or not. Apple won't do any validation against your logged in user.
You need to store the receipt (from whichever store they purchased from) for the user on your server. When the user logs in on any device, you can check your backend to see if the subscription is expired or not.
There is no way to upgrade/crossgrade between two platforms. As soon as userA has purchased the standard plan on Android, they'll need to use their Play Store account to manage the subscription. Look at large, cross-platform apps like Netflix or HBO to see how they handle this messaging to users.
There is a tool, RevenueCat, that might be worth checking out. It's essentially a subscription backend-as-a-service that handles exactly what your trying to do.

Android In-App-Purchase, how to check if user have purchased one item

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

Saving purchased details for the app

I am hosting a paid app. I have a query. How a person purchasing the app is recorded so as to when they need to re-download (say after wiping phone or refreshing the phone software) is the previous purchase recognised. Is there a registration or something that I would need to keep (or is it recommended).

If your app is downloadable from the Google play store then there is nothing you need to do. The play store will automatically work out when the user visits your apps page whether they need to purchase, whether they have purchased, or whether they purchased and then refunded.
The only thing you might want to do is to add some code at the start of your app launching that automatically checks google servers and ensures that the purchase has been made, otherwise you can block the app. Although this isn't fool proof but it highly reduces the changes of your app being pirated.