Blogtree. A Safe Haven in a Chaotic Industry.


Merchant Account Basics

Posted on Friday, July 11, 2008 by Bryan Johnson

There is a lot of confusion surrounding credit card processing and merchant accounts. Some of the most common areas of confusion are the different types of organizations that sell the services, what entities actually process the transactions and the fees and pricing structures that continue to form an unsolvable mystery for most merchants. I'm going to provide a broad overview that will hopefully help make sense of this complicated industry.

The necessity of merchant accounts
Some merchants prefer accepting credit cards because they are a much more convenient and cost effective way of collecting payments from customers. Other merchants, while it still may be convenient, struggle to pay the relatively high fees on their already- thin margins. Either way, merchants can make a number of improvements in their credit card processing by becoming more informed.

Providers of merchant accounts
If you want to get a new merchant account or switch from your existing provider, one thing is for sure: there is no shortage of companies that are anxious to earn your business. You can find merchant service providers by looking in the yellow pages, searching online, talking to your bank, or just waiting for the next sales person to either call you or walk into your business (which shouldn't be long). The key is choosing the RIGHT provider for your business.

Not all service providers are made equal
There are really two types of merchant service providers: processors and resellers (resellers are known in the industry as Independent Sales Organizations (ISO's) and/or Merchant Service Providers (MSP's)). Your first thought is probably that you would rather go with a processor to cut out the middle man, but I'll show you why it's not that clean cut. Before I started Braintree, I worked for a processor and saw first hand some of the limitations they had in providing solutions to merchants. I'll provide more detailed descriptions of both options and then offer an assessment of their differences.

1) Processors - Also known as Acquirers, processors are distinguished by their ability to actually process a transaction. To be a processor, a company must have the technical capability to receive transaction data from a merchant via a telephone line or the internet and then communicate with the appropriate financial institutions to approve or decline transactions. Processors must also be able to settle completed transactions through financial institutions in order to deposit funds into the merchant's bank account.

The processing industry is highly concentrated with the top five processors maintaining over 70% of all transaction volume. Processors can be banks or non-banks. While processors do maintain a direct sales force of their own, they primarily work through ISOs to acquire and maintain their merchant base. A processor's business model is really one of economies of scale. They're volume shops. They essentially outsource the sales function to ISOs. I don't have data on this but I would guess that over 80% of the 7 million U.S. merchants work with an ISO.

Below is simple diagram of the transaction flow. I took the liberty of putting my company in the value chain, but because Braintree is an ISO, there is a processor behind the scenes doing the actual transaction processing. Because most everything is private labeled, it's difficult for most merchants to discern whether their service provider is a processor or an ISO. Be careful not to be improperly influenced by this. Most sales people try to use the 'we are the processor' line to gain additional credibility when in reality it doesn't really matter. 



2) ISOs - ISOs resell the products or services of one or multiple processors. They can also develop their own or aggregate other value added products and services. ISO's range from a little sketchy to best in class providers.

There are two types of ISOs:

a. Banks - Banks of all shapes and sizes are ISOs. Wells Fargo, for example, is an ISO of First Data. Your local community and large regional banks are most likely ISOs. Banks entered into the merchant services business because it was a natural fit with their product and service offerings. It's a way to increase revenue per customer. Most, but not all banks, will private label the services so that it's difficult to distinguish whether they are a processor or ISO. The benefit of working with a bank is that you can consolidate your financial services. The drawback is the you usually get out of the box solutions and service.

b. Non-banks - These types of ISOs range from some of the most dynamic and capable providers to firms who don't represent the industry very well.

Industry Dynamics There are a few dynamics that make the industry landscape quite interesting. First, there are very barriers to entry due to the lack of certifications, licenses, and capital requirements. Secondly, there really is no active regulatory body that oversees and enforces acceptable practices. So naturally, with these two market conditions, merchants need to be mindful and through in selecting a provider.

