PCI DSS 4.0 Phone Payments: 2026 Compliance Checklist

If you take card payments by phone and your next PCI audit is on the calendar, this is the year the questions get sharper. PCI DSS v3.2.1 retired on 31 March 2024, and the future-dated controls in v4.0 became mandatory in March 2025. The current version on the table is v4.0.1, published in June 2024 with small clarifications. There's no "transition window" left — your Report on Compliance or SAQ in 2026 is judged against v4.0.1 outright.

For phone payments specifically, three things changed in a way that catches teams out. First, the customised approach gives you a route to meet a requirement with a non-prescriptive control, but you have to prove it works through a targeted risk analysis. Second, access control tightened — MFA for any non-console admin access into the cardholder data environment, no shared accounts, no role-based passwords. Third, the script-integrity rules under Requirement 6.4.3 now bite even on self-service payment portals that embed third-party JavaScript.

This piece walks through a 2026-ready checklist — seven practical requirements an operator should be able to evidence on demand — plus the new v4.0.1 traps, the SAQ question, and a short FAQ. It's written from where we sit as a PCI DSS Level 1 service provider. If you want the wider pillar view first, our PCI DSS v4.0.1 contact centre guide covers the principles in more depth.

SAQ A for phone-only merchants: who actually qualifies in 2026#

This is the section we get asked about most often. The PCI Council updated the SAQ A eligibility criteria in v4.0.1 and the line for phone-only merchants is now clearer than it's been since v3.2.1 shipped. If your business takes card payments only by phone, and you've outsourced the card-handling leg properly, SAQ A is on the table — and it's a 22-question form instead of the 300-question SAQ D you'd otherwise be sitting in front of.

The eligibility test for SAQ A on a phone-payment flow has five conditions. All five have to hold. First, the merchant's systems must not store, process, or transmit any cardholder data. Not capture, not log, not pass through. Second, all card-data handling must be performed by a PCI DSS validated third-party service provider whose AoC is current. Third, the merchant must have written confirmation that the provider is responsible for the PCI DSS requirements covering the outsourced functions. Fourth, the merchant must have a documented PCI DSS compliance program for the provider — which is to say, you're managing them under Requirement 12.8. Fifth, the merchant retains responsibility for any element of the cardholder data environment that hasn't been outsourced, however small.

Read those five clauses against a real phone-payment flow and the architecture decisions become obvious. If your agent hears the digits, your environment processes them — fail clause one. If your recording captures DTMF tones, you're storing PAN — fail clause one. If your CRM screen displays the masked PAN after authorisation, you're processing — borderline, and worth confirming with your QSA. The architectures that pass cleanly all have one thing in common: the card-data leg is fully separated from the merchant's environment, end to end, with a validated provider's AoC covering the path.

Sample SAQ A scenarios for phone-only merchants#

Here are four phone-only merchant scenarios we see in practice, with the SAQ outcome for each. They're composites drawn from common contact centre setups rather than specific clients — but the pattern is what matters. If your flow looks like one of these, the eligibility logic will look the same.

Scenario 1: Insurance broker, inbound renewals only

A motor insurance broker takes around 1,200 renewal payments a week, all inbound calls. Agents authenticate the customer against the policy record, quote the renewal premium, and read out the amount. When the customer is ready to pay, the agent triggers a DTMF masking session from the CRM. The customer keys their card number, expiry, and CVV on their handset. The masking provider — a PCI DSS Level 1 validated service — captures the digits, presents them to the payment gateway, and returns an authorisation code to the CRM. The agent sees "Approved" or "Declined" with the last four digits of the card. The call recording captures continuous audio of the conversation with neutral substitute tones during the digit-entry window.

The broker's systems never store, process, or transmit cardholder data. The masking provider's AoC covers the digit capture, the gateway transmission, and the tokenisation. The CRM stores a payment reference (not a token of the PAN, not the PAN itself). The recording archive contains no PAN. This is a textbook SAQ A flow. The broker has a 22-question form, an annual scope review under 12.5.2, quarterly ASV scans on the small attack surface that remains (the CRM web tier, the agent VPN), and a third-party management process under 12.8 to track the masking provider's AoC.

