• Skip to primary navigation
  • Skip to content
  • Skip to primary sidebar
  • Skip to footer

Sucuri Blog

Website Security News

  • Products
    • Website Security Platform
    • Website Firewall (WAF)
    • Enterprise Website Security
    • Multisite Solutions
  • Features
    • Detection
    • Protection
    • Performance
    • Response
    • Backups
  • Partners
    • Agency Solutions
    • Partners
    • Referral Program
    • Ecommerce
  • Resources
    • Guides
    • Webinars
    • Infographics
    • SiteCheck
    • Reports
    • Email Courses
  • Immediate Help
  • Login
In this post, we cover the Payment Card Industry Data Security Standard (PCI DSS) Requirement 5 & 6: Maintain a Vulnerability Management Program.

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

June 23, 2016Tony PerezEspanolPortugues

FacebookTwitterSubscribe

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..).

Sucuri-PCI-SAQ-Ecommerce

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.

FacebookTwitterSubscribe

Categories: Ecommerce Security, Security EducationTags: Best Practices, PCI Compliance

About Tony Perez

Tony is the Head of Security Products at GoDaddy and Sucuri Co-Founder. His passion lies in educating and bringing awareness about online threats to business owners. His passions revolve around understanding the psychology of bad actors, the impacts and havoc hacks have on website owners, and thinking through the evolution of attacks. You can find his personal thoughts on security at perezbox.com and you can follow him on Twitter at @perezbox.

Reader Interactions

Comments

  1. Luke

    September 1, 2016

    Doesn’t a redirect require SAQ A-EP?

    From: Part 2g. Eligibility to Complete SAQ A-EP

    “Merchant’s e-commerce website does not receive cardholder data but controls how consumers, or their cardholder data, are redirected to a PCI DSS validated third-party payment processor;”

    I have read that for fear of a compromised redirect sending consumers to a phishing page instead of the intended location, SAQ A-EP is now required under V3, but I am consistently finding mixed information on the web regarding this. The document itself seems to indicate A-EP is required. What are your thoughts?

    • Tony Perez

      September 1, 2016

      You just hit one of the many ambiguous pieces of the SAQ A vs A-EP guidance… when you dive into the details you’ll find a lot of information that could be considered contradictory. It’s also why I always joke that PCI is like law, it’s about interpretation.

      I’m personally hoping that the E-Commerce 2016 SIG will flush this out better and provide clearer guidance.

      I think that the section is poorly written. With that in mind, I would say that if a site is redirecting the user to a hosted page (think PayPal or one of the many other providers) they are ok with SAQ A. Be mindful however that this doesn’t account for any change that can happen at the application level, where the redirect can be modified. A good example of this can be found in one of our more recent articles in which the attacker targeted the check out page specifically, infected it with malware that redirected the user to another hosted page: https://blog.sucuri.net/2016/07/phishing-attacks-target-ecommerce-checkout-pages.html

      It’s these type of scenarios that the I believe the ecommerce guidelines need to be adjusted for.

      Does this help? Clear as mud? : /

Primary Sidebar

Socialize With Sucuri

We're actively engaged across multiple platforms. Follow us and let's connect!

  • Facebook
  • Twitter
  • LinkedIn
  • YouTube
  • Instagram
  • RSS Feed

Join Over 20,000 Subscribers!

Sucuri Sidebar Malware Removal to Signup Page

Footer

Products

  • Website Firewall
  • Website AntiVirus
  • Website Backups
  • WordPress Security
  • Enterprise Services

Solutions

  • DDos Protection
  • Malware Detection
  • Malware Removal
  • Malware Prevention
  • Blacklist Removal

Support

  • Blog
  • Knowledge Base
  • SiteCheck
  • Research Labs
  • FAQ

Company

  • About
  • Media
  • Events
  • Employment
  • Contact
  • Testimonials
  • Facebook
  • Twitter
  • LinkedIn
  • Instagram

Customer Login

Sucuri Home

  • Terms of Use
  • Privacy Policy
  • Frequently Asked Questions

© 2023 Sucuri Inc. All rights reserved

Sucuri Cookie Policy
See our policy>>

Our website uses cookies, which help us to improve our site and enables us to deliver the best possible service and customer experience.