PayPal and the PCI DSS

There is some confusion among online businesses over how PayPal payment acceptance relates to PCI DSS compliance. You may have heard that by using PayPal, your business is not subject to the PCI DSS.

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?

Even though 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), 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.

‍

When is SAQ- A Not Applicable?

Even though it does not itself receive the account data, your online environment is in scope for if any element of a payment page delivered to 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.0 SAQ A* includes additional requirements you may not yet meet, such as performing ASV external vulnerability scanning at least once every 3 months, as well as entirely new security measures designed to prevent and detect e-commerce website attacks and compromises that some SAQ A merchants will need to have in place by the end of March 2025.

I recommend checking out PCI DSS v4.0 and the Evolution of the Self-Assessment Questionnaire (SAQ) for E-commerce Merchants to learn more.

‍

* PCI DSS v4.0.1 SAQ A is not yet published, as of August 2024.