Processors versus ISOs
In comparing the two, ISOs offer all of the products and services that processors do (because they are reselling) but processors can't always offer the same products and services as ISOs. This is because ISOs can resell for multiple processors and can either develop their own technologies or aggregate solutions from other providers. ISOs have largely been the most successful creators of value-added services while attempts by processors have usually been pretty clunky. ISO's also tend to be smaller, which usually (but not always) leads to better customer service.

Processors are usually a safer bet for newer merchants that are still learning about the industry. Most still maintain what I consider less-than-upfront pricing practices, but with their services it is less common to hear about some of the more serious problems that merchants encounter when they deal with the wrong ISO. As for price, in most cases, there really is very little to no difference. I argue, and fully disclose my vested interest, that in nearly any situation a best in class, non-bank ISO can provide more value than a processor. For some other considerations about what to bear in mind when evaluating different providers, you can read How to choose a merchant service provider.

Business specific merchant accounts The rates, terms, and conditions of your merchant account will largely depend on your type of business and the provider you choose. Business types are first divided into two buckets: card present (swiped) and card-not-present (non-swiped). Card present merchants, such as restaurants and brick and mortar retailers are low risk and have fairly simple needs. Card-not-present merchants are much more difficult because the risk level is substantially higher when people are transacting business via the internet, telephone, etc. Other risk factors that will affect your merchant account are the types of goods that you're selling, delivery times, whether or not a deposit is required, and about 20 other variables. Most underwriting groups use some sort of actuarial model to determine their guidelines.

To give you an idea of one risk merchant service provider face, here is an example. Let's say that you sell $100,000 in books online. Within 48 hours of selling those items, the customer's money is deposited into your bank account. If you take that $100k and skip town without shipping the books to the people who bought them, the merchant service provider is stuck with the $100k bill because customers are going to contest and win the charge with their banks. So for a few hundred dollars a month in revenue, the risk better be pretty manageable for the provider.

Paperwork and underwriting
Most companies have a two page application that will require you to fill out both personal and business information. Many people are justifiably concerned about giving out personal information including their social security number. However, unless you are a publicly traded or non-profit, I don't know of a merchant provider that will underwrite a business without it. When asked why all of the personal information is needed, most companies will point to the Patriot Act that was passed in Congress shortly after 9/11. It basically requires all financial institutions, which include credit card processors, to collect specific identifying information about their customers. Click here for more information on this. You will also be required to sign a personal guarantee before the application is approved.

Most business owners will respond that they incorporated so that they wouldn't be required to sign a personally guarantee. The underwriter will respond by asking why they should have more faith in your business than you do. Both sides have valid points. I think that the issue boils down to whether or not the business will deliver the goods or services that were purchased under the accepted terms and conditions. The personal guarantee is not so much useful in collecting money, but instead used as a deterrent against fraudulent and irresponsible behavior.

Be Careful
As you can see in this very high level introduction to the industry, there are a lot of complexities and much to learn. You can also read my post on Some advice to help you avoid common mistakes.

Comments: 8 | Post a Comment

PCI DSS Requirement 6.6 - Code Review or Web Application Firewall (WAP)

Posted on Thursday, July 10, 2008 by Bryan Johnson

The deadline to comply with PCI DSS Requirement 6.6 was June 30th, 2008. Merchants have been given two options:

1. Have all custom application code reviewed for common vulnerabilities by an organization that specializes in application security.
2. Install an application-layer firewall in front of web-facing applications.

The driver behind this new requirement is that a large percentage of credit card breaches are due to SQL Injection, Cross Site Scripting (XSS) and Buffer Overflow attacks. The intent of this requirement is to eliminate those vulnerabilities which would contribute to a significant reduction in breaches. Here is the Information Supplement supplied by the PCI Security Standards Council.

Other related posts:
The cost of a credit card breach
PCI Compliance basics
The cost to become PCI Compliant
Comments: 1 | Post a Comment

