Tech-Angels

4beansoup:

Recently we have been working on adding billing support to tweet hopper, and we had all types of debates on how to handle each little nuisance. After much discussion and research, I have found the right answer: don’t make it complicated!

There is a saying, “no code is faster than no code”. Very smart coding proverb, which can be easily restated as “no functionality is less buggy than no functionality”. What I am trying to say is, adding complex billing functions just adds unneeded complexity to an already tough problem.

Once a month or 30 days?

This decision doesn’t have deep ramifications, but it is an important question to decide on. Do you bill every 30 days or the same day every month? Services like github charge on the same day every month, or be more like 37signals and charge every 30 days. The biggest difference is that going every 30 days means you get an extra payment every 10 years… Yes, 10 years, shrug.

There is also one other issue to consider if you charge on the same day every month, heard of February? What if someone signs up on the 31st? You have to start accounting for month end dates and make sure you get a monthly charge in on shorter and longer months, leading to more code complexity.

To prorate or not to prorate

Wait? Someone wants to upgrade in the middle of the month! There are two different schools of thoughts; prorate or just bill the higher amount on the next billing date. Linode, our hosting provider, charges on the 1st of every month and then charges prorated amounts if you need to upgrade or add services. On the other hand, github and 37signals both wait and charge you the upgraded amount on your next billing date, but you get immediate access to upgraded plans.

The prorating method has another down side that can lead to extra code complexity if you aren’t careful. What happens if you charge a customer $30 a month and they signup on November 29th? If you prorate and charge them, you will charge them $1, which will be almost nothing after credit card processing fees - depending on who you use to process transactions. Linode handles this by charging prorated amounts plus the next month if it is after the 20th, but that adds to complexity.

For tweet hopper, we decided to avoid complication and skip prorating and just go with the higher billing amount on the next billing date. Why write code that has to do complicated math? The side benefit of it all? Credit card billing can be completely separated from the app and run via cron scripts, there is no need to do on the spot prorate charging.

Refunds? We don’t need no stinkin’ refunds!

This one is pretty straight forward for me, don’t offer refunds. Don’t write any code in your app to push refunds - your gateway should have the tools you need for the few instances that you need it. It is the customer’s responsibility to cancel their account, and if they don’t it in time it isn’t your fault.

This is a clear cut “no code” win!

Freemium vs Trials

Free and paid plans versus 30 day trials with paid plans, it is less of a clear cut choice. The choice really depends on your product and the resources each plan uses.

With tweet hopper we have a lot of expense that goes into even just one twitter account. Due to that expense we decided to offer a free 30 day trial instead of a completely free account. We collect the credit card up front, mark the 30 day billing date, and charge your card once that date hits unless you cancel. By offering only paid plans, the plan changing and card collecting is pretty straight forward.

37signals offers both options in their products, either free plans or paid plans, taking credit cards up front. When you upgrade from a free plan to a paid plan, they have a bit of extra logic they need to handle to setup billing dates and get the charging going.

Keep it simple…

In the end, do whatever feels right when you are collecting payments. Keep it secure and keep it simple. The most important thing to understand is that no code is less complex than no code!