Currently I'm trying to learn how to use Google Play Billing Library V1.2 for implementing In-App Purchases (IAP) - Subscriptions mainly in my Android app.
While looking at Add subscription-specific features, I came across this:
Also, before reading the rest of this page, you should also have
real-time developer notifications enabled. Real-time Developer
Notifications allow you to react proactively to state changes, to
increase your engagement, and to reduce user turnover.
And when I tried to check Add real-time developer notifications, it told me I needed to setup Cloud Pub/Sub using my own Google Cloud Platform (GCP) project.
Then I checked GCP and found that it is a heavily paid service which I can't seem to go for, considering that it is my first app that I'm talking about.
So, my question is that is it really a must to enable Real-Time Developer Notifications for implementing subscriptions in an Android app? If yes, do we always have to go through a paid service like GCP to achieve this or are there any free options too?
No, I just added a subscription to an app and didn't do anything with real time notifications.
If you do not implement RTDN then you have to poll Google API periodically to get the latest user information and you have to do it for all of your users (it is paid, you do not want to excessively use it). You also have to implement the logic for that, and I would find this quite fragile and inefficient. Moreover, you will have to manage cases such as revoked, canceled, etc. from your back office(if you have any) or you are gonna have to manipulate your database manually. Coming back to your questions, it is not a must but you will have a lot of benefits from implementing them.
Related
The newly available Google Play Billing library does not support the SubscriptionManager of Unity IAP.
Usually, I would validate the receipt with the SubscriptionManager and check the is_subscribed, is_expired, etc attributes and act accordingly.
The documentation of Unity is not up to date with this new information. The Google Play Billing documentation offer no solution or insight as to how to validate that a subscription is still valid. "Not supported" is hardly a valid response, subscriptions are part of a lot of games and software made with Unity.
How can I validate that a Google Play subscription is valid and not expired in a Unity Project using the Unity IAP. Failing to be able to use Unity IAP, any other solution or insight is welcome.
It appears that this new plugin makes it mandatory to validate user subscriptions server-side. When implementing the plugin, I had to create a back-end service that provided the expiry date back to our app since we couldn't use SubscriptionManager to grab that information anymore.
I can't really recommend a specific way of doing this, because everyone's back-end will be different. For us, we utilize Docker containers on DigitalOcean droplets that our app and database can communicate with. This allows us to have a centralized location for back-end services, which we write in Python using Flask.
We have set up one that can go through our database, find every subscription that has expired based on the saved DateTime, and validate whether it has renewed or not. We added an extra endpoint to that service for grabbing the expiry date of a Google Play subscription, as mentioned above.
Subscription information can be obtained by accessing the Google Play REST API's purchases.subscriptions.get. This will return a SubscriptionPurchase object, which provides relevant information that you can then process to find out attributes such as is_subscribed, is_expired, etc.
It may be possible to send this directly from your Unity app/game, however this may also make man-in-the-middle attacks possible (admittedly my knowledge in this area isn't quite there, so I recommend you do your own reading on this).
Also as just a general suggestion, I recommend you try to post questions across both here and the UnityIAP sub-forum. The UnityIAP support folks are super active and even if they can't help because this is a Google implementation, it should definitely put it on their radar! I try to post there whenever I can as it allows them to make improvements to UnityIAP. (:
Yes at the moment we should use server-side API for getting Subscription related info. As SubscriptionManger was dependent on developer payload which is deprecated. See 2nd para https://developer.android.com/google/play/billing/developer-payload
I am developing an Android application to solve operational research problems. Right now it has a free mode and a paid pro mode using google play in-app purchases. Pro mode allows a user to solve problems of any dimension and using any method available in the app.
Now there is a following problem, which I don't know how to solve best:
I want to provide each user an ability to solve any kind of problem 3 times without paying when a user first installed the app. I'd like to somehow link it to a google account, so the state will be single across different devices with the same account. Good bonus would be if a user should not explicitly log in to the account in the app itself to identify.
What is the best way to do it? I'll need a backend server I suppose.
I'm thinking of two ways, the easy one and the right one:
The Easy one: you could use google play games services, which lets you store users game data without any backend. This is not the right way because what you are developing isn't really a game, thus when the user is prompted to sign in to google play games account will seem strange...
The right one: implement a google sign-in process and store your information on a database. I suggest you to use google's firebase which is free for limited usage and very easy to integrate. It offers an easy way to implement google sign-in procedure and a really cool database called firestore
I'm planning to add In-App purchases to my Productivity app. Enhanced features are purchase products (e.g., freemium).
I would like to have user access to purchased feature on both Android and iOS, if he has purchased on any one platform. Technically I plan to store purchase information on server and have it retrieved whenever user logs-in on either device, and unlock the feature if already purchased.
Is this allowed in both iOS and Android?
Apple App Store Review Guidelines on Section 11 have this explained.
Points "11.1/11.2" and "11.14" sounds conflicting (or I'm missing something.).
On Android, I do not see this point mentioning in Policies.
If you had any experiences (w.r.t sharing purchase info between devices) that I should take care additionally, any suggestions are welcome.
I'd like to add a note about subscriptions. Here's the quote from Apple guide:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have both an iOS and macOS version have separate products with separate product identifiers on each platform. You could let users who have a subscription in an iOS app access the content from an macOS app (or vice versa), but implementing that functionality is your responsibility. You would need some system for identifying users and keeping track of what content they’ve subscribed to, similar to what you would implement for an app that uses non-renewable subscriptions
Link to Apple docs: https://developer.apple.com/library/content/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Subscriptions.html
Quote from Android docs:
You can also build on your existing external subscriber base from inside your Android apps
If you sell subscriptions on a web site, for example, you can add your own business logic to your Android app to determine whether the user has already purchased a subscription elsewhere, then allow access to your content if so or offer a subscription purchase from Google Play if not.
You can implement your own solution for sharing subscriptions across as many different apps or products as you want ...
Link to Android docs:
https://developer.android.com/google/play/billing/billing_subscriptions.html
At the moment of writing this answer (May 23, 2017) Windows Store doesn't have subscriptions but they were announced during the latest BUILD conference. Some details here and here
Subscriptions should be available later this summer.
Answering myself. I submitted to App Store mentioning this case and got it approved. I'm yet to submit to Google Play so not sure about it.
Below the snippet I mentioned in App Store review notes that may help some
If user already purchased premium outside the app(our website or
Android app), then we are unlocking Premium as soon as user
logs-in to the app on iOS device. We do not include any button or link
or information inside this app regarding purchasing outside. If you
have any concern or comments regarding this, please let us know.
Additionally mentioned that our in-app item's service is based on user data at our server and not solely on iOS platform. I think this is the key point that makes sense to reuse user's purchase of our service. However, I do not find this case mentioned clearly in App Store review Guidelines.
[Update for April 2019]
As I've already answer here - from developer Apple guidelines:
3.1.3(b) Multiplatform Services: Apps that operate across multiple platforms may allow users to access content, subscriptions, or features they have acquired elsewhere, including consumable items in multi-platform games, provided those items are also available as in-app purchases within the app. You must not directly or indirectly target iOS users to use a purchasing method other than in-app purchase, and your general communications about other purchasing methods must not discourage use of in-app purchase.
So like #siddharth-gupta explain in his answer:
Apple's rule basically states that if you have a digital product in your app (in your case, your subscription), the only way to pay for it should be via Apple's in-app purchases. If instead of using in-app purchases, you redirect the user to pay using any other method, your app risks getting rejected.
Note: this Apple statement for April 2019 -> and can always change. To avoid potential rejection/ban Always verify it with current official Apple Documentation
I need to check, using APPLE ID/GOOGLE Android ID, if the user really has paid to buy my app.
I have to avoid an user use a cracked app (jailbreak)
Is there a "public key" unique for each app? I can use that (if exist) to check the unifier of my app
In short: No. You do not have access to this information via the API, but as others have said, you can roll your own solution via in-app purchases and your own server. If your concern is that unlicensed users will consume server bandwidth or other expensive resources, I'd suggest doing this.
If your end goal is just to prevent piracy, though, I'd suggest googling some of the off-the-shelf anti-piracy solutions available today. Even then, however, I would not expect miracles. I have implemented as many anti-piracy techniques as I can develop within a few of my own clients' apps, but to date, none of them remain "uncracked."
You could do something creative involving in-app-purchase and pinging your own server when the purchase is completed. This assumes you want to put content behind the IAP paywall and that you want to run your own server which perhaps isn't the case.
On Android, use the license verification library.
You could make it available for free on the AppStore, and then use a licensing or in-app purchases to deliver more content (full-content) to the users !
I want to know if its possible/legal(not against terms of service) to use the google checkout api for an android app to support in app purchases. The types of items being purchased would be something like extra coins where they can be purchased multiple times.
I know that this would require getting the user's credentials or pointing them to the checkout page or something. I want to know if its possible to do this within the app by opening a webview to the checkout process, and then getting a callback to a custom url on my server that will allow the app to see that the purchase was successful. Something like what the android market does for app purchases.
Thanks for any responses. I don't currently have code to show as I am researching into this before devoting time to create something I won't be able to use. Also maybe android will support native in-app purchases in newer versions of the sdk.
Spoke to (Android evangelist) Reto Meier at Google Tech Days about this and he said it is perfectly OK to do inter-app purchases in the market. You should comply to other regulations - most common is that you need to only buy content that is consumed on the mobile. Virtual "coins" are on quite thin ice, some countries ban issuing "virtual money" but you can do essentially the same with just little different paradigm. Hope this helps.
Android market documentation explicitly states that you can do check it.
http://developer.android.com/guide/market/billing/billing_admin.html#billing-refunds
Important: You cannot use the Google Checkout API to issue refunds or
cancel in-app billing transactions. You must do this manually through
your Google Checkout merchant account. However, you can use the Google
Checkout API to retrieve order information.