iTunes cross-platform IAP subscriptions - how does

Question

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. Skip IAP altogether and require users to subscribe via web.

Am I missing something? I'm really curious how Netflix is pulling this off.

Answer 1

I know this is old, but Apple recently introduced Status Update Notifactions which accomplishes what the OP asked for via webhooks:

1. Configure Apple to send notifications to your specified endpoint. (Apple's small guide)
2. Handle the JSON object that's sent via HTTP POST from the App Store and validate latest receipt.
3. Update/save data to your database.
4. 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.

Answer 2

For the initial subscription purchase:

1. User initiates a purchase on the iDevice
2. Device contacts Apple, Apple issues a receipt and sends it back to the device
3. The device sends the receipt to my server
4. The server validates that the receipt is legit through Apple's receipt validation API
5. Once the receipt is validated, the server stores it in my DB
6. The server responds to the app saying it's all good

To keep the server in sync with the iTunes subscription:

1. Setup a cron job to retrieve expiring receipts from the DB on a daily basis or something
2. Validate each receipt with Apple
3. Apple will respond with an updated version of the receipt that contains details regarding whether or not the subscription was canceled/renewed/etc.
4. 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.