PCI DSS Phone Payments and Recording

Taking a card payment by phone can put more of the voice environment into PCI DSS scope than many teams expect. Muting a call recording helps with one specific risk, but it does not automatically remove the PBXPrivate Branch Exchange, a private telephone switch. Asterisk is a software PBX that routes calls between internal extensions and the outside world., agent workstation, SIPSession Initiation Protocol, the standard signaling protocol used to set up, manage, and tear down VoIP calls between Asterisk and phones or carriers. signaling, RTPReal-time Transport Protocol. Carries the actual audio (media) of a VoIP call after SIP signaling has set it up. traffic, logs, or payment workflow from scope.

The short version

If a caller speaks a card number or card verification code while MixMonitor() is running, the recording may contain payment account data. If the caller keys the same data, muting the audio recording may still leave the digits visible in RFC 4733 RTP events, SIP INFO messages, Asterisk event streams, packet captures, application arguments, or debug logs.

A sound design uses several controls together:

1. Keep payment account data out of the merchant voice environment where practical.
2. Prevent sensitive authentication data from entering recordings.
3. Prevent DTMFDual-Tone Multi-Frequency, the touch-tone signals phones send for digit input during a call, used by IVRs and feature codes. digits from reaching systems that do not need them.
4. Keep payment data out of CDRCall Detail Record. The per-call accounting data Asterisk writes (start, answer, and end times, duration, disposition) to files or databases., CEL, AMIAsterisk Manager Interface. A TCP socket API for monitoring events and issuing actions in Asterisk, commonly used by click-to-dial integrations and dashboards., AGIAsterisk Gateway Interface. Lets external scripts (PHP, Python, and others) control a call by communicating with Asterisk over stdin/stdout or TCP., ARIAsterisk REST Interface. A modern asynchronous API exposing channels, bridges, and endpoints over HTTP and WebSocket for building custom call applications., application, and packet-capture logs.
5. Verify the complete call path, including transfers, failures, retries, and provider handoffs.

The safest scope-reduction pattern is usually a PCI-validated payment service that collects the card data without exposing it to the agent, the PBX, or merchant-controlled logs. The exact result still depends on the architecture and on who controls each part of the transmission.

What puts a VoIP system in scope

PCI DSS applies wherever payment card account data is stored, processed, or transmitted. PCI SSC states that VoIP traffic containing account data is in scope while it is within systems and networks controlled by the entity. For calls between a cardholder and a merchant, the merchant's systems and networks used for that transmission are in scope even though the merchant cannot control the caller's telephone network.

That can include:

• Asterisk servers and media relays
• SIP proxies, session border controllers, and recording platforms
• Agent phones, softphones, and workstations
• Voice, screen, and quality-management recording systems
• Network devices and administrative systems that can affect the card-data path
• Logs, backups, transcriptions, analytics, and packet captures
• Integrations that receive channelA single call leg passing through Asterisk. Channels represent connections to endpoints and are what dialplan applications act on. variables, AMI events, AGI data, or ARI events

Encryption is valuable, but it does not automatically remove systems from scope. Asterisk and the endpoints still handle decrypted media or signaling where the call is terminated.

PCI SSC FAQ 1153 explains how PCI DSS applies to VoIP and where an entity's responsibility begins and ends.

Cardholder data and sensitive authentication data

The primary account number, or PAN, is the defining element of cardholder data. Cardholder name, expiration date, and service code are also cardholder data when stored with the PAN. Sensitive authentication data includes full track data, card verification codes such as CVV2, CVC2, CID, and PIN or PIN blocks.

PCI DSS v4.0.1 Requirement 3.3.1 prohibits storing sensitive authentication data after authorization, even when it is encrypted. For recorded calls, PCI SSC specifically says organizations should enable technology that suppresses or redacts the audio while that data is entered. If sensitive authentication data is recorded despite those controls, follow the PCI SSC guidance for immediate secure deletion, documented risk treatment, and assessor validation.

Do not treat a recording as harmless because it is difficult to search. Speech recognition, manual playback, waveform analysis, and future tooling can make recorded digits retrievable.

See PCI SSC FAQ 1210 and the PCI SSC telephone payment guidance.