Scenario 2: Charity, outbound donation campaigns

A national charity runs outbound campaigns asking existing donors to convert one-off gifts to monthly Direct Debits, with a card payment option for donors who decline Direct Debit. About 18% of asked donors pay by card on the call. The agent's dialler launches a payment session at the moment the donor agrees. The agent stays on the line, the donor keys their card details, the masking provider handles the capture and tokenisation, and the agent confirms the gift amount and thanks the donor.

SAQ A applies here on the same logic as Scenario 1, with one wrinkle. The charity also issues thank-you receipts by email referencing the donor's gift but not the card details. Those emails are out of scope because they contain no cardholder data. The masking provider's tokenisation lets the charity charge the same card the following month for recurring donors without ever re-handling the PAN; the token is stored in the donor record, the actual card details live with the provider. This is the recurring-payment pattern most well-architected phone-only charities run on.

Scenario 3: Utilities supplier, arrears collections

An energy supplier runs an arrears team that calls customers about overdue balances. Roughly 60% of conversations end with a card payment, the rest with a Direct Debit setup or a payment plan. The agent's collections platform initiates a masked payment session inline. The customer keys their digits. The masking provider handles auth and returns a result. The collections platform updates the account balance from the gateway's webhook.

This is SAQ A territory, but only if a specific risk gets handled — the masking session must not be initiated from a screen that also accepts "agent-keyed" cards as a fallback. Some collections platforms have a "phone-in card" form on the agent side as a backup for when masking fails. The moment that form exists and accepts PAN input, your environment is processing cardholder data and SAQ A is gone. If you need a fallback, the right pattern is to fail the call over to a hosted IVR or a payment link sent by SMS — both of which keep the merchant's systems out of the card-data path.

Scenario 4: Healthcare clinic, patient self-pay invoicing

A private healthcare clinic chases patient invoices that weren't covered by insurance. Calls are made by a small in-house team of three. The clinic uses a phone system with a payment-link feature: the agent enters the invoice number and amount, and the system texts the patient a one-time payment link. The patient hits the link on their phone, completes the payment on a hosted page served by the provider, and the clinic's invoicing system updates from the webhook.

This isn't strictly a DTMF flow — it's a click-to-pay flow initiated from a call. SAQ A still applies because the clinic's systems never touch cardholder data, but the eligibility test sits closer to SAQ A-EP than SAQ A if the hosted page is iframed inside a page the clinic controls. Clinics doing this should confirm the redirection architecture with their provider and acquirer before filing. Our piece on secure payment links covers the click-to-pay pattern in more depth, and our payment links solution is built specifically for this kind of phone-to-link flow.

Where SAQ A breaks for phone-only merchants#

The four scenarios above show what passes. Here's what doesn't, with the most common reasons we see during scope reviews.

The first failure mode is partial outsourcing. A merchant who masks during digit entry but lets the agent enter a card manually for callers with disability access needs is processing card data on the manual path. The whole environment then falls into SAQ D for the audit, even if 95% of calls go through the masked path. The fix is to route the accessible-access calls through a different mechanism — a hosted IVR with screen-reader-compatible audio prompts, or a payment link delivered to the customer's choice of channel — so the merchant's systems never see a PAN.

The second failure mode is recording leakage. A merchant has masking on the primary call recording but a secondary QA application that taps into the SIP stream pre-masking. That secondary tap captures the unmasked DTMF tones. SAQ D applies, the recording archive becomes in-scope, and the QA tooling becomes in-scope. Fix: ensure the masking layer sits at the network edge of the merchant's environment so every downstream recording or analytics path receives only the masked stream.

The third failure mode is the "hot transfer" pattern. A merchant routes the customer to a hosted IVR for the payment leg but keeps the agent on the line for hand-holding through the keystrokes. If the agent can hear the DTMF tones during the transfer, those tones are reaching the merchant's environment via the agent's audio path. SAQ D applies. Fix: either mask the tones at the agent's leg too, or use a true blind transfer where the agent drops off before the payment IVR begins.

The fourth failure mode is the screen-pop pattern. A merchant's CRM displays full PAN after authorisation as a "convenience" for the agent to confirm the card to the customer. Storing or displaying full PAN inside the merchant's systems fails SAQ A clause one. The fix is to display only the last four digits and the card-scheme name, which is what nearly all modern payment gateways return by default.

Requirement 1: Know your phone payment surface area#

Before a single control gets reviewed, you need an honest map of where card numbers can enter your environment by phone. That's a wider surface than most teams realise. There's the obvious inbound call to an agent, but there's also self-service IVR, scheduled callbacks where a customer hits 1 to be called back about an unpaid invoice, web chat that escalates to a phone call mid-session, and SMS-to-call flows where a marketing message drops a click-to-call link.

Each path needs a diagram tagged with how cardholder data flows through it. If your agents transfer to a third-party IVR for the payment leg, that transfer point matters. If a CRM screen pops with a "take payment" button that opens a phone-attached payment widget, that's another path. If your contact centre records the entire call including DTMF tones, that recording channel has to be either descoped or treated as in-scope.

The scope review under Requirement 12.5.2 is annual now, and it's the artefact your assessor will ask for first — a scope diagram with timestamps and sign-off, an inventory of every system in scope, and a written justification for anything you've excluded. The wider PCI compliance for telephone payments view spells out the common path-mapping mistakes.

Requirement 2: Take cardholder data out of call recordings#

Requirement 3.4 says stored PAN must be rendered unreadable wherever it lives — and a call recording with a Primary Account Number in the audio is storage. Most contact centres record everything by default for QA. Without a control on the payment moment, every recording becomes in-scope cardholder data the second a customer reads out their card number. The recording archive, the backup tape, the QA tooling, the transcription provider, the analytics dashboard — all dragged into your cardholder data environment by association.

The cleanest fix is to take the card data out of the audio path entirely. DTMF masking does this: the customer keys their digits, the tones are intercepted by a Level 1 service provider before they reach your agent's leg, and your recording captures silence or substituted neutral tones. The agent hears no digits, the recording has no digits, the QA listener has no digits. DTMF masking and PCI compliance covers the architecture in detail.

The alternative — pause-and-resume — relies on agents stopping the recording before card capture and starting it again afterwards. It works on paper. In practice, the failure rate is high enough that PCI assessors look at it with a sceptical eye. A single missed pause leaves a PAN in the archive. If you're shopping for a 2026 architecture, masking is the route that scales. Requirement 3.5 is the partner rule: even when PAN is stored, it must be protected with strong cryptography at rest. The shorter your storage list, the less surface area for 3.5 to bite. Our piece on channel separation business benefits covers the wider commercial impact.

Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.

Requirement 3: Control who can hear card details#

Requirement 8.3.6 under v4.0.1 sharpened access control for the cardholder data environment. MFA is now required for all non-console administrative access — no exceptions for trusted networks or internal subnets. Shared accounts are out. Generic agent logins with rotating passwords on a sticky note are out. Each person who can reach a system in scope needs a unique credential, MFA, and a logged access path.

For phone payments, this is where masking pays for itself a second time. If your agents never hear the card digits, the agent population isn't an in-scope user group for the payment system. You don't have to roll MFA out to a thousand contact centre seats because none of them have administrative access to anything that touches a PAN. The MFA scope shrinks to the handful of integration engineers, payment ops staff, and audit reviewers who maintain the masked-payment plumbing.

Without masking, the alternative is heavier. Every agent who can hear card digits is touching cardholder data — which means every workstation needs to meet the in-scope hardening standard, every account needs MFA, and every login to the recording archive needs the same treatment. The economics rarely work out at scale. This is the requirement where teams discover they've been running an informal SAQ D environment without realising it.

Requirement 4: Encrypt cardholder data in transit#

Requirement 4.2.1 says strong cryptography is required for cardholder data crossing open public networks. In practice, your payment platform's connection to the acquiring bank should be TLS 1.2 or higher. TLS 1.0 and 1.1 have been disallowed for a long time. If you're still seeing TLS 1.0 anywhere on a payment path in 2026, that's a finding before the assessor even asks a question.

