Blog:

Increasingly web application developers and entrepreneurs are turning to the “Software As A Service” (SaaS) model to monetize their products.
Together with this growth has come the need for reliable recurring billing systems and in turn a number of enterprising folks have built said solutions and fittingly used the SaaS model to monetize their efforts.

In this article we will look at how these services work, why you’d want to use them, the various options available, and how they differ from one another. Hopefully it should give you a better idea of which service is right for you and how you plan to use it.

Why do I Need this Service?

There are many tools that are making web application development easier and easier, whether that be development frameworks such as Rails and Django or services like Amazon Web Services and Google App Engine, recurring billing systems are no different.

Building a billing system can be a complicated process with issues such as how to handle failed transactions, when and how to recharge cards, and not to mention all the data protection issues surrounding storing financial information and PCI compliance etc. These services allow you to abstract these concerns and let you focus on building the software you care about.

How do They Work?

The services all have a number of core functions in common. They provide a web application interface where you can create different products and configure pricing options. The service then deals with taking and storing your customer’s credit card details (normally with a PCI compliant third-party).

The information about customers, products and subscriptions is then exposed via a secure API which allows you to hook your app into the service. A fairly simple, elegant and, in my experience, reliable solution to something that could potentially be a major headache for app developers.

Essentially as a developer you have two options:

Option One

You choose to forward paying customers to the service’s hosted payment pages. This is the quickest and simplest way to get started. These pages are secure and accept query string parameters to pre-populate fields such as name and email address.

Successful payments will then be forwarded to a callback URL and any change to a subscription’s status will be posted back to your app via a post-back URL.

Both of these URLs are specified by you in the product settings of the billing service. Obviously, you would be mad not to validate the callback with a API query and likewise you will also need to check the nature of the subscription status change upon post-back notification.

Option Two

The process is almost identical to option one, however, you do not send users to the service’s hosted page to take payment. Your application collects (but does not store) all payment details and that data is then delivered to the billing service via their API.

In this instance the onus is upon you to take the user’s credit card details securely and handle the API’s response appropriately. However, the obvious benefits of this option is that the user’s experience is seamless, you have complete control over user interface design and user’s are unaware you’re using an external billing service.

Billing Systems vs. Payment Gateways

Amidst these technical decisions it is also important remember that these billing services are not payment gateways, they do not carry out the card transitions. They purely deal with the business logic of charges, re-charges, charge backs and data storage. In order to charge the card and for the money to end up in your account the billing service provider hooks into the API of your payment gateway of choice.

This means that it is important to check which payment gateways these service providers support. Some support more than others and until recently some have had a very limited choice of gateways.

Some common payment gateways include:

• Authorize.net
• Worldpay
• TrustCommerce
• Payment Express
• PayPal Website Payments Pro

There are also differences in these gateways and it is important to choose the right one for you and the billing service you choose.

Something to consider is that most of the gateways mentioned above require a merchant account which you would have to arrange with your bank. However, a lot of people avoid this by using Paypal Payments Pro where the money is transfered into a Paypal account ready for you to withdraw.

If you’d like to know more about merchant accounts hear what Ryan has to say about his experience in this arena on Think Vitamin Radio Episode 7.

What’s on Offer?

There are a good range of providers to choose from and unlike some services they do vary in their cost, features and pricing model. Here’s a breakdown of a few of the big players in the space.

Chargify

Chargify is seemingly the solution with the richest set of features and the lowest barrier to entry. They offer a free account which is limited to 50 paying customers plus 1,000 non-paying customers.

Their pricing model is clearly designed with the thought that those first 50 customers are the hardest to acquire and once you have those customers paying X amount per month you can afford to pay for their higher volume service.

These start from $49 a month for up to 500 customers and is graduated there on up to $2,499 per month for unlimited customers. As a result of these graduated monthly fees Chargify does not add any per-transaction cost, so within their pricing brackets your costs are fixed.

The people behind @chargify on Twitter are extremely helpful both in explaining their own service and in offering advice about merchant accounts and receptive banks in both the UK and USA.

This is unsurprising as Chargify is brought to you by the guys behind Grasshopper and if you’re a Rails person it is also worth noting that Chargify’s CEO and Founder is Lance Walley who was also Co-Founder of Rails hosting provider Engine Yard. Both these companies are known for their excellent software and, in my experience, great customer service which bodes well for Chargify.

http://chargify.com/

Spreedly

Spreedly is a younger service and therefore less feature rich. For example, I expressed an interest in charging a set up fee. A one-off fee that is only charged upon sign up. This can be useful to those services that have a fixed overheads for each user who signs up and something that’s easy to set up on Chargify.

However, Spreedly don’t currently offer this feature, but they say it is something that they are keen to do in the future. Likewise, at this point they don’t seem to have the choice to create add-ons for customers to add to their purchase at point of sale. Again, this is very useful for SaaS businesses offering bolt-on services.

Spreedly also takes a slightly different approach to Chargify in terms of pricing. They have a flat-rate monthly charge of $19 but also take 20c or 2% (whichever is the lower amount) of each transaction.

As with Chargify this pricing model scales with your business and means that at times Spreedly could be considerable cheaper than Chargify. That said, there are also points of customer volume where Spreedly’s costs will exceed Chargify’s. Plus with Chargify the frequency of your payment transactions is not an issue, if you want to charge users every 14 days you can at no extra cost whereas this would prove an expensive exercise with Spreedly.

A great benefit of Spreedly is the quantity of payment gateways they support. They are clearly focusing on simplicity and their support for gateways which is by no means a bad thing. As with Chargify the folks behind @spreedly were extremely helpful via Twitter and found my questions about their service without the need for a direct @ message. They were happy to answer questions and offer alternative approaches to features that weren’t available yet. In short, Spreedly is definitely worth a look if your current needs are simple and you like the idea of a per-transaction cost.

http://spreedly.com/

CheddarGetter

First up – what a name – CheddarGetter definitely wins in the name game. However, how does it stand up against Chargify and Spreedly. Well, in terms of features CheddarGetter definitely rivals Chargify and exceeds Spreedly. However, their pricing structure is different again. Like Chargify they have graduated montlhy charges based on customer volume with no transaction fees.

As with both Spreedly and Chargify @cheddargetter offer phenomenal service via Twitter. Mention the name CheddarGetter in the context of a question and they will find you and offer support. This proactive approach seems to be the norm is this space but we shouldn’t forget how rare it is to get this kind of customer service.

The major downside of CheddarGetter right now is its lack of payment gateway integration. The limited list of gateways includes Network Merchants and Authorize.net but no Paypal Website Payments Pro for those of you who don’t want to deal with getting a merchant account with your bank. That said, with some more payment gateway integration CheddarGetter has real potential.

https://cheddargetter.com/

But How do I Choose?

As you can see the billing services spaces has quite a spread of different pricing models so they can be hard to compare in terms of price and work out features vs. cost per customer vs. potentially cost per transaction with Spreedly.

Chad Glendenin has an excellent comparison of the pricing of these services including graphs which map customer growth vs. cost of service for all these of the providers I’ve mentioned. These are extremely useful in demonstrating how these services actually compare in terms of price and highlights the customer volume markers where favour shifts from one service to another. He also provides his Python script for generating these figures so that you can run the numbers with your own payment frequencies and prices.

It’s clear that if you expect a very high quantity of subscribers, meaning 15,000+ customers paying monthly, then Chargify’s features and unlimited plan makes them the obvious choice.

However, if you’re expecting very low volume, or your only taking annual payments and this is something you’re setting up on the side of a day job, Spreedly’s per-transaction model and simplicity would suit your needs. However, these are both extreme ends of the spectrum.

Extremes aside, I think this decision is really about features and not price. The costs are marginal compared to whether the service can provide you with what you need. Integration with a billing system while a fairly straightforward process isn’t something that you want to have change after 18 months.

Conclusion

If you’re planning more complicated pricing models, add on products, short payment intervals, or want a metered service where customers pay for their usage then you need to hunt down each service’s feature list and ensure they offer what you need. You are buying simplicity, you’re buying the ability to focus on your own app and abstract the billing logic, make sure the service you choose offers you what you need not just the best price.

Finally, if you guys are using any of these services it would be great to hear from you in the comments about your experiences and your decision making when you chose the service.