3

What methods of processing payments fit into the definition of SAQ-A for orders made over the phone?

I am confused because it says SAQ-A is valid when "All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers", yet SAQ C-VT is needed when a virtual terminal (hosted by a validated third-party) is used to take payments.

To my reading this means sticking Stripe Elements onto a page (normally valid for SAQ-A) and entering the customer's card details into it falls under SAQ C-VT.

So how could telephone orders be taken and the merchant remain under SAQ-A?

1 Answer 1

4

I am confused because it says SAQ-A is valid when "All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers", yet SAQ C-VT is needed when a virtual terminal (hosted by a validated third-party) is used to take payments.

What differs is who takes the call.

For SAQ C-VT, the Merchant has employees who sit at a Virtual Terminal hosted by a validated Third-Party Service Provider. Customers call the Merchant, the Merchant's employee types their card numbers into the VT, the purchase proceeds.

When SAQ A says (emphasis mine):

SAQ A merchants confirm that, for this payment channel:

  • Your company accepts only card-not-present (e-commerce or mail/telephone-order) transactions;
  • All processing of cardholder data is entirely outsourced to PCI DSS validated third-party service providers;

They are describing a setup where the Merchant outsources the entire telephone-order process to a validated Third-Party Service Provider. The Customer calls the number provided by the Merchant, but it rings at the Third-Party call center, and a Third-Party employee takes the details, enters them into the terminal, and proceeds with the purchase.

(In both cases, of course, the Third-Party is subject to much more extensive compliance requirements than either SAQ A or SAQ C-VT. The limited scope of those two SAQs rely upon the offloading of scope to the Third-Party Service Provider).

So how could telephone orders be taken and the merchant remain under SAQ-A?

If the phone calls go directly to the Third-Party Service Provider, and not to the Merchant, the Merchant may remain SAQ A.

3
  • Thank you for a very clear answer. An additional question: if the merchant takes card details over the phone and enters them into a payment terminal, the PCI requirements are different (to a virtual terminal) because the provider is guaranteeing that the terminal is secure, leaving only the terminal-to-provider communication to be covered?
    – PeterB
    Commented Feb 14, 2019 at 21:31
  • @PeterB physical terminals are going to fall under SAQ B ("Brick-and-mortar") or SAQ D ("All the requirements, all the time!"). SAQ B is less extensive than SAQ C-VT, because it has strict limits (e.g., terminals must dial out, not use the Internet to connect to the processor). SAQ D is more extensive than SAQ C-VT. Basically, SAQ D is everything, and all the other SAQ's trim down the scope based on the limits the Merchant embraces. So... the answer is, SAQs A* through C* enable the Merchant to answer less questions, if the Merchant restricts their configuration appropriately.
    – gowenfawr
    Commented Feb 14, 2019 at 21:46
  • 2
    PCISSC just a few months ago published an 'info supplement' describing and considering several scenarios for 'Protecting Telephone-based Payment Card Data' that @PeterB might find useful. (Although it spends a fair bit of space worrying about recording phone calls, and particularly NOT recording Sensitive Auth Data, which you don't even mention as a concern.) With the 'improved' (hah) website, you have to go to Document Library and pulldown to select Guidance Documents. Commented Feb 15, 2019 at 4:41

You must log in to answer this question.

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