PCI DSS version and validation

PCI DSS v4.0.1 is the current active version of the standard. PCI DSS v4.0 was retired on December 31, 2024. The requirements that had been future-dated became effective on March 31, 2025.

Your Self-Assessment Questionnaire is determined by the payment environment, not simply by the fact that an order arrived by telephone.

For example, SAQ C-VT is narrowly intended for merchants that manually enter one transaction at a time into a third-party, web-based virtual terminal from an isolated computing device, with no electronic storage of account data and no other electronic receipt or transmission of that data. A normal call-center desktop with other payment applications or connected business systems may not qualify.

SAQ A may be possible for some mail-order or telephone-order merchants that outsource all payment processing and do not electronically store, process, or transmit account data on their own systems. SAQ D is the broad fallback when the environment does not meet the eligibility criteria for a shorter SAQ. Your acquirer determines which validation form it will accept.

Do not select an SAQ from an architecture diagram alone. Confirm eligibility with the entity receiving the Attestation of Compliance. See PCI SSC FAQ 1229 and the PCI SSC document library.

Choosing a payment pattern

Agent hears and enters the card data

In the traditional model, the caller reads the PAN, expiration date, and verification code to an agent, who enters them into a payment application or virtual terminal.

This is straightforward for the caller, but it brings the agent, endpointIn PJSIP configuration, the SIP entity Asterisk communicates with: a phone, trunk, or other user agent. Defined by an endpoint section in pjsip.conf., workstation, voice path, and supporting systems into the discussion. Pause and resume controls can keep the spoken data out of a recording, but the agent still hears the data and the merchant still processes it.

Use this model only with a documented PCI scope, a validated payment application, strong access controls, appropriate physical controls, and a tested recording-suppression process.

DTMF masking or suppression

In a DTMF-masking design, the agent starts a secure payment session and asks the caller to use the telephone keypad. A payment service receives the digits while the agent hears masking tones or silence and sees only transaction progress or a token.

This can reduce exposure, but only if the service prevents the real digits from reaching the agent audio, Asterisk events, merchant-controlled signaling, logs, and recordings. Replacing each real digit with a flat tone for the agent is different from merely turning down the recording volume.

Validate where the DTMF is intercepted, who controls that component, what the PBX receives, and what evidence the service provider supplies for its PCI DSS status.

Transfer or bridge to a hosted payment IVR

Another pattern transfers or bridges the caller to a hosted payment IVR and returns the caller after authorization. This is often easier to reason about than building payment collection into the PBX.

Check whether Asterisk remains in the media path, whether the original recording continues across the bridge, and whether the provider returns only a token and transaction result. A transfer by itself is not proof that the merchant environment stopped carrying account data.

Tokenization

Tokens are useful after the payment processor has received the account data. A token can keep the PAN out of order management, CRM, reporting, and recurring-payment workflows.

Tokenization does not erase the scope of the point where the original card data was captured. The voice and payment path up to token creation still needs analysis.

Pausing and resuming MixMonitor

The supported Asterisk control for muting an active MixMonitor recording is the AMI MixMonitorMute action. State: 1 mutes the recording and State: 0 unmutes it. Direction may be read, write, or both.

The v(x), V(x), and W(x) options to MixMonitor() adjust recording volume. They are not pause controls. X is not a MixMonitor() option.

Start the recording and retain its actual filename

Use a filename derived from a call identifier, not from caller-supplied data. MIXMONITOR_FILENAME contains the actual filename Asterisk is writing, including filename normalization performed by Asterisk.

[recorded-service]
exten => _X.,1,NoOp(Start recorded service call)
 same => n,Set(RECORDING_BASENAME=${UNIQUEID})
 same => n,MixMonitor(${RECORDING_BASENAME}.wav,b)
 same => n,Set(RECORDING_FILE=${MIXMONITOR_FILENAME})
 same => n,Dial(<span class="term-ref" data-term="pjsip" tabindex="0">PJSIP<span class="term-tooltip">The modern SIP channel driver in Asterisk (chan_pjsip), replacing the older chan_sip. Configured in pjsip.conf using endpoints, AORs, auths, and transports.</span></span>/${EXTEN})
 same => n,StopMixMonitor()
 same => n,Hangup()

