3

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.

Chantz
  • 5,883
  • 10
  • 56
  • 79
  • Hey Chantz, were you able to build this kind of system that would verify cancelled subscriptions? I am facing with similar challenges and looking around for solution. – Andrey Feb 03 '17 at 17:09
  • @Andrey yeah, so IIRC then I ran a job every few hours to figure out whether or not particular subscription is active. I dont have the code or any docs any front of me to confirm, since I left this company a while ago. – Chantz Feb 03 '17 at 22:13
  • That is cool, thanks anyway, I feel like I am on the right pass. – Andrey Feb 04 '17 at 15:04

1 Answers1

2

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.

Brad Brighton
  • 2,179
  • 1
  • 13
  • 15
  • Just clarified my question. The payment processors I have integrated, they are solely for when the users subscribes via Web. For users subscribing via iOS devices we will provide only iTunes IAP & not anything else. – Chantz May 15 '15 at 16:16
  • Ok. I'd say your concern about receiving the updates via the app _may_ have merit (though if the content is net-connected, your chances of failing to get the updates seem to be slim). You're still going to have to validate-and-forward via the app or do server-based receipt validation, but either way, the initiation of iTunes-dependent action will be at the device level. – Brad Brighton May 15 '15 at 16:20
  • My concern with relyingg on app was, what if user first uninstalls the app & then cancels the subscription via itunes? They would still be able to view the paid-content on the web since the transaction observer was not present when iTunes sent the cancellation notification to it. – Chantz May 15 '15 at 16:30
  • I agree, that would be a real concern, though the real impact is manageable, I think. With iTunes subs, even if the user doesn't renew, it's still good through the end of the term (that is, no refunds). You will get the expiration date when the transaction comes through originally and you can use that to properly terminate access on the server when that time comes. You may be considering contravening Apple's subscription terms and wanting to terminate immediately, but I don't recommend it. If discovered, I'd wager it would be grounds for app rejection. – Brad Brighton May 15 '15 at 16:37
  • re: immediate termination = Agreed. We ourselves let the subscriptions run out upon cancellation so that's not a concern. I guess we would have to build some processes to verify the receipt every so often & see if it cancelled already. – Chantz May 15 '15 at 17:20
  • "I guess we would have to build some processes to verify the receipt every so often & see if it cancelled already." You'll need essentially the same process anyway to know when the new expiration is on auto-update since there are fail cases for that other than "active termination" (CC expiration primarily). Sounds like a "trivial" addition to existing requirements. – Brad Brighton May 15 '15 at 17:23