SaaS Subscription Billing, or How to avoid getting your n*ts in a vise
On Obsidian Portal we’re thinking of moving from Amazon SimplePay subscriptions to Chargify. I wanted to clarify my reasons and my thoughts, and I thought this might provide some helpful insight to other people who are trying to decide how to charge subscriptions for their SaaS app.
As a bit of background, we have been charging subscriptions with Amazon for a while. We started using Amazon Flexible Payment System (FPS), then recently moved to SimplePay, which is a simplified API built on top of FPS. We’ve never used PayPal, and we’ve also never accepted credit cards directly. Our main goals were simplicity of development and quick release. Fees and such didn’t really factor in, except for setup and monthly fees, which definitely were a major deterrent when trying to accept credit cards directly. I didn’t want to pay a $200 setup and $30 monthly fee when I wasn’t sure anyone would subscribe.
The decision of payment provider is a big one, with ramifications far beyond what I expected. I thought it would be about per-charge fees and percentage rates, but the real issues were vendor lock in and inflexibility. If I had it to do over again, I would have skipped right past Amazon and gone directly with credit cards. Here’s why…
Note: I’ve changed my mind recently about a lot of this, or at least my particular decision to use Chargify. Read below for more details.
Subscription modifications without user input
This cannot be overstated. If you can’t modify your subscription pricing without user interaction, then your hands are seriously tied. Unfortunately, this is the case with Amazon, and I believe it’s the same with PayPal.
Now changing someone’s subscription without their input may throw up some red flags, but before you get suspicious, realize that I’m not suggesting stealing behind someone’s back. There are many legitimate cases where you need to change a subscription, and I’ll give you an excellent example: please-dont-go pricing.
What if a user wants to cancel their subscription? Wouldn’t it be nice to offer them a discount period if they would reconsider and give it another shot? The phone company does it. So does the cable company. Why not your web app? Give them another year at 1/2 price, and you both win, assuming 1/2 of full price is better than $0 (definitely true in my case). Plus, implicit in this is the assumption that it jumps back to full price at some point.
Here’s the workflow if user input is required to update subscription pricing:
- User decides to bite on your reduced price offer.
- User is sent to 3rd party payment site (Amazon, PayPal), agrees to new discount terms.
- Live happily for a payment cycle or two.
- Discount ends, you want to switch them back to normal pricing…now you need to get them to come back and redo it.
Good luck on that last step. Most likely, they ignore the nag/email/whatever you throw at them. 2nd most likely, they cancel outright. Least likely, they resubscribe at the higher price.
This is just one example, but there are dozens of possible scenarios where you want to legitimately adjust payment terms, and the user should not need to be involved. Trust me on this:You will want to change your prices in the future for existing subscribers.
Failed Charge Processing (Dunning)
When we first set up billing, the number of failed transactions astounded me. Maybe 1 in 20 would fail. As time went on, it slowly increased to probably around 1 in 10. The payment credentials we had were rotting before my eyes. Looking back now, it’s obvious. Credit cards expire, get cancelled, get maxed out, etc, etc.
But what do you do? Cancel their account? Lock it down? Send a reminder? There are a lot of options, but guess what? They all suck. Moreover, they all require a lot of code. Code that doesn’t really go to improving your overall app. Instead, you’re writing lots of edge-case payment handling crap that really, really sucks. It’s probably buggy, poorly tested, and it deals with real money. That’s a recipe for pain.
This was the main reason we switched to SimplePay. Amazon promised to handle this process (called dunning). It’s a godsend. They retry the transaction a couple times, nag the user to update their credentials, then if nothing happens, finally send us a notification that we need to cancel the subscription.
If your provider doesn’t do this, they are worthless. Move along, no questions asked. This is a big selling point for Chargify, which leads me to believe they know what they’re doing. They speak directly to my pain, so I know they’ve been there.
Defer / Skip Payments
If you’re like me, your favorite prize to give users is free subscription time. It doesn’t cost you anything (usually) and gives them yet another taste of the good life. We give it as a reward for users doing things, as a giveaway for promotions, and as a way to smooth over hurt feelings.
At least, we did until we switched to Amazon SimplePay. With SimplePay, there is no way to defer a charge. If a user signs up for a monthly subscription, I can’t not charge them. The only way to give free time at this point is to say, “Ok, when you cancel and stop paying, it will be tacked on the end.” Wow, what a great deal.
I’m not sure if Chargify can do this, but it’s definitely a nice-to-have. Not as important as dynamic pricing and dunning, but still nice.
The Credit Card number
This is the Holy Grail / Hot Potato of subscriptions. Someone needs to have it in order to execute the charges, but whoever has it is holding something very dangerous.
Amazon and PayPal completely wrap the card so you never touch it. That means you’ll never get in trouble, but you are totally locked in to those services. There is no way to move people from PayPal to somewhere else without getting them to resubscribe. Once a PayPal subscriber, always a PayPal subscriber.
Now, I’m unfamiliar with other providers, but I’m assuming they work the same way. They lock the CC in their vault and give you a token or identifier, and that’s all you use. But…wouldn’t it be nice if you could get the CC data back at some point? Like say, when you want to move to a new payment provider? Just like it’s nice to be able to port your cell number, it would be great to be able to port your existing subscribers to a new platform.
There are a lot of data security issues that I’m glossing over here, but the underlying concept is sound. The CC data is stored somewhere, and you want it stored elsewhere. Further, I’d argue that you, the client of the provider, have a right to that data. After all, the user gave the data to you, and you then passed it on to the provider. It’s already been entrusted to you by the user. Heck, for 99% of users, they don’t even know that you’re not storing it. They think you have it already.
Are there any payment providers that allow this kind of credit card retrieval? I’d really like to know, as that would be the ultimate in provider portability.
Don’t roll your own
After all my rants about what you can’t do with X or Y, you may be tempted to write your own and just store the credit cards and charge them periodically. This is probably the worst choice of all. As much as it sucks to have your hands tied, there is a lot of sludge and horror in payment processing, and it’s really better to offload that onto someone like Amazon, PayPal, or Chargify.
Our first Amazon FPS-based system was like this and it really sucked. I wrote a ton of code, and ultimately it was buggy, failed on weird edge cases, and was generally a pain in the ass. Switching to SimplePay was definitely the right choice when I did it, and I think switching to Chargify is the right choice now. I just wish they had been there when I started.
More?
Those are the reasons we have decided to switch to Chargify. We want more flexibility to charge as we please, and we’re tired of having our hands tied. I’m sure there are other reasons that I’m forgetting, but my main goal is to force you to really think about what you’re giving up when you choose a provider. Fees and rates are real money, but the flexibility to modify your business model is what will make or break your SaaS app.
Update (2010-08-11): With the announcement of their new pricing structure, especially the loss of the free plan, Chargify is a much less appealing solution. I’m seriously considering looking for yet another solution. Ironically, their new pricing plan doesn’t change things that much in my particular case, but it has convinced me that they don’t have their heads screwed on right. Better to switch now while I have time on my side rather than wait until Chargify collapses under the weight of terrible decision making.
One of Recurly’s value props is that they store cc info so that you can change payment processors if necessary.
Braintree will also let you take your subscribers’ cc info with you to another processor, but I don’t know of any others.
Yeah, I knew that about Braintree, not Recurly, though.
I eventually went with Authorize.net, since their fees were a little better than Braintree. I think we’re locked in with Authorize, but they’re big enough that hopefully we never have to move. We can switch to another merchant account or something else, but always use Authorize as our gateway.
*fingers crossed…{*
Spreedly also acts as an intermediary (by storing the credit card data themselves), and allows you to change merchant account providers at will. If you want to export the Spreedly data to an entirely different provider, they’ll do that as well… as long as it will be a secure exchange (I think they talk with the company first or something).
It’s “vise,” not “vice.” A vise is a mechanical screw apparatus. A vice is a scandalous habit.
Ownership of the card data is key. Since our inception, Vindicia has ensured that merchants own their own card data.
The other side may seem like a contradiction, but it’s not. You want to *own* the cards, but you don’t want to touch them. the PCI standards mean that you’ll have to certify annually that you handle cards in accordance with the association rules. Small merchants can do a pretty light-weight audit, but as you grow, that burden grows too. While this initially makes solutions like Amazon seem attractive, it becomes a serious issue as your business grows. Plan for success: always have an exit strategy from your current environment, so that when your business grows, you can step up to a more flexible processor and payment infrastructure.
I recently switched from TrustCommerce to Chargify. I had to go to my customers and get their CC information from them since it was impossible to get it back from TC. It was a complete pain.
Now, I am encrypting the users billing info with a public key, and the private key exists (encryped) somewhere else completely. Now, if I decide to migrate from authorize, I can at least so it without calling my customers and sounding like a 2 bit operation
Giles, I once had my nuts in a vice. They just wouldn’t stop drinking and it nearly drove me to bankruptcy. Fortunately, with a 12 step program my nuts were on the road to freedom and now, I’m proud to say that my nuts have been dry for 2 years.
Thanks Giles. Being a grammar/spelling nazi is one of my vices, so I’m very ashamed to have been caught in a blatant misspelling like that.
Ian – I’d be very, very careful about what you’re doing. Depending on what you’re storing and where, you may be violating PCI compliance rules. You’ll probably never get caught or in trouble, but if you do the legal liability could destroy you.
Looking deeper, I guess there’s a little bit of leeway in how you spell it. Still “vise” is the more accepted spelling, so we’ll go with that.
I work for a hosted VOIP provider and have just gone through the very process you describe. We eventually settled on Zuora because of their pricing and product catalog models. Also, given that we are required to charge complex taxes, something with built in tax tables was appealing.
Justin: Good point about the built-in taxing. I’ve worked on another app that had to deal with sales tax a bit, and that was a real pain.
Nice post Micah! Many people are not aware of the issues with running a subscription business. The dunning process you talked about is really just the beginning of what is possible when optimizing your customer retention rates, but much better than simply doing nothing.
That said, the discussion here shows there is still a lot of confusion around online billing and how the different providers fit into the ecosystem. At the end of the day, make sure you are comparing apples-to-apples.
I work for Vindicia and a big part of our approach is to help educate merchants on the best practices in the industry. We have a full complement of resources and guides (http://www.vindicia.com/resources/index.html). For this conversation, take a look at our best practice guide for customer retention – http://www.vindicia.com/resources/best_practices/customer_retention.html
Downside to using SaaS is someone else has access to your billing data and anything could happen to it. I’m sure a lot of hackers target these services frequently as well — does the company hosting them notify you when they’re exploited secretly?
Open source all of the way, and roll your own. It’s worth the investment to retain access to security logs & such that your company is entirely reliant upon.
Thanks for helpful advice. Our new internal project needed a billing solution and this came at the perfect time.
Best wishes with Obsidian Portal as well! It seems like a very fun idea.
@David: I agree. That’s also something I’m worried about when it comes to SaaS regardless of what software it is. But I guess you can’t help it. If you want to reduce business costs, you go for SaaS.
And since we’re sharing subscription billing here, it’s something that I use, though not for an extremely long time. I think it’s worth sharing, considering the different packages one can choose from.
You may want to take a look at SaaSy and compare it against the others, as there are substantial advantages, including that it’s all-inclusive so you don’t have to do the development work you would need to do around the basic recurring billing solutions.