Guide 6 of 10

Telephone Payments and PCI DSS

Taking card payments by phone creates PCI compliance challenges that many businesses overlook — from call recordings to agent access. This guide covers the risks and solutions.

The Hidden Compliance Challenge

Most businesses think of PCI DSS in terms of online payments — websites, shopping carts, and hosted payment pages. But there's a payment channel that creates far more compliance headaches than any other: the telephone. If your business takes card payments over the phone, you're dealing with what many compliance professionals consider the most complex part of PCI DSS.

The reason is straightforward. When a customer pays online, you can use tokenisation, hosted payment pages, and encryption to ensure card data never touches your systems. Over the phone, the dynamics are completely different. A human being — your agent — is involved in the conversation. Card numbers might be spoken aloud, typed into screens, captured in call recordings, or transmitted through VoIP systems. Each of these creates a potential exposure point, and each one brings systems into PCI scope that you might not have considered.

As we discussed in Guide 1, PCI DSS applies to every organisation that stores, processes, or transmits cardholder data. For telephone payments, the "transmits" part is the critical word. Even if you never store a card number, the act of it passing through your phone system, your network, and your agent's ears puts you firmly in scope.

Why Phone Payments Are Different

With online payments, descoping is relatively straightforward. You redirect customers to a hosted payment page or use an iframe, and card data never enters your environment. Job done. But a telephone call is an analogue, human interaction happening in real time. That makes it inherently harder to control.

Consider what happens during a typical phone payment without any special technology in place. The agent asks for the customer's card number. The customer reads it out. The agent hears every digit. They type it into a payment screen — which means it appears on their monitor. If the call is being recorded (and most contact centres record calls for quality and training purposes), the full card number is now sitting in an audio file on a server somewhere. If the agent wrote the number on a sticky note as a backup — which happens more often than anyone likes to admit — there's now a physical record too.

Every one of these touchpoints is a PCI DSS concern. The agent's workstation is in scope. The call recording system is in scope. The network carrying the call is in scope. The screen recording software, if you use it, is in scope. The desk where the sticky note sits is in scope. The phone system itself — whether it's a traditional PBX or a cloud-based VoIP platform — is in scope. Suddenly, your PCI environment isn't just your payment gateway; it's your entire contact centre infrastructure.

Call Recordings: The Most Common Violation

Call recordings deserve special attention because they're one of the most common PCI DSS violations auditors find. Many businesses record calls for legitimate reasons — dispute resolution, quality monitoring, regulatory compliance (the FCA requires some firms to record calls), and staff training. The problem arises when those recordings capture card data.

PCI DSS Requirement 3 is clear: sensitive authentication data — including the CVV/CVC security code — must never be stored after authorisation. If a customer reads out their CVV during a recorded call, you've just stored it. That's a violation, full stop. And it's not just the CVV. Storing the full PAN (primary account number) in an unencrypted recording also creates significant compliance obligations under Requirements 3.1 through 3.7.

The challenge is that most call recording systems don't distinguish between a normal conversation and a payment transaction. They record everything. Some businesses try to address this with "pause and resume" technology, where the recording is paused while card details are being taken and resumed afterwards. We'll cover why this approach has significant limitations shortly.

There's another angle many businesses miss: even if you delete recordings containing card data after a set period, you still stored them. PCI DSS requires that if you store cardholder data, you must have documented retention policies, access controls, encryption, and regular purging processes. The simplest approach is to prevent card data from entering recordings in the first place.

Agent Access and the Human Factor

Your agents are not a security threat — but they are a security consideration. Any person who can hear, see, or access cardholder data is part of your PCI scope. That means agent workstations need to meet PCI requirements for access control (Requirement 7), unique user identification (Requirement 8), and physical security (Requirement 9).

In practical terms, this means every agent who handles phone payments needs unique login credentials, their access to payment systems must be logged and monitored, their workstations need to meet security standards, and the physical environment needs controls to prevent shoulder surfing and data theft. If you have 200 agents in a contact centre, that's 200 endpoints, 200 sets of credentials, and a significant ongoing compliance workload.

Screen recordings and screen-sharing tools add another layer. If a screen capture or remote support session records the payment screen while card data is visible, you've created another copy of cardholder data that needs to be managed under PCI DSS.

Staff turnover compounds the problem. Contact centres often have high turnover rates, which means constantly provisioning and deprovisioning access, training new staff on PCI procedures, and monitoring for policy violations. Each new starter needs PCI awareness training, and each leaver needs their access revoked promptly — Requirement 8.1.4 requires that inactive accounts are removed within 90 days.

VoIP and Network Scope

