PCI Compliance

Introduction

Ensuring that your business adheres to the security standards set by the credit card industry can be onerous and expensive. Instead, it might be wiser to invest in developing your payment processing systems, and avoid the harshest implications of PCI compliance.

Why Bother With PCI Compliance?

As an e-commerce merchant, if your company ever stores credit card details, you need to become PCI (Payment Card Industry) compliant at a very high level. The form of storage is irrelevant – computer disk or computer memory – if your computer system even sees credit card information before passing it on for processing – you definitely need to be PCI compliant.

The level of credit card business you do will dictate the level of PCI compliance you need to achieve. The process is complex, expensive and documented using terminology you probably won’t understand – tempting many businesses to ignore or overlook the requirement completely. However, the fines for non-compliance are simply massive – up to half a million dollars per infraction.

PCI Security Standards Council

It all starts with the PCI Security Standards Council who tell merchants what they need to do to stay out of trouble. Online merchants will be interested mainly in the PCI Data Security Standard (PCI DSS).

The DSS outlines 12 steps necessary for compliance and introduces the terms QSA (Qualified Security Assessor) and ASV (Approved Scanning Vendor). Now you know you’re looking at a potentially expensive process.

QSA’s are basically consultants who will walk you through the process of compliance. ASV’s are online services which periodically scan your system to see if they can breach your security measures.

Depending on how thoroughly you need to be PCI DSS compliant will dictate whether you need either of these services and how much they’re likely to cost you.

Merchant Levels

There are four merchant levels, with 1 being the largest / most difficult, and four being the least stringent / easiest to comply with:

Level 1	Any merchant, regardless of acceptance channel, who: Processes over 6 million Visa or MasterCard transactions per year Has suffered a hack or an attack that resulted in data compromise Has been identified by Visa, MasterCard, or any other payment card as Level 1
Level 2	Any merchant who processes 1 million to 6 million Visa or MasterCard transactions, regardless of acceptance channel
Level 3	Any merchant who processes 20,000 to 1 million Visa or MasterCard e-commerce transactions
Level 4	Any merchant who processes fewer than 20,000 Visa or MasterCard e-commerce transactions or processes fewer than 1 million Visa or MasterCard transactions, regardless of acceptance channel

Level 1 merchants must use the services of an ASV to walk them through compliance. It’ll be expensive, but they’re processing in excess of 15,000 transactions a day – so you’d hope they can afford it.

Level 2 and 3 merchants can become compliant using a DIY approach – no expensive consultants required. However, the cost of implementing any necessary security requirements could be significant. The DIY approach involves completing a questionnaire and having their systems scanned for security vulnerabilities.

Level 4 merchants are suggested to complete the questionnaire and have their systems scanned – but are not required to do so.

Perceived Credit Card Risk

It’s interesting to note that the credit card companies perceive an increase in risk with an increase in the number of transactions – not the value of those transactions.

You’d be a Level 1 merchant if you processed 6 million transactions, each for €0.10 – a credit card revenue of €600,000. With the same credit card reveune, but fewer transactions, you’d be a level 4 merchant if you processed 20,000 transactions, each for €30.

They also believe that e-commerce transactions are five-times more risky than other acceptance channels. You can be a level 4 merchant and process 1 million transactions offline, but only 20,000 online. That’s kind of weird, because the credit card holders I know who have been the victims of fraud, all had their details swiped (literally) offline at a physical store, not online.

Self Assessment Questionnaire

Happy with PCI, DSS, QSA and ASV? Let’s add SAQ into the mix.

One of the fundamental requirements for every form of compliance is to complete the self assessment questionnaire (SAQ). This is a document which you, or your expensive consultant, complete to declare that you are compliant with the requirements of the PCI DSS.

You could easily lie and tick all the boxes, but don’t forget that half-a-million-dollar fine hanging over your head.

There are four versions of the Self Assessment Questionnaire which correspond to five different types of Merchant. These have nothing to do with the Merchant Level outlined above.

Merchant Level determines whether or not you need to be compliant and how much expensive help you must buy to become compliant.

Questionnaire Level determines how thorough you need to be to become compliant.

Type 1	Card-not-present (e-commerce or mail/telephone-order) merchants, all cardholder data functions outsourced. This would never apply to face-to-face merchants.	SAQ A (13 questions)
Type 2	Imprint-only merchants with no electronic cardholder data storage	SAQ B (26 questions)
Type 3	Stand-alone terminal merchants, no electronic cardholder data storage	SAQ B (26 questions)
Type 4	Merchants with POS systems connected to the Internet, no electronic cardholder data storage	SAQ C (41 questions)
Type 5	All other merchants (not included in Types 1-4) and all service providers defined by any payment card as eligible to complete an SAQ.	SAQ D (238 questions)

Questionnaire A is the most basic; D is the most comprehensive. Pray that you don’t need to complete the ‘D’ questionnaire because it will cost you a lot to set up and maintain. If your system EVER sees credit card details, chances are you need to complete the ‘D’ questionnaire.  So far so good?

The Questionnaire D Gotcha

There’s really not much you can do about your Merchant Level – other than refuse credit card business which takes you over the 200,000, 1 million or 6 million annual credit card transactions. At least in this respect, compliance with PCI DSS is roughly related to business volume or revenue.