The phone-payment wrinkle is the SIP and RTP traffic that carries voice between the telephony provider, the masking layer, and the contact centre. If a masking provider sits in the call path and DTMF tones are encoded as in-band audio, the audio leg between the customer and the masking layer must be protected. SIP over TLS plus SRTP is the standard pattern. Ask your masking provider exactly which leg they protect, where the decryption happens, and what their AoC says about transmission controls. A vendor who can't answer that crisply is a vendor whose AoC won't help you when your assessor reads it.

Requirement 5: Monitor and log#

Requirement 10 covers logging and audit trails. The big v4.0.1 shift is the daily review obligation — Requirement 10.4.1 says security event logs must be reviewed at least daily, not weekly. That's hard to meet by hand at scale, which is why most contact centres run a SIEM with automated alerts. The point isn't human eyeballs on every log line; it's that an automated correlation rule fires on the anomalies and a human acknowledges each one.

For phone payments, the logs that matter are the payment attempt records — every initiation, every authorisation request, every response code, every failure — plus the access logs for any system that handles them. If your masking provider hosts the payment leg, ask them how their logs reach you. Some ship structured events to your SIEM. Some give you a portal you can pull from. Either pattern is fine; what isn't fine is finding out at audit time that your provider's logs are six time-zones away in a format your team can't ingest.

Requirement 11.4.2 covers intrusion detection on the cardholder data environment perimeter. Internal scans run quarterly under 11.3.1.1; external scans need an Approved Scanning Vendor under 11.3.2. The catch in v4.0.1 is that internal scans now have to be authenticated — credentialed scans rather than the lighter unauthenticated sweeps that some teams used to get away with. Pull together a monthly evidence pack: log review attestation, scan results, an open-issue tracker with remediation timelines.

Requirement 6: Have a tested incident response plan#

Requirement 12.10 says you need a documented incident response plan, tested annually, with named roles and a clear escalation path. Under v4.0.1, the requirement is more specific about what "tested" means — a tabletop exercise with the named roles in the room, scenarios run from start to finish, and documented findings with remediations. A plan that lives on a shared drive and has never been opened in anger doesn't count.

For phone-payment incidents, the scenarios worth rehearsing are a confirmed card-data exposure in call recordings, a payment-platform outage during peak call hours, a credential compromise on an integration account, and a vendor incident at the masking provider with knock-on impact. The card-data exposure scenario triggers acquirer notifications under your merchant agreement and potentially regulator notifications under UK GDPR — both clocks start fast, so the playbook should be written down rather than improvised at 11pm.

Requirement 7: Manage your third parties#

Requirement 12.8 covers third-party service provider management. Every PCI-relevant vendor needs a written agreement that acknowledges their responsibility for the cardholder data they handle, you need their current Attestation of Compliance on file, and you need a list of which PCI DSS requirements are theirs versus yours under a clear responsibility matrix.

For a phone-payment stack, the typical service provider list runs to four or five names — the masking provider, the payment gateway, the contact centre platform, the acquiring bank, and sometimes a telephony carrier. Ask each one for their AoC every year. Cross-check it against your scope diagram. The mistake teams make is assuming "PCI Level 1 service provider" on a marketing page is the same as "covers the thing I need them to cover". It often isn't. A masking provider's AoC won't cover the agent UI you've built around it — that integration layer is yours.

What's new in v4.0.1 that catches teams out#

Three v4.0.1 changes trip up phone-payment operators most often. The first is the customised approach — alongside prescriptive "defined approach" requirements, you can meet a control through any equivalent measure as long as you document a targeted risk analysis, define the customised control, and have your QSA validate it. The upside is flexibility for unusual architectures. The downside is paperwork; every customised control needs its risk analysis, control description, and validation evidence.

The second is Requirement 6.4.3 on payment-page script integrity. It was written with e-commerce skimming attacks in mind, but it applies to any payment page that loads JavaScript. If your phone-payment vendor exposes a self-service portal or a hosted page that an agent or customer hits in a browser as part of the flow, every script on that page needs to be inventoried, justified, and integrity-checked.

The third is the authenticated internal vulnerability scan requirement under 11.3.1.2. Internal scans now have to log in and look at the system from a credentialed perspective. If your scanning tool was unauthenticated, you'll need to provision service accounts, agree the scope with the system owners, and rerun the baseline.

