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.
Dustin Senos
on 28 Dec 07As someone who has never setup a billing process, I have a couple very simple questions.
How and where do you store the customers credit card numbers? Are these taken care of with the Merchant Account? Your own software?
How do you deal with high risk information such as credit cards?
Neil Henegan
on 28 Dec 07Dustin, I presume they don’t store that information. The gateway service usually keeps track of the details.
Anders Toxboe
on 28 Dec 07About the storing of the credit card information: Do you use authorize.net to do reference transactions (like with PayPal)? Or how do you manage and store cc information?
phantomdata
on 28 Dec 07Nice. We use Authorize.net where I work too, so its good to hear them used elsewhere. Personally I’ve found their software to be a huge PITA to interact with, but that could just be that integrating was low on the priority scale.
Anyway, I love these recently more “in depth” questions about the goings on under the hood at 37s. It’s definitely a breath of fresh air to get to peak at what’s going on behind the scenes of such a successful shop as yourselves. Good going!
Prashant Nadarajan
on 28 Dec 07@Dustin: If you do want to store the credit card details, you’ll want to be Payment Card Industry (PCI) compliant.
Brian
on 28 Dec 07My company has a similar setup. Our internal software checks for unpaid charges each night and runs them thru Authorize.net and deposits the funds into our Merchant Account with Wells Fargo. For the most part, the system works well.
Right now, each of our customers are on contract.
Because of the nature of our business, we have to project our needs/expenses a few months in advance so it helps to know just how many customers we’ll have at that time. Each of them being under contract makes that easy.
However, you mentioned that you thought the month to month was actually more lucrative in the long run because of the small initial investment from a customer. Now that has me thinking on if it would work for us. Do you think it was a big difference?
Jason Reynolds
on 28 Dec 07Avoid storing cc info whenever possible. The cost of securing it and the risk of not securing it are massive. PCI (payment card insdustry) compliance is getting a big push from Visa/MasterCard and there are large fines for not storing information properly. Also, not securing the data can lead to a nightmare scenario such as the T.J. Maxx data breach. That is just about the worst PR you can have.
Jack
on 28 Dec 07One gateway service that we used went to great lengths to insure the credit card number never hit our servers. The form submit must go directly to them and then they redirect to a return page with an appropriate error code. A bit kludgey but overall I was impressed with how professional they were.
Robby Russell
on 28 Dec 07Since you’re using Authorize.NET, are you guys using their automatic system to charge the same amount each month? Or are you (shudder) storing your customers credit card numbers in your own database?
We’ve been using Authorize.NET but don’t retain our customers CC info ourselves. To my knowledge.. in order to increase the payment amount (example: upgrading an account plan), it’d require our customers to provide their CC information again as it didn’t match the original amount. Because of this clunky nature and us being unwilling to store CC informration, we’ve been building our clients applications with TrustCommerce, which provides a much richer in API for handling complex subscription changes without storing CC data.
We’re actually wrapping up a rewrite of our whole subscription system that sounds similar to your rewrite efforts at 37signals. We’re building a new central application and our other applications/products are connecting through it through APIs.
Nate Westheimer
on 28 Dec 07Very interesting. We’re about to do the billing part of BricaBox.
Question: What do you fellas think about Amazon FPS for billing, instead of using a merchant account and gateway?
I think it has great possibilities to simplify the process. Until reading this, in fact, we were set on using FPS. (my extended thoughts here: http://innonate.com/2007/12/06/freemium-utility-amazon-fps-platform-currency/ )
Stephen Boisvert
on 28 Dec 07The active merchant link wasn’t working when i tried. After hunting a bit this seems to be what you need:
http://www.activemerchant.org/
Eric Prugh
on 28 Dec 07JF, thanks for the writeup. When you say the “system” runs a script to determine who’s up for billing, do you mean the Automated Recurring Billing from Authorize.net? Or do you have a cron job setup on your end to handle monthly billing?
Alex Young
on 28 Dec 07I implemented a similar system to the one described here using UK banks and payment processors for monthly recurring billing. Finding a payment gateway with a clean API is hard work, but eventually settled on: http://securetrading.com/
Out of the ones I tested I found some didn’t even provide “test” accounts, and others had inconsistencies between the test API and live API. It really is more work than it needs to be.
(Feel free to contact me through the contact form on my site if you want help with recurring billing in the UK.)
Steve O
on 28 Dec 07My company has done a fair amount with credit card processing through different providers. One interesting fact is that most will charge higher percentages than their quoted rates if a transaction is deemed “higher risk.” This is apparently levied by Visa/MC/etc, so you end up paying around a 4% processing fee on many transactions (where your quoted rate might be 2.2%). We switched to processing thru PayPal instead of Authorize because they charge a flat rate and eat any additional fees from the processor. Saved a ton of money.
jeff
on 28 Dec 07Thanks for the info! I have been trying to figure out the best way to handle the same process for some time!
Barry M.
on 29 Dec 07Has anyone ever used Amazon’s new payment service, FPS (Flexible Payments Service)? I am in the process of researching the different gateways for our new service and found FPS to be pretty competitive. There are no setup or monthly fees and no transaction limits. The only thing I found was that their credit card processing fees (depending on your monthly volume) can be a bit higher than some.
Jim Janke
on 29 Dec 07I can’t stress enough what others have said regarding PCI compliance and the handling of customers card data. The risks are real, the fines are huge, and the responsibility lies solely with the merchant. Before you write any application, website or offline process that deals with credits cards be sure that you know that the end result will meet the PCI compliancy standards. For more information go to www.pcicomplianceguide.org
glt
on 29 Dec 07It doesn’t have to do with actually processing credit cards, but might I make a pitch for accepting credit card numbers in space (or dash) separated groups – that is “dddd dddd dddd…” (or “dddd-dddd…”) instead of always requiring all the digits clumped together. From a human factors standpoint, allowing users to put spaces (or dashes) in the numbers makes both typing and verifying them much easier. And, honestly, any programmer who can’t cope with the spaces should not be trusted doing credit card stuff anyway.
RF
on 29 Dec 07Interesting. I work for an organization that accepts automatic monthly donations. We don’t store credit card numbers on our servers; VeriSign has the numbers and does the charging, which reduces the risk involved in a security breach for us.
Basically echoing what some other posters have said—outsourcing the CC# protection here is a win.
As a compromise, you could use a third-party charging service but keep the encrypted CC numbers archived so that you could switch providers someday or go back to charging cards yourself. The idea is, you’d public-key encrypt each day’s new CC#s, or each # individually; the private key would only exist somewhere outside your data center entirely—for example, two of you guys could keep copies on USB drives.
Really, that’s a lot of clever for a little flexibility. My vote is for not storing even encrypted CC#s.
nap
on 29 Dec 07Re: FPS I’m very interested in using it as well, as one of my projects could really make use of the aggregated pre/post-payment mechanism.
I started working on a Ruby API wrapper when it was first released, but kind of put the project aside when I saw that others were already working on it. That said, I’ve yet to see a working Ruby lib… So I may get back to it shortly. Ping me if you’ve got some interest in helping out or whatever.
If you’re interested, Amazon also has a “RESTful” (note the quotes) Hello World Sample App for FPS you can check out. Not pretty, but a good starting place.
Lee
on 29 Dec 07This is a great article and something I’ve wondered about for a while now, so it’s good to hear some first hand experience. Thanks
Matt
on 29 Dec 07Would you ever consider offering this internal payment web service as a paid service? I’m not sure exactly how it would work, but it seems like a lot of people need a solid and simple payment solution with an API like this. Myself included.
Serge
on 29 Dec 07Obtaining a merchant account is nothing short of a nightmare. Early on we decided that we wanted to integrate with http://www.billingcircle.com/ and forget about recurring billing, CC secure storage, e-mail reminders, etc. issues. Their API is nice and their support out of this world.
Billing Circle (BC) supports Authorize.net and SecureNet. We signed up with the former easily enough and started developing our interface with BC. We learned thereafter that Authorize.net only deals with US merchant accounts – fine.
A few days later we received the merchant account application forms and discovered that although our company is incorporated in Delaware and has been set up 1 year ago (already!), we also need a co-signatory officer in the company to be a US citizen, otherwise the underwriter cannot grant our application.
We are working on solving the issue. I read in various blogs that CC processing with a merchant account (as opposed to using PayPal or 2Co) was not for the faint hearted, but it is by far the thorniest administrative challenge we have ever faced. IMHO this industry could use a little bit more transparency and better advice to the newcomers.
Geoff
on 29 Dec 07To 37signals and those that chimed in: Thanks for the excellent post and comments. I’ve been astounded at the lack of straightforward resources for executing this kind of project, and this is really helpful stuff.
Gideon Greenspan
on 29 Dec 07Also look into doing this with WorldPay. They automate the recurring payments for you, you don’t need a merchant account for VISA/MasterCard and their rates are very low (circa 4.5% all in). I’ve been using them for years for several projects with very few problems. Their HTTP API is a little ugly but it works very reliably.
The one issue is that WorldPay sends out payment/subscription emails to your customers, as well as any emails you choose to send out yourself. This can lead to some occasional user confusion for more complex operations such as replacing a subcription due to an expired card.
DHH
on 29 Dec 07We actually store the credit card numbers ourselves, but as many has already pointed out, it’s a major, major hassle. We had to setup a totally separate network to run the credit card storage machine on and many other changes to live up to PCI. The credit card storage application exposes its interface via Active Resource and the applications then don’t know anything about the real credit card numbers, they just get a token.
Today, if we hadn’t already built the infrastructure, I’d probably just go with storing the CCs at the gateway. Even though it does some times restrict your options on moving from one gateway to another. But at least there are multiple merchants that you can switch between within the same gateway (at least that’s true for Authorize.net).
Shuba
on 29 Dec 07Has anyone tried using Google Checkout for this kind of thing?
Marvin Forte
on 29 Dec 07Great article and super feedback. This is an issue that we seem to bump up against on many of our projects.
We’ve built dozens of e-commerce sites and a handful of subscription sites. We use Authorize.net as the gateway for all our sites. For the subscription sites, we use Authorize.net’s Automatic Recurrent Billing API (which was only released in 2006). This new API made it possible to automatically set up ARBs (automated recurrent billing accounts). Before that, all we could do was set up a pending order that had to be manually converted to an ARB. A big improvement but it still doesn’t offer all the features we’d like.
In my opinion, if you are doing e-commerce transactions that are not recurring, there’s really no good reason to consider storing credit cards. It’s a huge burden with only a small payoff.
For recurring transactions though, it can be worth consideration for a few key features. We recently had an internal meeting about our subscription sites and used BaseCamp as an example. We were looking for an automated, efficient way users to update/renew their credit cards or upgrade their account.
After evaluating BaseCamp’s system, we came to the conclusion that they must have created their own recurrent billing system (confirmed) and that they must be storing cards (also confirmed). BaseCamp’s system of multiple warnings after a decline is great for users but Authorize.net’s Automated Recurrent Billing API doesn’t support anything like that.
We’ve come to the conclusion that at some point, in order to provide more advanced automation, we’re going to have to store cards. We’ve avoided it like the plague up until now.
If anyone knows another way around this dilemma, we’d love to hear it! Thanks again to all for their input.
MikeInAZ
on 29 Dec 07Marvin,
I think someone already mentioned TrustCommerce before. They have a more complete API that allows recurring billing without having to store any credit card numbers (citadel).
http://trustcommerce.com/citadel.php
jd
on 30 Dec 07“if you are doing e-commerce transactions that are not recurring, there’s really no good reason to consider storing credit cards. It’s a huge burden with only a small payoff.”
Everyone should think of any transactions as a potential recurring tranaction so it’s always better to store the credit card number if you can.
Zack Chandler
on 30 Dec 07I’ve too have had really good luck with TrustCommerce and their subscription API. It’s really nice to not have to worry about storing credit cards.
If you do use TC you may find my TrustCommerce subscription gem useful.
Tim
on 30 Dec 07@37signals et. al.
How do you reconcile your bank accounts?
I recently setup an account with Authorize.Net and Bank of America.
Does Authorize.Net provide you an unique identifier (invoice/transaction ID) that can be tied to the actual deposit in your business bank account?
I’m in a situation where I see deposits from Authorize.Net but can’t tie them out.
Thanks for any help you can provide.
Tim
on 30 Dec 07To follow up on my previous post, would it be to use the “Approval Code”?
And if so, where would that be displayed on my bank statement?
Thanks again for any help
Floyd Price
on 31 Dec 07We chose Active Merchant to use with our Paypal Payments pro account and it took about 30 mins to have our payment system up and running. Active Merchant ROCKS!
ChrisFizik
on 31 Dec 07I’ve been waiting for you to write this post for awhile! Great to hear you talk about this finally
Your purchasing systems have been a great inspiration for me before you even wrote this. And yes, I’m using Authorize.Net and ActiveMerchant. A simple, but highly effective, custom solution whipped together.
Thanks for the further insights and stuff in this post—nice to hear that even 37s runs into similar issues like me..haha
Hasan Luongo
on 31 Dec 07we have a bit of a unique challenge/twist to the reoccurring billing issue, much like an eBay seller – the costs of our soon to be launched app is based on volume. eBay handles this by a monthly charge to your account, just like a subscription, and we hope to emulate this functionality, but after reading the overall frustration other have experienced it seems like a fairly challenging process.
if anyone has tips or experience with billing variable amounts and wants to share, please contact me.
Victor
on 31 Dec 07Hassan, Have you taken a look at Authorize.Net’s new Customer Information Manager (CIM) API? In reading the description, it looks like it can help with billing variable amounts
Joe Van Dyk
on 01 Jan 08http://code.google.com/p/monkeycharger/ (one of my pet projects) sounds like it might be useful for some of you guys. It’s a Rails app that lets you store and charge credit cards.
Nick Tatt
on 01 Jan 08Your timing on this post couldn’t be better. We are just about to put the finishing touches to our very own payment process for a service that we we provide www.mapmytracks.com.
It’s nice to know that our hurdles are the same as everyone else’s! Outside of Ruby is there an equivalent to Active Merchant that anyone would recommend?
john Adeigbo
on 02 Jan 08Dear Sir/Madam,
We are writing you from global netsports Agency & communications cc Namibia, we are into the sale sports equipment.Our website is www.globalnetsports-agency.com and we will like to have credit card online payment facility on this site. please, how can your company be of help and what do we need to do to have this facility included on the site? i await your response please.
regards,
JOHN.A.
Harold Roach
on 02 Jan 08I work with a credit card processing company in Phoenix and I wanted to clear a few things up. Visa & MasterCard have over 160 card types each with there own rates and fees. To clear up some of the confusion we usually break these cards into 3 or 4 groups and charge a flat rate for each group. If you get a quote for service with only one rate then the details are in the fine print (banks are notorious for this). Your best bet is to call the customer svc. line of the bidding company and ask what the surcharges are for corporate cards, rewards cards, etc. And just because you have a contract does not mean you won’t have a rate increase, if Visa or M.C. have a rate increase (usually once a year) then you will be hit by that no matter what. Some companies exagerate how much these increases actually were or how often they occur to increase profit. Oh, and paying over 4% on any rate is rediculous, I think 3.2% is probably the highest any business should have for any rate and that’s being mighty generous. -Happy Hunting
Xprove Dan
on 04 Jan 08I think if you choose not to store CC’s (and I echo all the posters who say that it’s in general a bad idea!), and you want to support recurring billing, then you either build your own processing engine and use reference IDs (i.e. like a vault), or you let the processor handle it and you just pass in a profile (or update to a profile).
We did this for Xprove and it works reasonably well. The problem is, as we discovered too late, that if you don’t properly investigate all the features of the merchant provider, you may get stuck with less features than you like.
For example, if you don’t roll your own processor, then you may not have control over emails to customers (something we discovered).
Ultimately, the best solution, IMHO, is to roll your own processor (like BaseCamp did) but use a provider like TrustCommerce or BrainTree that supports reference-based transactions (as opposed to what BaseCamp did). This way, you get the flexibility and control of payments, notifications, updates, etc. But you also get the peace-of-mind in not storing CC info and not having to be PCI compliant.
For my part, I would love to see ActiveMerchant have a deeper level of integration with some payment providers (like TrustCommerce and BrainTree).
One other thought from my experience: If you don’t believe that your customers will mind if you use Paypal or Google or Amazon FPS, then those are by far the easiest solutions if you are starting from scratch. The major downsides are (a) perception and (b) account requirement. For example, to use Amazon FPS, the buyer must create an Amazon FPS account (if they don’t already). Same for Google. Nearly the same for Paypal. That may be a turn-off for some.
Anyway, it’s good to hear lots of discussion about this. eCommerce integration programmatically is never easy, but can be a lot easier if some time, thought and research is spent up front.
This discussion is closed.