The real sting lies with questionnaire D, which is applicable by default whenever questionnaires A,B or C don’t fit. Most of the discussion you’ll read is about whether merchant ‘X’ could scrape by completing questionnaire C instead of D.

The questionnaires themselves shed only a little more light on which is the correct one to complete for any given merchant:

Questionnaire A

• Merchant does not store, process, or transmit any cardholder data on merchant premises but relies entirely on third party service provider(s) to handle these functions.
• The third party service provider(s) handling storage, processing, and/or transmission of cardholder data is confirmed to be PCI DSS compliant
• Merchant does not store any cardholder data in electronic format, and if Merchant does store cardholder data, such data is only in paper reports or copies of receipts and is not received electronically.

Questionnaire B

• Either: Merchant uses only an imprint machine to imprint customers’ payment card information and does not transmit cardholder data over either a phone line or the Internet.
• OR: Merchant uses only standalone, dial-up terminals; and the standalone, dial-up terminals are not connected to the Internet or any other systems within the merchant environment
• Merchant does not store cardholder data in electronic format, and if Merchant does store cardholder data, such data is only paper reports or copies of paper receipts and is not received electronically.

Questionnaire C

• Merchant has a payment application system and an Internet or public network connection on the same device.
• The payment application system/Internet device is not connected to any other system within the merchant environment
• Merchant does not store cardholder data in electronic format, and if Merchant does store cardholder data, such data is only in paper reports or copies of paper receipts and is not received electronically
• Merchant’s payment application software vendor uses secure techniques to provide remote support to merchant’s payment application system.

Questionnaire D

All 238 questions – should be completed when Merchant activity is not covered by Questionnaires A, B or C.

Host Your Own Payment Pages?

If so, chances are you’d need to complete Questionnaire D – because none of the others cover your activity.

• Questionnaire A is not applicable because you transmit cardholder data
• Questionnaire B is not applicable because it precludes any internet connection
• Questionnaire C is not applicable because of the definition of ‘storage’. All information is stored in computer memory before being forwarded across the Internet (store and forward). Chances are that your payment application IS also interconnected with other systems on your network too.

If you host your own payment pages, your systems are storing credit card details (albeit very briefly), you need to complete Questionnaire D.

Aside from the cost of implementing the required levels of security, completing this questionnaire will require a significant investment of time from your technical and systems administration personnel.

How to Avoid Completing Questionnaire D

By using a payment processor (Protx in our case), and having them handle the entire credit card transaction, you offload all the difficult bits of PCI DSS compliance to them.

Protx has to maintain a much higher level of compliance – and this covers merchants too IF they use the Protx payment pages (VSP Server in Protx speak).

If the merchant hosts their own payment pages (Protx VSP Direct), the merchant is required to comply with a much more stringent level of PCI.

Why Merchants Host their own Payment Pages

One problem of having the payment gateway host their payment pages is that, during the credit card transaction, the client is actually passed back and forth between the Merchant’s system, and the Payment gateway.

This can be confusing or unsettling to the client and can cause them to abandon the transaction. Careful customisation of the payment pages to mimic the merchant’s own web site can minimise this – but this is the main reason merchants prefer to host their own payment pages entirely – so that there are no jarring transitions between systems.

(WorldPay is a great example of a payment gateway doing this very, very badly).

Another reason is when merchants want to process recurring or subscription transactions. Protx use a token system to help merchants avoid the requirement to store credit card details on their own systems.

Essentially, Protx store the card details and provide the merchant with a secure token which represents the card details. When the merchant wants to process a repeat or subscription transaction, they simply present the token to Protx, who then process the transaction – all without the merchant needing to know or store any credit card details.

Protx support this method whether the merchant hosts the payment pages or they are hosted by Protx themselves.

The problem is that ActiveMerchant only supports recurring billing when the payment pages are hosted by the merchant.

ActiveMerchant + Repeat Billing = Questionnaire D = Expensive

Tweaking ActiveMerchant to Avoid Questionnaire D

ActiveMerchant already has an interface to Protx, and it can use their VSP Server (Protx hosted pages) or VSP Direct (Merchant hosted pages) methods. For repeat billing, ActiveMerchant currently only supports the VSP Direct method.

The work-around appears to be to have ActiveMerchant use merchant-hosted pages (VSP Direct) for everything EXCEPT entering credit card details. This single part of the transaction could be switched to use the existing VSP server method and then switch back to the existing VSP Direct method.

Repeat billing of the same credit card would use the existing token exchange within the existing VSP Direct method. This has yet to be programmed but it seems to be the way to go for us.

Summary

PCI DDS compliance can be a serious and expensive business. The penalties for non compliance are severe and the requirements to meet compliance are not straightforward.

All but the largest companies can offload this requirement to their payment processor – provided that the payment processor hosts the payment pages.

If this is not possible for technical, business or aesthetic reasons, a more cost effective approach is for the merchant to invest in programming a hybrid solution using their own payment pages where possible, combined with a credit card form hosted by the payment processor.

For us, investing in developing ActiveMerchant makes far more sense than investing and continuing to invest in PCI compliance.