PCI DSS for call centers: secure phone payment architecture

PCI DSS call center compliance in one minute

Design the payment moment so payment-account data never enters the ordinary conversation path. The agent or voice AI can explain the charge, confirm consent, and initiate payment. A separately controlled payment system should collect the card number and security code. The conversation should receive only a bounded result such as payment_succeeded, payment_failed, or a provider token that cannot reveal the card number.

This boundary should keep raw card data out of:

• agent audio and desktop fields;
• model prompts, context, memory, and tool arguments;
• call recordings and transcripts;
• ordinary webhooks, application logs, traces, and analytics;
• customer relationship management (CRM) notes, support tickets, and quality-assurance systems.

That architecture can reduce the systems and people subject to PCI DSS controls. It does not make a merchant compliant by itself. The merchant still owns its validation path, payment-provider oversight, written responsibility allocation, and the controls on every system that remains in scope.

A practical first-pass checklist is short:

1. Map every point where payment data can enter, move, persist, or be observed.
2. Put card capture in a separate payment path with explicit demarcation points.
3. Prevent card numbers and security codes from reaching agents, recordings, transcripts, AI systems, and general application data.
4. Return only the minimum result needed to continue the call.
5. Assign each PCI DSS responsibility to a named party and preserve evidence that the controls operate.
6. Confirm the required assessment and validation method with the acquirer or payment brand.

What puts a call center in PCI DSS scope

The Payment Card Industry Data Security Standard (PCI DSS) applies to entities that store, process, or transmit payment-account data and to systems that can affect its security. The current standard is PCI DSS v4.0.1. PCI SSC published it as a limited revision on June 11, 2024, with clarifications and corrections but no added or removed requirements. PCI DSS v4.0 retired on December 31, 2024, and the future-dated requirements took effect on March 31, 2025, as planned. The PCI DSS v4.0.1 announcement and document library are the source of record.

Two data classes matter:

• Cardholder data (CHD): at minimum, the full primary account number (PAN). It may also appear with the cardholder name, expiration date, or service code.
• Sensitive authentication data (SAD): full track data, card-verification codes or values such as CVV2, CVC2, CAV2, and CID, and personal identification numbers (PINs) or PIN blocks.

These definitions come from PCI DSS v4.0.1, which uses payment-account data to mean CHD and/or SAD.

For entities other than issuers and companies that support issuing services, Requirement 3.3.1 in PCI DSS v4.0.1 prohibits storing SAD after authorization, even when it is encrypted. That rule reaches digital audio. A recording by one of those entities that retains a spoken card-verification code after authorization violates the requirement. PCI SSC's telephone-payment supplement recommends preventing or suppressing recording, redacting the data, or securely deleting it immediately after authorization. Only when prevention or deletion is technically or operationally impossible because of documented legitimate technical, business, or legal constraints should such an entity use the compensating-control route. Any SAD retained under that route must not be queryable, and controls must prevent unauthorized use. The exception requires documented justification, a risk assessment, protective controls, annual validation, and review with the acquirer or payment brand.

PCI DSS v4.0.1 has a narrow applicability exception for issuers and companies that support issuing services when they have a legitimate issuing business need and meet the standard's conditions; this guide addresses merchant payment-acceptance flows where that exception does not apply.

A call center's cardholder-data environment (CDE) includes the people, processes, and technologies that store, process, or transmit CHD or SAD, plus connected systems that can affect their security. Depending on the design, that can include:

• agents and supervisors who hear or see card details;
• softphones, Session Initiation Protocol (SIP) infrastructure, Real-time Transport Protocol (RTP) processing, merchant- or provider-controlled carrier termination, media gateways, and session border controllers;
• agent desktops, virtual desktops, browsers, and payment forms;
• recording, transcription, speech analytics, and quality-assurance systems;
• conversational runtimes, model providers, tool servers, and webhook receivers;
• CRM, ticketing, workforce, log, backup, and analytics systems;
• payment processors and other third-party service providers.

Voice over Internet Protocol (VoIP) does not change this boundary. Network encryption alone does not remove a system from scope. Merchant- or provider-controlled carrier termination, SIP trunks, media gateways, session border controllers, and RTP-processing components remain in the applicable entity's PCI DSS scope when they store, process, or transmit payment-account data. A carrier that only provides a public communications link is generally not part of the merchant CDE. Document that demarcation and determine whether the carrier or provider does more than public transport. The November 2018 telephone supplement provides telephony implementation guidance, while PCI DSS v4.0.1 governs current scope. A service provider can also be in scope without directly handling card data when it can affect CDE security.

