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.
Related
my name is Antony Basta and I am the developer of an app called SecuriKey. SecuriKey allows any old apartment building intercom to be controlled from an app. Users can create entry codes that work once, up to a certain date, or are instantly revokable. There is no need for any new or additional hardware – it works with the buildings existing intercom.
Currently, the app is using Stripe for subscriptions and it was initially approved 2 months ago for the App Store. I pushed an update a few weeks ago and Apple Rejected it because I am not using In-App Purchase (IAP). I submit an appeal, mentioning that we offer a consumable service that takes place outside of the app (guideline 3.1.3(e)), it is effectively a "Reader" app since we provide VoIP numbers to our customers (guideline 3.1.3(f)), and SecuriKey requires hardware to function – that is, it will not work without a physical intercom (guideline 3.1.4). Additionally, we do ship physical goods to our customers (NFC tags and Security Signs) monthly and require monthly service personnel to service the building using the physical goods for our own back end workflow. A lot of back and forth has occurred between the review team and at the time of this post, the app is still being reviewed by the board. I thoroughly believe we fit within all of the mentioned IAP exception guidelines – but that's a conversation for another day.
As I wait, I began to delve into using IAP for this product. I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made, and I am able to create an account and collect a payment. But there's one huge oversight. This is a cross-platform app. Meaning, roommates or family members who use different mobile operating systems, can be logged into the same account. A user may sign up from the iPhone but his/her roommate/family member may have an android that also has access to the service under the same account. Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either.
Has anyone ever dealt with something like this? How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)?
If Apple says you have to use IAPs, you should leverage IAPs and not a payment service provider like Stripe.
I'm confused with what
I was able to jerry-rig the IAP platform to feed Stripe the necessary data through the notifications apple sends when a subscription is made,
means but does not sound like the right thing to do.
Thus, the android user will not be able to change the IAP subscription plan from the android side of the service. Furthermore, a web-portal is being developed, and using IAP will not allow us to modify the subscription via the web-portal either
Your user will have to use Apple's Platform (i.e. an Apple device that they are signed into) to cancel the IAP subscription.
How can you use IAP for a cross-platform application and allow android users to modify the subscription (Whether it be canceling, upgrading, or downgrading)
You can't. Take a look at the IAP experience for subscription services like HBO Max. Accounts are all ultimately provisioned through the same system, but the funding source may differ. When you attempt to manage your subscription, the website or android app could inform you that the subscription is billed via Apple, and send you to a page like this: https://support.apple.com/en-us/HT202039.
If the user has no Apple devices, they can contact Apple Support:
If you don't have an Apple device or Windows PC
You can cancel Apple Music on the web.
You can cancel Apple TV+ on the web.
If you want to cancel a different subscription from Apple, contact Apple Support.
I work for a game developing company which releases at least one game a month. For our true fans we want to start providing a subscription to our games, so they can play all our games (on any platform) without constantly having to buy them.
The idea for iOS is to use the in-app auto-renewable subscription. This results into a receipt which we store in our backend. The backend can validate this receipt and provide the apps with information about the subscription of the user.
This system will solve a lot of problems: You can take the subscription in 1 game, and play all the games as well, on any device you like.
But now we come to the problem: After a month the receipt is not valid anymore, and we need to check in the iTunes store to see if the user still has a valid subscription.
My first idea was to use the "latest_receipt_info" field, to get the latest receipt and validate this. But according the documentation this feature should only be used for iOS 6 receipts:
"Only returned for iOS 6 style transaction receipts for auto-renewable
subscriptions."
source:
https://developer.apple.com/library/content/releasenotes/General/ValidateAppStoreReceipt/Chapters/ValidateRemotely.html#//apple_ref/doc/uid/TP40010573-
Even though I can actually still use this field with my brandnew iOS 10 receipt, I don't think it's smart to use it since it's deprecated.
(another source telling you shouldn't use it anymore: https://forums.developer.apple.com/message/156580#156580)
The advised solution of apple is to implement a SKPaymentTransactionObserver in the app. This will retrieve the latest receipt when it's available, and send this to the backend. Even though this is far from ideal, this could work... however:
This means the app has to be active to retrieve the latest receipt. And in our case it's very well possible a user takes a subscription in app1, and after a couple of days downloads app2, 3 and 4, but never uses app1 again. So in this case the latest receipt will never be fetched (because only the observer of app1 can access the receipt)
To fix this problem we should be able to fetch the receipts from this subscription from any app in our subscription group. But according the documentation on the apple site (https://developer.apple.com/app-store/subscriptions/ ) you can only access a subscription from 1 app, and you have to do the multiple app thing yourself:
You can offer auto-renewable
subscriptions to access multiple apps in your portfolio. Each app must
be approved to use auto-renewable in-app purchases and must be
published under the same developer name on the App Store.
In iTunes Connect, you’ll need to set up separate and equivalent
auto-renewable in-app purchases in each app offered in the multi-app
subscription so that users can subscribe from any app. To avoid users
paying multiple times for the same offering, you are responsible for
verifying that they are subscribers in one of the apps before showing
any subscription options. To do this, consider maintaining an account
management system in which users create an account with your business
to sign in to each app.
So is there any way to do what we want, without forcing the user to go back to the app he used to purchase the subscription every month?
On the last WWDC we went to StoreKit labs and personally asked StoreKit evangelist about this. We were told that the 'latest_receipt_info' field return by iTunes validateReceipt endpoint is exactly what we are suppose to use in order to check if the subscription was renewed or not.
This is not going to be deprecated in the near future but they do have plans for adding some server-to-server communication that solve few of the problems we ran into:
Your server will be able to get notification from Apple regarding any subscription renewal, cancellation, downgrades etc.
In the latest_receipt_info returned by the validateReceipt endpoint few fields will be added, providing information like whether the subscription will be renewed after current one is expired, whether there was a problem charging the user's credit card etc.
Sources:
WWDC 2017 Session 303 - What's new in StoreKit
WWDC 2017 Session 305 - Advanced StoreKit
We run a SAAS Web app and are going to be launching our app in Apple’s app store (up to now we’ve had a mobile Web app).
We want to offer the ability to purchase a subscription in app due to the ease of use for our customers. No problem, we know how to do that.
The question we have is whether there is an easy way to keep our web app's db updated with the user’s current subscription status so if they access our Web app we know whether their subscription is valid.
Ideally it would be great if Apple offered a web hook option where they would post an update to a url on our server. From what I've read this isn't an option.
We can always post the data to our server from the iPhone app when the user logs in, but if the user doesn’t log in on the iPhone for a while the subscription status recorded on our server will be out of date.
How are other people handling this? Are we missing something?
Update:
The closest I've found is this thread: https://forums.developer.apple.com/message/70707#70707
The app gets a receipt the first time it buys a subscription or
restores a subscription. The app can send that original receipt to
anyone's server. Anyone's server can then use that orignal receipt to
verify the current subscrition anytime it wants. You can't do that
with a non-renewing subscription but with a non-renewing subscription
the user must purchase the extension from the iOS device each time
period.
Followed up with this:
https://hetzel.net/2011-04-01/server-side-auto-renewable-subscription-receipt-verification/
And from Apple it sounds like they definitely do not make any provisions on their end for synchronization:
Cross-Platform Considerations
Product identifiers are associated with a single app. Apps that have
both an iOS and OS X version have separate products with separate
product identifiers on each platform. You could let users who have a
subscription in an iOS app access the content from an OS X app (or
vice versa), but implementing that functionality is your
responsibility. You would need some system for identifying users and
keeping track of what content they’ve subscribed to, similar to what
you would implement for an app that uses non-renewable subscriptions.
Late to the party, but I think this is a relevant reply to this question:
https://stackoverflow.com/a/47537279/543423
Hopefully this is helpful to someone :)
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)