When you enter your credit card on a website, it sends the credit card information over an encrypted channel to a payment gateway. The payment gateway’s primary responsibility is to authorize payments and communicate with the merchant’s bank. Banks communicate with the payment gateway using a proprietary network and/or protocol.  Since your website is not processing billions of transactions a month, your bank does not want to integrate with you.  So, the payment gateway effectively becomes the middle man.

However, if the merchant bank is small (compared to a bank like CitiBank, Chase, or Bank of America), the merchant bank likely uses another company to communicate with the payment gateway.  This middle man is known as a merchant service provider.  Unless you run into some very tricky problems authorizing transactions, you are not likely to know this company exists.  In most cases, the merchant service provider does their job and stays completely in the background.

Now that the merchant bank has the transaction information, it routes the details to the customer’s credit card company — Visa, MasterCard, Discover, American Express, etc.  Since Discover and American Express are usually issued directly to a customer (and not through an issuing bank), these card companies return an authorization or declined message.  Otherwise, the credit card company must now connect to the customer’s credit card issuing bank.  Finally, the customer’s bank can authorize or decline the transaction and the message routes all the way back to the originating e-commerce site.  On average, the whole authorization process can take 2-3 seconds due to all the parties involved in the transaction.

To summaries the authorization flow, the credit card information goes from the user’s browser to the e-commerce website to the payment gateway (optionally) to the merchant service provider to the merchant bank to the credit card company to the user’s bank for approval.

At the end of the day, the merchant’s bank must settle the transactions (assuming the funds were captured, or approved for transfer).  The merchant bank then works with the credit card company and users’ banks to transfer the funds.

What happens if my business grows?

When you sign up for a merchant account, your application details the typical transactions you’ll process.  If you’re a start-up and you experience a rapid growth (good for you!), then you may be in for a surprise.  Banks scrutinize their merchant accounts continuously.  As part of that process, they’ll actively profile all your transactions.  If there’s a sudden spike in dollar amounts or the average transaction amount changes, the bank may review your account.  Or, they may not be so nice and you’ll receive an account termination or suspension notice.

If your business is like 97% of e-commerce sites out there, your income stream will be pretty steady and this isn’t a concern.  If your company is an internet start-up and the sky’s the limit, your initial revenue stream is going to be unpredictable.  Be upfront with your merchant account provider and ask about the review process should your transaction profile change.

If I offer yearly subscriptions, do you gradually release the funds or are all the funds available immediately?

Recurring revenue is great, that’s the beauty of selling a service.  However, the merchant account bears a small risk when you charge upfront for that service.  If you’re renewing the subscription on a monthly basis, the risk is pretty minimal and your merchant account will be happy.  But your most dedicated customers may want to pay upfront for a yearly subscription and get a little discount.  That’s great.  Be sure to ask your merchant account how this revenue is treated.

When you collect payment upfront for a year, the merchant bank is liable for those funds for duration of the year.  Ideally, your company is established and your merchant bank will release the funds immediately.  However, your bank may not do that if you’re a start-up.  In that case, ask if the yearly subscriptions can be released 1/12th every month.  That will certainly make your bank more comfortable with your service and less likely to freeze the entire merchant account, should a red flag ever be raised.

Who owns the payment gateway account?

When you sign up for a merchant account, the bank will likely be a reseller for a payment gateway (like Authorize.NET or CyberSource).  And, they’ll likely be able to give you a discount on the setup fee for the payment gateway, in addition to handling some paperwork for you.  Sounds great.

What happens if you ever need to change merchant accounts? You’ll likely need to open a new payment gateway account too.  When a reseller sets up the payment gateway account, they own the account and it cannot be updated to point to a different merchant account as part of that setup.  If you open the payment gateway account yourself, switching merchant accounts at a later date is not an issue.

Of course, this usually is not much of an issue if you’re a typical e-commerce site and you’re processing a bunch of one time transactions.  If you’re accepting subscriptions and you depend on your payment gateway to securely store your credit card information for your recurring billing, then it’s a problem.  If you ever switch payment gateway accounts, your subscriptions will stop working.  Now, that’s important.

Is there an intermediary (Merchant Service Provider) between the merchant account and the payment gateway?

If you sign up with a fairly large bank for your merchant account, they may communicate directly with the payment gateway.  If your bank is a little smaller, they may use an intermediary, known as a Merchant Service Provider, to communicate with the payment gateway.  While in most scenarios this really does not matter, the intermediary may introduce a little more lag into the communication and it may cause some variation in the error messages returned from the payment gateway.

In one scenario that I have seen, switching a merchant account while keeping the payment gateway the same introduced a new error message; “Invalid configuration in payment gateway.”  Investigating this error message was a major headache as multiple parties were involved in the transaction and each pointed the blame at someone else without identifying the problem.  In the end, we found that all the credit cards we investigated with this error were legitimately declined by the end user’s bank.  Due to the various parties involved in the transaction, the real reason for the decline was lost in translation and we were left with a generic message.