DTMF masking — silence card tones, stay PCI compliant

How DTMF masking works on a live call

Every key on a phone sends a pair of tones, one low and one high. Press “5” and the handset plays 770 Hz and 1336 Hz together. That's how a card number travels over a call, and it's why your agent, your call recorder and anyone listening back can pick it up.

We sit in the audio path between the customer and your agent. When it's time to pay, the agent enters the amount in our agent terminal and presses one key, usually 729. The customer hears a short prompt and types their card on their own keypad. We catch each tone, decode the digit and send it over an encrypted channel to your payment gateway. The agent and the recorder get a flat chirp instead, the same sound for every key. The agent's screen shows **** **** **** 1234 as the capture progresses, then paid, declined or retry. Most cards take 20 to 30 seconds, and the call never goes anywhere.

Where the interception happens is what separates a control that passes audit from one that doesn't. If a platform waits for the carrier to report a finished digit before it swaps the audio, a few milliseconds of the real tone slip through. The PCI Security Standards Council's telephone-payments guidance calls this DTMF bleed, and a QSA can find it with a spectrogram. We detect on the live waveform and clamp the stream at both ends, so no tone leaks under any timing. It adds under 20 milliseconds to the call, well inside the 150 ms ITU-T G.114 limit for transparent voice.

Some SIP carriers send keypresses as out-of-band RFC 4733 events rather than audio tones. We handle both: in-band tones are replaced in the audio, and out-of-band events are dropped from the agent's stream and decoded on our side. The card number never sits in our systems beyond the few hundred milliseconds it takes to reach your gateway. For repeat payments, the gateway tokenises the card and the original PAN still never enters your environment.

What it does to your PCI DSS scope

Anything that stores, processes or transmits card data is in PCI DSS scope. Without masking, a phone payment pulls in the agent's headset and desktop, the call recorder, your QA and workforce tools, and the network joining them. That's SAQ D: 329 controls, audited every year.

With masking on, card data never reaches any of those systems. The recording drops out because there are no digits in it. The agent's desktop and your CRM drop out because no card data reaches them. You move to SAQ A, 22 controls, the same questionnaire a business uses when it takes payment through a hosted page on its website. The PCI Council's information supplement Protecting Telephone-Based Payment Card Data recognises DTMF masking as a way to take the telephony, agent and CRM environments out of scope.

It also deals with the risk most contact centres underweight: the insider. If an agent can hear the digits, no audit log will tell you one went into a notebook. Masking takes the data away, so there's nothing to mishandle. Two things stay with you. Records of the result of a payment, such as an order number or the last four digits, still need basic protection. And each year you check our Attestation of Complianceand include it in your SAQ A. That's an afternoon's work. Most of our customers tell us their PCI costs fell 80–90% in the first year.

What changed under PCI DSS 4.0.1

Version 4.0.1 has been mandatory since 31 March 2025. A recording that captures sensitive authentication data after authorisation is now an explicit control failure, which leaves pause-and-resume very little room when an auditor finds the calls where the pause fired late. It also expects clearer evidence of where in-scope systems end, which is simple to show when card data never crosses the line. In the UK, masking also squares PCI DSS with the FCA's SYSC 10A taping rules: the recording stays complete and the digits simply aren't in it.

Pause-and-resume, masking or channel separation?

These are the three ways contact centres handle card payments on a call. Only two of them keep card data out of your business.

Pause-and-resume is a behavioural control: it works until a busy agent presses the button a second late. See our pause-and-resume alternative for what that looks like in an audit.

Between the other two, pick masking when the agent needs to stay in the conversation: insurance renewals where customers ask about cover mid-card, retention calls, fundraising where the agent is the relationship. Pick channel separation when your compliance team wants the agent out of the payment step entirely, or on short transactional calls where the agent adds nothing during capture. You choose one per call flow, both work inbound and outbound, and switching later is a configuration change.

What you need from your phone system

We don't replace anything. You keep your telephony, gateway, CRM, recorder and headsets, and we change what reaches the agent during the seconds the customer is keying digits. Almost every setup we've seen since 2016 falls into one of four shapes.