The SAQ question#

Which Self-Assessment Questionnaire applies depends on how card data flows through your environment, and that's where DTMF masking has its biggest paperwork impact. SAQ D is the full version — around 300 questions across all twelve requirements. It applies to merchants who store, process, or transmit cardholder data and don't fit a more specific scenario. A contact centre where agents hear card numbers and recordings capture them is squarely in SAQ D territory.

SAQ A is the shortest at around 22 questions. It applies where all card data functions are performed by a PCI DSS compliant third party and the merchant's systems never touch cardholder data. SAQ A-EP sits between them, for merchants whose systems redirect or partially handle the payment flow without storing data.

A properly implemented masking architecture can move a contact centre from SAQ D back to SAQ A or SAQ A-EP. If your agent's screen never displays PAN, your systems never store it, your recordings never capture it, and the masking provider runs the full payment lifecycle, you're typically in SAQ A territory. Always confirm with your acquirer or QSA — they own the call. The wider article on what "descoped" actually means is worth a read before you write the determination up.

UK, EU and US: how the assessor's questions differ by region#

The standard is the same. The regulatory environment around it isn't, and that shows up in the supplementary questions an assessor will ask. In the UK, the FCA's operational resilience rules (PS21/3, in force since March 2022) sit alongside PCI for any firm that handles consumer payments, and the Information Commissioner's Office treats card data as personal data under UK GDPR. A breach in a phone-payment context typically triggers reporting obligations under both regimes — 72 hours to the ICO, prompt notification to the acquirer under merchant agreement terms.

In the EU, NIS2 expands cybersecurity reporting obligations for "essential" and "important" entities, which catches a lot of mid-size contact centres. PSD2 strong customer authentication requirements apply to most card-present and card-not-present transactions; phone payments fall under the MOTO (Mail Order/Telephone Order) exemption in most jurisdictions, but national interpretations vary. Check the local supervisor's guidance before filing your SAQ.

In the US, state-level data breach notification laws layer on top of PCI. California's CCPA/CPRA, New York's SHIELD Act, and the Texas Data Privacy and Security Act all have specific notification triggers for cardholder data exposure. The HIPAA crossover applies if you're a healthcare phone-payment operator — a card-data exposure in a recording of a clinical conversation can trigger both PCI and HIPAA notification clocks. Our piece on HIPAA vs PCI DSS walks through the overlap.

Evidence pack: what to have ready before the assessor calls#

Whether you end up on SAQ A or SAQ D, the same six artefacts will be requested first. Have them on a shared drive with version control and dated sign-offs. Scope diagram updated within the last twelve months under 12.5.2. Data-flow diagrams for every channel that can carry cardholder data. AoCs for every PCI-relevant third party, refreshed annually. The most recent quarterly ASV scan report. The most recent annual penetration test report. The incident response plan with the date of the last tabletop exercise on the front page.

For phone-only merchants pursuing SAQ A, add three more: the masking provider's AoC with the specific services covered highlighted, the responsibility matrix showing which PCI DSS requirements are the provider's versus yours, and a written confirmation from the provider that they handle the card-data functions described. That last one is the document an assessor will use to validate clause two of the SAQ A eligibility test.

Frequently asked questions#

When does PCI DSS 4.0.1 become mandatory?

It already is. PCI DSS v3.2.1 retired on 31 March 2024 and the v4.0 future-dated requirements became mandatory on 31 March 2025. The current version is v4.0.1, published June 2024 with small clarifications. Any audit or self-assessment in 2026 is judged against v4.0.1 — there's no transition window left.

Can a phone-only merchant qualify for SAQ A?

Yes, if the card-handling leg is fully outsourced to a PCI DSS validated service provider, the merchant's systems never store, process or transmit cardholder data, and the merchant has a Requirement 12.8 third-party management process for the provider. A masked DTMF flow with a validated provider is the most common architecture that meets the test. Scenarios 1, 2 and 3 in this article are practical examples.

What's the difference between SAQ A and SAQ A-EP for phone payments?

