
Don't complicate your billing - tortilla
http://cooking.fourbeansoup.com/post/265425704/dont-complicate-your-billing
======
mrkurt
Don't write your own billing system. :)

To elaborate, these recommendations are backwards. They're _business
decisions_ that are being influenced by technical considerations for a non-
core product. Users might prefer to be billed on the same day every month than
every 30 days. Choosing not to prorate in favor of waiting 'til the next cycle
is basically throwing money away. Relying on the gateway to handle refunds
takes a crucial part of your data out of the system that otherwise reports on
your money. Freemium vs free trials isn't a decision anyone should make based
on the capabilities of their billing systems.

Billing is a pain in the ass and it's not a core feature for most companies.
And unlike most things, it's reasonably uniform between companies, making
third party billing packages fantastically useful.

~~~
seekely
Meant to hit the up arrow. Hit the down arrow by accident. My apologies.

I agree completely. There are now so many subscription billing providers,
writing your own, for such a small service none the less, is a big waste of
time.

------
texel
I wrote the billing system for onehub.com, and we had to deal with each issue
mentioned in this article. ActiveSupport makes some of the date problems melt
away, but we ended up implementing pro-rated upgrades and downgrades, free
trials, and discounts.

There are some _super_ fun edge cases: \- Handling the case when someone
upgrades or downgrades after we've billed three days in advance for the next
month's service

\- Handling the case when someone downgrades during a free trial (you don't
want to pro-rate money back to their account that they never paid in the first
place)

If I had to do it all over again, I would probably use one of the services
that handles this exclusively. Unfortunately, when we started out, none were
available.

------
burnout1540
Having written a billing system that relied on a third-party recurring billing
solution (which I later ripped out), I would advocate rolling your own
subscription system for anything but the simplest case. The article has some
suggestions on how to keep it simple:

1\. Charge everyone on the 1st of each month. 2\. Keep refunds out of your
system 3\. Run the billing as a batch job based off of cron

Once you've made those decisions, writing a subscription service really isn't
very difficult.

It's a lot easier than dealing with multiple API calls to modify a user's
subscription, any one of which may fail _.

Plus you don't have to deal with polling the recurring billing service to find
out a transaction's status nor the race conditions inherent in such a setup.

Finally, when you want to get more complicated and deal with promotional
periods, billing on different dates for different customers, etc., you will
find that it's much easier to modify your own code to fit your business
requirements than it is to retrofit your interface with a third-party (not to
mention any possible data migration issues).

_ This could be solved by an excellent recurring billing API, but most suck.

~~~
sunir
As mentioned in the other post linked below, I'm the product manager for the
FreshBooks API. We are extremely aware there are many problems with the
recurring billing market right now, and we are currently committed to doing a
better job serving it. We are committed painless billing for web apps too.

If you can please forgive the shilling, I'm very interested in hearing what
sucks about the recurring billing APIs on the market and specifically what
sucks about ours (<http://developers.freshbooks.com>). I'm sure our
competitors in the market would also be interested so we can all do a better
job.

This isn't so much about us, but letting you know that at least one vendor is
here listening, and maybe others.

Thanks for anything you can throw at me, good or bad.

(And you can't hurt my feelings except by being quiet. I _need_ to know.)

 _NOTE_ I rewrote this comment to be less self-conscious.

~~~
mrkurt
My information may be out-dated, but Freshbooks seemed like it wouldn't have
been a good fit for subscription billing back when we were looking.

Basically, it wasn't possible to create a signup form that resulted in a
recurring invoice with credit card data attached. So you'd end up with janky
situations where you're either invoicing people and waiting for them to pay,
or charging them through another gateway, then hoping they enter payment
information before the next cycle.

There's also no callback mechanism from Freshbooks to an outside site, making
it extremely difficult to keep track of expiring
subscriptions/cancellations/etc.

I would love, love, love for Freshbooks to also be a drop in subscription
billing platform. It seems like most of the bits are there, but there's no
guiding force trying to make sure it works well for that purpose.

~~~
sunir
Thanks for your help!

Callbacks and credit cards are the top two problems with the existing API. At
least callbacks are a problem with a clear solution (HTTP postback, aka
webhooks).

As for credit cards through the API, we debate about that one extensively. The
concern we have is that ideally, our customers would prefer not to touch
credit cards because of the liability of credit cart theft. That's why for now
we take on the risk of managing credit cards by letting you punt the customer
to our invoice page.

What's preferable to you?

1\. Never touching the credit card ever, but redirecting the customer to a
good payment experience

2\. Taking the credit card on your own sign up form and sending it through our
API

3\. Taking the credit card through a FreshBooks https iframe on your website

Or any other solutions?

~~~
mrkurt
I'd prefer to have both #1 and #2, actually. #1 for quick implementation, #2
for later when it's worth controlling the signup flow more granularly.

~~~
sunir
Thanks. That's actually very helpful.

------
billswift
Arithmetically challenged - "The biggest difference is that going every 30
days means you get an extra payment every 10 years… Yes, 10 years, shrug."
It's 6 years. If you're going to emphasize something in your writing, for
example by repeating it, you really ought to get it right.

------
pchristensen
Interesting to see this in contrast to
<http://news.ycombinator.com/item?id=968943>

