I have some subscription-based content that should be accessible to the user from their iOS app and from the website as well. My understanding of in-app purchases (IAP) on iOS is that I have to set up some "products" in the App Store that the user then "subscribes to" from the app. Apple provides functionality (detailed here and here) on how to check subscription status from within the app in this case.
My question is :
What if i want to allow the user to access their subscription on the website ?
Is there a way to check the status of an IAP subscription in the App Store to see whether it is active or not from my web server ?
It's not clear from Apple's documentation whether this is the case.
Validating Receipts With the App Store
This is the documentation from apple on how to validate a receipt with iTunes. This does not necessarily have to be done from iOS. Once you send the receipt data to your web service you can make the same call directly to iTunes from there as well.
So to answer you questions:
1- Once you validate the receipt with iTunes from web, you can upgrade the user account to have a subscription.
2- You can validate the receipt data with iTunes whenever you like, in the response from iTunes one of the fields is the latest user receipt. This will allow you to check if the user still has an active subscription or not.
Related
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.
Lets say I have website where user can purchase subsciption x,y,z and I have app where user can also buy same subsciption. What happen when user alredy bought sub on website and then login to app? Can we push informations to apple server or just check in app with our backend if user has sub and ignore apple?
For the multiple plateform scenario you have to maintain the server DB along with the status of the account is either purchased or not. If user is paid then which type of subscription (x,y,z) it is. For app (android, iOS), you have to use API's and for web you have fetch data from server DB.
Can we push informations to apple server.
No, you can not do this. Apple IAP data only maintains that you have purchased from the IAP. And same as for the google in app purchase.
Hope now you have been cleared.
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.
here's my straightforward question:
is it allowed for my iOS application to force users to log into my custom account management system, so I can link them to my backend when they want to purchase a non-renewing subscription?
Here's the backstory:
I have a non-renewing subscription. For a good amount of users I can see that the Apple receipt does not contain information about this subscription; the in_app array is empty. This is correct according to the API:
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
The in-app purchase receipt for a consumable product or non-renewing subscription is added to the receipt when the purchase is made. It is kept in the receipt until your app finishes that transaction. After that point, it is removed from the receipt the next time the receipt is updated—for example, when the user makes another purchase or if your app explicitly refreshes the receipt
For some users, I can still see the purchase in the receipt, but let's consider that a bug from Apple and follow their API documentation to the letter.
(More on why this is a bug here https://forums.developer.apple.com/thread/22345)
In order to restore the user's purchase, I'd need something to identify him with. I could create a unique token, store that on the iCloud keychain and use that across the devices to detect the purchase belongs to that Apple account, but since my application supports account creation, I'd rather just use that mechanism. Else I'm using two different methods of purchase detection side by side: iCloud keychain token or a user account.
Thing is, I'm not sure I am allowed to force users to make an account before making a purchase. Is this something Apple would reject the app submission for with a message like "Your users must be able to buy stuff without going through your lengthy account registration process" ?
From Apple :
Non-renewable subscriptions. Subscriptions that don’t involve
delivering episodic content. Examples include access to a database of
historic photos or a collection of flight maps. It’s your app’s
responsibility to make the subscription available on all of the user’s
devices and to let users restore the purchase. This product type is
often used when your users already have an account on your server that
you can use to identify them when restoring content. Expiration and
the duration of the subscription are also left to your app (or your
server) to implement and enforce.
https://developer.apple.com/library/ios/documentation/NetworkingInternet/Conceptual/StoreKitGuide/Chapters/Products.html
So its your app's responsibility to check that user has valid subscription or its over and let them purchase it again !
For this you will ask user to first make account or login into app so by this way you can track their subscriptions.
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.