

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

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.<p>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.<p>I'm interested in pointers to libraries, samples, what to look at and think about, etc? Thanks!
======
bediger
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.

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

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

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

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

~~~
flacon
"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.....

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

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

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

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

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

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

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

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

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

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

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

~~~
poink
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"

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

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

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

