PCI compliant phone payments, from one shop phone to a contact center

The services side by side

Each row is something the Council's telephone guidance or PCI DSS asks about, phrased as a buyer would ask it. “Ask the vendor” means the vendor's own pages did not say so when we read them. It does not mean no.

On the core job the services look alike: keypad masking, spoken card capture, an IVR and payment links. They part on the edges. On the pages we read, only Eckoh showed a call recorder of its own. None of them says it hands customers its Attestation of Compliance and a list of who manages which requirement, so ask each one.

Service by service

These services sit in front of a payment processor rather than replacing one. If you are still choosing the processor, the payment gateway comparison judges each by the SAQ it leaves you on.

Which phone setup are you?

Answer for one ordinary phone order. The receipt shows where the card number lands and the questionnaire that points to, with the rule behind it.

The picker covers phone orders only. If you also sell online or at a counter, run all your channels through the SAQ type finder.

What each method takes out of scope

The Council's information supplement on telephone payments sorts the methods by what they remove. Its goal for all of them: “SAD is never stored after the transaction is authorized, and account data is secured and/or removed from systems and storage.” Read across a row to see what still needs PCI DSS controls.

Call recording and the security code

Recording is where most phone setups fail. The Council's telephone guidance accepts that “local laws or regulation may require call recordings to be retained for a number of years,” so the recorder often cannot simply be switched off. PCI DSS does not bend for it. Requirement 3.3.1: “SAD is not stored after authorization, even if encrypted.” Sensitive authentication data covers the card verification code, full track data, PINs and PIN blocks, and 3.3.1.2 names the code on its own: “The card verification code is not stored upon completion of the authorization process.”

So a caller reading out the three- or four-digit code printed on the card puts data on the recorder that has to go. The Council is blunt: if pause-and-resume “cannot block the audio or video from being stored, the sensitive authentication data (SAD) MUST BE DELETED from the recording as soon as the transaction is processed.” The card number itself may stay only if “PAN is rendered unreadable anywhere it is stored” (Requirement 3.5.1), which the supplement says includes “voice and screen recordings.” A recording that holds card numbers is also electronic storage, which no SAQ short of SAQ D allows.

Masking changes the recorder's job. Recordings that hold “only flat tones that cannot be converted back to the original data” do not need to be made unreadable, and when card data is masked before it is recorded, “a non-PCI DSS recording service may suffice.” If the security code truly cannot be kept off your recordings, the Council says to discuss it with your acquirer, and the recordings “must not be able to be queried.” Encryption alone does not achieve that. Its example steps:

One phone, no call center

Most shops that take a card over the phone have one line and whoever picks up. The Council's guidance is reassuring about the line itself: “Generally speaking, entities are not considered responsible for the transmission of card data over an external traditional telephone line.” That changes once the number is kept or the call runs over VoIP. If staff write the number down or an answering machine takes it, that “would be considered ‘storage,’” and the desk is in scope. And on a VoIP phone, “the entity's systems and networks used for those transmissions are in scope.”

Where the number goes next decides the questionnaire. The main routes, as the SAQ Instructions describe them for phone orders:

A virtual terminal is the usual answer, and SAQ C-VT is written for it: “Merchants that manually enter payment account data a single transaction at a time via a keyboard into a PCI DSS validated and compliant third-party virtual payment terminal solution, with an isolated computing device and a securely connected web browser. No electronic account data storage.” No card reader may be attached to that computer. The virtual terminal comparison sets the providers side by side.

Stripe's phone-order section (“Supporting MOTO (Mail Order/Telephone Order) Payments”) maps the same ground for its own users: SAQ A for a pay connector where card data is collected by “a PCI-compliant third-party solution” and “the user should not have access to the card data”; SAQ C-VT when MOTO card data is “directly entered into the Stripe Dashboard”; SAQ D for “electronic storage of cardholder data within their environment.” It also says Dashboard entry is “for exceptional circumstances only, not routine payment processing.”

The route most shops miss is the terminal already on the counter. The Council's own example: a phone-order merchant “could be eligible for SAQ P2PE if they receive account data on paper or over a telephone, and key it directly and only into payment terminal from a validated PCI-listed P2PE solution.” Only a solution on the Council's list counts; our P2PE guide explains the list. Among the processors on this site, these were listed when we read it:

What to ask before you sign

Every service in the table says it keeps card data away from you. The proof is in the answers to these questions, in writing. Requirement 12.8.4 also asks you to check each provider's PCI DSS status “at least once every 12 months,” so keep the replies.

Questions