Considering how many businesses there are out there, one would think this process might be smooth and painless by now. Just apply for a merchant account, sign on the dotted line, and receive your merchant id in the mail a couple of weeks later. Unfortunately, this is not the case. Obtaining a merchant account can be a long and complex process, particularly if you’re a new, small business that’s going through this process for the first time.
Go read his article now if you think you ever need a merchant account. He describes the process very accurately. I thought I’d add my 5 cents to this as well, with a few other things you need to worry about before picking a processor.
Originally the Merchant Account and Credit Card processor were separate companies. They still are, but most processors now hide this fact by offering a bundled merchant account through a partner bank of theirs. You may end up not even knowing what bank that is.
At Agree2 we opened our account last year with Braintree who have been very responsive. The paperwork did take a lot longer than we thought and involved a few changes to our site. They also did want to see a prototype of our credit card payment page as well.
Don’t use a proprietary api
If you use ruby be sure to use ActiveMerchant. It provides a really well designed API for dealing with most kinds of payment processors. I’m sure there are similar libraries for other languages.
The reason why this is important is that it helps protect you against lock in to the processor. If for some reason you can’t open an account with your preferred provider or they close you down, you don’t have to rewrite your code from scratch. These things happen to good companies.
So start your search for a credit card processor from the list of supported gateways on the ActiveMerchant page.
Use a Vault
I would say that if you are building a SAAS kind of business with recurring payments, you absolutely need a processor that supports some sort of vault. A vault is a secure store of credit cards numbers on the credit card operator’s own servers. Several of them do that now. Braintree for one.
Due to new security requirements from the credit card associations (Visa and M/C) it really is not feasible for small operators to store the card details locally anymore. So if you are developing your application with credit cards stored in your database, be aware you will need to change this.
Also never, ever store the CVV anywhere. It is completely against credit card association rules.
Briefly the way the vault works is that when a user gives you their credit card details you store it in the vault, even if you don’t need to charge it straight away. In return they provide you with a vault id. This you DO store in your database and you provide it to them every time you charge it in the future.
Updated Fixed some language issues and explained the Vault further. Thanks to Travis for his feedback.