My app implements the iOS auto-renewing subscription to access premium content. I haven't yet submitted this for approval, because I want to know what subscriber information I'll be able to access once users purchase subscriptions. I need this information so that iOS app subscriptions integrate with a separate business database handling subscriptions on other platforms.
My reading of the typically-cryptic Apple docs is that name, e-mail and zipcode are available but only if the user explicitly opts in. But I'm not clear how to request that this information be asked for during the purchase process, or whether there's additional information I can ask for.
So here are my questions:
Are subscriber name, e-mail and zipcode the only pieces of information available via iTunes Connect?
If (1), is this information available only through opt-in?
If (1) and (2), how does the opt-in process work?
I think so. Although I've never received this info, based on the dialog below, I can only assume you don't get more info than they list.
Yes. You can't require the information. You'll only get the information if the user opts in.
You don't have to request that the user be prompted. In fact, you can't prevent the dialog from appearing when the user first subscribes to your auto-renewing subscription.
From Marco Arment's post on The limited world of auto-renewable subscriptions:
There’s no way for a developer to opt out of this data collection and
disable this dialog. If you sell an auto-renewable subscription, your
customers will be told that you want their personal information, and
you will be given that information [...] whether you wanted it or not.
Please read the rest of his post to see why you may want to steer away from ARS. Apple may reject your app if you're not a magazine or newspaper.
This is what the dialog looks like:
Related
I have 2 auto-renewing in-app subscriptions being reviewed by Apple, but I keep getting rejected. Note that this is not related to IAP product (which apparently have not yet been reviewed) but instead to how I present the information in the UI. I can never get Apple to say expressly how to overcome the rejection. I appealed it once and it was again rejected, although I did put the requested information in the metadata and in the binary. I changed the flow of the app so that I present the information as soon as the user chooses the subscription and before I send the purchase request to the StoreKit. Apple apparently thinks that I am "adding to" the StoreKit modal alert, but I am not. I am presenting the information in a UIAlertController alert BEFORE the user requests to Buy or Restore. All of the buy and restore code is thoroughly tested, but I am stuck at this UI rejection.
Here is the rejection notes from itunes connect:
Guideline 3.1.2 - Business - Payments - Subscriptions
We continue to find that your app and its metadata did not fully meet
the terms and conditions for auto-renewing subscriptions, as specified
in Schedule 2, Section 3.8(b).
Your app's binary did not include:
– Information about the auto-renewable nature of the subscription –
Links to the privacy policy and terms of use
While your app displays subscription information in a modal alert,
this information must be clearly listed within the app itself before
the user initiates the in-app purchase. Displaying this information in
a modal alert is not sufficient.
Your app's metadata did not include:
– The length of the subscription – A privacy policy in the Privacy
Policy URL field of iTunes Connect
For your convenience, we've included Schedule 2, section 3.8(b) below.
You clearly and conspicuously disclose to users the following
information regarding Your auto-renewing subscription:
– Title of publication or service
– Length of subscription (time period and/or content/services provided
during each subscription period)
– Price of subscription, and price per unit if appropriate
– Payment will be charged to iTunes Account at confirmation of
purchase
– Subscription automatically renews unless auto-renew is turned off at
least 24-hours before the end of the current period
– Account will be charged for renewal within 24-hours prior to the end
of the current period, and identify the cost of the renewal
– Subscriptions may be managed by the user and auto-renewal may be
turned off by going to the user's Account Settings after purchase
– Links to Your Privacy Policy and Terms of Use
– Any unused portion of a free trial period, if offered, will be
forfeited when the user purchases a subscription to that publication,
where applicable
Next Steps
To resolve this issue, please revise your app or its metadata to
include the missing information. Adding the above information to the
StoreKit modal alert is not sufficient; the information must also be
listed somewhere within the app itself, and it must be displayed
clearly and conspicuously.
If the above information is in your app, please reply to this message
in Resolution Center to provide details on where to locate it.
You should try to look at what other apps are doing to get an idea of what is required. Here are the things they asking for:
1- Information about the auto-renewable nature of the subscription:
For this you need to include this section from the apple contract in you app. I think they don't want you to use a UIAlertView for this. This might be what they are referring to by 'a modal alert'. This is the text you need to include (exactly or rephrased):
• Payment will be charged to iTunes Account at confirmation of purchase
• Subscription automatically renews unless auto-renew is turned off at
least 24-hours before the end of the current period'
• Account will be charged for renewal within 24-hours prior to the end of the current period, and identify the cost of the renewal
• Subscriptions may be managed by the user and auto-renewal may be turned off by going to the user’s Account Settings after purchase
• Any unused portion of a free trial period, if offered, will be forfeited when the user purchases a subscription to that publication, where applicable.
Here is an example of how evernote does it:
2- You also need to include links to you privacy policy and terms of use inside the app. You can put these the same place you put the information above
3- You need to include the length of you subscriptions in app description from itunes connect. (e.g monthly and annual subscriptions plans ... )
4- You need to put you privacy policy in the privacy policy URL field:
My app was approved this morning. The two keys that led to approval are: 1) putting all of the requested information into the metadata in the Description field on itunesconnect; and 2) changing the UI to a tableview controller with all of the requested information in a UITextView inside a static cell, with active links to the terms of use and privacy policy. Given my experience, I doubt that the way Evernote did it in a comment on this thread will work in the future (it looks like a UIAlertController modal alert, which has been one of the sticking points in my case - Apple absolutely does not want modal alerts, apparently because the user must click on something to display the required information). In contrast, the solution that worked for me was to have all of the information passively displayed in a tableview, and to have the in app purchase selected by clicking on a row in the tableview.
Evernote have updated their subscription purchase flow slightly since the screenshot above. It's still a very good example of how to do this well without the mandatory "Your iTunes account..." stuff getting in the way of the purchase process.
Note that Evernote now have links to their Privacy Policy and Terms of Service just below the monthly / yearly purchase options.
We want to use auto-renewable subscriptions in our app (iOS/Android). But I don't understand what is the best way to sync these subscriptions between devices and platforms.
We are using user email for authentification but it seems that all subscriptions are linked to user's Apple account.
Does it mean that I can't sell subscription to some user if another user (from the same device) already bought one on this device because this device is already subscribed?
What is the best way to sync subscriptions between platforms? Should I write some server code to check subscription status for the current user? But, again, right now I don't have any information about user except his/her email. Of course, it is possible for me to put subscription status on our server but what to do with this case:
user A bought auto-renewable subscription on iPhone from the app;
user A cancelled this subscription via subscription management (app doesn't know anything about it yet)
user A logged-in on Android device, and he is subscribed because I don't have any information about him/her cancelling his subscription yet.
I understand that I am able to check his/her subscription status from my server, but his/her in this case means I am able to check his/her Apple account status, not his/her account in my app. So, for example, if I have two/three/million users on the same Apple device (first is a paying user, and the second cancelled his subscription) it means that I will always get the good receipt from Apple, right?
It's possible that my understanding of how it works is not very good, or, maybe, I can't see the good working pattern here, but I don't understand how to create convenient subscriptions that would work for iOS/Android both.
At the same time I know it's possible because of Wunderlist and dozen other apps with this functionality. Could someone please describe high-level logic behind that?
If your app offers auto-renewable subscriptions, you can receive server notifications from the App Store about key events by setting up an optional URL that links to your server.
https://help.apple.com/itunes-connect/developer/#/dev0067a330b
I need to get the user billing address and full name, is it possible to get such information after the user finishes an In-App Purchase or do I need to request it from the user itself?
You cannot get such information from the in-app purchase. Apple is very strict on sharing personal data of users.
Your only option would be to ask users to provide these voluntarily. Although to be honest I would be very reluctant to share such info myself. Why would an app developer need my private address?
Situation:
- User makes an IAP and is awarded some content, we store the users device id to ensure they can access this content whenever they want.
- User decided they do not like the content, so they call Apple and get a refund.
- User can still access the content, even though they have been refunded for their IAP
Problem:
We don't want the user to be able to access this content anymore. This could become a loophole that they would take advantage of. (unlock content, then get refunded and keep their access to said content)
Question:
Is there any way for us to check if a user has been refunded for an IAP with either their transactionId, transactionReceipt, or any other information we may have?
For Reference, I've read the StoreKitGuide, it did not mention this case.
No. There is no way to revoke access to content if they have been refunded. I believe this is by design. It is the same with App Store refunds; if someone buys an app and then asks Apple for a refund, Apple does not stop the user from continuing to use the app.
No. you cannot stop user to access. Apple does not stop user to use that feature after refund
Below a recent answer from the overbearing Apple!!!
At April 11
Hello Joe,
Thanks for your quick reply at first.
I think there were some misunderstandings. We understand that you must protect the user information. And we do not require any user info. We do not require any user's information---- iTunes account, User Name, email address and other information about himself/herself.
We require only one data----- transaction id (named "transactionIdentify" in your code), for example "1000000033409668" (this transaction id is a record at March 13).
A user buys a product from IAP, you will generate a "transaction id" and send it to us. This transaction id is stored in our database then. Now he/she gets refunds from you, so please send the transaction id to us. Let us know which one in the game canceled the IAP.
When a refund occurs, we think you should provide the transaction id to us. With these data, we could make a more fair service for all players. If you do not do it, more and more players will use your refund mechanism to get game items without real payment. You and we will lose money then. We think it is very important.
Regards,
Baibo
At April 12
Hello Baibo,
Thank you for following up with me regarding the refund transaction data.
We will not be able to provide you with the refund transaction data you have requested as it is not a feature or benefit provided to you per the contracts you have agreed to.
To view your paid applications contract and review your membership benefits, please access the contracts, tax and banking module within iTunes Connect:
http://itunesconnect.apple.com
If you are not happy with large refunds, you may want to consider adjusting the price of your in-app purchases as we will not be able to provide you with the refund transaction data in the future.
According to an answer one of my users received from Apple, refunding an app means they will no longer receive updates to the app, but doesn't remove the app from the device. IAP appears to work the same.
I am wondering if there is not a way by using restoreCompletedTransactions to check for the iAP purchase, but this would pop up a request for the user's iTunes password, so its use is limited.
We are building a subscriptions based video on demand platform that lets our subscribed users to access films from a variety of devices including iOS, Web etc.
So no matter from where the user has subscribed, they should be able to access the content from any & all devices that we support.
Since I need to maintain user's state at a central system (so that all devices can query & allow/disallow access to paid-content).
I have read through multiple documentation re: iOS In-App Purchases & have determined we are a good fit for auto-renewable subscription category.
I have already integrated subscriptions via Roku & using that as a reference. For users who are subscribing through the Web, I have also integrated payment processors like Amazon Payments, Stripe & PayPal - the transactions for which are triggered by the Subscriptions Billing platform that I have already built.
My server (or an endpoint essentially) needs to be able to receive following bits of information preferably directly from iTunes and not from my app.
Notification when a user subscribes successfully to one of my products
Notification when iTunes sucessfully renews a subscription i.e. if user is subscribed to a monthly product then at start of next month, I need to have notification from iTunes that user has been successfully charged for upcoming month
Notification when iTunes successfully refunds a user for whatever reason
Notification when a user cancels a subcription directly from iTunes (not from the app). I know in this case it will mean that it stops the auto-renewal, but I still need to know that this has happened.
Notification when a user un-cancels the auto-renewal.
Does iTunes support any of these actions via Webhook or Push or IPN (instant payment notifications) etc? I havent come across it, if it does.
I know that there is something called as Validating Receipts but that seems to be not a good solution for me, since I need to know ASAP rom iTunes that one of the above flows has happened.
What, if any, are the workarounds to get this information? I am afraid that getting this info from my app is neither timely nor guaranteed to get it.
If you're expecting a direct feed from iTunes, you need to reevaluate your requirements. The in-app purchase ecosystem simply doesn't work that way. You may have the option to write your own subscription processing system (requires an outside payment processor) but whether Apple will approve it will depend on the exact nature of your content. From your description, you have mutually-exclusive requirements.
If the immovable requirement is that you use iTunes, you will need to validate receipts and forward those results to your server.