Most businesses that pick DTMF masking software live with that decision for at least three years. The contracts run that long, the integrations dig deep into your contact-centre stack, and the cost of switching mid-cycle — re-mapping every payment flow, retraining agents, re-doing your PCI Attestation of Compliance — is usually higher than the cost of just sticking with whatever you've got, even if it's wrong for you.
So getting the choice right matters more than the difference in monthly fees would suggest. Two vendors can both call themselves "DTMF masking providers" and quote prices within 10% of each other, and you can still end up with a solution that costs you an extra £40,000 a year in failed transactions, manual reconciliation, or an extended SAQ. The price tag isn't where the real money lives.
What follows is the checklist we'd run if we were on the buying side. We sell DTMF masking ourselves, so I'm not going to pretend this is neutral — I'll declare that up front. But the questions below are the ones a competent procurement team would ask any provider, ours included. If a vendor can't answer them clearly, that's the signal.
Step 1: Confirm DTMF masking is the right tool#
Before you start shortlisting vendors, make sure DTMF masking is what you actually need. It isn't the only way to take a card payment over the phone, and for some contact centres it isn't the best one.
The main alternatives are pause-and-resume on the call recording, transferring the customer to a dedicated IVR for the payment portion, and full agent channel separation (where the agent stays on the voice channel and the customer keys card digits into a parallel data channel). Each one has a different scope footprint and a different effect on call handling.
If your agents need to verify the card with the customer in real time — read back the last four digits, confirm the billing postcode against the CRM — DTMF masking keeps that conversational flow. If your call volume is low and your agents are happy to transfer, an IVR-only flow can be cheaper and just as compliant. If you want the agent off the call entirely during card capture (so the merchant can't see or hear any digit), channel separation goes further than masking does.
We've written a detailed comparison at channel separation vs DTMF suppression, and a broader overview at the PCI compliance for telephone payments guide. Read both before you go to vendors — going in without a clear view of which approach you want is how you end up with a salesperson choosing for you.
Step 2: Map your current call flow#
You can't evaluate a vendor against your stack until you've drawn your stack. Most procurement processes skip this and it costs them later, when the chosen provider turns out to need a SIP trunk reconfiguration nobody scoped.
Get a piece of paper and a whiteboard, and write down every component a call touches from the moment a customer dials your number to the moment the payment settles in your acquirer's batch. That includes:
- Your inbound number provider and the SIP trunk that delivers calls to your premises (or to your cloud telephony platform).
- Your contact-centre platform — Aircall, 3CX, Zoom Contact Centre, Genesys Cloud, Cisco Webex Contact Centre, Talkdesk, NICE CXone, RingCentral, or whatever else you're running.
- Your call recording system, including where the recordings live, how long you keep them, and who can pull them.
- Your CRM, because the agent will be looking at a customer record while the payment runs.
- Your payment gateway and acquirer — and any payment service provider sitting in front of those.
- Any analytics, QA, or transcription tooling that ingests the call audio after the fact.
Each of those is a potential touchpoint for the masking solution and a potential place it can fail. A masking product that integrates smoothly with Aircall but treats Genesys as a custom job is a different proposition for an Aircall shop than for a Genesys one. A product that needs to sit between your SIP trunk and your contact-centre platform changes who's responsible if call quality dips. Map first, then ask vendors how they fit the map.
Step 3: PCI scope questions to ask#
This is the part where vendors get vague and you have to push. The whole reason you're buying DTMF masking is to reduce your PCI DSS scope — so you need very specific answers about how the product actually does that.
The first question is where the DTMF tones get suppressed. Is the suppression happening at the customer's edge (the tones never enter your network at all), or somewhere inside the vendor's platform after the audio has been carried across? "Before it hits your systems" is the answer you want. If suppression happens inside your network — even briefly — that network segment is still in scope for the duration.
The second question is whether the masking is attendant-based or in-band. Attendant-based masking puts a separate IVR-style attendant on the line during card capture, so the agent isn't on the voice path for those seconds at all. In-band masking keeps the agent on the line but injects flat tones or silence over the digits. Both can be compliant, but attendant-based is a stronger scope-reduction story for your QSA — there's no path by which the agent could hear the digits even if the suppression failed.
The third question is what your SAQ looks like after deployment. The right answer is SAQ A or SAQ A-EP — the simplest forms — and the vendor should be able to talk you through which one applies and why. A provider who shrugs at SAQ questions or sends you to your QSA is telling you they haven't thought about your compliance position, which is exactly what you're paying them to do.
The fourth question is whether they're a PCI DSS Level 1 service provider in their own right, with an active Attestation of Compliance you can read. Level 1 means they're assessed annually by a QSA against the full DSS, not self-assessed. Anyone selling masking to enterprise contact centres should be Level 1 and should hand you the AoC on request. We are; we will.
Step 4: Integration depth#
Most masking products do the same job at the audio layer. Where they differ is what happens around the payment itself — and that's usually where the daily friction of running the system either disappears or piles up.
Ask the vendor what they do with the captured card token. Some providers tokenise the PAN inside their own vault and hand you back a reference you can use only with their gateway. Others let you pass the token through to your existing payment gateway and acquirer, so you keep your processing relationship intact. The second option is almost always better — it means the masking product is solving the audio problem without making itself a sticky middle-man on every future payment.
Ask what the integration looks like with your CRM. Does the agent click a single button inside the customer record and the payment runs against the right invoice? Or does the agent have to alt-tab into a separate web portal, type the amount, copy a reference back to the CRM, and update the record manually? The first one saves about 90 seconds per call. The second one is a frequent source of mis-keyed amounts and broken reconciliation.
Token reuse across channels matters for repeat customers. If a customer pays once by phone and then comes back to your website a week later, can the gateway recognise the saved card and bill it again — with the customer's consent — without re-keying? The masking vendors that have thought about cross-channel commerce have an answer here. The ones that haven't will tell you "that's a gateway question," which usually means no.
Step 5: Audit trail and reporting#
When your QSA turns up next year, you'll need to show evidence that every card payment taken by phone went through the masking flow. A vendor that can't produce that evidence on demand has effectively given you a compliance liability rather than a compliance solution.
Ask what gets logged on every transaction. The log should contain, at minimum: the call identifier, the agent who took the call, the timestamp of the masking event, the duration of the masked portion, the last four digits of the PAN (which is fine to log), the transaction amount, the gateway response, and any retries. Anything less and you can't reconstruct what happened on a disputed payment.
Ask how the logs export. Daily CSV to an S3 bucket is the bare minimum. A webhook into your finance system or your SIEM is better. Read-only API access for your QSA during audit week is best. Vendors who can only show you a web dashboard are usually hiding the fact that they don't have a stable export schema yet.
Ask whether the reporting reconciles transaction-by-transaction with your payment gateway statements. If there's drift — and there will be, on refunds, partial captures, and pre-auths — you need a way to investigate it without an email thread.
Step 6: Commercials — what to expect#
Pricing for DTMF masking falls into two broad models, and which one suits you depends entirely on your call shape.
Per-transaction pricing charges you a small amount per masked payment. It scales linearly with volume, which is great when you're small or growing slowly, and painful when you have one big sales month. There's usually a minimum monthly commitment hidden in the contract — read it.
Per-agent (or per-seat) pricing charges you for each named user authorised to take masked payments. It's predictable, it's easy to budget, and it gets expensive fast if you have a large pool of agents who only occasionally take card payments. If 200 of your 300 agents take cards twice a week, per-agent is the wrong model.
Setup fees are where the surprises usually hide. Some providers include integration, others charge professionally-services rates for everything beyond a standard SIP cutover. Get a fixed-fee quote for your specific stack and ask what triggers a change order. "Custom CRM integration" is a particularly broad term in some vendor contracts.
Watch for pass-through charges. Call minutes for the masked attendant. Card brand fees that the vendor marks up. Telephony surcharges. Storage charges if you keep recordings long-term. None of these are unreasonable on their own, but they add up to a different headline price than the one on the proposal — and they're almost always missing from the first conversation. Make the vendor build you a model at your actual annual volume before you sign anything.
Step 7: References and proof points#
The marketing pages will all sound the same. The references won't.
Ask for three customer references in your industry, at roughly your call volume. A retailer doing 50,000 phone payments a month has a very different operational pattern from a financial services firm doing 5,000 — and a vendor whose entire customer base is one or the other may struggle on yours. If they can only offer references from sectors that don't match yours, that's information.
Ask to see their Attestation of Compliance, current within the last twelve months. AoCs are private documents but vendors share them with prospects under NDA all the time. If the AoC is older than that, the vendor isn't current.
Look at the wider security posture too. Cyber Essentials Plus and ISO/IEC 27001 aren't PCI controls, but they tell you whether the company runs itself with the discipline you'd want from someone handling card data. SOC 2 Type II is the equivalent benchmark for US-based providers.
Then read independent reviews — G2, Capterra, TrustRadius, Gartner Peer Insights. Skim the negative ones, not the positive ones. The pattern of recurring complaints (poor support response, broken integrations with a specific CRM, surprise renewal pricing) is what you're looking for. Five-star reviews are interchangeable; the one-star reviews tell you the truth.
Frequently asked questions#
Is DTMF masking software always the right choice?
No. If your call volume is low, an IVR transfer for the payment portion is often cheaper and just as compliant. If you want the agent off the call entirely during card capture, channel separation gives you a stronger scope position than masking does. Masking is the right pick when you want the agent to stay conversational throughout — including during card entry — and you have enough payment volume to justify the per-transaction or per-seat cost.
How long does a DTMF masking deployment usually take?
For a standard cloud contact-centre stack — Aircall, 3CX, RingCentral, that sort of thing — a competent provider will have you live in two to four weeks. Genesys, Cisco, and on-prem PBX deployments take longer because the SIP routing is more involved. If a vendor quotes six months for a cloud-only environment, they're either underbuilt or padding the timeline.
Will DTMF masking work with our existing payment gateway?
Usually yes, but ask the question explicitly. Some masking providers will only process payments through their own gateway, which means switching gateways as well as adding masking. Others sit on top of your existing acquirer relationship. The second option preserves your processing rates and your existing reconciliation flow.
Does masking affect call recording quality?
Not the parts that matter. The masked seconds are replaced with flat tones or silence, but the rest of the call — the agent's voice, the customer's voice, everything outside of card entry — records normally. Your QA team and your dispute-resolution process work as before. The only thing that changes is that your recordings no longer contain card data, which is the whole point.
What happens if the masking fails mid-call?
A well-designed product will end the payment attempt and prompt the agent to retry, rather than letting the call continue with unmasked digits in the recording. Ask the vendor what their failure mode is and what their incident rate looks like over the past twelve months. "Never" is not a credible answer; a published incident rate under 0.1% is.
Can we change providers later?
Technically yes, in practice it depends on how deeply you integrate. If the vendor owns your tokenisation, switching means re-tokenising every saved card — which usually means asking customers to re-enter card details, which is a customer-experience hit. If the vendor sits cleanly on top of your existing gateway, switching is much easier. This is another reason to favour vendors that integrate with your payment stack rather than replacing it.
Putting it together#
Run all seven steps against any shortlist before you sign. If a vendor scores well on architecture but vague on commercials, push harder on the commercials. If they score well on commercials but their integration story is "custom development," that's where your project will overrun. The best providers are clear on every step, can show you reference customers in your industry, and don't flinch when you ask for the AoC.
For what it's worth, Paytia is built around the seven checks above. We're a PCI DSS Level 1 service provider with a current AoC, we integrate with Aircall, 3CX, Zoom, RingCentral, and Genesys (among others), we hand the token through to your existing gateway rather than locking you into ours, and we log every masked transaction in a format you can hand to your QSA. If that sounds like a fit for your contact centre, drop us a line and we'll run through your specific stack with you.
How does Paytia score on the checklist?
PCI DSS Level 1 certified. Integrates with Aircall, 3CX, Zoom, Genesys, and most major payment gateways. Per-transaction pricing with no per-agent surcharge. Customer references across financial services, healthcare, education, and contact centres — happy to share on a call.
