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.
Related
I would like to know how can I avoid having the user re-pay for an in-app subscription he already purchased.
Example: I purchase an App which offers in-app purchase on google play store for 5$ and now I shift from using an Android phone to an iPhone.
I came across this post which says it's not possible as they are two different competitors and would have to re-purchase the same app on the iOS once again, but is there a way to avoid it so that the end-user does not repay the sum of 5$ again?
I was thinking if it would be a good idea to have the receipt stored on a server and then when the user enters his email just do a lookup if there's a receipt associated with that email along with some validation logic.
In theory, I could avoid the user having to pay the 5$ with this approach but at the same time, I am not sure if doing this could get my app rejected or If this could lead to some different issues OR this is not doable at all and the user will have to end up paying 5$ anyways if he shifts from android to ios and vice versa.
The approach you suggested is correct. You would store the receipt on your server, along with the user identifier. Your server is responsible for refreshing the receipt with Apple/Google to keep the status up-to-date. You can then have an endpoint to your backend to check if a user is subscribed - regardless of the platform.
This is well within the App Store Guidelines, and is how large subscription businesses like Netflix and Spotify operate.
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.
I have to create an application for iOS and Android, from which I can buy some "items".
I don't understand how the in-app purchase work; can I buy and download the content I already paid for? Or can I buy just the unlocking of internal content without downloading it? If its just for unlocking internal content, is there any way to buy and download the content?
Thanks
The only thing you can't do with in-app purchase is selling actual goods - that's also allowed in case you have a website doing the same thing (eg ebay app). And there are some more rules for iOS in-app purchase.
As for the step by step idea about in-app purchase, here is a gist:
iOS app requests for SKProducts from app store (already setup via itunes connect portal by developer)
The retrieved products are displayed in the app along with localised pricing
User selects a product to buy
Purchase goes through via various steps - in-progress / success / failure. Depending upon the status, the app UI should be updated to keep the user informed.
Upon successful purchase, you can download content inside the app using your own server, or the content that's uploaded on Apple servers. You can unlock the content from within the app as well.
In a nutshell, you have a long way to go. The best way to start theoretically is to refer to In-app purchase programming guide. In addition, this book by Apple is also helpful. And for your needs, here is a sample code from Apple to begin with.
If you rather want a step by step tutorial, here is one authored by me. A rather easier one is the video lecture series with SWIFT and Objective C - prepared by me - which also accompanies code sample for SWIFT and Objective C to save time.
We are about to release an application on the Android Market, with In-app Billing for subscription that unlocks certain features for a the subscription period.
My boss now wants me to implement varying number of "free subscriptions" in the sense that:
The "lucky user" downloads & installs the application from the Android Market like any other customer (always free to install, but premium features require payment via In-app Billing).
The "lucky user" receives some key via email that allows him or her to avoid going through the In-app Billing checkout process (i.e. actually pay).
The key can only be used once.
Entering the key via a menu item, enables subscription for X months, as if he actually paid via In-app Billing.
The "key" basically acts like a coupon, but I haven't found any such option in the Publisher's Console.
Do you know of any such feature or a simple way to implement the above without duplicating the customer database on our (the publishers) server?
I actually dove into this subject maybe 2, 3 months ago. My conclusion was that currently there's no way of setting up this system, without using your own server.
Generating unique coupon-codes and expiring them on use is pretty straightforward. Let the user enter the code, send a POST-request to your server, hash the code both client- and server-side and see if they match. Next, expire the code serverside and you're set. It does however make your app vulnerable to piracy (if it isn't already); if you have a high-profile app, make sure to implement security checks (e.g. check SSL certificates to prevent a man-in-the-middle attack).
The hard part is reinstating previously acquired 'freebies' when users reinstall your app or change phones/firmware. For this purpose you're going to need a stable and reliable (cross-device) form of identification (e.g. access to the user's main Google-account on the phone). If you use user-provided e-mailaddresses, it's too easy to just enter someone else's e-mailaddress. If you were to implement a coupon-system, I would advise against reinstating 'freebies'.
I know this is a really old thread, but I had a similar need and found an official solution. For anyone who comes here for a solution:
Google introduced Promotional Codes couple of years ago and that is exactly what you're looking for.
You can create Promo Codes on the Play Console under Your App -> User Acquisition -> Promotion.
You can use promotions to give users a paid app or in-app product for free with a promo code. You can create promotions to reward loyal fans, acquire new users, and reconnect with previous users. Learn more.
yuo can add a screen for enter a coupons.
and the user can go in there and insrert his code and if it is correct you can give him whatever you want.
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.