By lance

This is a guest post from Lance Walley, the Co-Founder of Chargify and EngineYard. Chargify is an SaaS software that manages billing activities.  Engineyard provides infrastructure for running Ruby on Rails applications in the cloud (TransFS runs on Engineyard).  I suspect that his story of how Engineyard got buring in billing activities will resonate with many entrepreneurs and developers.

Over the course of a few years, Engineyard grew from 0 customers to 1,000 and by month 12 we were buried in Managing our Billing Activities (BAM – Billing Activity Management).  We had a combination of software and people involved every day just to keep up.  It became very expensive in terms of operational costs, customer dissatisfaction and the inability to report on that activity.

Engine Yard started reining in these costs in 2009, but I wish a better solution had existed earlier.

How We Got Buried

Here’s what happened. I think it’s pretty typical:

• It’s easy to get started with tools like Quickbooks and Auth.net to set up simple recurring billing of ‘x’ dollars per month on a customer’s credit card. When you just want to get a customer set up, this is quick and simple, but the simplicity is short-term because…
• Customers add & remove products,  you need to change the  recurring amount they are billed
• You’ll change pricing over time. We did so 4 times over a couple of years. We gave existing customers 1 year of grandfathered pricing, which added another layer of complexity to pricing.
• Some customers get special pricing because they’re in a special group, such as a charity, school, or reseller. Another layer of pricing.
• Credit cards get declined or expire, so someone needs to resolve these issues. I later learned that this process is called “dunning”.
• As you figure out what your customers really want, you’ll change your products.
• This is where “metered billing” comes into play. Unlike pre-paid flat-rate plans mentioned so far in this story, this is where customers pay ‘x’ amount per ‘y’ widgets used in the previous billing cycle.
• As your business grows and you get a finance person, you’ll discover that some charges must be “recognized” over different periods of time. We found out that set-up fees are supposed to be recognized over the expected life of the customer. I had never heard of “revenue recognition”. Wouldn’t it be nice if your BAM system could help with things like this?

As you can see, Engine Yard quickly outgrew the systems we started with, and we had almost no ability to report on all of this activity because the data was either spread across different systems or just didn’t exist.

We were paying a lot for a bad BAM system.  For my next business I wanted to solve the BAM problem, which I think we have done at Chargify.

By sean

PCI Compliance rules, designed to ensure that credit card numbers are not kept on merchants’ computers in a form that are easy to steal, is a good thing, nobody like having their credit card stolen and fraud hurts everyone.  However, it is expensive and complicated for everyone who accepts credit cards, in particular online merchants.  Most business owners have no idea what they have to do to meet the PCI compliance requirements.

If you are confused about PCI compiance, Internet Retailer recently posted a good article on the topic. The best part of the article is this:

Don`t hold data
PCI experts say one of the best ways for a retailer to reduce PCI compliance costs is to not hold cardholder data, because only retailer systems—networks, servers, databases and software—that hold cardholder data fall under PCI. No card data in a customer history database, for instance, means that database is excluded from PCI audit.

Seriously folks, most smaller businesses do not even require an audit if their numbers are not stored.  Just send the card into on to your gateway company and let them store it.  Most small and midsized businesses, if they don’t store credit card numbers, can achieve PCI compliance by simply filling out a self-assessment questionnaire.

By sean

Last Friday, Authorize.net had an outage for several hours due to a fire in a Seattle data center (coverage on TechCrunch), leaving many companies without the ability to accept credit cards.   In addition to the many ecommerce and software as a service companies that were impacted, many POS systems connect to Auth.net to process card-present transactions.

While Authorize.net has had several high-profile outages through its history, the overall reliability rate is pretty high.  Even so, prudent businesspeople should consider having a backup gateway setup in case of an Auth.net outage.

While there are some gateways that are processor-specific (for example Braintree), there are many that are not processor-specific, for example eProcessingNetwork and USAePay, that, like Authorize.net, can be used with most processors.  The cost of such gateways, with no transactions being processed, ranges between $10-$20 / month.  When you process a transaction with your alternate gateway, it will be transmitted in exactly the same way to your credit card processor and your billing and deposit will happen as if Auth.net had never gone down in the first place.

It is not very difficult to integrate an additional payment gateway into your software, in fact, most ecommerce packages and payment processing libraries have support for multiple gateways built in.  Some competing gateways, for example eProcessingNetwork, have auth.net emulation which allows even easier integration.

In short, if the latest Auth.net outage cost you more than $120-240, you should consider having a hot backup online and ready to go in case of another outage.