3

We've been asked by one of our clients to complete a SAQ-D. Even though PCI is not a law, we don't want to attest to something that shouldn't apply to us in the first place.

We're not sure compliance is necessary because all credit card transactions are handled on a third party website. The information we have about the customer is nothing more than name, address and a little contact info (phone, email).

The customer logs in, puts products in their cart and clicks to checkout which sends them to a third party site where they put in their credit card information. The only information that comes back to our servers is a transaction code used by our client to reference the payment in their off-site merchant area.

Do we have to do the SAQ-D or should we push back?

Anders
  • 64,406
  • 24
  • 178
  • 215
Gary Cornelisse
  • 31
  • 1
  • 1
    What's your role here? Are you the web host provider for non-payment store pages? The fulfillment warehouse for a collection of actual merchants? Some other unspecified business who isn't a merchant, and isn't a payment processor, but who sits between those two entities? Do you have a business relationship with the payment processor, or do your clients? If so, what's your business relationship with your clients? If your page sends customers to the checkout page, you're within PCI scope (but probably not SAQ-D). But more details are needed to understand your obligations. – gowenfawr Sep 07 '16 at 18:20

1 Answers1

2

It sounds like you might qualify for the SAQ A. I would suggest going through the SAQ Instructions and letting it guide you on which SAQ to use. If your business takes credit cards payments, it is required to be PCI compliant. Just because you outsource the payments to another site does not mean you skip the SAQ entirely, but you might qualify for one that requires less demonstration (like SAQ A vs SAQ D).

John Downey
  • 1,915
  • 13
  • 12