• Cloud contact centre platforms such as Genesys Cloud, Five9, Amazon Connect, NICE CXone, 8x8, RingCentral, Talkdesk and 3CX. You enable our integration, add a routing rule for the payment leg and set the screen-pop URL. Typically two to four working days, mostly waiting on your change windows. The Aircall walk-through is a worked example.
• On-premise PBX such as Mitel, Avaya, Cisco UCM, Asterisk or FreeSWITCH. We connect over SIP and need access to your trunk configuration and a short-code routing rule. Typically five to ten working days.
• A plain SIP trunk feeding agent softphones. We provision an endpoint and you point the payment leg at it. Two to three days.
• Hybrid or legacy setups with an old PBX behind a session border controller or a media gateway. These need a discovery call and run one to three weeks.

On the recorder, we need to know where it forks the audio. If it records what the agent hears, masking is clean automatically. If it forks at the network or the SBC, we confirm our interception sits upstream, which it does in every pattern we deploy. On the gateway, we need API credentials and a sandbox. We work with Stripe (where we're a partner), Worldpay, Adyen, Barclaycard, Tyl by NatWest, Ryft, Elavon and the long tail beyond. Your merchant ID stays where it is and the money settles to your bank as before.

What you don't need: new hardware on the desk, software on agent workstations (our terminal runs in a browser tab), or changes to your CRM. The agent learns one habit: enter the amount, press 729, wait for the green light. A 15-minute team huddle covers it.

Why customers and agents notice the difference

Customers know when an agent can hear their card details. Some wait until they're home to call, others ask for an invoice instead, and a share of those never pay. With masking they key the card silently, in an open-plan office or on a train platform, while the agent stays on the line to confirm the amount. Agents working from home no longer take card details within earshot of their household, and they stop worrying about whether a digit ended up on a recording. The number to watch is payment completion: calls where payment is offered against calls where it's captured before the customer hangs up.

How to choose a DTMF masking provider

Any DTMF masking provider worth shortlisting will tell you it gets you to SAQ A. The differences show up later: when your QSA pulls a spectrogram, when the platform meets your phone system, and when you want to change gateway. These are the seven checks we'd run if we were the buyer. Run them on us too.

1. Is it a PCI DSS Level 1 service provider with a current AoC?

Ask for the Attestation of Compliance, check the date, and check the provider is on the PCI Council's list of registered service providers. Someone “working towards” Level 1 leaves a gap in your SAQ A. We've held Level 1 every year since 2016.

2. Does the masking stop tone bleed?

Ask how detection works, and ask for a masked recording you can put through a spectrogram yourself. This is the question most buyers skip and the one assessors care about.

3. Does the agent stay on the call?

Some products transfer the caller to an IVR for the payment and lose the conversation at the moment the customer is most likely to hesitate. If you might want the agent out of the loop instead, pick a provider that also offers channel separation, so switching later is a configuration change.

4. Will it work with the phone system you already run?

Get a straight answer for your platform, check it handles out-of-band RFC 4733 tones as well as in-band audio, and check what goes on the agent's desk. The right answer is nothing.

5. Do you keep your own gateway and merchant ID?

Check the masking isn't tied to the provider's own card processing, because that ties your card rates to your compliance tool.

6. Does the recording keep running?

If the answer involves pausing the recording, it isn't masking. The recording should run from start to finish with the digits absent.

7. Can they prove it to your QSA?

Ask for a standard evidence pack, logs of the masking event against a specific call ID, and whether they've briefed assessors before. We supply all three.

What to ask your QSA before you commit

Your SAQ changes, and so does the conversation with your assessor. Get these answered in writing for your environment before you make architecture decisions on them.

• Will you confirm our contact centre falls under SAQ A with masking deployed? The PCI Council's guidance says yes. Your QSA will usually want our Attestation of Compliance and a network diagram showing masking upstream of the recorder and the agent.
• How do you want us to evidence that masking works? Usually a sample recording from a real masked call, and sometimes our platform logs for that call ID.
• Is the recording still in scope if there's no card data in it? Most QSAs say no, a few treat it as a supporting system. The answer decides whether PCI controls apply to your recording storage.
• How do you treat agent desktops that never receive card data? Normally out of scope. Our platform sits upstream of your network, not on it.
• What's your view on phone payments under PCI DSS 4.0.1? A QSA who has thought about it will be clear on pause-and-resume, token handling and continuous recording.

Our pre-sales team has worked through these with most of the major UK and US assessors, and we can send a briefing pack ahead of your scoping call. Drop us a line.