4

If I'm using PayPal Express Checkout on my website, am I required to be PCI DSS compliant?

PayPal says "With Website Payments Standard, Online Invoicing, Express Checkout and Website Payments Pro Hosted, PayPal handles the payment card information on your behalf and so greatly eases the burden of PCI compliance." What? "greatly eases the burden"? What does that mean? Do I need it or don't I? If I do, what version do I need? SAQ A? SAQ A-EP?

Please help, I'm very confused and not sure whether I need to put the work into becoming compliant or not.

4

IANAQSA...

If I'm using PayPal Express Checkout on my website, am I required to be PCI DSS compliant?

Yes. If a customer goes to your web site, puts stuff in their cart, and then clicks "I want to pay for this stuff" and gets redirected somehow to a payment page hosted by someone else, you still have PCI compliance obligations.

With Website Payments Standard, Online Invoicing, Express Checkout and Website Payments Pro Hosted, PayPal handles the payment card information on your behalf and so greatly eases the burden of PCI compliance." What? "greatly eases the burden"? What does that mean?

"greatly eases the burden" means you'll be eligible for a less onerous SAQ than you would be if you weren't using their services. I don't know enough about the different products they've listed there, but for example, tokenization can help reduce scope from SAQ-D to SAQ-C. If tokenization is in use and a web redirection is used to transmit payment data through their servers, then you can drop down to SAQ-A EP or SAQ-A, depending on which type of redirection is used.

Looking at the Express Checkout description, it probably means you're looking at SAQ-A or SAQ-A EP.

Please help, I'm very confused and not sure whether I need to put the work into becoming compliant or not.

You need to become compliant. In the case of SAQ-A, that's pretty simple. In the case of SAQ-A EP, just a little bit more complex. If you go up to SAQ C+, now you have work to do.

To find out which level of compliant you need to be, you work with your processor - which in this case would be PayPal. Tell your sales contact you want to understand what your PCI obligations will be and ask if you can talk to someone in their Compliance department about understanding which SAQ you'll fall under and what the process is for submitting it to them.

  • Your first statement is not strictly true - PCI compliance is only required if you accept payment cards. If you only accept payment by direct debit, for example, there is no PCI DSS requirement. (Payment Card Industry) – James May 16 '16 at 11:22
1

From https://www.paypal.com/au/webapps/mpp/pci-compliance:

Our most popular products, like Website Payments Standard, Express Checkout and Invoicing, are already PCI compliant. And, because we handle your customers’ card information for you, you can forget about the time, cost and headache of maintaining PCI compliance.

So by PayPal's wording there, you don't need to do anything if you are not handling cardholder data (must include at least the PAN -- Primary Account Number -- for a card).

In the first instance, fines for non-compliance are levied on payment providers and large merchants, so if PayPal was in line for a huge fine, they would have been ensuring every merchant using their services would be filling out their self-assessment questionnaire (SAQ), since PayPal would be responsible for ensuring that inputs into their systems are also compliant.

Even the simplest SAQ-A self-assessment would be beyond most sole traders to reliably complete themselves, just because it has too many technical considerations that they would have no idea about.

From this diagram (https://www.pcicomplianceguide.org/wp-content/uploads/2016/01/SAQ-3-1-Ecommerce-Options-Explained-Examples-ControlScan.pdf), even having a product page -- regardless of whether it collects cardholder data -- seems to imply that the SAQ-A-EP needs to be used. However, SAQ-A-EP is covering the situation where the merchant site simultaneously provides css or javascript to maintain consistency of presentation between the merchant and provider sites, so the diagram may be just indicating that, but not unambiguously.

Generally, I find the PCI documentation rather obtuse and an over-reach since they continually refer to cardholder data as their principal criteria, but seem to want to control every system that feeds into their process, regardless of whether the PAN is included or not. Providing the information means that your personal details, and the detailed configuration of your systems, is being provided to one or more third parties, whose own systems and processes you are expected to trust.

The PCI documentation refers to the situation even if you don't store cardholder data, but don't separately explicitly cover the situation where your systems do not handle any cardholder data, that is, don't even collect or transmit it. Note that data only becomes cardholder data when it includes the PAN, otherwise it is just customer data that you might hold regardless of whether you took credit card payments, and while having good data handling security of that customer data is good, it should be none of the card companies' business if it does not include the PAN.

Note that, technically, PDT and IPN do not return cardholder data, as they do not include the PAN with the customer and transaction details returned.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.