If your phone system uses Voice over IP (VoIP) — and most modern systems do — then your data network is carrying voice traffic that may contain cardholder data. This brings your network infrastructure into PCI scope under Requirements 1 and 4. Firewalls, switches, routers, and any network segments carrying voice traffic all need to meet PCI standards.

This is a significant expansion of scope that many businesses don't anticipate. A traditional analogue phone system was separate from the data network. With VoIP, voice and data share the same infrastructure. If card numbers are being spoken during calls carried over that network, the network itself becomes part of the cardholder data environment.

Cloud-based contact centre platforms (CCaaS) add their own considerations. While the platform provider handles much of the infrastructure compliance, you still need to ensure that the connection between your environment and the cloud platform is secure, and that any local components (softphones, headsets, local network) meet PCI requirements. Your responsibility doesn't end at the cloud boundary.

Solutions: Descoping the Phone Channel

Given all these challenges, the most effective strategy is the same one we discussed in Guide 5: descoping. Remove card data from the telephone payment process so that your agents, call recordings, workstations, and phone systems never come into contact with it.

There are two main technologies used for this:

Pause and resume attempts to address the call recording problem by pausing the recording while the customer provides card details. The agent typically asks for the card number, pauses the recording, takes the details, processes the payment, and resumes the recording. While this prevents card data from appearing in recordings, it has significant limitations. The agent still hears the card number. The agent's workstation still displays it. The phone system still carries it. Pause and resume addresses one symptom but doesn't descope the environment. The agent and their workstation remain firmly in PCI scope.

DTMF masking takes a fundamentally different approach. Instead of the customer reading their card number aloud, they enter it on their phone keypad while remaining on the line with the agent. The DTMF tones (the beeps you hear when pressing phone buttons) are intercepted and replaced with flat, uniform tones. The agent hears a sound for each keypress but can't distinguish which digit was pressed. The real card data is routed directly to the payment processor, completely bypassing the agent, the call recording, and your entire infrastructure. This is the technology Paytia provides, and it's why DTMF masking is considered the gold standard for telephone payment security.

We go into much greater detail on how DTMF masking works in Guide 7: DTMF Masking Explained.

The Business Case for Descoping Phone Payments

Beyond the security benefits, descoping your telephone payment channel makes compelling business sense. When agents never hear or see card data, you eliminate the risk of internal fraud. When call recordings don't contain card numbers, your quality monitoring and training programmes can operate without PCI restrictions. When your contact centre infrastructure is out of PCI scope, your compliance validation becomes dramatically simpler — potentially qualifying for SAQ A instead of the far more demanding SAQ D, as we explained in Guide 4.

There's a customer experience benefit too. With DTMF masking, the customer never has to read their card number aloud in a potentially public place. They simply tap the digits on their phone while continuing to speak with the agent. The payment happens within the call, without interrupting the conversation, with no awkward silences or transfers to automated systems.

Key Takeaways

  • Telephone payments create the broadest PCI scope of any payment channel, pulling in agents, workstations, phone systems, call recordings, and network infrastructure
  • Call recordings containing card data are one of the most common PCI violations — storing CVV in any form, including audio, is explicitly prohibited
  • VoIP systems place your data network in scope because voice traffic carrying card data shares the same infrastructure as your business data
  • Pause and resume has significant limitations — it addresses call recordings but doesn't descope agents, workstations, or phone systems
  • DTMF masking fully descopes the phone channel by ensuring card data never reaches agents, recordings, or your infrastructure — it's routed directly to the payment processor
  • Descoping telephone payments reduces compliance burden, eliminates internal fraud risk, and can simplify your SAQ from D to A
  • The phone channel deserves priority attention in any PCI compliance programme — it's often the area with the most unrecognised risk

Frequently Asked Questions

Are telephone payments in scope for PCI DSS?

Yes — any process where cardholder data is spoken, entered, or transmitted over the phone is in scope for PCI DSS. This includes the phone system, call recordings, agent workstations, and any network they connect to.

Can I record calls that contain card numbers?

You must not store the CVV/CVC in any form, including call recordings. If your calls are recorded, you need a way to prevent card data from being captured — either by pausing recordings or using DTMF masking so numbers are never spoken aloud.

What is the safest way to take phone payments?

The safest approach is DTMF masking, where customers enter card details on their phone keypad while staying on the line with the agent. The tones are masked so the agent never hears or sees the card number, and nothing is stored in your systems.

Related Glossary Terms

Ready to simplify your PCI compliance?

Book a personalised demo and we'll show you how Paytia can descope your telephone payment environment.

PCI DSS Level 1
Cyber Essentials Plus

Trusted by law firms, insurers, healthcare providers and regulated businesses worldwide. Learn more about Paytia