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.
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.
It depends, really, but I think it would take a lot for the long term fees to outweigh the opportunity cost of spending time on something that's not really your product.
Well, CheddarGetter would be ~$170/mo for 10k customers, while Spreedly would cost us $1000/mo for 10k customers (we paid for the Spreedly kickstarter, so $.10 transaction fees). We use Spreedly, but I like both.
If you wanted to be really, really cheap, the best course is probably to take something like Ubersmith or Modernbill and bend them to your will. They're both designed for hosting companies, but can be contorted into other business without too much effort. Both have 1 time license fees that aren't insane.
Even the most expensive option (Spreedly) is $12k/year. If you're billing $10k customers even $5/mo, that's really not much money.
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.
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.
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.
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.
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
Payflow Pro (by PayPal) Recurring Billing. I'm sure there are much, much better APIs out there but most of my comments would apply to any of them.
EDIT: tl;dr for my above comment: Third-party solutions are basically a replacement of a cron job that figures out when to bill someone and how much. It's easier to write that cron job than it is to keep your billing data synchronized across two systems.
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.
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.