What does it cost to become PCI Compliant?

Posted on Wednesday, June 25, 2008 by Bryan Johnson

The cost of becoming PCI DSS Compliant depends on a number of factors including your business type, number of transactions processed annually, existing IT infrastructure, and current credit/debit card processing and storage practices. Gartner estimates that during 2007, the nation's largest merchants, classified as Level 1 (processing in excess of 6 million transactions of a single card type per year), will spend $125,000 assessing the scope of required PCI-related work and another $568,000 to meet the requirements.

As an example, Robin Sidel and Pui-Wing Tam of the WSJ recently reported that Guitar Center, a national retailer of 210 stores, recently spent nearly $500,000 to become compliant. Gartner also concluded that Level 2 merchants, those processing between 1 and 6 million annual transactions, will spend $105,000 to determine scope and another $267,000 for compliance. Level 3 merchants, processing between 20,000 and 1,000,000 e-commerce transactions, are expected to spend $44,000 assessing and $81,000 for compliance. The costs associated with Level 4 merchants, those doing less than 20,000 ecommerce transactions or up to 1,000,000 non-ecommerce transactions, varies widely.

Only Level 1 merchants are required to have an on-site audit. Levels 2, 3 and 4 need to fill out the Self Assessment Questionnaire and sign up for a quarterly scan to check vulnerabilities on all outward-facing IP addresses. A rough estimate for the scans is $150 to $2,500 per IP address per year.

Other costs may include software and hardware upgrades if information is stored in house. Gartner estimates that a company with 100,000 credit cards on file will pay $6 dollars in encryption costs per card. Alternatively, merchants can use technologies such as tokenization where the data storage is remote, which typically have per transaction fees instead of upfront costs. All of these estimates exclude the cost of labor and the opportunity cost of pursuing other profit-making endeavors.

Smaller restaurants and retailers that only have a single terminal or POS system are still required to become compliant. Both need to fill out the Self Assessment Questionnaire, but the compliance process is usually much less involved. Merchants that are using POS systems to process credit cards need to make sure they are not improperly storing prohibited card data and need to verify that their vendor is PABP compliant (soon to become PA DSS). To verify that your POS system is not storing prohibited information and is compliant, see this updated list was published in November 2007. Some merchants such as Brad Friedlander, a restaurant owner in Cleveland with two stores, paid $50,000 on technology upgrades to become compliant. Any merchant that accepts, stores, or processes credit card information is required to already be compliant.

The Card Associations have determined specific dates about when merchants need to validate compliance. Level 1 merchants were required to validate compliance by 9/30/07. Level 2 are expected to validate compliance by 12/31/07. Level 3 and 4 validation deadlines will come, but at this point they have been left up to the merchant's specific acquirer to be determined. Not only is becoming compliant not optional, but Card Associations have threatened larger merchants with the imposition of monthly fines until compliance is obtained. They've also threatened to increase the cost of interchange, which would increase these merchants' processing costs. But perhaps most importantly, the Card Associations will levy fines and penalties if a merchant is not PCI Compliant at the time of breach. The fines can be devastating to merchants. I've written about two breaches, both of which had significant consequences. One merchant is large, the other is small.

In addition, merchants face remediation and discovery costs can be just as costly, if not more so, than the fines. For a cumulative number, Gartner estimates that the cost of a data security breach can range from $90 to $305 per customer record. Some merchants are frustrated about the PCI requirements, while others see them as basic security requirements that should already be in place. A common misconception is that compliance equals security, but a number of recent breaches have proven that not to be the case. Other related posts: PCI DSS Compliance basics for credit card security PCI DSS Compliance and the cost of a credit card breach Braintree solutions: The Smart Approach to PCI DSS Compliance

Comments: 0 | Post a Comment

Subscribe via email


Subscribe via RSS

Search

Creative Commons License
This work is licensed under a Creative Commons License.