Yes, phone payments can be fully PCI compliant, and the fastest route is keeping cardholder data out of the contact centre entirely. DTMF masking, secure IVR with channel separation, and one-time payment links all achieve this by design. Each shrinks your PCI scope dramatically, often turning a lengthy SAQ D assessment into a much simpler SAQ A.
TL;DR:
- Removing cardholder data from contact center systems dramatically reduces PCI scope, often allowing a switch from SAQ D to SAQ A compliance.
- Masking, secure IVR, and one-time payment links each prevent data exposure during calls but require proper configuration and oversight.
- Call recordings capturing unmasked payment details re-establish PCI scope, so redaction or encryption and strict access controls are essential.
- Validating vendor compliance with current attestation, security testing, and system integration checks is critical before deployment.
- Starting with a pilot deployment ensures payment security measures work effectively within your specific call flow and PCI compliance requirements.
Table of Contents
- What PCI DSS requires for telephone and MOTO payments
- Keeping card data out of the contact centre
- How scoping and your SAQ change once card data is removed
- Call and screen recordings: the risk most businesses miss
- A procurement checklist for vendors and integrations
- How Gmdautomation approaches PCI-safe call payments
- Where most contact centres actually go wrong
- Getting started with a compliant call payment setup
- Sources
What PCI DSS requires for telephone and MOTO payments
Cardholder data (CHD) means the primary account number and related details; sensitive authentication data (SAD) covers things like the CVV, which you should never store after authorisation. PCI DSS applies fully to telephone and mail-order/telephone-order (MOTO) payments, not just online or in-store transactions. Plenty of business owners assume phone calls sit outside the standard because there's no card terminal involved. They don't.
The PCI Security Standards Council writes the rules, but it doesn't police them. Enforcement and validation run through your acquirer and the card brands, which is why confirming your reporting route with your acquirer or a Qualified Security Assessor matters more than reading the standard cover to cover.
Your telephony setup changes your exposure too. A few things worth mapping before anything else:
- Whether calls run over VoIP or traditional analogue lines (POTS), since VoIP calls can traverse IT networks that also hold other sensitive data.
- Where call recordings are stored, and whether that storage sits inside or outside your existing network segments.
- Which staff, systems, or third parties can access live calls or saved recordings.
Documenting these data flows properly is often the single most useful exercise a contact centre can do before touching any new technology.
Keeping card data out of the contact centre
Three approaches dominate practical PCI compliant call payments setups, and each solves a slightly different problem.
- DTMF masking. The customer keys in card details on their handset, and the system replaces those tones with flat audio before they reach the agent or any recording. The agent sees a payment status on screen but never hears or sees the number. Done properly, this removes PAN exposure from calls and recordings, which is why DTMF masking is widely credited with cutting a contact centre's PCI footprint more than almost any other single control.
- Secure IVR with channel separation. Rather than masking tones mid-call, the customer is transferred to a separate, PCI-scoped IVR system to enter payment details independently of the agent's line. This suits businesses that want a harder technical wall between the voice call and the payment capture, particularly where agents need to stay on the line for support but shouldn't touch payment data at all.
- One-time payment links. The agent sends a secure link by SMS or email, and the customer pays through a hosted page or tokenised checkout. This works well for callbacks, deposits, or scenarios where the customer isn't ready to pay mid-call, and it pairs naturally with tokenisation for recurring or subscription billing.
None of these are a complete compliance product on their own. Masking and similar tools reduce scope, but they don't erase your remaining obligations around network segmentation, access logging, and vendor oversight of the systems doing the masking or hosting the links.
Pro Tip: Test what happens when an agent puts a masked call on hold or transfers it. Poorly configured masking sometimes reverts to unmasked audio during hold, transfer, or conferencing, which quietly reopens the exact exposure you paid to close.
How scoping and your SAQ change once card data is removed
Your Self-Assessment Questionnaire (SAQ) type reflects how your systems touch cardholder data, and the PCI SSC is explicit that removing CHD from your environment can shrink the applicable SAQ considerably.
- SAQ D applies where your systems store, process, or transmit CHD directly. It's the longest questionnaire, covering the full range of PCI DSS controls.
- SAQ A-EP fits partially outsourced e-commerce setups where you don't store card data but your website still influences the payment process.
- SAQ A is the shortest option, typically available once card data capture is fully outsourced to a validated third party and never touches your systems, network, or agents.
Moving from SAQ D to SAQ A is the outcome most contact centres are chasing when they adopt masking or secure IVR. But descoping doesn't mean the obligations vanish entirely. You'll still need:
- Network segmentation between the payment capture system and everything else.
- ASV vulnerability scans where your environment still requires them.
- Logging and monitoring of access to payment-adjacent systems.
- An incident response plan and ongoing vendor management for any third party in the payment chain.
Don't assume which SAQ applies to you. Confirm it with your acquirer or QSA before you build a compliance story around it.
Call and screen recordings: the risk most businesses miss
A call recording that captures a customer reading out their card number, or DTMF tones that weren't properly masked, pulls that entire recording archive into your PCI scope. That includes the storage system, the backup copies, and anyone with playback access.
Industry guidance on the telephone payment supplement's recording provisions is consistent on the fix: remove sensitive authentication data from the recording entirely rather than trying to secure it after the fact. Practical mitigations include:
- Masking DTMF tones before they hit the recording, not just before the agent hears them.
- Redacting or encrypting any recordings that do capture payment moments.
- Restricting playback access to a small, logged group of staff.
- Deleting recordings as soon as the business need for them ends, rather than defaulting to "keep everything."
Some businesses face retention laws that conflict with minimal-retention advice; regulatory or dispute-handling requirements sometimes force longer storage. Where that's the case, build the retention period into your formal data retention policy and raise it directly with your acquirer or QSA rather than guessing at what's acceptable.
A procurement checklist for vendors and integrations
Before signing anything, get evidence rather than assurances. A vendor's marketing page isn't proof.
- Request current attestation. Ask for their Level 1 Attestation of Compliance, recent ASV scan results, and any penetration test summary. GOV.UK Pay publishes its own PCI DSS Level 1 status as an example of the kind of evidence a serious provider should hand over without hesitation.
- Interrogate the integration. Ask about SIP trunk compatibility, what the agent desktop actually displays during a masked call, whether webhooks create a full audit trail, and what tokenisation options exist for repeat customers.
- Check the operational basics. Confirm network segmentation, least-privilege access controls, secure disposal of any stored data, and a documented incident response playbook, and ask how they train staff.
Pro Tip: Ask explicitly what happens when the payment fails mid-call. Some systems fall back to reading card numbers aloud when the automated flow breaks, which quietly undoes everything the masking was meant to achieve.
Contact-centre platforms that integrate voice and workflow automation, like conversational IVR systems, tend to make these failure modes visible earlier because the routing logic is auditable rather than buried in a black box.
How Gmdautomation approaches PCI-safe call payments
Gmdautomation designs managed voice and automation deployments so cardholder data is captured through a compliant, tokenised layer rather than passing through agent screens or standard call recordings. The aim is straightforward: reduced PCI scope and faster audit readiness, without months of internal rebuilding.
Responsibility doesn't disappear, though. Businesses still own their acquirer relationship, their SAQ confirmation, and their internal access controls. A sensible path is a short pilot on one call queue, checked against acquirer requirements, before wider rollout. Ask any provider, including Gmdautomation, for current attestation evidence before you commit.
Where most contact centres actually go wrong
The failures I see repeated aren't exotic. It's agents putting masked calls on hold and the system reverting to raw audio. It's segmentation that looked fine on a network diagram but was never tested against a real breach scenario. It's vendor "compliance" claims with no attestation behind them.
Fix the basics first: verified masking or secure IVR, genuine segmentation, and one honest conversation with your acquirer about what you're actually required to prove.
— Ravi
Getting started with a compliant call payment setup
Building this in-house usually means stitching together a telephony provider, a masking vendor, and your existing CRM, then hoping the integration holds under audit. Gmdautomation takes a different route: a fully managed voice automation deployment where secure payment capture, tokenisation, and call handling are built in from day one, not bolted on afterwards.
Deployment typically starts with a pilot on a single queue, moving to full rollout once the integration is proven against your acquirer's requirements. It runs on a monthly subscription that covers implementation, operation, and ongoing maintenance, with no large upfront build cost. If you're combining payment security with broader contact-centre automation, it's also worth reading how customer service workflow automation fits alongside secure payment capture, and separately, gateway selection shapes how tokenisation and reconciliation actually behave once a call ends.
Book a demo through Gmdautomation to see how a PCI-safe capture pattern would work against your current call flow.
Sources
- Security and compliance
- Protecting telephone‑based payment card data (PCI SSC information supplement)
- PCI Security Standards Council: FAQs