I just run into a problem with in-app auto-renewable subscription. The app contains this kind of subscription and the app can be used by multiple users but the subscription is bind to the apple id is used on the device. So if a different user log in to the app than the system say he has a valid subscription. If I log the subscribed users on my backend server than if a user without subscription log into the app can not make a new subscription according to the Apple's response because the apple id used on the device. An other problem if a keep track of the subscriptions on my backend server if the user unsubscribe on the apple's webpage I can't notify the server about if.
What do I do wrong? What is the right workflow for this case?
I hope do you understand my dilemma.
Thanks!
Your use case is absolutely valid and that's exactly how the subscriptions In-App purchase work with any platform (Apple/Google).
In case of Subscriptions in-app purchase the content delivery is entirely the responsibility of the app provider and not the platform. You have no direct way of identifying if the app user has been switched to a different user as you can't access the current logged in user on iTunes account on the device.
You need to manage this use case on your own by keeping some data locally on the device and maintain user purchase history but still that wouldn't solve the purpose 100%. When user will go for purchase of the subscription it will show the service as already subscribed unless the iTunes user account is also switched on the device.
You can keep track of the unsubscribed state from the backend as when the subscription is successful you will get a receipt from iTunes which you can use to save in your DB. You need to run a backend job on the server side to validate the saved receipt to check the updated receipt which will give you details if the subscription has been expired or not.
Related
I'm wondering, if a user cancels a subscription and are trying to resubscribe am I supposed to present the management portal from within the App Store to this user and let them resubscribe from within the App Store or am I supposed to allow them to purchase a new subscription from within the App itself? It seems as if once a user has purchased the initial subscription from within the app itself Apple wants all other management to be done using the App Store.
I'm not exactly sure how this works and because I cannot access the 'Manage Subscriptions' portal for a sandbox App Store account I can't tell exactly how subscriptions are handled when they expire.
Thank you!
From the App Store subscription management page a user will be able to:
Change their auto-renew status
Upgrade or downgrade to a different subscription in the same group (e.g. change from a monthly to yearly subscription)
Resubscibe to an expired subscription
Paulw11’s comment is correct that you handle a re-subscribe exactly as a purchase in your app (the user won't receive a free trial if they had before). The purchase will go through as a normal subscription and it will be less confusing to your users.
Let's assume we are Netflix. The user created an account on our webpage and then downloaded the iOS app. Within the app he started a payed subscription by purchasing an auto-renewable iOS subscription.
The subscription is added to the user account on our webpage. Thus the user can access the paid content not only within the iOS App but also on our webpage from his SmartTV, etc.
The user can mange his account not only from within the iOS app but also directly on our webpage.
The iOS Subscription is not linked to the iOS app but the users Apple ID account. Deleting just the iOS app does not has any effect on the subscription at all. At the end of the subscription period the subscription would sill be auto-renewed and our server. Our server does not need an installed iOS to recognize the renewal (e.g. using Status Update Notifications or by polling the /verifyReceipt endpoint). Thus the user could still continue to access the payed content even if he does not use/install the iOS App any more. Is this correct?
But what happens if the users decides to delete his user account on our webpage and forgets to cancel the iOS subscription?
In assume the subscription would simple do the same as before and would auto-renew at the end of each subscription period. Since the user account on our server has been deleted the server does not recognize the renewal any more and the user simply pays for nothing. Is this correct?
Or is there any way the server can notify Apple to cancel the subscription?
Question 1: The iOS Subscription is not linked to the iOS app but the users Apple ID account. Deleting just the iOS app does not has any effect on the subscription at all. At the end of the subscription period the subscription would sill be auto-renewed and our server. Our server does not need an installed iOS to recognize the renewal (e.g. using Status Update Notifications or by polling the /verifyReceipt endpoint). Thus the user could still continue to access the payed content even if he does not use/install the iOS App any more. Is this correct?
Ans: Yeah You are right. When you had send receipt to server first time, then receipt will be verify with apple by verifyReceipt, after that your server validate this receipt time to time.
Question 2: But what happens if the users decides to delete his user account on our webpage and forgets to cancel the iOS subscription?
Ans: If user has deleted his user account on webpage then user account will be auto-renew at the end of each subscription period. There is only the way to manage i.e. if a user request for refund after deleting the account, then you can check form server(for deleting his account) and refund his money.
Question 3: In assume the subscription would simple do the same as before and would auto-renew at the end of each subscription period. Since the user account on our server has been deleted the server does not recognise the renewal any more and the user simply pays for nothing. Is this correct?
Ans: No this is not correct. Subscription will only be managed by Apple , not your server. Only your server can hit the request for verify subscription status time to time nothing than else.
Question 4: Or is there any way the server can notify Apple to cancel the subscription?
Ans: No, there is no way. Because of apple security. Server has not any authority to do anything in users account(Apple account). That is the reason apple will never approve your app with auto renew if you will not clearly see the below information to user before his purchasing(Subscription). Please refer attached screenshot.
There is no automatic API for this flow it seems within IAP ecosystem.
Here is what you can do.
Upon (before / after, depending upon how you want it) account deletion from within iOS app, you are obligated to route the user to the following page to remove his / her subscriptions, by visiting the following page:
https://buy.itunes.apple.com/WebObjects/MZFinance.woa/wa/manageSubscriptions
Opening this URL launches iTunes or iTunes Store and displays the
Manage Subscription page.
If account deletion was initiated from web UI, you should show an instructional page for canceling subscriptions from all possible devices (iOS, Android, TV apps, Web). It is then user's responsibility to ensure he / she cancels it.
Since Apple is the marketplace, this is not different from you buying a grocery product from a supermarket. As it is mentioned on Apple docs pages, it is iOS user's responsibility to get in touch with Apple Customer Care for subscription cancellation.
As a service provider, you are obligated to demonstrate to the user how to do it.
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'm creating a service which allows users to register on any number of devices (web, Android, Roku, iOS, Apple TV), and then purchase a monthly subscription to watch video content. The subscription provides access to the entire catalog. I have my own subscription management API running on a server which I'd like to leverage as the source of truth so users can purchase a subscription on their iPad, login to the app on Roku, and continue watching where they left off.
Basically, Netflix.
Here are my options as far as I can tell:
Auto-renewing subscriptions: this is what Netflix uses today, but Apple doesn't provide an API or any set of webhooks around their payment platform, so I don't know how this option could work. My back-end service will have no idea when Apple automatically renews the subscription each month or if a user cancels their subscriptions.
Non-renewing subscriptions: users purchase the subscription inside
the app though IAP. Once purchase is complete, the app sync’s the
subscription to my back-end system. The app interfaces with my
back-end any time an entitlement check is required. When a user’s
subscription is about to expire, the app must present purchase
workflow again.
Import iTunes reports: won't work because it's not realtime (pull, not push) and doesn't tell me anything about cancelled subscriptions. I can only generate reports of new subscribers.
Receipt validation & push receipts to my service: won't work because it depends on the user actually using my app. Users could theoretically subscribe in my app, switch to Roku, and never open it again.
Skip IAP altogether and require users to subscribe via web.
Am I missing something? I'm really curious how Netflix is pulling this off.
For the initial subscription purchase:
User initiates a purchase on the iDevice
Device contacts Apple, Apple issues a receipt and sends it back to the device
The device sends the receipt to my server
The server validates that the receipt is legit through Apple's receipt validation API
Once the receipt is validated, the server stores it in my DB
The server responds to the app saying it's all good
To keep the server in sync with the iTunes subscription:
Setup a cron job to retrieve expiring receipts from the DB on a daily basis or something
Validate each receipt with Apple
Apple will respond with an updated version of the receipt that contains details regarding whether or not the subscription was canceled/renewed/etc.
Server replaces the original receipt with this updated version in the DB
Now if someone logs into their account on a Roku or some other device, the subscription can be honored because my DB is the source of truth.
I know this is old, but Apple recently introduced Status Update Notifactions which accomplishes what the OP asked for via webhooks:
Configure Apple to send notifications to your specified endpoint. (Apple's small guide)
Handle the JSON object that's sent via HTTP POST from the App Store and validate latest receipt.
Update/save data to your database.
Respond with a 200 status code to report a success.
You'll be able to handle the following notification types: INITIAL_BUY, CANCEL, RENEWAL, INTERACTIVE_RENEWAL, DID_CHANGE_RENEWAL_PREFERENCE
The documentation in the link above explains implementation and types in more detail.
I need to build an app for a system, which already has a subscription on its website. It looks like Apple doesn't allow to use any own subscriptions and forces to integrate any app with iOS in-app subscriptions.
Is it any way to integrate two subscription systems? The main problem is that users can manage iOS subscriptions via iTunes and I can't find whether it's possible to get information about this and to stop subscription in the existing system if it's stopped via iTunes.
So is it possible to get notifications about unsubscribed iTunes users?
Using third party subscriptions
First off, it is possible to support an existing subscription system in your app, but it must be in addition to the App Store subscriptions. Also you have to be very careful about the UI you use. You can't prompt users to bypass the App Store and purchase through your server, but you can offer existing subscribers the ability to sign in with credentials they may have previously obtained through your website.
That said, Apple can be fairly capricious in their rulings on what is and isn't allowed in the App Store. I have worked on apps that have done this sort of thing, but they have been for fairly well known magazine publications. There's no guarantee that they will allow it for everyone.
Detecting unsubscribed App Store subscriptions
As for using App Store subscriptions, when a user purchases a subscription in your app, they will receive a receipt in the SKPaymentTransaction object. This receipt should be posted to your backend server to make sure it is valid before you give the user access to anything. See the In-App Purchase Programming Guide for more details.
When you setup a subscription type, you specify how long that subscription lasts. So if you log the transaction date in the SKPaymentTransaction when you receive a receipt, you can determine exactly when that subscription should expire by adding the duration of the subscription to the transaction date.
If it's an auto-renewing subscription, you will receive a new receipt when the subscription is renewed. So once you have validated that with your backend server, you can update your expiry date based on the new transaction date. If you don't receive a new receipt before the first one expires, it's likely the user has cancelled their subscription.
On the backend, your server can also tell when a particular subscription will expire based on the response from the verification server. First there is the status code which will tell you whether the subscription has already expired, but there is also an expiry date returned in the decoded receipt which will tell you when it is expected to expire if it hasn't already.
For more details, see the Auto-Renewable Subscriptions documentation.
Testing auto-renewing subscriptions
It's worth noting that when you are testing auto-renewing subscriptions in the App Store sandbox environment, the length of the various subscription types is dramatically shortened to make it easier to test. For example a 1 week subscription lasts only 3 minutes in the sandbox environment. You can see the full list of times in the iTunes Connect Developer Guide.
So you want the people that have bought the service from the website to be able to use the app, exactly like if they had purchased it from in App Purchases and in App Purchases people to be able to join the service just like people that joined through the site? As far as I know, Apple doesn't allow you to pay through other services as you said, but let's say someone buys the service from the app. What should happen would be that the money will be transferred to the company. Then after the payment you should include some code doing what the site does after a new person has payed for the service, so create his account as a paid account. Then, the app should also have a login screen where the registered users (no matter where they registered from) will be able to login into the app and use the service. Now the problem is indeed that if the subscription is stopped through iTunes you would never know, though a way around this would be to make a check in the server of this company which should monitor the income coming from one account. Then if this user has stopped paying (or stopped the subscription) you would be able to stop the service from the app. And you should recheck the server for payment after the duration of the subscription has passed, let's say a weekly subscription should be checked every week. (Sorry I would do this a comment but I haven't got enough reputation for this)