eCommerce Demystified – Part 3: PCI-DSS

Now that we have identified the 4 major scenarios for how to divide the eCommerce functionality between the merchant's website and outside providers, we'll begin covering some general considerations that might influence your decision about which of the scenarios is right for you.

Specifically, we will cover a relatively new development in payment card security that has important implications for all eCommerce implementations.

PCI-DSS

Once upon a time you could load eCommerce software onto your web server, set up a Merchant Account and start accepting payment (credit/debit) card payments without many constraints other than having a legitimate business. That time has passed.

What happened? Lax safeguards on collected payment card information allowed criminals to get at the data and use it for fraud.

In 2006, the major payment card companies (American Express, Discover, JCB, MasterCard and Visa) created an industry standards body called the Payment Card Industry (PCI) Security Standards Council. One of the standards created by this council is the PCS Data Security Standard (PCI-DSS). It's purpose is to prevent credit card fraud and compromise of cardholder information.

What Is PCI-DSS?

The PCI-DSS standard covers all aspects of eCommerce. It has 12 major sections:

1. Install and maintain a firewall configuration to protect cardholder data
2. Do not use vendor-supplied defaults for system passwords and other security parameters
3. Protect stored cardholder data
4. Encrypt transmission of cardholder data across open, public networks
5. Use and regularly update anti-virus software
6. Develop and maintain secure systems and applications
7. Restrict access to cardholder data by business need-to-know
8. Assign a unique ID to each person with computer access
9. Restrict physical access to cardholder data
10. Track and monitor all access to network resources and cardholder data
11. Regularly test security systems and processes
12. Maintain a policy that addresses information security

But these are only the top-level categories. Underneath these major headings there are 226 or so specific requirements.

The Carrot and the Stick

So, how does the standard affect you? Most merchants who accept payment cards must validate their compliance to the standard. The exception is merchants with small transaction volumes (we'll define that further in the next section). But ultimately the one who establishes what you need to do is your Acquirer, and a number of banks are requiring validation of everyone.

Why might you want to validate even if you aren't required to? That is where the Carrot and Stick analogy comes into play.

The stick in this case is the financial disaster you might face if you ever have a credit card information breach. First, the affected credit card company will levy a fine that usually starts at $50,000 and goes up from there. Although the fine is levied against your Acquirer, they are going to a pass it through to you. Second, you will be placed in a different merchant category and required to go through an annual validation by an outside auditor. Then there are the notification costs and potential financial liability for losses.

In practice, more than 50% of small merchants who suffer a credit card information breach either don't survive, or face massive business changes.

The carrot is that validation against PCI-DSS affords you a "safe harbor", at least as far as the credit card companies are concerned. This means that you will not face the fines and other penalties from them.

PCI-DSS Validation

So, how hard is it to validate your PCI-DSS compliance? That depends on 2 things — your transaction volume and how you handle payment cards.

Transaction Volume

How many payment card transactions you handle per year is the primary factor in determining how you need to handle the validation. The following table is a somewhat simplified summary of how merchants are classified and how that affects validation.

Merchant Level	Transactions/ Year	On-Site Assess	Quarterly Net Scan	Self- Assess
1	> 6 million	X	X
2	1-6 million	X	X
3	20,000 - 1 million		See below	X
4	< 20,000		See below	X

Very large (Level 1 or Level 2) merchants must have an annual audit by a certified Qualified Security Assessor (QSA), or by their own in-house equivalent. In addition, they must have their network scanned every quarter by an Approved Scanning Vendor (ASV).

For the purposes of this series, we're going to assume that all of you are either Level 3 or Level 4 merchants. This means that, instead of having to pay a QSA to do an audit, you are eligible to use the Self-Assessment Questionnaire (SAQ). Does that help? Maybe. If you are eligible for self-assessment, you need to consider the next level of detail.

SAQ Validation Type

There are 4 versions of the SAQ document—A, B, C and D. A is the easiest, with just a handful of questions. If you have to complete a SAQ D, you have to validate that you meet all of the same 226 criteria as a Type 1 or Type 2 merchant.

For eCommerce, the criteria can be summarized as follows:

Your Payment Processing	SAQ
All cardholder data functions outsourced	A
Cardholder functions performed locally, but no cardholder data stored	C
Cardholder functions performed locally, and cardholder data stored	D

Just to be clear, the phrase “All cardholder data functions outsourced” means that no payment card information ever touches your website. All of the payment card processing, including the collection of payment information, has to be handled by a third-party.

For example, if the customer enters their payment card number on your website and you pass it to your Acquirer to be authorized, then you do not quality for Level A. But you could qualify for Level C if you don't store that cardholder information. Level C is a lot easier than level D.

The decision as to whether you need to do a quarterly network scan is based on similar factors. If your network ever has payment card information passing over it, then you have to have the scan. If all payment card information goes to a third-party provider without passing through your site, then you don't.

Implications For Your eCommerce Decision

If you recall, our 4 eCommerce scenarios are as follows:

If we apply the factors from the previous section, we get the following:

Scenario	SAQ Version	Network Scan
Merchant Store	C or D	Yes
Hosted Payment	A	No
Hosted Cart	A	No
Hosted Store	A	No

As you can see, the downside of completely hosting your own online store is that every year you have to perform a full PCI-DSS assessment and every quarter you must have your network scanned by a specialist. Although you could theoretically your own assessment via the SAQ D, in practice you are better off having it done by a professional (at significant expense).

Where To Now?

We have spent an entire installment of this series on PCI-DSS because:

1. It's relatively new, so many merchants don't know much about it
2. It is a major factor in any decision about how to handle eCommerce.

In Part 4, we'll cover a number of other factors that may also affect your eCommerce decision.

Note: When you're ready, I have the skills to help you implement your online store.

Get a Quote