Matt asks:

In my experience, credit card processing has been one of the major hurdles in starting an online business. Especially recurring/subscription charges.

You’ve got PayPal, which seems a little unprofessional (and is a pain in the a*), and an absurd number of 3rd party vendors offering various pieces of the puzzle. Integration is a pain, and the costs are really steep.

Can you offer any advice or guidance? When you were still small and just starting out with Basecamp, how did you tackle that?

I think I was a relatively early customer, and I was really impressed by how smooth and seamless the payment process was – it gave me a lot of confidence that I was buying a professional product, even though you hadn’t yet developed much of a name yet in the product world.

Many thanks for all that you contribute to the small business community – great products, great insights, and great inspiration.

First off, thanks for being an early customer. We have a special affinity for those who were willing to take a leap of faith and trust us in the early days. I know it’s hard to trust something new, so thanks.

So, credit card processing and set up and all that stuff is a real pain in the ass. It’s definitely intimidating to get started. The industry just feels dirty. So many companies offering merchant accounts, so many companies providing gateway software and integration, so many deals and discounts and conditions and terms and acronyms. What do we need? Who can we trust? How does it all work?

Some background

Before I get into how we’re set up now, I’ll tell you a little story about how we originally thought we’d be selling Basecamp.

We launched Basecamp back in February 2004. We were planning on launching in January, but we were held up because the sales method we originally wanted to go with was rejected by our merchant account provider.

At first we wanted to sell Basecamp with a flat yearly fee. $99/year, $149/year, $199/year. We thought it would be easier for customers to just pay once a year instead of every month. So we built the internals to support such a sales cycle.

However, when we explained our business to the company we picked to process our credit card transactions, they balked. They wouldn’t allow us to charge annually because we were unproven, we didn’t have a corporate credit history, and they didn’t really get the idea of subscription-based software. When we couldn’t provide a marketing brochure (didn’t have one), an annual report (didn’t have one), or anything “official” on paper (we still don’t have official letterhead stationary), I think they may have thought we were peddling porn.

The main issue was that if we went out of business in three months, they’d be left holding the risk of an annual subscription fee. So if someone paid us $149 in April for 12 months, and we went out of business in July, the merchant account company would be on the hook when the customer came calling for a refund. That wasn’t risk they were willing to take. I can’t say I blame them.

So we had to rejigger our entire business model. Instead of billing annually we had to switch to billing monthly. It turned out to be considerably more lucrative for us, and considerably more comfortable for our customers too. More revenue for us, lower cost of entry our customers. Instead of having to pony up $99 up front, they could pay $12/month for as long as they wanted. No contracts, no lock-in, no big initial investment on their part.

Today’s moving parts

Ok, so how do we do all this? First off, we have a merchant account. A merchant account is needed to accept credit cards. Every business that accepts credit cards needs to have a merchant account. We’ve used a few companies in the past, but currently we’re using an account provided by Chase bank. You should basically look for a reputable company you can trust that has good rates. The rates may not make all that much difference early on, but once your daily volume picks up a few basis points can make a big difference on your bottom line. But at first I’d pick trust over rates. You can always negotiate for better rates down the road.

Next we have an account with Authorize.net. Authorize.net is the gateway that our systems talk to. They take the credit card charge information from us, process the charge, and then deposit the money into our merchant account. If the charge doesn’t go through they send us a denial code which we then wordsmith and present to our customer.

The engine to process the recurring monthly charges is something we built custom. If you use Rails, Active Merchant would give you a good place to start. We don’t use Active Merchant because we built our stuff before AM was released, but it’s definitely a nice library.

Every night the system scans the paying accounts for each product and determines which ones are due for a charge. We then submit the charges one by one and record the result.

If the charge was successful we shoot off an paid invoice to the customer via email. If the charge was declined we shoot them an email with the explanation. We then try the declined card again three days later and then another three days after that if it was declined a second time. The customer’s account remains open while we attempt to process the charge. If the charge was declined three times we freeze the account until the customer is able to provide a valid credit card number.

The one thing we’re often surprised by is how many accounts have charge issues so it’s important to really think about the error handling and customer experience issues related to declined cards. Freezing an account too fast is unfair, but it’s also important to put a limit on your goodwill. We’ve gotten better at this over time, but the sheer number of charge errors initially caught us off guard. It’s not fraud, it’s just things like expired cards, credit limits, corporate charge policies, etc.

We’ve also recently started a major conversion of our internal systems to a centralized billing system. In the past each product had its own internal billing engine. Today we’re centralizing this. We’re essentially building an internal web service that our other products can talk to when they need to charge a card. They ping the service with the details and the central system takes care of the rest. This is much cleaner and much easier to maintain since we only have to deal with processing in one place. Other benefits will come from this centralization down the road.

Did that help?

I hope this provides at least a basic understanding of the fundamental moving parts and how we bill our customers. If you have other questions please post them in the comments section and we’ll try to answer what we can.

Got a question for us?

Got a question about design, business, marketing, etc? We’re happy to try to provide some insight into how we’d tackle the problem. Just email svn [at] 37signals dot com with the subject “Ask 37signals”. Thanks.