Physical space can matter too. When a call-center area contains systems that process, transmit, or store cardholder data, PCI SSC says the area needs controls that prevent unauthorized access and identify entrants. See the Council's call-center physical-access FAQ.

Compare secure phone-payment capture patterns

No capture pattern is compliant on its own. Each changes where payment data flows, which components remain in scope, and which failure modes need evidence.

Transfer to a controlled IVR or provider

A hard transfer can offer a clear boundary: the caller leaves the ordinary conversation, completes payment with a dedicated system, and returns or reconnects with a non-sensitive result. A bridged or conference design needs closer analysis because the agent, recorder, or voice runtime may remain on the media path.

The transfer itself proves little. Document exactly where control changes, which system can hear the caller, how the payment result returns, and whether anyone can retrieve the card data later.

DTMF suppression or masking

DTMF tones are the sounds created by telephone keypad presses. A payment system can intercept the digits while replacing what the agent and recorder receive with flat tones, silence, or another safe signal. The desktop should display masked placeholders rather than the digits.

Unaltered DTMF tones are reversible and remain payment data. Equipment that receives the original tones also remains relevant to scope. Test for tone bleed across recordings, live monitoring, transfers, conferencing, packet captures, and failure modes. The PCI SSC telephone-payment supplement provides useful design guidance, but its November 2018 requirement references predate PCI DSS v4.0.1. Use it as supplemental architecture guidance and map the design to the current standard.

Agent-assisted capture in a segmented CDE

Some operations need an agent to see or hear card data. In that case, place the agent, desktop, payment application, supporting network, and relevant physical area inside a controlled CDE. Segmentation can limit the boundary, but the organization has to demonstrate that the separation is effective. Requirement 3.5.1 in PCI DSS v4.0.1 requires stored PAN to be rendered unreadable using one of its allowed methods: strong cryptography with associated key-management processes, truncation, keyed cryptographic hashes based on strong cryptography, or index tokens with associated pads securely stored.

This pattern carries more operating burden. Remote work, clipboard functions, screenshots, local storage, personal devices, screen sharing, supervisor monitoring, and support access all need explicit treatment.

Hosted payment link

A hosted link moves capture from voice to a browser or mobile device. It can be a good option for callers who can receive and open a message during the call. Keep the conversation focused on the amount and status. Do not ask the caller to read the card details aloud when the link fails.

The callback should contain a transaction reference and minimal status. A URL redirect or token does not decide scope by itself. The systems that create, route, administer, or can affect the payment flow still need assessment.

Reference architecture: separate conversation and payment planes

A robust design uses two planes with a narrow contract between them.

The conversation plane handles telephony, dialogue state, business context, authentication appropriate to the use case, explanations, consent, and call lifecycle. It may include an agent desktop or voice AI runtime. It must be unable to collect or retrieve the PAN, security code, or PIN.

The payment plane handles card capture, authorization, tokenization where used, and the controls required for the payment environment. It should be administered separately, expose the smallest practical interface, and prevent raw payment data from returning to the conversation plane.

A typical flow is:

1. The conversation confirms the payable amount, currency, merchant identity, and customer intent without collecting card details.
2. The merchant backend creates a single-use payment session and returns an opaque session identifier.
3. Telephony routes the payment portion to the controlled provider, DTMF capture service, or segmented payment environment.
4. The payment plane collects the card data and submits the transaction. Raw digits never appear in a model prompt, tool call, webhook, transcript, recording, or agent field.
5. The payment plane returns a bounded event such as payment_succeeded, payment_failed, or payment_abandoned, plus an opaque transaction reference if needed.
6. The conversation resumes, communicates the result, and follows a defined retry or human-escalation policy.

Treat the boundary as an application programming interface (API) contract. Allowlist fields and event types. Reject unexpected payloads. Do not pass free-form provider responses into prompts or logs. Never put PAN fragments, security codes, track data, or PIN data into error messages. A provider token is useful only when it cannot be reversed by the receiving system and the surrounding token service is assessed correctly.

Failure handling deserves the same design attention as the happy path. Decide what happens when the transfer fails, the customer starts speaking digits early, a webhook times out, the payment result arrives twice, an agent joins mid-capture, or recording suppression does not activate. Default to stopping capture and routing to a safe recovery path.

Recording, transcript, and log controls

The safest recording control is exclusion. Stop CHD and SAD before they enter audio recordings, screen recordings, transcripts, prompt histories, model-provider logs, quality systems, or backups.

Pause and resume can support that design, but it is not a compliance shortcut. It may remove a recording repository from exposure while the agent, desktop, live media, and telephony path remain in scope. Manual pause and resume is especially fragile because late pauses, early resumes, transfers, and agent error create silent gaps in protection.

When pause and resume is used:

• trigger it from the payment-session state rather than agent memory where possible;
• fail closed if confirmation does not arrive;
• reconcile every payment window against recording and transcription events;
• test transfer, conference, supervisor-monitoring, and retry paths;
• alert on unmatched pause and resume events;
• check that transcription and analytics stop independently, since pausing one recorder may not stop another consumer.

If an organization has a business and legal reason to retain CHD, it must render stored PAN unreadable using a method allowed by Requirement 3.5.1. Apply the relevant access, logging, retention, and deletion controls as well. For entities other than issuers and companies that support issuing services, SAD has the stricter rule: it cannot remain after authorization. For those entities, recording and retention obligations do not make retaining SAD PCI DSS-compliant; design controls to meet both and obtain legal, acquirer, or payment-brand guidance if obligations appear to conflict.

Logs should record control events rather than secrets. Useful evidence includes the payment-session identifier, handoff time, responsible component, suppression confirmation, provider response class, retry count, policy decision, and final status. Do not log raw payloads as a debugging convenience.

Production implementation checklist

1. Draw the real data flow. Include caller audio, RTP and SIP paths, DTMF, agent monitoring, desktop fields, recordings, transcripts, prompts, tools, webhooks, logs, backups, and provider administration portals.
2. Classify each system. Mark where CHD or SAD is stored, processed, transmitted, or can be accessed. Also mark systems that can affect CDE security.
3. Define demarcation points. Record the exact component where the conversation hands off to payment capture and where the non-sensitive result returns.
4. Minimize collection. Make the conversational path technically unable to request, retrieve, or persist payment-account data. Script a safe interruption when callers begin speaking digits.
5. Separate networks and tenants. Restrict routes between the payment environment and general call-center systems. Prove segmentation and prevent one tenant's configuration, logs, or data from crossing into another's context.
6. Control identities and access. Use individual accounts, least privilege, strong authentication, joiner-mover-leaver processes, privileged-access review, and separation of operational and payment administration.
7. Protect the physical environment. Control and monitor access to locations that contain in-scope systems. Address paper notes, mobile phones, cameras, printers, and visitor handling.
8. Suppress every recording path. Cover audio, screens, transcripts, model histories, analytics, supervisor monitoring, and backups. For merchant payment-acceptance flows where the issuing exception does not apply, test that card-verification codes do not persist after authorization.
9. Protect and minimize retained data. Keep only data with a defined business and legal need. Render any stored PAN unreadable using a method allowed by Requirement 3.5.1. Apply access, logging, retention, and deletion controls to replicas, exports, caches, and backups where applicable.
10. Constrain tools and webhooks. Use typed schemas, field allowlists, authenticated endpoints, idempotency controls, payload-size limits, and redaction before logging. Keep the conversation runtime's payment result contract narrow.
11. Protect secrets and keys. Store provider credentials outside prompts and application code, scope each credential, rotate it, monitor its use, and document emergency revocation.
12. Monitor control health. Alert on tone bleed, capture outside the payment window, missing suppression events, unexpected fields, recording-policy drift, privilege changes, and repeated payment failures.
13. Preserve assessment evidence. Retain current diagrams, inventories, configurations, access reviews, segmentation results, provider attestations, incident exercises, and control-test results.
14. Prepare incident response. Define how to stop capture, preserve evidence, contain exposed systems, notify the responsible parties, investigate recordings and logs, and restore service safely.
15. Review third parties. Obtain the provider's current Attestation of Compliance where applicable, confirm which services and locations it covers, document responsibility acknowledgements, and monitor status at least annually.
16. Confirm validation. The acquirer or payment brand determines the accepted validation path. A Qualified Security Assessor can assess the environment, but cannot transfer ownership of the controls away from the organization.

Where Dasha fits

Dasha can run the non-card conversation and call lifecycle around a separately controlled payment step. Our managed runtime, REST APIs, and web application support production voice AI workflows. Tools can use JSON Schema and authenticated HTTPS webhooks, while activity logs and completed-call artifacts support operations and review.

Those capabilities also create data paths that must be designed deliberately. Completed-call data can include transcripts and recording URLs. Keep the PAN, security code, PIN data, and unmasked DTMF out of Dasha prompts, tools, webhooks, transcripts, recordings, and logs. Dasha should receive only the payment session handle needed to coordinate the handoff and the minimum non-sensitive result required to continue the call.

Dasha is not the payment processor or the compliant card-data environment, and using Dasha does not confer PCI DSS compliance. The customer backend remains authoritative for authorization, sensitive-data access, policy, and recovery. The payment provider and telephony design own the secure capture path.

Technical teams can use our API integration pattern to design narrow tool contracts, our security architecture guide to plan runtime boundaries, and the voice AI backend to evaluate Dasha's role in the broader production stack. The existing Stripe integration example is useful integration context, but a production phone-payment design still needs the isolated capture boundary described here.

Shared responsibility matrix

Outsourcing can reduce the number of PCI DSS requirements that apply directly to the merchant's environment. It does not remove merchant responsibility. PCI SSC's outsourcing FAQ requires merchants to verify provider compliance for the services used, maintain written responsibility acknowledgement, monitor the provider at least annually, and understand shared responsibilities.

Create a requirement-by-requirement responsibility matrix rather than relying on a contract phrase such as “PCI compliant.” For every shared control, identify who implements it, who supplies evidence, who monitors it, and who acts when it fails.

Frequently asked questions

Can a call center be out of PCI DSS scope if agents never see card numbers?

Potentially, some systems and people can be excluded when payment-account data bypasses them and they cannot affect the security of the payment environment. Agent blindness alone is insufficient. Check the telephony path, recordings, transcripts, desktops, integrations, administration, and connected systems. The organization still has provider-management and validation responsibilities.

Are call recordings allowed to contain card details?

In merchant payment-acceptance flows where the issuing exception does not apply, a recording must not retain SAD, including card-verification codes, after authorization, even when encrypted. Prevent or suppress that data, redact it, or securely delete it immediately after authorization. Only when prevention or deletion is technically or operationally impossible because of documented legitimate technical, business, or legal constraints should the entity use the compensating-control route. Any SAD retained under that route must not be queryable, and controls must prevent unauthorized use. The exception requires documented justification, a risk assessment, protective controls, annual validation, and review with the acquirer or payment brand. A recording that retains permitted CHD must render stored PAN unreadable using a method allowed by Requirement 3.5.1, plus applicable access, logging, retention, and deletion controls.

Does DTMF masking make a call center PCI compliant?

No. Correct suppression can keep digits away from agents, desktops, recordings, and conversation systems, which may reduce scope. Original tones remain reversible payment data. The capture service and any equipment that receives unsuppressed tones remain relevant, and the full deployment still needs assessment.

Does outsourcing phone payments remove the merchant's PCI DSS responsibility?

No. Outsourcing may reduce directly applicable requirements. The merchant still needs a compliant provider for the services used, written responsibility acknowledgement, annual status monitoring, clear shared responsibilities, and the validation method accepted by its acquirer or payment brand.

Is VoIP in scope for PCI DSS?

VoIP is in scope wherever payment-account data is stored, processed, or transmitted on systems and networks the entity controls. This includes merchant- or provider-controlled carrier termination, SIP, RTP, media gateways, and related telephony components that handle the data. A carrier that only provides a public communications link is generally not part of the merchant CDE. Encryption protects transmission but does not automatically remove controlled components from scope.

Which PCI DSS version applies now?

PCI DSS v4.0.1 is the active version. PCI DSS v4.0 retired on December 31, 2024, and all future-dated v4.x requirements became effective on March 31, 2025.

Design the boundary before the payment flow ships

A clean payment boundary is easier to build than to recover from leaked card data across recordings, transcripts, prompts, webhooks, and analytics. Map the media and data paths first, choose the capture pattern with your payment and telephony providers, then make the conversation plane technically incapable of receiving payment-account data.

Evaluate Dasha for the non-card conversation and integration layer, with a narrow payment-session contract and a separately controlled capture path.