4 ms·

Don't complicate your billing

23 points by tortilla 17y ago

mrkurt 17y ago
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 17y ago
  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.
  - deleted 17y ago
    [deleted]
- callmeed 17y ago
  But if a 3rd party billing "package" means paying higher fees long-term, doesn't it make sense to write your own billing system?
  - mrkurt 17y ago
    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.
    - callmeed 17y ago
      You think so? If your users measure in the thousands, it seems even half a percentage point or a large monthly fee would add up.
      - mrkurt 17y ago
        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.
texel 17y ago
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 17y ago
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 17y ago
  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 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 17y ago
    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.
pchristensen 17y ago
Interesting to see this in contrast to http://news.ycombinator.com/item?id=968943 http://news.ycombinator.com/item?id=968943
billswift 17y ago
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.

23 points by tortilla 17y ago

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 17y ago
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.
- deleted 17y ago
  [deleted]
callmeed 17y ago
But if a 3rd party billing "package" means paying higher fees long-term, doesn't it make sense to write your own billing system?
- mrkurt 17y ago
  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.
  - callmeed 17y ago
    You think so? If your users measure in the thousands, it seems even half a percentage point or a large monthly fee would add up.
    - mrkurt 17y ago
      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.

texel 17y ago

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 17y ago

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 17y ago
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 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 17y ago
  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.

pchristensen 17y ago

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

billswift 17y ago

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.