Reading the documentation for subscriptions and related SO questions/answers i am still confused what to do when i have to stop providing the subscription services and content:
https://developer.android.com/google/play/billing/billing_subscriptions.html#cancellation
In all cases, you must continue to offer the content that your
subscribers have purchased through their subscriptions, as long any
user is able to access it.
For example i am offering some content via my server to subscribed users in my app. At one point i am unable to offer that content and i want to cancel all subscriptions?
The users theoretically wont be able to access the content any more and i certainly dont want to charge them for it any longer. The proper use case for me would be to cancel the user subscriptions and refund the remaining money for them. But i am not sure that this is acceptable according to the available information in the docs...i guess that i can do the cancellation and refunds using the google play developer API (still reading the available options) if that will cover the policy requirements somehow?
I am just finding it hard to believe that if a user for ex. rejects app updates and stays on an old app version with an old subscription i have to support him for eternity :) ?
I know what you are suffering the only way around this is communicate to your users to update. Usually this case would mean a FORCE UPDATE so when they open your app they have to update. Your backend has to have a service like that. If user doesn't update they can't use the app. Also I pretty much believe that some subscriptions are auto renewal so that's one the reasons why deleting in the play store is not possible. Also take into account that change price would generate almost the same problem. Since you can't change a price of a subscription at least the base price, the country price you can.
Related
I plan to use non-renewing subscription on SaaS app since apple doesn't allow auto-renewable for SaaS.
Apple also requires us to provide a server side mechanism to track the subscription with multiple devices.
But, based on my research, apple also seems to reject app if registration is mandatory, so such user registration must be made optional.
My app can be used without registration at start, so registering is optional at this point. But, if users want to buy non-renewing subscription, registration is mandatory to track the subscription.
Does apple reject this approach?
Related links:
app rejected.how to track user non-renewing subscription
*UPDATE
I checked the session video of WWDC2012, and it seems it is ok to ask user to register with your server BEFORE purchase for non-renewing subs. I will post an answer once they really approved this method.
*UPDATE
I got an reply from apple through Resolution Center.
The bottom line is we should allow user to buy subscriptions without registration anyway.
This is the answer from apple review team.
It would be appropriate to make registration optional. You may provide
an alert stating that the user will not be able to track a
subscription on multiple devices without registering. However, you
should provide the option to register and track a subscription after
the subscription is purchased as well.
I don't have a definitive answer but my understanding (not just a guess) is that you must permit them to purchase the subscription without making an account. You can warn them that if they don't make an account, their subscription won't be portable to other devices, but you still have to let them move forward without an account if they want.
From a technical perspective, you could treat this as "you must allow the user to make an account without any personal information"; they might have an account on your server for receipt validation, etc, but it's not tied to their name, email, udid, etc. The issue is one of privacy, so as long as it's not personally identifiable info you're storing, it's fine to keep track of the subscription so you know when it expires, etc. (It's nice to later let them enter their email if they want so they can make the subscription portable.)
Of course, what Apple approves or not changes over time and varies for other reasons, so YMMV.
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.
I'm writing an app that will support in-app subscriptions. The subscriptions will enable my users to use a number of services and benefits outside the Android world. I know that I can use Google Play Developer API to query the status of a subscription, but due to the nature of the offered services and benefits, it is not very convenient to do that. I was wondering if there is a way to get notified about the status of the subscription when it changes. Something like a web hook for example.
I wanted to post a comment in response to yours, but apparently this was too long. In addition to that, it is also kind of an answer to your question, so I thought this might be a good thing to just post it as an answer instead. Maybe it even solves your problem.
So, regarding your comment. You don't necessarily have to do it that way. Now, I don't know your system requirements, but I'll just share mine and hope it helps you out.
Save Users and Subscriptions on your server (database tables). Have a check_at column on the Subscriptions table, besides a renew_at one. Suppose the user has a monthly subscription created on the 1st of January. On that first day, you call your server from Android after the purchase is finished, save the subscription details, then set renew_at as February 1st and check_at as February 4th, considering you set 3 days as delay for transaction failure in Google Play Developer Console. This way, the user has time from 1st February to 3rd February to change credit card details if the payment fails on the 1st. Then on the 4th you will check the Google Play API for subscription details. But don't disable premium functionality during 1st-4th February. Disable it on the 4th if the subscription was canceled. This way, premium content is not delayed nor tampered with in any way. If the subscription end date returned by the API is in the future, then it was renewed, so you should keep premium activated. Now, how do you check it monthly on the 4th you may ask. Use some kind of scheduler to schedule tasks on the database.
This way you remove the need to rely on webhooks. Although I agree, webhooks would've been more efficient and probably even easier to implement.
Let me know if you have any questions or there are some flaws in the system I described.
Take a look at Real Time Notifications using Google Cloud's PubSub service. It sends notifications of payment/subscription events like: new buy, renewal, cancellation etc. It includes the token which can be used to retrieve additional info from the API like you do now.
You can also configure this PubSub Subscription to call a custom webhook (which still needs to query the PubSub) on each message that you receive.
Okay, something really dumb happened to my friend.
He submitted an Android application a few weeks ago that offers In-App Purchases to the user.
Now, he needed to update the .apk to fix a bug, but he actually lost the keystore that he used to sign the application the other day (what a dumbass...). He tells me it's definitely lost. He exhausted all options to find or restore it, but without success. So, as he understands, the only way to submit the update is to actually create a new application in the Google Play Developer Console. He is so dumb, I always tell him to do backups of important files, he just won't listen (wow, really, such a blockhead...)!!!! sigh...
Luckily, he only had a handful of users who actually purchased something in his app during that time. However, I would like to know (for my friend) if there is any way to transfer the In App Purchases from the same user from the old app to the new one, so that the users who bought something in the app and now want to update it, won't get punished for his stupidity and have to purchase the same items again....
AFAIK, there is no way to do that. The only option is to refund them and ask them to buy again in the new app. I believe refunding can be done by logging in to Merchant account.
Google Play does not provide any form of content delivery. You are
responsible for delivering the digital content that you sell in your
applications. In-app products are always explicitly associated with
one and only one app. That is, one application cannot purchase an
in-app product published for another app, even if they are from the
same developer.
And BTW, Does the app have any backend? Where in he saved data of all purchases made?
Before I ask the question, I have gone through the Android In-App billing documentation, and some similar questions on StackOverflow like this. Also I am guessing this question may be closed or down-voted, as its not a direct programming question and is subjective in nature. But still, here it goes.
The implementation works fine. My question is what would be a good way to store the in-app purchases locally. In my case, there is only one one-time unlockable item which unlocks full functionality of the app, and does not expire or get consumed.
Shared Preferences seems a little too easy for piracy. Even though querying the Google Play works fine and seems relatively secure, is it good enough to rely on? Since the documentation recommends to make the call asynchronously, it doesn't sound like a good idea that the user who has paid for the unlocked features, might have to wait to get access to the unlocked features. Also, when the GP cache is cleared, it takes longer than usual (which might be a rare scenario).
But seeing that there are so many apps and developers, I am wondering how other developers handle it?
Actually i think that your question will be closed for a few different reasons, but i will give you some insights.
You have a few options, depending on the nature of the products, and in some other things.
If the product is valid for life time, or depending on time (for instante, updates for a year) you can rely in google play, and that could be good.
If the product is something that the user will expend in different ways inside the application, such as in-game currency, extra lives, etc, you should save it locally, in a sqlite database, or in a remote database if you want to use a server to centralize some services.
If you take a look at the section "Consume a Purchase" of the guide purchase iab products you can read:
Once an item is purchased, it is considered to be "owned" and cannot
be purchased again from Google Play while in that state. You must send
a consumption request for the item before Google Play makes it
available for purchase again. All managed in-app products are
consumable. How you use the consumption mechanism in your app is up to
you. Typically, you would implement consumption for products with
temporary benefits that users may want to purchase multiple times (for
example, in-game currency or replenishable game tokens). You would
typically not want to implement consumption for products that are
purchased once and provide a permanent effect (for example, a premium
upgrade).
For consumable products:
It's your responsibility to control and track how the in-app product
is provisioned to the user. For example, if the user purchased in-game
currency, you should update the player's inventory with the amount of
currency purchased.
Security Recommendation: You must send a consumption request before
provisioning the benefit of the consumable in-app purchase to the
user. Make sure that you have received a successful consumption
response from Google Play before you provision the item.
Anyways, at any range i would recommend to keep track of all the products that an user buys and all the privileges that he has by yourself, since it is faster, and it could be useful for some other things like custom stats, reporting, etc.
You should use a backend web server if you're concerned about piracy. Google has a web api for checking if a purchase is legit. Have the device contact your web server. Have the web server validate with Google. If valid then let the device download your assets from the server.
If the in app item is not an asset, but a consumable item like in a game maybe have your server return an encrypted string that your app knows how to decipher.
If you rely completely on locally stored purchase info it will be very easy to spoof.