Lessons Learned Implementing Renewable Subscriptions In A Cross Platform Application
My name is Ryan Lefebvre, I am the founder of LogSmarter™, a full stack software developer and a senior computer science student at University of New Hampshire. If you don’t know about LogSmarter™, we make nutrition tracking software that uses machine learning to help people reach and sustain their body composition goals. Our application uses a freemium model where we give our customers a limited time free trial, then require an auto-renewing monthly subscription once the trial is over to continue using LogSmarter™. In this article, I am going to share 4 things that I wished I had known before I started implementing cross platform renewable subscriptions in our application and the lessons I learned from encountering those problems.
For some context, LogSmarter™ was developed using Angular and Google Firebase. The web version of our software is live and you can check it out at logsmarter.net. By far the most common question we get is when will our mobile app be released? We don’t have a release date for the app yet, but it’s our top priority going forward. The app is in development and almost ready. We are using Cordova to convert our web application into a mobile application and plan to release on iOS first then Android. The end goal is a cross platform application that allows our users to access their data on any device anywhere.
We currently use Stripe to process payments made on the web and will use In-App Purchase for iOS payments and In-App Billing for Android payments. The biggest roadblock that we’ve hit in development is that cross platform subscriptions can be a bit of a nightmare. In general renewable subscriptions can be hard to wrap your head around if you haven’t dealt with a third party payment processor’s API before.
Now, I am going to get into the 4 things that I wish I had known before I started implementing subscriptions in LogSmarter.
- This is probably not going to be a quick task if you haven’t done this before
Before I had written a single line of code for implementing renewable subscriptions in LogSmarter™, I had the idea that this would be a week or two of implementation and then I would be good to go. So many different applications are $5-$15 a month now, so in my head, I was thinking how hard could implementing subscriptions really be? Unfortunately, I was wrong. It took me about two months to get Stripe fully implemented. This was partly because I was working 40 hours a week for my internship when I was developing this so the only times I could work on it we’re at night or the weekends.
One of the biggest things that held me up was trying to design a UI and UX that looked and felt good for accepting credit card information and handling payments. I was following some tutorials online but just didn’t come up with anything I liked or was confident in.
Handling credit card information is tricky and what I ended up doing is what a lot of people do and integrated with another third party service which creates a checkout page for Stripe. This page is hooked up to your Stripe account and all of these services follow a similar pattern. You tell their API what product from your Stripe store you want to create the checkout page for and you send them some metadata that you want to associate with the checkout session like a user id along with a return URL which their page will navigate to when the user is done with their payment. Then their API will return a URL that you can navigate to for the checkout session. If the user purchases a subscription, then a webhook will be sent to a URL you configure and you can respond to subscription state change events.
Unless you have a very specific checkout flow that isn’t possible to be satisfied by using one of these third party checkout pages, I would recommend just skipping trying to create your own and instead finding one that meets your needs. Especially if you’re a small team, it eliminates a lot of development time and the hassle of having to maintain the checkout form as regulations change
2. Stripe does not handle taxes
This leads me perfectly into the next thing that I really wish I had known about Stripe and that is that they do not calculate sales tax for you. This broke my brain when I first found out. It was one of those things I hadn’t even thought about until it was too late. Unfortunately, most guides online fail to even mention this as something to consider.
I wasn’t willing to risk any potential legal issues related to taxes so I ended up educating myself on sales tax and specifically software sales tax. This is a tricky topic because the industry is moving faster than legislation in a lot of places and there are a lot of unknowns. You are absolutely going to have to use a third party service to help with this. There are a couple different ones available that Stripe is partnered with and you can check out on their website.
After consulting my advisers, my team and an accountant, I finally felt confident enough to proceed and landed on using Octobat which is a third party service that integrates with Stripe to create a checkout page that calculates sales tax at checkout time based on customer location. It is actually the checkout page that you saw in the last section.
This was honestly the most stressful part of the whole process of LogSmarter’s development because I had already chosen a separate service to use for our checkout page, but Octobat had by far the cleanest way of handling sales tax that I could find. They also generate some nice reports to help with filing your taxes. Overall the whole learning experience of integrating with Stripe was worthwhile but definitely not an easy or quick implementation for one developer with no prior experience.
3. One payment processor isn’t going to cut it
Once our Stripe implementation was good to go, we did some final rounds of testing and released LogSmarter™ on the web. Things were great but we kept on getting asked about when we would have an app. We had always planned to have an app and we landed on using Cordova to convert our Angular web app into a mobile app with a focus on iOS first. But the third thing I wish that I had known is that Apple doesn’t play well with Stripe.
Apple wants you to use their proprietary payment processor called In-App Purchase (IAP). If you don’t, your app is going to get rejected from the app store so we had no choice. From a developer’s perspective, this is really annoying since we already have a working subscription system implemented with Stripe. But since we want to be on the app store we have to play by Apple’s rules. So far this is nowhere near as bad as getting set up with Stripe was the first time and luckily IAP handles sales tax for you but it does require some development time because you are going to have to make sure your subscription system is compatible with multiple payment processors.
Another thing worth mentioning here is that we have plans for an Android app as well. We are going to have to add another payment processor into the mix which is Google Play In-App Billing (IAB). After the IAP integration we are hoping that getting setup on Android and with IAB will be a lighter lift then the Stripe or IAP integration because we are working to make sure we have abstracted all logic related to subscription state update events and separated that code from the code that deals with integrating with any of the 3 payment processors we are using. Right now it seems like developing the Android app will be a quick process but I’ve learned my lesson about underestimating the unknowns in any large development task.
4. Profit margins will not be the same across different platforms
This is one of those things that was unknown to my team and I before we started working on our IAP integration and it is the final thing I wish someone had told me before I started.
This stems from the fact that we didn’t know we needed multiple payment processors initially and each one has a different pricing scheme. Depending on what your implementation is across the various platforms, you are going to have a mix of fixed and scaling fees. Below this paragraph is a breakdown of our fees as an example. There are other fees associated with development on the various platforms but I’ve only listed fees that are a direct result of processing payments made for renewable subscriptions.
As you can see, you’re probably going to have much better profit margins per subscription on the web then in your apps. Apple has received a lot of flak for taking 30% of profits from developers but they haven’t budged on that position until very recently. Apple just announced that starting January 1st of 2021 they will only take 15% for businesses earning less than $1 million in the app store.
In the past, Apple has had some notable disputes with companies like Spotify and Fortnite where they’ve beefed up their app store review guidelines to prevent pretty much any way of getting around that 15%-30% cut. Google is following in their footsteps. Google policy isn’t enforced yet but developers have until 2021 to integrate with IAB which will also take a 30% cut of whatever you make.
Once you’ve accepted you can’t get around these pretty egregious fees from Apple and Google there are a couple of different strategies you can take with your pricing. You can calculate what you need to price subscriptions on the different platforms to keep your profit margin per subscription the same or you can keep the price the same across all platforms. It’s hard to say what will work best for your business but it’s probably a good idea to experiment and see how customers respond to different pricing models before making a decision. Ultimately, you will want to go with whatever makes the most sense for your business which is something that only you can answer.
Conclusion
That’s all I have to say about how we handle cross platform renewable subscriptions and the lessons I learned along the way. If you want to learn more about LogSmarter™ you can go to our website www.logsmarter.net
