Ask HN: Developing a recurring payments system, what do I need to consider?
I'm starting work on the payments portion of our saas load testing app. My partner and I have been dogfooding our app for a while on our own load test consulting gigs and we're at the point where we want to roll it out. The app is written in rails. I was planning to use a "credits" system, and thinking about using Braintree.
I'm wondering what things I need to consider, and trying to reinvent as little as possible. I'm wondering if there any full example apps I could work from. Maybe something with templates for Success emails? Failure emails? Card expiry? One time payment/monthly payments. Also wondering what libraries I should look at, etc.
I'm interested in pointers to libraries, samples, what to look at and think about, etc? Thanks!
(
27 comments
| 39 points
| on HN
)
1. Keeping the credentials (account number, name, telephone number, credit card number, routing number and account number, etc etc). You may have legal duties to perform certain things, or to delete them every so often.
2. Retries of failed payment authorizations. The ACH and credit card systems ARE NOT THAT RELIABLE. Your code will need to take account of network failure (failed to contact Paymentech or AmEx) vs a declined payment. Not the same things at all. You need to have the ability to retry an authorization.
3. Your own software failures can leave a "batch" of payments in an inconsistent state. The dangers here are double-billing a human, and on the other hand, not billing a human. In one case, your clients cry out, in the other, you miss some money.
4. Give your clients the ability to cancel a scheduled payment right up to the deadline, but don't let them schedule a payment too close to the deadline. Horrible race conditions that are hard to imagine ensue.
If you wish to handle credit card details in your systems, you must pass PCI compliance, and this is something you really, really do not want to do if you're a small company.
You're usually better off keeping your brainpower focused on your app's differentiators, and leaving the recurring billing part to someone whose brain has already been sucked down the black hole of gateways, processors, and PCI compliance.
Chargify, Spreedly, and CheddarGetter come to mind as SaaS billers discussed frequently here.
(If your pain tolerance is higher, PayFlow Pro has tremendous institutional knowledge under the hood from handling over $100 million USD daily, despite changing corporate owners several times. Also compare Authorize.NET.)
These are not that complex and should be well-understood by any would-be entrepreneur. We are writing our own recurring billing system right now for our startup www.wellhubstudios.com, using Auth.net CIM. Auth.net even offers recurring billing themselves. Another obvious issue with the services you mention such as Chargify et al is that they charge a higher rate for each transaction than most other Merchant Account providers, sometimes 1-2% more per transaction which, if your trying to run a viable business based on margins it is something to greatly consider. The Transaction fee we got was ridiculously low compared to what these "recurring billing" apps (which surely will reduce your headache) are offering. Off to make some money.....
How many stores write the software in their cash register? Who would argue that was useful instead of working on their product line?
The would-be entrepreneur really should be doing other things with his time, and if the card processing percentage difference matters to the business model, hopefully the model is micropayments or billing itself, because for anything larger, there should be room and the entrepreneur better watch out for the much larger expense of supporting billing.
Billing is rarely a differentiator, except when it goes wrong.
On the other hand, if you're selling billing itself as a service, as I see your site says you are, then sure. You're competing with Chargify, Spreedly, etc., for a more targeted vertical. So sure, billing is your product. In that case, agreed, it needs to be well-understood.
i did the recurring billing manually rather than using braintree's automated billing. i'm storing credit card numbers and addresses in their secure "vault" and just store the associated token with each customer record for pci compliance and added peace of mind.
some things to consider:
- store the last billed timestamp with each customer record, don't just sweep through each customer and try to bill for anyone with a billing date of today. if something goes wrong in your billing script halfway through, you don't want to double-bill those first customers and don't want to forget to bill the second half. when billing auth failures happen, you want to retry those failed customers the next day.
- don't be quick to blame the customer for their card not going through. even if it is on their end, it might not be their specific fault, and may be their credit card company, someone else using their company card, etc.
for corduroy, it emails the customer with a notice saying the charge failed but it'll retry for a week or so before anything bad happens. it sends the error message from the credit card processor, though many times they're hard to decipher exactly what's wrong (usually a billing address change though). if the card continues to fail for a week, the customer's site is put into a disabled state where the customer's staff users can't login without fixing the problem, but none of their data is affected.
http://peepcode.com/products/activemerchant-pdf
edit: I also found this plugin:
http://github.com/maccman/saasy
sample apps: http://github.com/linoj/saasramp
If anyone has looked at these or others, I'd love to hear thoughts on them before I dig in.
1. You will not be able to collect raw credit card data without having a PCI certification. This is easy to get by filling out a questionaire if you have only a few thousand transactions per year (below 200k iirc) and it's about a ~1500$ fee (iirc).
PCI compliancy limits your choices of payment gateways and inhouse software solutions:
a) you can use a payment gateway that supports recurring payments: they save your customer's raw data and provide you a token where you can bill future charges. This is the simplest way, does not require a PCI certification of you but has a huge vendor lock-in. If ActiveMerchant (e.g.) supports your gateway of choice AND recurring functionality WITHOUT dealing with raw credit card data: Go for it, it's the easiest way.
b) you can chose between more payment gateways by using the various 3rd party services that are PCI compliant (recurly.com, spreedly.com, chargify.com). Of course this is another vendor lock in and costs money.
2+3) This is about dealing with subscriptions and is primarily not credit card dependent. Of course you want to deal with chargebacks (you don't want to but this will happen) but usually the hardest parts are: up/downgrading within a paid period. Everything else is easily done, imho no special "kits" are needed UNLESS you're busy or lazy which is sometimes ok.
TL;DR
If you think that your MVP and core functionality needs more love than a fancy payment system, go with one of the services (recurly, chargify … or even paypal). If you business works, you've the time and money to upgrade to a better/your own solution/pci compliancy. It usually does not pay off to write your own billing system unless you already have paying customers :)
Why are you considering Braintree? They seem a little more expensive for starting out (though probably they are more robust and have better support than the rest -- Spreedly/Chargify/Recurly/CheddarGetter/Vindica/Zuora/Aria are some I researched).
After the chargify free account fiasco, I'm staying away from them. I would have started with the free account there and moved up, but now I'd be too nervous to look at them. Not familiar with the others, but I'd be nervous to go with anyone who doesn't have serious momentum, or size in their favor, as I don't want to rewrite my code if a startup fails or deal with stranded account information.
We had to change providers about a year after we launched, and it ended up costing us nearly half of our early customers.
Changing your gateway however would probably cause significant difficulties though.
I've also been looking at various payment gateways lately, and Braintree looks awesome. However, the $75 monthly minimum in fees is way too much to start out. Sadly I think I will either be locked into another provider or have to make the painful migration once revenue reaches the point where it makes sense to switch.