Call Center Compliance — Phone Payments Under PCI DSS v4.0.1
Call Center PCI Compliance: What Phone Payments Actually Require
Call center PCI compliance comes down to one blunt rule and a set of scope decisions. The rule: the card security code a customer reads out over the phone is sensitive authentication data (SAD), and it may never be stored after authorization — not in a recording, not in a CRM note, not even encrypted. The scope decisions: whether your recordings, agent workstations, and networks ever touch card data at all, because everything that does is assessable. The active standard is PCI DSS v4.0.1 — the only version in force since December 31, 2024, with all 51 of v4’s future-dated requirements mandatory since March 31, 2025. Here is what that means for a team taking payments by phone, as of July 2026.
This page is education, not legal or compliance advice. A dialer is a tool — the dialer itself is compliant software, but compliance depends on user behavior. Enzo makes no PCI DSS claims and is not a payment-processing environment. PCI DSS is enforced through card-brand and acquirer contracts, so scope your program with your acquirer and a Qualified Security Assessor.
One Active Standard: PCI DSS v4.0.1
PCI DSS is published by the PCI Security Standards Council and reaches merchants through their agreements with acquirers and card brands — it is a contractual standard, not a government law, so treat every “deadline” below as a contract obligation rather than a statute. The version picture in 2026 is simple because the transition is over:
| Milestone | Date | What it means now |
|---|---|---|
| PCI DSS v4.0 published | March 31, 2022 | Start of the v4 era |
| v3.2.1 retired | March 31, 2024 | v4.x became the only active line |
| v4.0.1 published | June 11, 2024 | Limited revision — no new or deleted requirements |
| v4.0 retired | December 31, 2024 | v4.0.1 is the sole active version |
| Future-dated v4 requirements in force | March 31, 2025 | All 51 initially “best practice” requirements now mandatory |
If your call center last looked at PCI during the v3.2.1 days, the standard you validated against no longer exists — and the grace period for the new v4 requirements ended over a year ago.
The Non-Negotiable: Card Codes Never Survive Authorization
The rule that decides most call-center assessments lives at PCI DSS v4.x Requirement 3.3.1 (the successor to v3.2.1’s Requirement 3.2): sensitive authentication data is not stored after authorization, even encrypted. The Council’s telephone-payment supplement is explicit that this includes the phone channel: even where encryption is in place, an entity should not store SAD after authorization, and “for all telephone environments,” SAD includes the card security code taken during a call. The only entities permitted to store SAD after authorization are card issuers and companies supporting issuing services — a narrow exception carried in Requirement 3.3.3 that no merchant call center fits.
Two adjacent points complete the picture. Since March 31, 2025, Requirement 3.3.2 requires that SAD stored electronically before authorization completes be encrypted with strong cryptography — so even the temporary window is controlled. And any cardholder data you legitimately retain, such as account numbers in a CRM, sits under Requirement 3’s cryptography, truncation, and hashing rules.
Call Recordings: Where Phone Payments Actually Fail
For an operation that records calls, the recording system is the most likely place card data ends up stored. The Council’s guidance draws a hard line: if SAD is received and recorded, the entity must render all of it unrecoverable upon completion of the authorization process — and implementing a process that prevents the recording of SAD in the first place may be considered a best practice.
The common control is pause-and-resume (stop-start) recording: the recorder halts while the customer reads out the card details, then resumes. It works, with two caveats straight from the supplement:
- Agent-initiated pause is failure-prone. Where pause-and-resume is used — especially where the agent triggers it — the Council recommends verifying on a regular basis, preferably weekly, that recordings contain no cardholder data or SAD.
- If the technology cannot block the audio from being stored, the SAD must be deleted from the recording as soon as the transaction is processed. “We’ll clean it up later” is not the standard; upon completion of authorization is.
Recordings also answer to a second body of law entirely: state recording-consent statutes. If you record payment calls, the announcement and consent practices in the call recording consent states guide apply on top of everything here.
DTMF Masking: The Cleanest Scope Reduction
The stronger pattern removes the card digits from the audio path altogether. With DTMF masking, the customer keys the card number on their own phone keypad; the system captures the digits and replaces the keypad tones with flat or random tones, so the agent hears masked tones and the recording stores nothing usable. DTMF suppression removes the tones entirely.
The scope payoff is stated directly in the Council’s supplement: storing only suppressed or masked tones rather than the original DTMF “can reduce applicability of PCI DSS” requirements — while recordings that retain unaltered DTMF tones are fully in scope. One engineering trap to check in any vendor demo: DTMF bleed. Detection-based masking can let the initial portion of a tone through before masking kicks in, so a solution has to mask all tones, including partial ones.
Agent Workstations, Networks, and Third Parties
Beyond storage, the Council’s telephone-payment supplement maps the PCI DSS requirements that most often hit phone-payment environments:
| Requirement | What it demands in a phone-payment call center |
|---|---|
| Req 3 | No SAD after authorization; strong cryptography or truncation/hashing for any stored cardholder data — recordings and CRM fields included |
| Req 4 | Strong cryptography for card data transmitted over public networks — including remote and at-home agent connections |
| Reqs 7–8 | Access to recordings and CRM card data restricted to business need; proper authentication for all personnel |
| Req 9 | Physically secure media; clean-desk-style controls on notebooks, personal phones, and recording-capable devices around agents |
| Req 12.8 | Documented management of third-party service providers, with the responsibility split written down |
The last row matters more than it looks: your telephony platform, payment gateway, recording vendor, and any BPO all share the environment, and Requirement 12.8 expects you to know — on paper — who owns which control.
Which SAQ Fits a Phone-Payment Operation?
Self-Assessment Questionnaires are how smaller merchants validate, and the phone channel has a specific lane. Eligibility descriptions below are from the Council’s official v4.0 SAQ Instructions and Guidelines — but SAQ selection is not self-serve: acquirers and payment brands determine which SAQ, if any, a merchant may use, so confirm before you assess.
| SAQ | Who it fits | Call-center relevance |
|---|---|---|
| A | Card-not-present merchants (e-commerce or mail/telephone-order) that completely outsource all account data functions to PCI DSS validated third parties; no electronic account data on their systems | The fully-outsourced phone-payment model |
| B / B-IP | Imprint machines or standalone dial-out terminals (B); standalone PCI-listed PTS point-of-interaction devices on IP (B-IP); no electronic storage | Rarely a call-center fit |
| C-VT | Agents manually key one transaction at a time into a PCI DSS validated third-party virtual terminal, from an isolated computing device with a securely connected browser; no electronic storage | The classic agent-keys-the-card path |
| D (Merchants) | Every merchant not fitting another SAQ — including those that electronically store account data | Where call recordings containing card numbers put you |
| D (Service Providers) | The only SAQ available to service providers | A BPO taking payments on clients’ behalf |
Read the pattern in that table: the less your systems touch and store, the shorter the questionnaire. Recordings that capture card numbers are what drag a phone operation from C-VT territory into SAQ D.
Where Enzo Fits — and Where It Doesn’t
Enzo is an outbound sales dialer — power, predictive, and preview dialing, CSV import and list management, campaign scheduling, and call recording. Enzo makes no PCI DSS claims, and this page is not one: it is the same honesty gate as our HIPAA call center requirements guide. The dialer itself is compliant software, but compliance depends on user behavior — what your team stores, records, and transmits. If any campaign conversation could involve card data, design that payment flow with your acquirer and assessor, in a validated payment environment — not inside a sales recording.
The whole subject compresses well. One active standard: PCI DSS v4.0.1, fully in force since March 31, 2025. One hard rule: the card security code never survives authorization — render it unrecoverable, or better, keep it out of the recording with masking or pause-and-resume, verified weekly. One scoping principle: PCI follows the card data, so the less your dialer, recordings, and workstations touch, the smaller your assessment. And one process rule: your acquirer, not your vendor stack, decides how you validate. For the calling-law side of the same operation — DNC, hours, consent, recordkeeping — start with the call center compliance pillar.
See how optional call recording and campaign scheduling work inside a real calling workflow — book a free discovery call.
Not legal advice. This guide is general information for outbound calling teams, not legal advice. Rules change and apply differently by state, industry, and call type — confirm your program with qualified telemarketing compliance counsel.
Sources: PCI Security Standards Council publications — the PCI DSS v4.x version announcements, the “Protecting Telephone-Based Payment Card Data” information supplement (v3.0, November 2018), and the v4.0 SAQ Instructions and Guidelines (September 2023) — as of July 2026. PCI DSS is a contractual standard; company names are trademarks of their owners. Educational only, not legal advice.