iOS Renewable Subscriptions Overview: Stripe vs. In App Purchases
Two common ways to implement purchases in an iOS application are to use either Stripe or Apple’s in-app purchases (IAP). This applies to auto-renewing subscriptions just as well as one-time purchases, this post will focus on renewable subscriptions.
The Costs
Stripe: 2.9% + $0.30 for every successful card charge
IAP: 30.0% for every charge (reduced to 15.0% for every charge after one year of successful recurring payments per subscriber)
The preferable option of the two is obvious. However, just because you CAN use either Stripe or IAP doesn’t mean your app will get past Apple’s review process. We are dealing with money changing hands, so don’t be surprised if Apple wants a cut. They kind of feel strongly about this, considering they have constructed the ecosystem where these purchases can take place. The questions are, when are you allowed to deviate from IAP? And when must you deviate from IAP?
The Difference: When do we have to use IAP?
The general rule here is if you are selling goods or services “outside of the app” you must use a payment service other than IAP (such as Stripe). If all that you are selling to the user is provided within the app/device itself (aka “digital goods”) then you must use IAP.
IAP example
You are building an exercise and calorie tracker. You have a simple free version but a much more sophisticated premium version. You intend to have your users subscribe to auto-renewing monthly payments in order to use the premium version. Since your app is providing “digital goods” (maybe your using the HealthKit framework and some fancy machine learning technology to analyze the users data and make recommendations) you must use IAP.
Stripe example
You are building a fashion/clothing app where your users can subscribe to a service which sends them a new piece of clothing everything month tailored to their size and preferences. Since you are selling real world goods and services that exist outside of the app/device, you must use something other than IAP (Stripe would be a great solution).
The Gray Area
There is always room for debate, but just keep in mind that Apple has the final say. Whether you believe you can avoid IAP or not, you do not get to decide if your app will reach the Appstore. If you don’t like it you can take your product and go find yourself a different Appstore.
A great example of trying to skirt the steep cost for IAP can be found with Spotify. Even though Spotify provides you with real artists’ audio content, it’s still technically digital content provided via the app/device. You may have noticed this skirting of the rules if you’ve ever subscribed to the premium service. Remember any friction trying to get that subscription? If you look in the app, you’ll notice that you cannot sign up for the premium service on the iOS application, you have to go to their website (which I guess, is free territory)… there isn’t even a link to the appropriate page from the app. Spotify was willing to trade some serious friction in their payment flow in order to dodge that hefty 30% fee. I’d bet that Spotify had to do some serious legal gymnastics and has been in countless talks with Apple for this to be the case.
You may find yourself in a situation where you think the case for your app using “real world” goods and services is debatable. Say you have an app that, if users subscribe, they will receive a monthly phone call from a live celebrity of their choice for a brief conversation (Bear with me here, the example is for the sake of argument).
This app has a real life person involved in the product, but the goods are still digital. In these cases you should reach out to Apple. In my experience, they may not give you a straightforward answer, you may have to wait until Appstore review. In this situation, I believe it’s best to implement both IAP and Stripe in different versions of your app so you can react to their game time decision.
Detailed Technical Comparison
I am going to assume any iOS app attempting to implement auto-renewable subscriptions has a somewhat robust server component and may be a multi-platform application (web app, android app, etc.). I am also going to assume your application has some concept of users and authentication.
If you want auto renewable subscriptions for an app that has no server component (all the content is unlocked in the app itself) you will be definitely using IAP, are in the minority, and may want to consider a different way to collect money (paid app, nonrenewable subscriptions, etc.). You can still use IAP auto-renewable subscriptions (I personally wouldn’t) but most of what I will go on to say won’t apply to you.
Here are the differences between using Stripe and IAP for renewable subscriptions across different areas of concern.
UI/UX
Stripe: You can use a mixture of Stripe UI elements (such as payment info collection ViewControllers) and whatever custom UI you like. You will have to create custom UI for updating payment and cancelling subscriptions as well.
IAP: You will only be responsible for UI explaining the purchase options. The StoreKit framework and system will take over and display standard UIAlerts for subscription purchases or changes. The user will only be able to cancel the subscription via the iTunes store.
Unlocking Content
The main purpose of your subscriptions is to unlock some sort of content. Chances are you are maintaining the status of the users’ subscriptions in database records.
Stripe: Your user entering their payment info will generate a token which you can send to your server. Your server will use this token to create a Stripe customer object and subscribe it to a plan. Your server application will receive notifications about payment successes, failures, card expiration, and other events via webhooks. You can update your users subscription related state upon receiving these events.
IAP: After purchasing a subscription you will have to ask the system for a receipt. This receipt is encrypted binary data. You can send this data to your server which should store it and associate it with the user (it will essentially act as a token). This receipt can be sent to Apple’s servers at any time and Apple will return the most up-to-date decrypted JSON about the state of the user’s subscription. You can update your users subscription related state based on this returned JSON. Apple also recently started offering webhooks (called status update notifications) so you could be notified about certain events (not as robust as Stripe’s webhooks).
Testing
Stripe: Complete testing environment which provides you with all sorts of mock payment credentials. You can test virtually every scenario fairly easily by just using your test credentials.
IAP: Very constrained testing. You must create a sandbox iTunes user with a valid email address and must never sign into any production environment or risk invalidating the sandbox account. You are unable to test the act of cancelling subscriptions as you cannot log into the production iTunes account and there is no sandbox account for cancelling or updating test subscriptions.
Multiplatform support
Stripe: Stripe is built for this, your web and android apps can also use stripe so the interface and subscription state can be completely shared.
IAP: None, you will likely have to leverage a mixture of IAP (for your iOS app) and other payment processing services for other platforms. You will have to create a way to consolidate the subscription state in your database.
Dashboard
Stripe: Comprehensive web dashboard with many features and settings. Complete control over individual subscriptions (refunds, cancellations, etc.). Dynamic control over subscription plans, customer outreach, analytics integration, and more.
IAP: None. There is some new visual representation of your user base’s overall subscriptions in iTunes connect… but there is no interactive dashboard that offers you dynamic control over the subscriptions you offer or the current subscribers.
Conclusion
It’s fairly obvious that Stripe is the preferable option of the two (To be fair their whole company is based on being the best solution for things like this). The real problem is that we may not have a choice in the matter. It seems that Apple is making an initiative to improve their auto renewable subscription service, yet (in my opinion) it is still miles behind Stripe in terms of being a “pleasure to work with”. It’s nice that they are trying to improve their service. After all, they don’t really have to offer a very competitive alternative when you have nowhere else to turn for subscriptions
That’s all please give a clap and stay tuned for any code examples on how to implement the two different renewable subscription services!
