PCI Compliance for eCommerce – Choosing Between SAQ A and A-EP

Update: Read our new PCI Compliance guide.

The Payment Card Industry Data Security Standards (PCI DSS) is a set of security standards established in a joint venture between a number of the top credit card issuers in the world – Visa, MasterCard, American Express, Discover and JCB. It was created to provide a minimum set of security requirements designed to help protect what is known as the Cardholder Data Environment (CDE).

This CDE is what is responsible for the storage, processing and transmission of what we all recognize as credit card information. This is also what causes misunderstanding that you must only be compliant if you store, process or transmit CC data. This is grossly inaccurate. All merchants must understand that PCI compliance specifically applies to all merchants that accept credit cards regardless of how.

How a merchant complies is determined by a number of factors, and what they must comply with also varies on another set of factors. These come in the form of different assessments, and the most prominent ones are the Self Assessment Questionnaires (SAQ). SAQ’s are specific to merchants that are categorized as a PCI Merchant Level 2 through 4. There is a different requirement for Level 1 merchants known as a QSA but that’s a discussion for a different day.

PCI Compliance for Ecommerce Websites

As a website owner interested in online commerce it behooves you to become familiar with the importance of PCI Compliance. If nothing else, you can make your own risk determination and not be caught off-guard in the event of a security incident.

This post will be specific to businesses that are only focused on online commerce, not those that have a brick-and-click business model (other means of collecting credit card data beyond the website i.e., Point of Sales [POS] devices, etc.).

Self Assessment Questionnaires (SAQ)

When we’re talking specifically about ecommerce merchants, based on PCI DSS v3.2, you’re going to want to focus specifically on SAQ Type A and SAQ Type A-EP. This will be determined by how you choose to handle credit cards.  Another great resource will be the ecommerce guidelines set for by the PCI Special Interest Group (SIG). This SIG document is dated 2012 and is currently under review (2016) so expect changes as they account for the latest advances in attacks and platforms.

If you are choosing to process locally on the web server, which is obviously an option, but not recommended, you’re going to focus on SAQ Type D but we won’t get into that in this discussion.

You won’t have to comply with both, but you will be responsible for one. For the everyday small business you won’t have to worry about someone knocking on your door looking for the documentation without cause (i.e., a compromise), but you might be asked for it when interfacing with specific service providers (i.e., gateways, issuers, etc..).

Which assessment you’ll be responsible for will be determined by how your website accounts for credit cards. SAQ A-EP is fairly new to the game (introduced in v3.0 of PCI DSS), relatively speaking, and there is some ambiguity with ecommerce store owners as to when it applies to them. It was introduced in version 3.0 to account for some inherent security risks that hadn’t been accounted for, specifically the various options website owners have for handling credit cards.

Defining Your Scope with PCI

With PCI, everything is about scope, specifically reducing it. Scope can be pretty ambiguous, so for an ecommerce site it specifically pertains to the Card Data Environment (CDE), or the way you handle credit cards on the site (i.e., how a customer enters their information and where it goes). There are four things that website owners should be thinking about when thinking about the CDE:

• Storage – How will the data be stored? Will you store it as an organization? Will you use a third-party vendor to store the data?
• Transmission – How will the data be transmitted between locations? How will the data get to the gateway? processors? Are you leveraging an SSL Certificate?
• Collection – How will the customer provide you the information? Will you use a form on the page? Will you use a form off the page? Will you accept via chat? Will you take it over phones?
• Processing – How will the data be processed? Will you do it locally? Will you use a service provider?

What you choose above can have significant impacts on which SAQ you must comply with and the actions you’ll have to take as an organization from a security perspective. The general consensus is that an ecommerce site should try not to store or process credit card data within their environment (locally). Use reputable service providers to handle this process for you.

In doing so, it leaves you as the website owner two domains to focus on: collection and transmission.

Handling Credit Card Data

If you follow the guidance of not storing or processing locally then you’ll have the luxury of focusing on SAQ A or SAQ A-EP. Which one will be determined by how you choose to integrate your service providers. Some will allow you to create a form on your page, then use their own hooks and methods to post to their API’s. Others will allow you to embed forms or similar elements into your website to assist in the process.

In general, you will find four types of payment integration options regardless of the platform you are running.

• Direct Post
• JavaScript
• iFrame
• Hosted Page

SAQ A

If your website uses an iFrame or Hosted Page implementation, you will be responsible for complying with SAQ A. In either case, the user is taken to a payment page that is hosted by the service provider. This can be done by introducing a redirect, where the user is taken to another page (i.e., hosted page), or can happen on the same page in the form of an iFrame.

Since the introduction of SAQ A-EP there have been some changes by service providers that would allow you to stick with SAQ A even though you might be using their JavaScript implementation option. Two examples of this can be found in Stripe and Recurly.

Here are a few  examples of service providers that offer integration options that allow you to leverage SAQ A:

• Stripe: Stripe.js and Checkout
• Recurly: Hosted Payment Page and Recurly.js (v4)
• BrainTree: Drop-in Payment UI
• Authorize.net: Hosted CIM
• PayPal: Hosted Pages

Note: This is meant to be a high level guide, if you have questions specific to your existing implementation it’s best you talk to your service provider or QSA. 

SAQ A-EP

If you use a Direct Post or JavaScript implementation, you will be responsible for complying with SAQ A-EP. In either case, you are capturing the information via your own form, using actions and methods to push to an API.

Here are a few  examples of service providers that offer integration options allowing you to leverage SAQ A:

• Stripe: Older JS implementations and Webhook implementationStripe: Older JS implementations and Webhook implementation
• Recurly: API and Recurly.js (<= v3)
• Authorize.net: Advanced Integration Method (AIM)

Note: This is meant to be a high level guide, if you have questions specific to your existing implementation it’s best you talk to your service provider or QSA. 

Choosing the Right SAQ

There is a lot of misinformation around PCI compliance and it’s exasperated by vendors that regurgitate information as a form of product differentiation. As a website owner, be wary of claims that sound too good to be true, and ask questions. Remember, compliance is a requirement for all merchants that accept cards, regardless of how they choose to implement their payment options. How you implement can often be facilitated by the platform you choose (i.e., WordPress WooCommerce, Magento, etc.).

The key for you as an ecommerce business owner will come in defining the full CDE scope and making the right decisions that fit your business needs; those decisions will tell you which SAQ you need to be in compliance with. These are conversations you want to be having with your development and integration teams early in the website’s lifecycle.