SAQ A is for merchants whose systems never touch cardholder data at all. SAQ A-EP is for merchants whose systems redirect or partially handle the payment flow without storing card data. For phone payments, SAQ A applies when DTMF masking removes card data from the entire call path; SAQ A-EP usually applies when a payment-link flow involves a hosted page iframed inside merchant-controlled chrome, or when a redirect from the merchant's site initiates a payment session.

Does PCI DSS 4 require DTMF masking?

No. PCI DSS doesn't mandate any specific technology — it sets outcomes the merchant has to achieve. You can be compliant without DTMF masking if you have other controls that keep card data out of your environment, such as fully transferring the payment leg to a hosted IVR. Masking is popular because the alternatives — pause-and-resume in particular — are unreliable at scale and a single failure creates a compliance breach.

Can we self-assess for phone payments?

Yes, if your merchant level allows it. Level 1 merchants always need a Report on Compliance from a QSA. Levels 2 to 4 can self-assess using the appropriate SAQ, with the choice driven by your data flow. Most phone-payment operators end up either at SAQ A (descoped via masking) or SAQ D (not descoped). Talk to your acquirer to confirm.

What changes for small merchants?

The requirements don't shrink for smaller operators — they apply in full. What changes is the validation path: smaller merchants self-assess rather than commission a QSA-led RoC. The biggest win for a small phone-payment operator is descoping through masking — it converts a heavy SAQ D into a short SAQ A.

How often is recertification?

Annually. A QSA-led Report on Compliance, an SAQ, or an Attestation of Compliance — whichever applies to your level — is valid for twelve months. Quarterly ASV scans run alongside, and an annual scope review under Requirement 12.5.2 has to happen before the certification is renewed.

What's the penalty for non-compliance?

The fines come from card schemes via your acquiring bank rather than from the PCI Council directly. Typical ranges run from a few thousand pounds a month for ongoing non-compliance to six- or seven-figure fines per breach incident, plus forensic investigation costs and card-reissuance charges. The reputational cost usually outruns the regulatory cost — a publicly disclosed card-data breach is the sort of event most operators only survive once.

If our masking provider has a Level 1 AoC, does that cover us?

It covers the services the AoC says it covers. Read the "Services Covered" section of any provider's AoC carefully — a Level 1 attestation might cover DTMF masking but not tokenisation, or might cover both but not the integration API your team built on top. The merchant remains responsible for any element of the cardholder data environment that hasn't been explicitly outsourced. This is why Requirement 12.8 and a written responsibility matrix matter so much.

What about MOTO transactions specifically?

MOTO (Mail Order/Telephone Order) is a transaction category, not a PCI exemption. PCI DSS applies in full to MOTO. What's different is the acquirer's interchange treatment and the PSD2 strong customer authentication picture in the EU — MOTO is exempt from SCA in most jurisdictions because there's no online flow to challenge. PCI compliance obligations on the merchant don't change.

Where to take this next#

If your next audit is on the horizon, work backwards from this checklist. Start with the scope diagram — if you can't produce one in an afternoon, that's the first thing to fix. Then walk through each of the seven requirements above and rate yourself honestly: green, amber, red. The amber and red rows are the work for the quarter. The bigger architectural question — whether to bring DTMF masking in to descope the call recordings problem — is the highest-use decision on the list, and it tends to make every other requirement easier rather than harder.

If you'd like to walk a real call flow through the checklist with someone who's done it before, we're a PCI DSS Level 1 service provider with ten years of contact centre integrations behind us. Have a look at our DTMF masking solution for the architecture, or get in touch and we'll talk through your specific path.

Related reading#

• The full picture: how to take card payments over the phone — this checklist baked into a complete methods + compliance walk-through.
• Pillar guide: PCI DSS v4.0.1 contact centre guide
• HIPAA vs PCI DSS: What Healthcare Providers Need to Know
• What Is AOC? Attestation of Compliance Explained
• PCI Scope Reduction (Descoping): Cut Audit Scope 96%
• Cardholder Data Environment (CDE): How to Reduce Its Scope

Want to see this working in your setup? Book a working-demo call — we'll wire up your actual phone system and show you a live capture.