5

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.

squirl
  • 153
  • 1
  • 4

3 Answers3

5

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.

gowenfawr
  • 71,975
  • 17
  • 161
  • 198
  • 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. (**P**ayment **C**ard **I**ndustry) – James May 16 '16 at 11:22
  • Technically, PCI compliance is only necessary if the data includes the Primary Account Number (PAN = card number) . When bundled with the PAN, other customer details become potent for exploitation. As I say in my answer, the PCI DSS documentation is ambiguous to the extent of its reach into when and how much system information has to be provided to them, which is what puts people into a panic about whether they are compliant even if they are just providing a link to the payment site and no PAN is involved – Patanjali Aug 17 '22 at 01:29
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 that includes 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. In other words, where the merchant is providing potential access to cardholder data (if with PAN) via associated content. Plain links (non-form) and customer data transfer without the PAN (uses forms) do not require PCI compliance if the PAN is never part of the data being communicated.

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.

Patanjali
  • 111
  • 3
  • SAQ-A = https://www.pcisecuritystandards.org/documents/SAQ_A_v3.pdf. SAQ-A-EP = https://www.pcisecuritystandards.org/documents/SAQ_A-EP_v3.pdf. – Patanjali Mar 28 '17 at 00:13
0

You Still Have Some Requirements Under PCI

Other answers have already addressed more or less what that means in legal terms, but not necessarily what this means from a product development or flow of data stand point, and why PCI may still effect you. The over-arching point of PCI is not just to make sure that credit card numbers are not stolen but to make sure that the whole process behind a credit card transaction is preventing money from being stolen.

An online transaction can roughly be broken up into 3 phases: Generation, Payment, and Resolution.

PayPal only assumes responsibility for the Payment and in some cases the Resolution parts of the transaction. But you will always be responsible for the Generation part yourself. When you create a shopping cart, you assume the responsibility for making sure that what it sends PayPal is correct. And, if you use that shopping cart to Resolve the transaction (decide who gets what), then you also need to make sure that you are properly processing the confirmations PayPal is sending you back.

Some common ways you could violate PCI, even when using PayPal, include:

  • Allowing users to alter the transaction by making changes to the HTML.
  • Allowing a XSS script injection to alter the transaction.
  • Transferring data in a way that allows a MiM to alter the transaction.
  • Allowing a transaction and/or verification to be faked.
  • Allowing a transaction to be altered.
  • Allowing unnecessary access to your fulfilment records (so that they could be altered)
  • False positives/negatives.

An Example Case:

You have a website with a shopping cart that allows users to leave product reviews. Your shopping cart has a form which contains in it a hidden HTML input containing the PayPal account of the company who is supposed to receive the payment (that being you) so that your webpage can post the transaction straight to PayPal when they click submit. The reviews section does not protect against XSS attacks; so, a hacker simply leaves a review on the product containing JavaScript that re-writes the hidden recipient field to be the hacker's PayPal account. Then, every time a user goes to buy your product, the hacker gets paid instead of you. When clients complains later that you did not deliver the product they paid for, your records will show that they never paid for it.

Here, PayPal did their job of securely collecting and processing the information that your system sent them, but your negligence still resulted in a hacker being able to steal money from your clients because the part of the transaction that you did handle was improperly done. So, PCI still requires your part in the transaction be compliant even when you use a service like PayPal because PayPal only handles part of the transaction as a whole.

Nosajimiki
  • 1,799
  • 6
  • 13
  • Your 'common ways' list and example would likely NOT be caught by filling out a SAQ as your issues are dealing with details mostly subliminal to the SAQ details. Sloppy customer data handling and web design are things that a lot of people and organisations will want to line up to claim their share of any payouts for lost data or money, IF that sloppiness is ever found out about. – Patanjali Aug 17 '22 at 01:56