First, PCI compliance involves more than just your website. If your business takes credit card numbers over the phone, has face-to-face transactions, or keeps paper records that contain credit card numbers there are PCI requirements concerning that aspect of your business that has nothing to do with your website. This article addresses the PCI requirements specifically related to ecommerce transactions.

Do I Need To Worry About PCI Compliance?

Anyone who has a business that receives payments from customers who use their credit cards to pay needs to be PCI compliant – even if you only receive one credit card payment per year. The volume of transactions does not make a difference. Even if your website uses a 3rd party service like PayPal, Google Checkout, or Cart66 Cloud you still need to be PCI compliant because your business (not necessarily your website) receives payments via credit card.

What if I am not PCI compliant?

If you do not meet the PCI standards for compliance and the security of your site gets compromised, you will be facing penalties and fines ranging from $5,000 to $500,000. The fines, however, are just the beginning of the overall damage caused by noncompliance.

If your website or company are not PCI compliant, you run the risk of losing your merchant account, which means you won’t be able to accept credit card payments at all. You will also be placed in the Visa/MasterCard Terminated Merchant File (TMF), making you ineligible to obtain another merchant account, at least for several years. The TMF, is essentially a BLACKLIST from which it is almost impossible to be removed.

When a merchant is added to the TMF, sometimes called The Match File, their name, business name, business address, and home address are all noted. So, you can’t just apply for a new account under the name of another family member or business partner because it will be seen as the same business and location.

Getting on The Match File is just about the worst thing that can happen to any merchant.

What Level Of PCI Compliance Do I Need?

Even if your website does not store credit card data, if it transmits credit card data you need to complete the Self-Assessment Questionnaire C (SAQ C) in order to be compliant. If your website has a form that collects credit card data, and the domain name in the web browser is your domain name, then your server needs to be PCI compliant and you need to complete SAQ C.

If ALL cardholder data function are outsourced to a 3rd party like Cart66 Cloud, and your website does not store, process, or transmit card holder data, you only have to fill out Self-Assessment Questionnaire A (SAQ A).

If your website connects with a payment gateway directly over an API call, you MUST complete and comply with SAQ C.

What Does Self-Assessment Questionnaire C Require In Order To Be PCI Compliant?

It is very challenging to be compliant with all of the requirements of Self-Assessment Questionnaire C. Here are some direct quotes of the requirements from SAQ C that pose the most trouble and expense. You may download and review Self-Assessment Questionnaire C for yourself here.

Section 1.3: Does the firewall configuration prohibit direct public access between the Internet and any system component in the cardholder data environment…

Explanation of Section 1.3: The cardholder data environment includes all components of your website including the database. For most websites, including WordPress websites, this involves your web server and your database server. This requirement means that your database server must be on it’s own, physical server – not on the same box as your web server – and that you must connect to it over a Virtual Private Network. Using PHPMyAdmin, for example, is not a PCI Compliant way to manage a database.

Even if your database does not store credit card information, it is responsible for providing content to your website which does collect and transmit the cardholder data and, therefore, is part of the cardholder data environment.

Section 2.3: Is all non-console administrative access encrypted as follows:
Use technologies such as SSH, VPN, or SSL/TLS for web-based management and other non-console administrative access.

Explanation of Section 2.3: If your web site allows you to FTP in (even if you don’t personally choose some other means other than FTP) to make updates to your website, then your server is not PCI compliant. FTP is a form non-encrypted access to your server. A PCI compliant server must disable FTP entirely.

Section 6.1: (a) Are all system components and software protected from known vulnerabilities by having the latest vendor-supplied security patches installed? (b) Are critical security patches installed within one month of release?

Explanation of Section 6.1: If you host your website on a shared server, you will have no control over which security patches get installed and when those patches are installed. Unless you have the ability to install your own security patches or have a written agreement with your web hosting provider that this requirement will be met, your server is not PCI compliant.

An easy way to check is to see what version of PHP and what version of MySQL your server is running. The vast majority of web hosts do not update their software quickly enough to meet this requirement. For example, at the time of this writing, Rackspace Cloud Sites is still running PHP 5.2.13 which was released on February 25th, 2010 over 2 YEARS ago!

Section 8.3: Is two-factor authentication incorporated for remote access (network- level access originating from outside the network) to the network by employees, administrators, and third parties?

Explanation of Section 8.3: An example of two factor authentication is logging in with a username and password then, before gaining access to the system, you also get a phone call to verify your identity. If you can log into your system with just a username and password, your server is not PCI compliant.

Section 11.2: Are internal and external network vulnerability scans run at least quarterly and after any significant change in the network…

Explanation of Section 11.2: You need to subscribe to a security and vulnerability scanning service and have those scans run at least once every 3 months.

What If I Use A System That Passes Credit Card Data Directly To My Payment Processor?

There are several attempts to work around these PCI and security requirements. One common attempt is to submit cardholder data directly to a payment gateway using JavaScript, and iFrame, or a transparent redirect. A transparent redirect means you host the checkout form but the action tag on the form points directly to your payment gateway. Admittedly, there is a great deal of confusion as to whether or not this is a PCI compliant solution. Our firm has interviewed multiple Qualified Security Assessor (QSA) firms and the vast majority of them suggest that this is not a PCI compliant solution because the merchant’s website is still responsible for generating the code that transmits the cardholder data. Whether it be javascript, HTML markup for an iFrame source, or HTML markup for a form action tag, if the merchant’s website is hacked the cardholder data can easily be stolen. Therefore, almost every QSA we spoke to said that even sites that pass cardholder data directly to payment processors still need to comply with Self-Assessment Questionnaire C (SAQ C) and adhere to the requirements listed above.

Even if directly passing card holder data to a payment processor was PCI compliant, it is still not as secure as using 3rd party service such as Cart66 Cloud, and you will sacrifice the ability to design the look of your checkout page. Cart66 Cloud solves this problem by allowing you to completely design your own checkout page but have it hosted on our secure ecommerce platform.