PCI Compliance for Telephone Payments: 2026 Guide

If your contact centre takes card payments by phone, PCI DSS applies to you. v4.0.1 has been mandatory since March 2025, and a year in, the bar for "compliant" is tighter than most organisations expected. Three questions come up again and again from heads of customer service, compliance leads, and IT. What does the standard actually require for a phone payment? Why is pause-and-resume recording suddenly being challenged? And which architecture choice makes the audit small enough to be worth doing without rebuilding the contact centre from scratch?

This guide works through all of them. It's written from inside a PCI DSS Level 1 service provider that has held that certification every year since 2016, so the focus is on what works in production rather than what reads well on paper.

What PCI compliance means for telephone payments#

PCI DSS — the Payment Card Industry Data Security Standard — applies to any organisation that stores, processes, or transmits cardholder data. There is no exemption for telephone channels. There is no exemption for "we just take the card details once and put them straight into the gateway." From the moment a customer reads their PAN out loud, the agent's headset, the call recording, the desktop, any screen-share session, the network the call traverses, and every system that any of that touches are all in scope.

Two pieces of context matter in 2026. Version 4.0.1 of the standard has been mandatory since 31 March 2025 — a limited revision of v4.0 with corrections and clarifications, several of which bite hardest in contact-centre environments (more on those below). And the SSC's Information Supplement on Protecting Telephone-based Payment Card Data is still the canonical scoping reference. It's explicit that telephone environments are PCI scope, that pause-and-resume recording on its own does not constitute a complete control, and that technical architectures which keep cardholder data out of the agent leg are the cleanest path to limited scope.

In the UK the practical regulators behind PCI are the ICO under UK GDPR, and for FCA-regulated firms, the FCA's operational-resilience expectations. In the US it's the FTC plus state breach-notification law. The card schemes themselves — Visa, Mastercard, Amex, Discover, JCB — enforce PCI through your acquiring bank. Penalties for non-compliance show up as scheme fines, raised transaction fees, and, in the event of a breach, mandatory forensic-investigation costs that routinely run six figures before a single consumer is contacted.

The four ways card data leaks on a phone call#

Before the architecture conversation, it helps to be specific about the threat model. Card data on a phone call leaks at four points, and any compliant design has to close all four:

1. The agent leg. The agent hears the digits, can write them down, can repeat them back, can mention them on a personal call later in the day. Human-error data loss is the largest single source of confirmed contact-centre incidents in the public record.
2. The call recording. If sensitive authentication data — full PAN, expiry, CVV — is captured into a recording, the recording itself becomes scoped data. Every backup, every QA platform, every supervisor's desktop that ever opens the file gets pulled in too.
3. The desktop and any screen-share. Screen recording, supervisor whisper, screen pop, AI co-pilot overlays — if the agent types the PAN into a CRM field, all of those layers can capture it.
4. The network leg. Voice paths carry the digits in DTMF tones (or as audio) across SBCs, SIP trunks, recording infrastructure, and increasingly cloud telephony. Each hop is a potential capture point and an audit-scope boundary.

A control regime that covers three of these four is not compliant. It's a regime with a known hole.

What PCI DSS v4.0.1 specifically requires for phone-based environments#

The full standard runs to twelve top-level requirements and several hundred sub-requirements. The ones that matter disproportionately in a phone payment environment are these.

Requirement 3 — protect stored cardholder data. The v4.0.1 clarification that hits hardest is on sensitive authentication data. SAD — full magnetic-stripe data, CVV/CVC, PIN data — must not be retained after authorisation, even if encrypted. That includes call recordings. If a recording captures a customer reading their CVV and your retention policy keeps the file for any length of time, that's a control failure. It's the most common audit finding in pause-and-resume environments.

Requirement 8 — multi-factor authentication. v4.0.1 broadened MFA expectations to cover access to any system that can view or export payment data. In a contact centre, that pulls in the telephony admin console, the workforce-management tool, the recording platform's QA UI, and any AI co-pilot that surfaces transcript fragments. Plenty of organisations had MFA on the CRM and stopped there; v4.0.1 closes the gap on the layers behind it. What changed with v4.0.1 goes through the requirement-by-requirement list.

Requirement 9 — physical access. Open-plan floors with paper notebooks, sticky notes on monitors, and casual visitor traffic are scoped. Home-working agents are scoped too. v4.0.1 expects the same physical-security controls on the kitchen-table desk as on the office floor — a point that catches most remote-agent expansions by surprise.

Requirement 10 — logging and monitoring. Every system that touches scoped data has to produce tamper-resistant logs, retained for a year. For phone payments that's the SBC, the recording platform, the IVR, the gateway, the CRM, and any DTMF capture solution.

Requirement 12 — security policy. A documented information-security policy that covers telephone payments specifically, with annual review, sign-off, and demonstrable awareness training for every agent. A generic IT-security policy doesn't satisfy this.

At QSA review the auditor will walk through a real call, ask where the digits go second by second, and test whether the answer at every step is verifiable from logs and architecture. The contact centres that pass cleanly are the ones whose answer at every step is "the digits never enter our environment in the first place."

Why pause-and-resume recording is no longer enough#

Pause-and-resume — the agent presses a button to stop the recording while the customer reads the card number, then presses it again to resume — is the control most contact centres started with. It still gets a mention in the SSC's guidance. What v4.0.1 has clarified is that pause-and-resume on its own depends on a human executing the control correctly on every call, every time. In a busy contact centre running thousands of payments a day, the empirical failure rate isn't zero, and it's not negligible.