Do not place a PAN, verification code, payment token, or customer-entered value in the filename, command argument, channel name, account code, or user field.

Mute before requesting card data

Send the action to the exact Asterisk channel on which MixMonitor() is running:

Action: MixMonitorMute
ActionID: payment-mute-01
Channel: PJSIP/customer-0000012a
Direction: both
State: 1

Resume after the payment service has finished collecting sensitive data:

Action: MixMonitorMute
ActionID: payment-resume-01
Channel: PJSIP/customer-0000012a
Direction: both
State: 0

Use the live channel name reported by Asterisk. Uniqueid and Linkedid are useful correlation values, but they are not substitutes for the Channel argument.

Your controller should not play the card-entry prompt until Asterisk confirms that the mute action succeeded. If muting fails, do not continue with card collection. Resume only after the payment component reports that entry is complete, and alert on calls left muted unexpectedly.

Transfers, Local channels, queues, and channel replacement can change which channel owns the audiohook. Test each supported call flow and track the active channel rather than assuming the original name remains valid.

There is no MixMonitorMute() dialplanThe core call-routing configuration of Asterisk, written mostly in extensions.conf as contexts, extensions, and priorities that decide how every call is handled. Full definition → application. An IVR can signal an AMI controller before entering its payment contextA named section of the dialplan that groups extensions. Calls enter a specific context and can only reach extensions visible from it, making contexts the basic unit of call routing and security., an agent hotkey can signal the same controller, or an AGI or ARI application can coordinate the state change. Keep AMI credentials out of the dialplanThe core call-routing configuration of Asterisk, written mostly in extensions.conf as contexts, extensions, and priorities that decide how every call is handled. Full definition →, and make the controller enforce the sequence rather than relying on an agent to mute and resume at exactly the right moment.

Stopping and restarting MixMonitor() is not equivalent to muting it. That approach creates multiple files and introduces timing, naming, upload, and reconciliation problems. If it is the only available design, treat it as a separate recording architecture and prove that no sensitive audio reaches any file during the transition.

Muting one MixMonitor audiohook does not control a second recorder. Inventory separate receive and transmit files, queueAn Asterisk call queue (app_queue) that parks incoming calls and distributes them to logged-in agents according to a chosen ring strategy. or contact-center recorders, SIPREC, endpoint recording, conference recording, voicemailAsterisk's built-in voice messaging system (app_voicemail), configured in voicemail.conf with mailboxes per user. copies, live transcription, speech analytics, and provider-side recording.

See MixMonitorMute, MixMonitor(), StopMixMonitor(), and the official MixMonitorMute documentation.

Why recording mute does not suppress DTMF

DTMF can travel through a SIP call in several forms:

Muting MixMonitor() prevents audio from being written to that recording for the selected direction. It does not promise to discard RFC 4733 events, SIP INFO bodies, ARI ChannelDtmfReceived events, CEL DTMF events, or digits captured by another component.

The PJSIP dtmf_mode setting chooses how Asterisk exchanges DTMF with an endpoint. Documented values include rfc4733, inband, info, auto, and auto_info. It is not a PCI scope switch, and none is not a documented value. Changing the mode can also break IVRs and other call features.

SendDTMF() sends digits. It does not suppress them. Never use it with a PAN or verification code stored in a channel variable, because the digits can then appear in dialplan traces, CDR or CEL application data, AMI traffic, and debug output.

A real DTMF-suppression service must intercept the digits at the correct boundary and make sure merchant-controlled components receive only masked tones, status events, or tokens. Test all negotiated DTMF modes, not just the expected one.

See the Asterisk PJSIP DTMF mode documentation and SendDTMF().

Logs and captures that can leak digits

Review every place that can observe the payment segment.

SIP and RTP troubleshooting

pjsip set logger on exposes SIP messages to the Asterisk console and configured logs. SIP INFO DTMF can therefore appear in plain text. Packet captures can contain SIP signaling, in-band audio, or RFC 4733 events when those streams are not encrypted.

TLS and SRTP reduce exposure on the wire, but they do not sanitize logs created after decryption or protect data from administrators and applications at an endpoint. Do not run broad packet captures or verbose protocol logging during live payment entry. If troubleshooting is unavoidable, use a controlled test account with non-production data, minimize the capture window, restrict access, and securely dispose of the files.

Also review rtp set debug, DTMF logging in logger.conf, FRAME_TRACE(), SIP proxies, session border controllers, media relays, intrusion-detection systems, and provider diagnostics.

CDR and CEL

Standard CDR fields include lastdata, accountcode, and userfield. CEL records can include application names, application data, user-defined fields, and DTMF events when those event types are enabled.

Do not put payment data in:

• Dialplan application arguments
• Channel variables that are exported or logged
• CDR(accountcode), CDR(userfield), or custom CDR fields
• CELGenUserEvent() payloads
• AMI ActionID, UserEvent, or variable fields
• AGI commands, environment data, or debug output
• ARI events, application logs, URLs, or query strings
• Queue variables, CRM screen-pop parameters, or recording metadata

The right design keeps the digits out of Asterisk rather than collecting them and trying to scrub every copy later.

See the Asterisk CDR variable documentation and CEL specification.

Recording law and PCI DSS can both apply

PCI DSS does not override laws or regulatory rules governing call recording and retention. At the same time, a recording mandate does not make it acceptable to retain prohibited sensitive authentication data after authorization.

The usual answer is not to record the sensitive segment in the first place. Use pause and resume or a payment service that removes the card-entry media from the recording path while preserving the rest of the call. Document what is omitted, why it is omitted, and how the control is tested.

For US consent requirements, see Call Recording Consent Laws by State. International calls may add privacy, notice, localization, and retention obligations.

What an assessor will want to understand

An assessor or acquirer will usually need more than a screenshot of a successful payment. Be ready to show:

• A current data-flow diagram for voice, signaling, DTMF, recordings, and payment responses
• An inventory of systems that store, process, transmit, or can affect account data
• The exact point where recording is muted and DTMF is intercepted
• Failure behavior when a mute, transfer, or payment request fails
• Evidence that PAN and verification codes do not appear in recordings or logs
• Recording retention, access, encryption, backup, transcription, and deletion controls
• Network segmentation and testing evidence when segmentation is used to reduce scope
• Access controls and audit trails for PBX, recorder, payment, and support systems
• Service-provider responsibility matrices and current Attestations of Compliance
• Change-control and regression tests for PBX, carrier, endpoint, and payment-service updates
• Annual scope confirmation and incident-response procedures

Do not test by entering real card data and then searching production logs. Use processor-approved test credentials and synthetic calls in a controlled environment.

Deployment checklist

Before accepting live phone payments:

1. Map voice, SIP, RTP, DTMF, recording, payment, logging, and backup paths.
2. Confirm the PCI DSS scope and SAQ or ROC method with the acquirer or assessor.
3. Verify the payment provider's current PCI DSS validation and contracted responsibilities.
4. Keep PAN and sensitive authentication data out of Asterisk wherever possible.
5. Test mute and resume timing in both directions.
6. Test in-band, RFC 4733, and SIP INFO behavior.
7. Test transfers, queues, Local channels, conferences, retries, and abandoned calls.
8. Disable unnecessary SIP, RTP, DTMF, AGI, AMI, ARI, CDR, and CEL logging.
9. Check recordings, transcriptions, backups, CDR, CEL, application logs, and packet captures for synthetic test digits.
10. Make card-entry failures stop safely without asking the caller to read the data aloud.
11. Monitor for failed mute actions, unexpected recording state, and diagnostic logging left enabled.
12. Repeat the tests after changes to Asterisk, endpoints, carriers, recorders, or the payment service.

Sources

• PCI DSS v4.0.1 document library
• PCI SSC FAQ 1153: How PCI DSS applies to VoIP
• PCI SSC FAQ 1210: Audio recordings and sensitive authentication data
• PCI SSC FAQ 1229: SAQ C-VT eligibility
• PCI SSC Information Supplement: Protecting Telephone-Based Payment Card Data
• Asterisk MixMonitor documentation
• Asterisk MixMonitorMute AMI action
• Asterisk PJSIP DTMF mode documentation
• Asterisk CDR variables
• Asterisk CEL specification