Ask HN: Developing a recurring payments system, what do I need to consider? | Hacker News Reader

Ask HN: Developing a recurring payments system, what do I need to consider?

39 pointsericb27 comments

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!

View on HN

Things to think about:

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.

Unless you know exactly what you're doing - and if you're asking this question, you don't - don't store credit card numbers at all. There is no justifiable advantage to doing this when Braintree/Authorize.net/etc provide much more secure ways to make arbitrary charges against a card.

May have legal duties?

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.

This is correct, I offer PCI complaince tools and advice, for recurring billing, you will need to have pci scanning on your servers, if your hosted and not doing sys admin yourselves or if you dont have sys admin skills it's going to cost you dearly. Basic advice, use a linode, get a sys admin who knows about pci compliance, set up pci compliant approved server, check with scanning software, we offer it for 200 GBP which includes the SAQ wizard which will save you days. pcicompliance.org.uk, nightmare process. Best advice, just starting, use Paypal...

I thought VMs didn't qualify for PCI compliance unless you had the physical hardware the VM runs on.

The intellectual property for minimizing charge backs, preventing fraud, and handling exceptions and edge cases--knowledge built up over handling millions of transactions--is generally not worth relearning. Then there's the outrageous business crushing liability if something with CC data goes wrong.

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.)

"gateways, processors, and PCI compliance"

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.....

To say the ins and outs of card processing should be "well-understood" by any would-be entrepreneur seems like saying biochemistry should be well understood by anyone who wants to wear a Got Milk? t-shirt.

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 implemented the recurring billing for http://corduroysite.com with braintree and ruby activemerchant.

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.

What made you not use Braintree's automated billing? How long do you think it took you to implement from soup to nuts?

We have several projects (non-Braintree, we use Authorize.net) where the amount billed per month varies. Authorize.net's automatic recurring billing system doesn't allow you to change the amount in between pay periods, so we had to do something similar to what the original commenter said. Basically cron running a script that bills whoever needs to be billed for the proper amount.

For anyone else interested, I found this while googling for ActiveMerchant sample apps and will probably pick it up. Looks apropos. Thanks for the feedback!

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.

To clarify your first point, do you have a separate process that runs per customer so that if the process fails and has to be restarted (auth failure with merchant etc) only that one customer will be restarted?

not a separate process, but it will continue to try each customer. any customers not billed on that day will be retried the next day if not manually before then.

1. It's about PCI compliancy 2. It's about running a cronjob/sending invoice mails 3. It's about fancy features (up/downgrade/trials/coupons/variable fees)

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 :)

You need to worry about everything mentioned as a feature at https://cheddargetter.com/features. No, I am not associated with them, but I have been researching subscription billing and found CheddarGetter's list of features a good template to compare other providers.

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).

I haven't looked exhaustively.

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.

That happened to my co-founders and I on our previous product (the one visible at the website in my profile). The only thing our payment provider ended up being serious about was getting acquired.

We had to change providers about a year after we launched, and it ended up costing us nearly half of our early customers.

Interesting that the data didn't transfer over to the acquiree. Is that a rule in terms of PCI I wonder?

My understanding was that it was a low-dollar tech acquisition. The acquiree had no interest in existing customers beyond the fact that they validated functionality.

changing from Chargify or any other recurring payment service to another provider shouldn't be too hard, considering all your customer data should be stored in your Payment Gateway(Authorize.Net, Braintree, etc.).

Changing your gateway however would probably cause significant difficulties though.

They seem a little more expensive for starting out

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.

You might want to check out http://railskits.com/saas/. Yes it actually costs money, but consider what your time is worth.

Just bear in mind that the SaaS Rails Kit has been around for quite a while. I don't know if the features page lags behind the actual code, but: "Compatible with Rails 2.3.8"

I enquired the other day about Rails 3 support - he's working on it and expects to release it in the next few weeks.

In fact the rails3 release is mostly ready. There's a rails3 branch in the customer git repo that will be merged into master in the next week or two.

Just use Braintree's API with their vault. It's as easy as it gets without going with Chargify/Spreedly/etc, especially if you're just doing plain vanilla recurring billing.

Reply on news.ycombinator.com