Picture this: you’re a child getting ready to head to the beach. Your parents grab your swimsuit, sand bucket, towel, flippy floppies, sunscreen, water, and snacks, and you’re all out the door. For you, it’s been a fairly simple operation to have some fun.
But twenty years later, you’re corralling your two children—you’re the one making sure they have their swimsuits, floaties, multiple towels, snacks, and anything else you need, just as your parents did for you.
In both instances, the end result is still fun at the beach—it’s just the scope of your work is markedly different.
While PCI DSS definitely is not a visit to the beach—unless you liken it to the annoyance of the lingering sand between your toes on the drive home—e-commerce merchants look for ways to reduce the scope of their compliance because a smaller scope means less work. And when it comes to the Self-Assessment Questionnaire (SAQ) for e-commerce transactions, the details on payment acceptance mean that you are the child ready to party or you are the parent with more to do.
If you’ve had experience with PCI DSS before, you know that, unfortunately, payment card security is incredibly complex. As QSAs that perform hundreds of these assessments annually, we know the pain organizations commonly feel in trying to make sense of everything.
That’s why in this article, we’ll first define all the important terminology you need to know regarding SAQs before we get into the differences between an SAQ A and SAQ A-EP—including the relevant PCI DSS requirements.
We’ll also include visual data flows for reference so that everything is as straightforward as possible for you merchants when delving into e-commerce and as a result, PCI DSS.
Important PCI DSS SAQ Terms
As promised, here is a sort of glossary that’ll help when making sense of the forthcoming details.
(Note that in this context, the client we refer to is the computer connecting to a website and the server is hosting the website.)
- Server-Side – In a client-server model, a server-side operation means that the function runs on the server and the result is provided to the client.
- Client-Side – In a client-server model, a client-side operation means that a function is provided by the server and runs on the client.
- Uniform Resource Locator (URL) – The common name for a resource. Website names are an easy example, like https://www.schellman.com.
- Third-Party Service Provider – A separate organization or entity that performs functions on behalf of another. For e-commerce payments, a common example is the payment gateway providing the iFrame or redirect to merchants.
- Direct Post – Data is received by a web server and relayed to another URL. A merchant website provides the payment form (generates the payment page) before the end-user’s browser sends the card data directly to the third-party service provider.
- Inline Frame (iFrame) – An HTML element that references another HTML element on a web page.
- Let’s say you were reading a physical book that cited another work. To read the work referenced, you would need to look it up. But if the first book was instead a webpage and the citation an iFrame, the webpage would provide both resources on the same page.
- The content within an iFrame can be something your organization maintains or something that is provided by a third-party service provider.
- Redirect (A.K.A. a URL Redirect) – A method of sending users to another page automatically—there are multiple ways to do this.
- Within the PCI context of payment pages, this is a client-side redirect. Meaning that the web server includes a URL redirect and when the end-user goes to apply payment, the end-user’s browser loads the page directly from their computer for payment, delivering credit card details directly to the third-party service provider.
Payment Data Flow Diagrams
To help illustrate how it works, here are diagrams of each defined, technical approach to online purchasing.
Payment Processing and PCI DSS
So what’s the difference?
- Direct Post (server-side operation): Your web server creates the payment page, receives, and then sends card data to the third-party service provider directly from your customer’s browser.
- If you use direct post, you can make your payment page look any way that you want, which can be enticing if you’re trying to achieve a consistent website aesthetic or have specific creative ideas in mind.
- iFrame or Redirect (client-side operations): Your customer’s browser loads the payment page and sends the card data to the third-party service provider.
- Unlike with the direct post, if you’re using an iFrame or redirect, you’re at the discretion of the third-party service provider regarding how portions of or the entire payment page look.
Aside from control over aesthetics, there’s a bigger difference between direct post and iFrame/redirect. How you’re managing this data flow also potentially impacts the security of your transactions—and therefore, it impacts your PCI DSS options.
This has everything to do with your third-party service provider (or lack thereof):
- Direct Post: Little scope reduction for your SAQ, as you are responsible for everything on the payment page.
- There’s increased capability for attackers to compromise the security of cardholder data with direct post, and so you must be evaluated fully.
- iFrame/Redirect:
- Because a third party is responsible for the majority of the compliance surrounding cardholder data, it’s possible to reduce the scope of your SAQ.
- However, that service provider offering the iFrame or redirect must be compliant with the PCI DSS—if they aren’t, you don’t get any scope reduction.
The Differences Between SAQ A and SAQ A-EP
The PCI SSC is quite clear on how these differences translate to your self-assessment:
“If any element of a payment page originates from the merchant’s website, the implementation is not eligible for SAQ A. If any element of a payment page originates from a non-compliant service provider, the implementation is not eligible for either SAQ A or SAQ A-EP.”
These two self-assessment options are most starkly different when it comes to the PCI DSS requirements for each:
- SAQ A: 22 requirements that focus on the removal of system defaults, patching, and access controls.
- SAQ A-EP: 191 requirements that essentially cover the full standard minus cardholder data storage, a bit of software development, and some physical controls.
So, to pull it all together:
- For a merchant using direct post, you will need to conduct an SAQ A-EP with the greater number of requirements to account for the security of payment data flow implementation.
- For a merchant using iFrame or redirect, you do have the option to choose an SAQ A instead, but you must ensure that your third-party service provider is PCI DSS compliant.
What to Ask Your E-Commerce Payment Provider
For those merchants using the latter, it likely seems like a lot hinges on your chosen third party, and it’s true. As such, there are certain things you’ll need to understand and ask before engaging one to accept your e-commerce payments. Ensure you get the answers to these questions:
- Does the payment page load from an iFrame, a redirect, or direct post?
- Will my web server offer up any portion of the payment page or will the end-user’s browser perform these actions in full?
- Will my web server receive or have access to card data?
- What documentation can you provide to support the payment channel?
- (This will further confirm that what you’re being told aligns with how the payment data is handled and should include the third-party service provider’s compliance.)
Also, be aware that a large number of third-party service providers offer all three—yes, ALL THREE options of direct post, iFrame, and redirect.
Next Steps for Your PCI DSS Self-Assessment
If there’s anything to take away from all this, it’s that not all e-commerce solutions are equal, and the third party you choose to trust with your payment transaction processing will make all the difference when it comes time to perform your PCI DSS SAQ.
If you’re a merchant looking to reduce the scope of such, the benefits of using an iFrame or redirect are quite clear in the reduced requirements that you don’t get with direct post. You may still have questions about this or other facets of PCI DSS, and we encourage you to reach out to us so that we may help you address any lingering issues.
In the meantime, please go through our other content on this standard that covers a lot of the various complexities: