I was a web developer for nearly 20 years before I ever built web pages that accept payments from customers. I'm not sure if that's a comment on my career in particular or the industry as a whole. But the day finally arrived in 2013, when we at ThinkUp decided to try something uncommon: build a web business supported by customer subscriptions instead of advertising.
Since then, despite relying on third parties to handle all the complexities of credit card transactions, we've developed and deployed seven billing-related projects. SEVEN BILLING PROJECTS. It's April of 2015 now. That means our tiny team launched a new billing-related project every two to three months. In short, during the entire existence of our business, we've been constantly occupied by designing and building a system tangential to our actual product (albeit core to our business).
In order to assure myself that I'm not crazy for being tired of billing-related code, I'm documenting our journey so far here. Maybe it will help someone out there make decisions about their new subscription-based web product.
Project 1, October 2013: DIY Crowdfunding
Before we launched ThinkUp, we wanted buy-in from the community. As an open source project built for the community by the community, it made sense. Given the rise of Kickstarter into the mainstream and the audience that my co-founder and I had through our writing and podcasting, we knew we could pull off a successful crowdfunding campaign. We also knew that ThinkUp would be a subscription service, and we wanted to start capturing recurring payments from day one. At the time, Kickstarter and other crowdfunding platforms didn't support recurring payments. (Patreon hadn't launched yet; but it wouldn't have made sense for us anyway. ThinkUp is squarely a subscription service versus arts patronage.)
We knew we'd have to write a subscription billing system anyway, so why not start with the crowdfunding campaign? Following in Kickstarter's footsteps, we decided to use Amazon Payments over more developer-friendly options like Stripe to collect payments. Anil and I both loathe entering credit cards into web pages. Our target customers already have Amazon accounts. We felt that the user flow for backing Kickstarter projects, which ThinkUp would emulate, was so smooth and easy it would enable even impulse backers to pledge a subscription on their tiny mobile device screen.
Because it was a crowdfunding campaign modeled closely after Kickstarter's flow, there was one particular requirement that had serious repercussions for us down the road. During the campaign we'd collect credit card authorizations—agreements from our backers to let us charge them when the product was ready. We promised we wouldn't charge anyone until January, when ThinkUp was available for them to use.
This had two big implications on the backend: first, we'd have to use Amazon Flexible Payments Service, Amazon's more advanced, customizable payments API which allowed apps to collect authorizations first and not charge till some much later date. It also meant we could put off writing any software that performed actual charges until later.
So while over 1,000 backers gave us permission to charge their Amazon account a lot of money in aggregate, our system wasn't ready to do that—until a special day in January, the 17th, when it was time to run the charges. That day we collected a lot of money from our backers—and a hell of a lot of payment failures.
Remember the Target hack? Forty million credit cards were compromised, and a great deal of them were owned by people who backed ThinkUp's crowdfunding campaign. In the time between ThinkUp collecting the authorization to charge their card, and the charge itself, almost a third of our backers had changed their credit card thanks to Target. And thanks to things like Gmail's Priority Inbox (a majority of our subscribers use Gmail), spam filters, and just busy people who don't get through all their email every day (like me), a majority of those failed payments went unfixed because backers simply never saw the multiple emails from us and Amazon alerting them to the failed payment.
While I am eternally grateful to every single human who backed our campaign, failed payment or not, it was a bummer.
Project 2, March 2014: Annual subscriptions
ThinkUp launched on time to its crowdfunding backers in January, but it was available to only them. We weren't yet open to the public. Mostly this was because ThinkUp the product had a lot of bugs to work out, but we also didn't have the billing system in place to collect an authorization and charge it immediately. Each day, by hand, I'd run a script that collected stray charges left over from the crowdfunding campaign, and we scrambled to put out instructions on how to update your payment method and fix failures.
In March we finally opened up to the public, and began accepting annual subscriptions on the spot. We were still using Amazon's Flexible Payments Service, with the key difference that the charge happened immediately after the authorization. The immediacy of the charge cut down on payment failures a whole lot.
Project 3, July 2014: Free trial
Once ThinkUp was open to the public, the software was a reality, and we'd exhausted the goodwill of crowdfunders who were inspired by an idea presented in a video, it was time to get real. ThinkUp's annual subscription price was pretty high ($60/year for members, $120/year for Pro plans). Without a way to try the app out first, our subscriptions slowed to a trickle, and cancellations after a week or two of using the service spiked. We had to offer a free trial.
Our one big requirement for the free trial was that we could say: "Credit card not required." We hate free trials that collect your payment information upfront, and then when you forget to cancel, charge you automatically. So, on the backend, this project had less to do with billing, and more to do with building in a trial state where the user hadn't paid yet but was still getting access to the full app. We also needed reminder emails letting trialers know they had X number of days left to pay in order to keep their account active.
Once we launched free trials, it was a thrill to see so many people try out the app. This is when, as a business, we started concentrating on converting users—not just from landing page to signup, but from trial to paying subscriber.
Project 4, August 2014: Monthly subscriptions
With free 14-day trials in full swing, we poured a great deal of effort into making the first 14 days of app usage the best they could possibly be, in order to convert more subscribers. But the annual subscription fee was still pretty high, and we fiercely debated internally if we could market a $60/year product as $5/month. Not until our customers could actually PAY monthly, I argued.
It wasn't until we had to offer monthly subscriptions that all the highly-customizable-but you-gotta-do-it-yourself of Flexible Payments Service (FPS) became a liability. I didn't want to create cron jobs that ran daily charging people on a monthly basis. That figured out if someone paid on January 30th that it should recharge them on February 28th the next month. That had to deal with timezone stupidity. That meant we lost revenue if our servers had a problem. I wanted someone else to handle all that for us.
We were still convinced that Amazon Payments was the best user interface. So, since we wanted to stick with Amazon Payments, we switched to Amazon Simple Pay, a wrapper for FPS that handles recurring charges for you. Subscribing to a service via Simple Pay was still a one-click affair, and Amazon did all the recurring charges for you. Great!
Around this time, our Amazon Payments account manager got in touch, pitching Amazon's new payments product, Login and Pay with Amazon (LPA). He wanted to set up a call about ThinkUp migrating to LPA. I looked at LPA's documentation, and it appeared to be built for web sites selling physical products, geared towards businesses who needed a full shopping cart experience and had to collect shipping addresses. It didn't offer subscription management. That wasn't for us.
In a decision I regret to this day, we decided to go with the older, established Amazon Simple Pay instead of the new Login and Pay. Even though LPA didn't offer features we needed, I ignored very obvious signs that Simple Pay was no longer on Amazon's roadmap. The code libraries hadn't been updated in years. For a business as small as ours, our Amazon account manager pursued us with a lot of persistence to consider switching over.
Project 5, November 2014: Coupon codes
It's not easy getting consumers to pay for recurring subscriptions on the web. In an effort to boost our sales during the holiday season and give users the opportunity to give ThinkUp as a gift, we launched The Good Web Bundle. A partnership with four other subscription sites that we love, a user could purchase the "bundle" for a discounted price. When they did, they received a coupon code they could redeem at ThinkUp and at the four other sites for one year of use.
The big difference between this project and the earlier work we'd done was this was the first one-time purchase a user could make. We used Amazon FPS to give users a link to make that one-time purchase, then emailed them a unique coupon code. Just like the other four sites, we built in the ability to redeem that code for a year of ThinkUp in our membership system. Similar to free trials, this was a matter of creating a non-recurring subscription state in our system that ended on a date exactly a year away from redemption.
It was around the bundle's launch that we heard a troubling rumor from a reliable source. Amazon was going to discontinue Flexible Payment Service (including Simple Pay), and go exclusively with Login and Pay. Kickstarter was switching to Stripe.
THAT put a damper on the holidays.
Project 6, January 2015: First annual renewals
In January, our first annual renewals were up from the crowdfunding campaign. Since those came in via FPS and not Simple Pay, we'd have to recharge them manually. We were hyper-aware that most crowdfunding campaigns do NOT charge you again a year later, so we spent a good amount of time writing and designing email notifications for crowdfunders informing them that their annual renewal was coming up. We sent one 2 weeks before the member's renewal was due, and one week before. I wrote code that gave users the ability to close their ThinkUp accounts and get a pro-rated refund via FPS right inside ThinkUp. (Prior to that, they had to email us, which sucked.)
Then, each day we ran the annual renewal charge job by hand as members came up on their renewal date. There were a ton of payment failures again, due to expired or changed credit cards, and a good number of users closed their accounts because they hadn't used ThinkUp as much as they thought they would. That is understandable, if hard to watch. I was glad to finally give our members a guilt-free escape hatch if they wanted out.
Project 7, March 2015: End-of-life
In January, Amazon made the announcement official: Amazon Flexible Payments Service (FPS) would be discontinued effective June 1, 2015. Worse! Existing subscriptions would NOT get automatically migrated over to Login and Pay. Our customers would have to come in and pay again.
In short, the payments API our entire business was based on, and the sole source of our revenue, was going away. I'll be honest: I spent a couple of weeks feeling crushed. We'd worked hard to acquire every single paying ThinkUp subscriber, and we know that in the transition, because of lost emails or busy lives or second thoughts, we will lose customers. Not to mention rewriting our billing interactions and backend again to work with Login and Pay.
We thought long and hard about moving to Stripe. To Amazon's credit, our account manager and a solutions architect spent a great deal of time with us, offering help, making suggestions, accepting bug reports. Login and Pay does not offer subscription management, and that was not software I wanted to write in-house. Among a handful of other products, Amazon suggested we check out Recurly, which offers recurring subscriptions via Login and Pay. Beyond offering way better customer management features than Amazon Payments itself does, Recurly offers integration with Stripe and PayPal, generates customer invoices, and made offering both a monthly and an annual subscription plan very easy.
So, last month, we removed the Amazon Simple Pay code from ThinkUp, and we're now accepting payments via Login and Pay with Amazon (by way of Recurly). The customer experience is just as simple as it always has been, with one additional choice: between a monthly or a discounted annual plan. Recurly, of course, takes a cut, but given the dev time they saved us and the features we'd never build by hand, it's worth it.
Having been through these past 20 months of billing system development, I truly appreciate the value of app stores, and how they let software developers worry about their software instead of accepting payments.
It might seem like the moral of the story here is "Don't depend on third-party billing services—especially Amazon Payments!" But I don't believe that. As a small startup you don't have a choice about depending on third-party services that could get pulled out from under you on any given day. Even all this was more efficient than building our own in-house credit card transaction service. And there's no telling how things would have played out if we had, say, gone with Stripe from the beginning. Maybe we would have skipped a lot of steps in this journey so far and had a ton more time to focus on ThinkUp the product versus handling subscriptions. Maybe we would have had a lot fewer customers who didn't want to enter their credit card into a new app they didn't trust yet. Maybe in the end the dev time we saved would equal the revenue we'd lose. (Though I'm not sure Stripe would have supported delayed charges the way Amazon FPS did at the end of 2013.)
When I started building subscription payments into ThinkUp, I had zero experience and only vaguely understood the difference between a credit card authorization and a charge. I was dumb. Today, so far, I'm really happy to pay someone (sometwo, actually, between Recurly and Amazon) to do the work of dealing with payments, invoices, recurring charges, and expired credit cards for us.
Amazon FPS and Simple Pay will stop charging our customers as of June 1. Between now and then, our EIGHTH billing project will be asking our current customers if they will re-pay for their subscription. Wish us luck.