PCI Compliance Requirements for e-Commerce Merchants

It seems as if the PCI compliance requirements for e-Commerce merchants seems to be getting more stringent as each year goes by. With a never ending list of PCI DSS Self-Assessment Questionnaires (SAQ) available for merchants to use, it’s becoming a complex and challenging process in determining which SAQ to embark upon, what documentation is needed, what important scoping considerations should come into play, and so much more.

Need answers to the dizzying array of PCI compliance requirements for e-commerce merchants, then you’ve found the right place! As the world’s undisputed leader for PCI Policy Packets & Compliance Toolkits for e-commerce Merchants, pcipolicyportal.com provides the following in-depth analysis and overview for helping you become PCI compliant – quickly, comprehensively, and cost-effectively. Want to safe hundreds of hours and thousands of dollars on annual PCI compliance reporting – sure you do – then use our industry leading PCI toolkits, available for instant download today.

Making Sense of PCI Reporting and the Various SAQ Options

The biggest challenges we see when it comes to PCI compliance requirements for e-Commerce merchants is determining which of the PCI DSS Self-Assessment Questionnaires (SAQ) to use? After all, here’s the lucky list a merchant can choose from: SAQ A, SAQ A-EP, SAQ B, SAQ B-IP, SAQ-C, SAQ C-VT, SAQ P2PE-HW, and SAQ-D. It’s enough to make your head spin, for sure, so here’s a quick overview on each of the applicable SAQ’s in regards to determining which one is the best fit for your e-commerce platform.

• SAQ A: Card-not-present merchants (e-commerce or mail/telephone-order) that have fully outsourced all cardholder data functions to PCI DSS validated third-party service providers, with no electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Note: This is not applicable to face-to-face channels.

Therefore, to be eligible for SAQ A, e-commerce merchants must essentially meet all eligibility criteria detailed in SAQ A, including that there are no programs or application code that capture payment information on the merchant website. Examples of e-commerce implementations addressed by SAQ A include the following:

Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third-party payment processor.
Merchant website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process.
Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.

• SAQ A-EP: E-commerce merchants who outsource all payment processing to PCI DSS validated third parties, and who have a website(s) that doesn’t directly receive cardholder data but that can impact the security of the payment transaction. No electronic storage, processing, or transmission of any cardholder data on the merchant’s systems or premises. Note: This is applicable only to e-commerce channels.

Please keep in mind that if ANY element of a payment page delivered to a consumers browsers originates from the merchant’s website, SAQ A does not apply; thus, SAQ A-EP would have to be used. Some common examples of e-commerce implementations addressed by SAQ A-EP include the following:

Merchant website creates the payment form, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “Direct Post”).
Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.

• SAQ D: SAQ D for Merchants: All merchants not included in descriptions for the above SAQ types.

Additionally, the following SAQ’s are NOT applicable to e-commerce merchants: SAQ B, SAQ B-IP, SAQ C, SAQ C-VT, and SAQ P2P-HW. Therefore, you really only have three (3) options as an e-commerce merchant: SAQ A, SAQ A-EP, or SAQ D.

So what are My Next Steps as a Merchant?

Next steps? Determine which of the SAQ’s you are going to assess against, for which the vast majority of e-commerce merchants will choose either SAQ A or SAQ A-EP, but that’s the easy part. The difficult compliance pill to swallow – one that often leaves a bitter taste in your mouth – is if you chose SAQ A-EP. Why? Because SAQ A-EP is a tremendous leap in terms of the number of requirements and overall complexity of controls that merchants have to comply with when looking at the ease and simplicity of SAQ A.

SAQ A vs. SAQ A-EP – What You Need to Know

It’s important to note that prior to the release of SAQ A-EP, many e-commerce merchants with web sites that impacted the security of payment transactions truly felt they only had to comply with SAQ A because their web server did not store, process, or transmit cardholder data. While true, the problem was that many of these web servers did not have sufficient security controls applied to them and have thus become common targets for attackers as a means to compromise cardholder data. So say hello to SAQ A-EP, a much more comprehensive Self-Assessment Questionnaire indeed, unfortunately. Here’s our expert advice on deciding between SAQ A vs SAQ A-EP:

For SAQ A, e-commerce merchants must meet the following conditions:

Merchant has no access to their website, and the website is entirely hosted and managed by a compliant third-party payment processor.
Merchant website provides an inline frame (iFrame) to a PCI DSS compliant third-party processor facilitating the payment process.
Merchant website contains a URL link redirecting users from merchant website to a PCI DSS compliant third-party processor facilitating the payment process.

Therefore, if ANY element of a payment page delivered to consumers’ browsers originates from the merchant’s website, SAQ A can NOT be used, thus e-commerce merchants will have to look at SAQ A-EP or SAQ D. Examples of e-commerce implementations addressed by SAQ A-EP include:

Merchant website creates the payment form, and the payment data is delivered directly from the consumer browser to the payment processor (often referred to as “Direct Post”).
Merchant website loads or delivers script that runs in consumers’ browsers (for example, JavaScript) and provides functionality that supports creation of the payment page and/or how the data is transmitted to the payment processor.

Download SAQ Policy Packets from pcipolicyportal.com

Based on your e-commerce platform, merchants can become PCI DSS compliant via SAQ A, SAQ A-EP, or SAQ D, and pcipolicyportal.com has policy compliance packets available for each of these three reporting options. Visit pcipolicyportal.com today to instantly download your PCI policy compliance packets and get started immediately with becoming PCI DSS compliant. The PCI DSS standards are a fixture in today’s world of regulatory compliance – it’s just the world we live in – so now’s the time to get compliant and put in place all necessary policies, procedures, and related processes. pciolicyportal.com also offers professional consulting services for helping e-commerce merchants become compliant, such as policy writing, expert guidance on completing the applicable SAQ, and much more.

Since 2009, we’ve been helping e-commerce merchants become PCI DSS compliant, and now we’re ready to assist you! Just remember that often the most time-consuming and challenging aspect of compliance is none other than documentation – but we’ve got you covered. Our SAQ A, SAQ A-EP, and SAQ D policy packets are just what the PCI compliance doctor ordered!