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" has moved up sharply. Three questions come up on almost every prospect call I take — what does the standard actually require for a phone payment, why is pause-and-resume recording suddenly being challenged, and which architecture choice keeps the audit small without rebuilding the contact centre? This piece works through all three.
I'm writing from inside a PCI DSS Level 1 service provider that's held that certification every year since 2016, so the focus here is what works in production, not 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's no exemption for telephone channels. There's 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 aloud, your agent's headset, the call recording, the desktop, any screen-share session, the network the call traverses, and every system any of that touches are all in scope. That's the bit most teams underestimate the first time round.
Two things matter in 2026. v4.0.1 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. 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 isn't a complete control, and that the cleanest path to limited scope is a technical architecture that keeps cardholder data out of the agent leg.
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, American Express, Discover, JCB — enforce PCI through your acquiring bank. Penalties for non-compliance show up as scheme fines, raised transaction fees, and, after a breach, mandatory forensic-investigation costs that routinely run six figures before a single consumer is contacted.
How 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 in four places, and any control regime has to close all of them.
The agent leg is the obvious one. 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 — nothing close.
The call recording is the second. If full PAN, expiry, or CVV ends up in 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. This is the hidden cost teams miss when they cost up "a quick pause-and-resume add-on."
The desktop and any screen-share is the third. 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. We've seen this come up most often where a contact centre has bolted on a transcription or coaching tool without thinking through what it's recording.
The network leg is the fourth. Voice paths carry the digits 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 isn't compliant. It's a regime with a known hole.
What v4.0.1 specifically asks for in a phone payment environment#
The full standard runs to twelve top-level requirements and several hundred sub-requirements. Five of them disproportionately matter for phone payments, and they're the ones I'd start with if I were doing this for the first time.
Requirement 3 covers stored cardholder data, and 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 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 we see in pause-and-resume environments.
Requirement 8 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, and our v4.0.1 walk-through goes through each requirement in detail.
Requirement 9 is physical access. Open-plan floors with paper notebooks, sticky notes on monitors, and casual visitor traffic are scoped. Home-working agents are scoped too, and v4.0.1 expects the same physical-security controls on the kitchen-table desk as on the office floor. That catches most remote-agent expansions by surprise.
Requirement 10 is logging and monitoring. Every system that touches scoped data has to produce tamper-resistant logs, retained for a year — the SBC, the recording platform, the IVR, the gateway, the CRM, and any DTMF capture solution.
And Requirement 12 is your 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 pass.
At QSA review the auditor walks through a real call, asks where the digits go second by second, and tests 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 isn't enough on its own anymore#
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, and you'll still find vendors selling it as a tick-box solution. The honest read on it in 2026 is that it 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 failure rate isn't zero, and it's not negligible.
The audit consequence is that a pause-and-resume environment effectively forces the QSA 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 what gets you to the next section.
The architectures that work for phone payments#
You've really got four options that meet v4.0.1 cleanly, and each fits a different call type. None of them are exotic — they're all in production at hundreds of UK and US contact centres today.
DTMF masking, sometimes called DTMF suppression, is the headline. The customer enters 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 our flagship technology.
IVR self-service is the second pattern. For repeat collections, premium payments, parking-fine settlement, and any "I just need to pay an amount I already know" workflow, an automated IVR menu is the cleanest path. 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. We cover this under IVR self-service payments.
Agent-assisted with secure capture is the third. 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. We connect 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 is the principle running underneath the other 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 right choice depends on your 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 the scope reduction actually works#
Scope reduction is the economic argument for any of the architectures above. The mechanism is simple. 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 our 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 into a board-level number, the audit cost difference is real: a full SAQ-D engagement at a mid-sized UK contact centre is typically a £35,000 to £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. None of them rebuilt their telephony stack to get there. They added a layer.
A practical 2026 implementation order#
If you're starting from a typical contact-centre environment that takes card payments today, here's roughly the order of decisions that gets you to a defensible v4.0.1 posture. None of them are quick wins on their own. Together they're a programme.
Start with the call profile. Count the calls, classify them by type — assisted sale, repeat collection, complex application, refund — and decide which architecture fits each. Then identify scope today. Walk a real call with your QSA or your internal audit lead and document where the digits go, second by second. Most teams find at least one path they hadn't realised was scoped.
From there, pick the architecture per call type. IVR for repeat collections, DTMF masking for assisted, channel separation across the lot. Pick a Level 1 service provider with a current AOC and verify it's been issued in the last twelve months and covers the architecture you're buying. Ask for the AOC document, not just a marketing claim — we'll send ours over without being asked twice.
Then put MFA on every admin console that can see payment data — telephony admin, recording, WFM, QA, AI co-pilots. Lock down recording retention. SAD must not survive authorisation in any retained recording, and the only way to be sure is to sample. Update the security policy and re-train every agent. Documented, signed off, repeated annually, demonstrable. And then 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, you can read how we remove 96% of PCI scope or book a demo. We've 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.
