2

We need to fill out a PCI self assessment questionnaire, and I am wondering If we need to fill out SAQ A-EP or SAQ D.

We are an e-commerce merchant that doesnt operate trough a website, but we receive credit card details on our API. We tokenize it and send it to third-party PCI compliant service provider. We don't store any credit card details.

6
  • The first sentence under "Before You Begin" of the SAQ A-EP document includes "_ applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data" so clearly does not apply. The corresponding sentence in SAQ D is "_SAQ D for Merchants applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type".
    – TripeHound
    Nov 6, 2019 at 10:00
  • @TripeHound Please read my question carefully. I never mentioned a website, only an api service. Could you please provide me with a further explanation of a term website? Is an API service a website? Does an API fall under website category when we speak in PCI DSS language?
    – mko
    Nov 6, 2019 at 10:20
  • 3
    Assuming an "e-commerce merchant" has a (designed for human interaction) website is not, I think, unreasonable... if that's not the case, I suggest you edit the question to make it explicit. I strongly suspect that an internet-hosted API would count as "a website" as far as PCI DSS is concerned but am not certain. What probably matters more is "does not itself receive cardholder data". That your servers get such data is, I believe, sufficient to exclude you from SAQ A-EP.
    – TripeHound
    Nov 6, 2019 at 10:36
  • 1
    Indeed, the second paragraph "SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises" makes no mention of "website". You are an "e-commerce merchant" who processes cardholder data, therefore cannot be "SAQ A-EP merchant".
    – TripeHound
    Nov 6, 2019 at 10:39
  • I agree with you. If you want to move it as an answer, so I can accept it.
    – mko
    Nov 6, 2019 at 10:41

1 Answer 1

6

The introduction to the SAQ A-EP Document (PDF) reads (emphasis mine):

Before You Begin

SAQ A-EP has been developed to address requirements applicable to e-commerce merchants with a website(s) that does not itself receive cardholder data but which does affect the security of the payment transaction and/or the integrity of the page that accepts the consumer’s cardholder data.

SAQ A-EP merchants are e-commerce merchants who partially outsource their e-commerce payment channel to PCI DSS validated third parties and do not electronically store, process, or transmit any cardholder data on their systems or premises.

Your servers receive cardholder data (albeit via an API rather than through an interactive web-page) and processes cardholder data (to tokenize it before forwarding to a third-party site). Therefore my reading of the above is that SAQ A-EP is not applicable.

The use of the word website in the first paragraph is, presumably, to cover "normal" websites that hand both the acquisition and processing of cardholder data to another party: for instance by opening a new window or embedding an <iframe> in their webpage (and where the contents of the window/iframe is provided by the third-party and not your servers).

While one could debate whether "website" in the first paragraph includes a non-interactive API, I think that is irrelevant1. The second paragraph does not use "website" – it talks only of "systems" and "channels" – so would unambiguously apply to your situation. Since you do process cardholder data, you cannot be an "SAQ A-EP merchant".

Therefore, of the two, the SAQ D questionnaire would apply to your situation2.


1 My strong suspicion is what really matters in the first paragraph (and this view is backed-up in the second paragraph) is the passage I highlighted, namely "that does not itself receive cardholder data". Even if your API is not considered a website, it does (or will) receive cardholder data, and therefore you would not be eligible for the (presumably less onerous) obligations of SAQ A-EP.

2 Note that the introduction of SAQ D (PDF) reads "SAQ D for Merchants applies to SAQ-eligible merchants not meeting the criteria for any other SAQ type.". Of the two SAQs you mention, you clearly (in my mind) don't meet the criteria for SAQ A-EP. However, according to Understanding the SAQs for PCI DSS version 3 (PDF), there are a number of other types. It's conceivable (though from a quick scan of the opening page, unlikely) that you could be eligible for one of those.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .