You may have heard the term PCI compliance, and you might even know about the new changes in PCI 3.0 that came into effect this year. But do you know if the PCI updates will impact your company? Don’t worry if you don’t know, as industry experts, we’re here to help! This article will shed some light on what has changed and what solutions we offer that can keep you in the clear for PCI compliance.
PCI, or PCI DSS, stands for Payment Card Industry Data Security Standard. It is a security standard that is created and organized by the major credit card companies, such as MasterCard, Visa, American Express, Discover, and JCB. The goal is to increase security around card holder data: how it is stored and transferred. Merchants processing credit card data for these card companies must validate that they are compliant and this must be done annually.
For merchants processing very large volumes, this involves being audited by a Qualified Security Assessor (QSA) to produce a Report on Compliance (ROC). For merchants with smaller processing volumes only a Self-Assessment Questionnaire (SAQ) is required. Most merchants just need to fill out the SAQ form. To determine what SAQ form you need to fill out you need to know what Merchant Level you are.
What Merchant Level Are You?
There are four different merchant levels in PCI. The levels are broken down based on how many transactions of a single card type you process. Along with the level you also need to look at how your site comes into contact with the card.
The table below lays out the details you need to know to find where you fit:
|Merchant Level||Number of Transactions Annually (per single card type)||Hosted Payment Form or Shopping Cart (all images hosted within Beanstream Secure Webspace)||Hosted Payment Form or Shopping Cart (any images hosted by merchant)||Client-side Tokenization or encryption||API||Other (Batch/Recurring/No website involved)|
|1||Over 6 million||RoC||RoC||RoC||RoC||RoC|
|2-4||Under 6 million||SAQ A||SAQ A-EP||SAQ A-EP||SAQ D||SAQ A|
As you can see there are different SAQ levels too:
- SAQ-A EP
- And some more not listed here
As you move higher up the alphabet (SAQ-D), there is more security responsibility due to the direct exposure to the card data. The lowest level is SAQ-A, because there is no direct contact with card data.
SAQ-A: The Easy Road
For most merchants this is where you want to be. It is the least amount of paperwork and the least amount of card data exposure to your website. To fit into the category you must process under 6 million transactions (for a single card type) and not have any of that card data go through your network. Prior to PCI 3.0 you could fit into SAQ-A by tokenizing or encrypting the card data on the client machine (app or web page) and send that data to your web server. However with PCI 3.0 this has now changed.
Now tokenizing or encrypting the card data is not enough since it comes into contact with your client-side app or web page. This contact puts you in SAQ-A EP. There is a solution to this, and we will discuss it below.
SAQ-A EP: Where Many of You Are Now
Many payment gateways promote that they take care of the burden of PCI compliance for you by providing tokenization or encryption mechanisms for card data. This was true up until PCI 3.0. Now with PCI 3.0 any card data touching your software, be it on the client or server, means you are in SAQ-A EP. You are required to complete a more in-depth audit in this level.
SAQ-D: Seeing Card Data
In this level servers and network have the ability to see the credit card data. It means you must take extra precautions to avoid a data breach. An easy solution to avoid being placed in SAQ-D is to use a tokenization or encryption tool such as Beanstream’s Legato service. This converts the card number, expiry, and CVD into a single-use token that you then send to your server. With this solution you fall back into the easier SAQ-A EP level.
The big difference, you will see right away, is how much larger the SAQ-A EP form is than SAQ-A:
- SAQ-D: 53 pages
- SAQ-A EP: 36 pages
- SAQ-A: 16 pages
Beyond filling out the longer form you need to perform many more security checks and possibly perform a lot of refactoring of your site and infrastructure. You can view the different forms here. They go into a lot of detail about what password storage, account access, network scanning, and much more.
Solutions for SAQ-A
Since you can’t use client-side tokenization or encryption to be compliant with SAQ-A (you now fall under the EP category), then you need another solution. The solution is to host all of the payment collection software and tools on your payment provider or gateway. Because all of the card information is on this 3rd party’s network and servers then it is up to them to handle the security responsibilities for PCI compliance.
We Are Here To Help
PCI Compliance is not the easiest audit to work through, we are here to help you. We have an excellent support team that can answer your questions either over the phone or by email. If you have more questions on PCI compliance then reach out to us, we will be glad to help.