.svg)
The truth is, even accepting PayPal payments requires you to be PCI DSS compliant. In this scenario, it is helpful to think of PayPal as a third-party payment processor. Even though they are ultimately receiving, processing, transmitting and storing the payment card account data, as a merchant your business is the one accepting that information and you are responsible for the actions of all third-party service providers acting on your behalf.
By integrating with PayPal in order to sell your goods and services, your online environment does have the ability to affect the security of the payment process/transaction.
PayPal and Self Assessing PCI Compliance
The good news? Using a PCI DSS compliant third-party service provider (PayPal, Authorize.net, etc.) for all acceptance, processing and storage of your customers’ payment card account data does limit your scope of compliance assessment.
And, if your e-commerce business accepts less than 1M Mastercard or Visa card payments per year, then you can self-assess your compliance rather than hiring a PCI Qualified Security Assessor (QSA) or investing in PCI Internal Security Assessor (ISA) certification for one of your own team, to complete your compliance validation.
When is SAQ A Applicable?
SAQ A applicability depends on your website set-up and how it accepts card payments:
Determine Merchant SAQ based on how the website is setup. See PCI SSC FAQ: 1588.
Even when it does not itself receive the account data, your online environment is in scope for PCI DSS because of its potential to impact how that account data is transmitted.
If all elements of the payment page are sent from PayPal or any other PCI DSS-compliant third-party service provider (TPSP) to your customer’s browser, then you can validate your merchant compliance using the Self-Assessment Questionnaire (SAQ) A.
The key here is the phrase “all elements”. The payment page is the web-based user interface, displayed in the consumer browser, that shows the fields or elements the consumer enters their payment card account data into. SAQ A requires that all elements of that payment page originate only and directly from a PCI DSS compliant TPSP or payment processor.
Note that a payment page may be:
- A single hosted payment page displaying all card data capture fields, such as when your website fully redirects the cardholder away from your website to the TPSP or payment processor’s hosted payment page.
- It may also be a single form or instance, displaying all card data capture elements, in an inline frame or iFrame.
- That payment page iFrame may be embedded in your website’s non-payment ‘parent’ page or displayed as a pop-up iFrame or Lightbox shown ‘in front of’ your website’s non-payment ‘parent’ page.
The payment page can also be rendered as multiple individual TPSP or payment processor’s hosted iFrames, one for each card data element. PayPal Advanced Card Fields or PayPal Braintree Hosted Fields are examples of this type of payment page integration.Another scenario where SAQ A is applicable, is when your entire website is fully managed and operated by a TPSP whose own PCI DSS compliance covers all aspects of the e-commerce website, the TPSP is responsible for all of the technical controls and security measures for the website you accept online payments through.
When is SAQ A Not Applicable?
Even though it does not itself receive the account data, your online environment is in scope if any element of a payment page delivered to the consumer browser originates from your website, then you cannot use SAQ A.
- A common e-commerce implementation is where your website creates the payment page displayed in the consumer browser from which the payment card account data is sent directly from the consumer browser to the payment processor (usually called a Direct Post).
- Another common implementation is where your website’s payment page is configured to instruct the customer browser to request and execute some JavaScript from your PCI DSS compliant TPSP or payment processor. This creates the card data form elements that appear on the payment page in the customer browser.
- The cardholder enters their payment card data into the JavaScript created form which is sent directly to the TPSP or payment processor. In this type of integration, the JavaScript created payment form is not contained in a TPSP or payment processor hosted iFrame.
The SAQ A-EP may be applicable SAQ type for Direct Post or JavaScript created form implementations, which is much more burdensome that the SAQ A. More on the differences between SAQ A and SAQ A-EP can be found in the PCI SSC’s SAQ Instructions and Guidelines.
But Wait, There’s More!
There is actually a third SAQ option for e-commerce merchants: SAQ D Merchant. If you are accepting payment account data on your website and your implementation is not eligible for SAQ A or SAQ A-EP, then SAQ D is your compliance option.
SAQ D applies to e-commerce website implementations that do not meet the eligibility criteria of SAQ A or SAQ A-EP, such as where your website presents both the checkout page and the payment page and receives the account data back from the consumer browser. The SAQ D Merchant includes all PCI DSS Requirements.
And be aware, even if you have been assessing your website’s PCI DSS compliance using the SAQ A for many years, that the PCI DSS v4.x SAQ A requires website external vulnerability scanning at least once every 3 months, also referred to as ASV scanning as these scans need to be performed by a PCI- Approved Scanning Vendor (ASV). These non-intrusive website scans help to identify vulnerabilities that may lead to a compromise of your website and customer card data.
A new version of the SAQ A (version 4.0.1 revision 1, published January 30, 2025) is effective from April 1, 2025. In response to stakeholder feedback, the PCI SSC modified the SAQ A to remove the future-dated requirements 6.4.3, 11.6.1 and 12.3.1 that were anticipated to be required for some SAQ A eligible e-commerce implementations after March 31, 2025. These security measures are designed to prevent and detect e-commerce website attacks and compromises. They were originally included in the v4.x SAQ A in recognition that attackers can and do succeed in compromising payment card account data even on websites that entirely outsource all account data acceptance and processing. Instead, a new SAQ A eligibility criterion was added for e-commerce.
The new criterion requires merchants to “confirm their site is not susceptible to attacks from scripts that could affect the merchant’s e-commerce system(s).” This new SAQ A criterion applies only to e-commerce merchants whose website embeds the TPSP/payment processor hosted payment page/form in one or more inline Frames or iFrames.
If your website embeds the card data capture elements in an iFrame(s), such as through use of PayPal’s JavaScript SDK and Hosted Card Fields, then make sure to reference the PCI SSC’s guidance on how to meet the SAQ A eligibility criteria for scripts, published in FAQ 1588:
Confirmation that your iFrame-using website is not susceptible to attacks from scripts may be provided by your TPSP or payment processor - hosting the embedded payment form or fields - that their solution includes techniques or measures able protect your website from script attacks.
But if that confirmation can’t be provided, then you will need to implement measures to be able to confirm your website’s non-susceptibility to script attacks. FAQ 1588 suggests that those measures could include implementing requirements 6.4.3 and 11.6.1.
More Resources
For more details on the PCI DSS v4.x SAQs applicable to e-commerce merchants see pciportal.info. I also recommend checking out our eBooks.
For more detail on PCI DSS v4.0.1, the version of the PCI DSS effective from January 1, 2025, see “PCI DSS updates from v4.0 to v4.0.1.” For a detailed discussion of the new PCI DSS requirements effective from April 1, 2025, including those e-commerce payment page script management and monitoring requirements, see our eBook “Exploring the New PCI DSS Requirements Effective April 1, 2025.”
More resources include the webinars “The Hidden Threat: Unraveling E-Skimming, Script Security, and PCI DSS Compliance” which details the specific threat of skimming for e-commerce merchants, and “The Threat of E-Skimming: Helping Level 3 and 4 Merchants Protect Their E-commerce Websites by Leveraging E-Skim Monitoring for PCI DSS 6.4.3/11.6.1 Compliance” which demonstrates how VikingCloud’s E-Skim Monitor helps merchants meet the new PCI DSS requirements 6.4.3 and 11.6.1.
.png)