This might be a subjective question, but I'll give it a go.
There are already a number of questions on SO that revolves around subscription billing management. I am currently working on a SaaS solution that will require a fully automated billing system.
What I am not looking for when asking this question is not advice on implementing towards a specific payment gateway or stuff like that. Instead I'd like advice on what kind of approach to take.
The functionality that I need is a system that can handle upgrades, downgrades, recurring billing, cancellations, etc. Initially for one product only, but it might over time be a requirement that the system can handle multiple products (by products I mean fundamentally different products, not different variations of the same product).
As I see it there are a number of possible approaches when you need a solution like this:
The advantage of using a hosted solution is obviously that you don't need PCI certification, the concern is outsourced and it is a lot faster to get up and running. These advantages come at a cost however: The most important support function for your product - i.e. the billing is not in your control. Additionally you have less control and flexibility.
What would you do? If we look beyond the PCI requirements I would definately prefer to have a system coded in-house that could do this kind of job. On the other hand I've heard from numerous sources that coding a system like this is a pain.
Any advice is highly appreciated. Also, if you advice to code it yourself, any experiences on how to do it or if there are any opensource projects (no matter the language, what I'm after is not the code but the structure) that I can benefit from would really mean alot.
We're in the process of moving from PayPal recurring billing to CheddarGetter. I highly recommend CheddarGetter, and we evaluated all 4 you mention. (Chargify came in a close second). The CG support forums are great as well. Go post a question (pre-sales, technical, etc.) up on http://support.cheddargetter.com/discussions/questions and you'll usually get a clear and concise answer within a day.
Unless you have a development and support team sitting idly waiting for work, I think in the majority of cases it would be a mistake to devote any resources toward building this in-house. Focus on your core product and meeting your customers' needs. Let people/companies who live and breath billing, dunning, prorating, invoicing, etc. focus on collecting your money from your customers.
You can always write your own in-house billing system down the road if you need to. But if you start with that now, you'll likely find yourself mired in details that are far removed from your business and core competency and lose your edge to lighter more dynamic competitors who are building great products and iterating quickly.
There's also a hybrid answer: my SaaS Rails Kit (if you are building on Rails). You don't have to build it yourself from scratch, but you do get the flexibility of having the billing code in your app, under your control, and customizable. You still have to have a lower level of PCI compliance, since CC info is transiting your server, but you don't have to worry about the more strict compliance requirements involved when storing card info, since the Kit passes on the card info to the credit card gateway and stores it there.
Braintree has a Transparent Redirect API that allows you to maintain control without passing credit card data through your servers. You host the credit card form on your site, but submit it directly to Braintree. Something like that might give you the flexibility that you're looking for without needing to worry about PCI compliance.
Keep in mind when choosing a provider that many companies won't let you get your customers' credit card data back if you decide leave. Disclosure: I work for Braintree.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With