The audit consequence is that a pause-and-resume environment effectively forces the auditor to assume the control fails some percentage of the time, and to scope accordingly. Every recording in retention has to be treated as if it might contain SAD. That pulls the recording platform, the storage, the QA tooling, and every operator who ever touches the file into scope. The licence cost of pause-and-resume is small. The audit cost it generates is what makes it a false economy.

The alternative is a technical control that strips the digits out of the audio path before they ever reach the recording. That's what DTMF masking does, and it's the bridge to the next section.

The compliant architectures for taking card payments over the phone#

Four architectures meet PCI DSS v4.0.1 cleanly for telephone payments. Each fits a different call type.

DTMF masking (also called DTMF suppression). The customer is asked to enter their card number on their phone keypad. The tones are intercepted in the live audio stream, replaced with flat tones in everything the agent and the recording can hear, and the original digits are routed straight to the payment gateway. The agent stays on the line, the customer stays on the line, the conversation continues — the agent just never hears the number, the recording never captures it, and the desktop never sees it. This is the architecture that produces the largest scope reduction for assisted calls, and it's Paytia's flagship technology.

IVR self-service. For repeat payments, premium collections, parking-fine settlement, and any "I just need to pay an amount I already know" workflow, an automated IVR menu is the cleanest pattern. The customer talks to the IVR; no agent is ever in the path; the call leg that handles the card data is fully isolated from the contact-centre environment. This is the umbrella pattern Paytia covers under IVR self-service payments.

Agent-assisted with secure capture. For complex assisted sales — insurance applications, account changes, multi-product orders — the agent stays on the call, walks the customer through everything, and triggers a secure capture step at the point of payment. Paytia connects to a contact centre via any of seven integration patterns (network divert, PBX divert, IVR transfer, conference, outbound, WebRTC, SIP), so the architecture fits whatever telephony stack is already in place. See agent-assisted phone payments.

Channel separation. The principle running underneath all three. The PCI-scoped data flow and the contact-centre flow share a customer and an outcome, but they don't share a system. Channel separation is what auditors are testing for when they walk the call.

The architecture choice depends on the call profile. High-volume repeat collections lean toward IVR. Complex assisted sales lean toward DTMF masking. Most contact centres end up with a mix.

How to cut PCI scope by up to 96% on your phone channel#

Scope reduction is the economic argument for any of the architectures above. The mechanism is simple enough. PCI DSS scope is defined by the systems that store, process, or transmit cardholder data, plus any system connected to those. If the cardholder data never enters your telephony environment, your CRM, or your recording platform, none of those systems are scoped. The audit shrinks from a full SAQ-D — the longest of the self-assessment questionnaires — to a shorter SAQ A or SAQ A-EP, which is what an organisation that outsources card handling to a Level 1 service provider can typically attest under.

The 96% figure that appears in Paytia customer outcomes is the proportion of contact-centre systems that drop out of scope when DTMF masking is implemented properly. It tracks closely with the SSC's own scope-reduction principle. Translated to a board-level number, the audit cost: a full SAQ-D engagement at a mid-sized UK contact centre is typically a £35,000–£90,000 annual exercise; SAQ A is a fraction of that, and the residual operational overhead — agent training, retention reviews, breach drills — falls in proportion.

The percentage isn't really the point. The point is that compliant phone payments stop being an expensive ongoing programme and become a configuration choice you make once. That's the difference contact centres at British American Tobacco, Warby Parker, and Allclear describe when they talk about the change.

A practical 2026 implementation checklist for UK and US contact centres#

If you're starting from a typical contact-centre environment that takes card payments today, this is the rough order of decisions that gets you to a defensible v4.0.1 posture. None of them are quick wins individually. Together they're a programme.

1. Establish the call profile. Count the calls, classify them by type (assisted sale, repeat collection, complex application, refund), and decide which architecture fits each.
2. Identify scope today. Walk a real call with your QSA or your internal audit lead and document where the digits go, second by second.
3. Choose the architecture per call type. IVR for repeat collections, DTMF masking for assisted, channel separation across the lot.
4. Pick a Level 1 service provider with a current AOC. Verify the AOC is current within the last twelve months and covers the architecture you're buying. Ask for the AOC document, not just a marketing claim.
5. Put MFA on every admin console that can see payment data — telephony admin, recording, WFM, QA, AI co-pilots.
6. Lock down recording retention. SAD must not survive authorisation in any retained recording. Test the policy by sampling.
7. Update the security policy and re-train every agent. Documented, signed off, repeated annually, demonstrable.
8. Schedule the v4.0.1 SAQ. Aim for SAQ A wherever the architecture allows it.

For US contact centres the same checklist applies, with state breach-notification readiness and FTC-aligned incident response added on top.

Make the audit small#

Telephone payments aren't the hard part of running a contact centre in 2026. The wrong architecture, though, makes them disproportionately expensive — in audit cost, breach risk, and operational drag. The right architecture lets the customer experience the caller expects sit alongside the compliance posture the board expects, at the same time. If you'd like to see what that looks like in your environment, see how Paytia removes 96% of PCI scope or book a demo. Paytia has held PCI DSS Level 1 certification every year since 2016, and the same people who built it will be on the call.

Author: Curtis Nash, founder and CEO of Paytia. Curtis has worked in payment security for over 15 years and has led Paytia through every PCI DSS revision since the company's founding in 2016. Paytia is a PCI DSS Level 1 service provider trusted by contact centres at British American Tobacco, Warby Parker, and Allclear, and endorsed by NatWest and Lloyds.