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?

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.

  • 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 Feb 14 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 Feb 14 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. – dave_thompson_085 Feb 15 at 4:41

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.