AI Voice Agent Payments: PCI, DTMF and What to Test

Last verified November 5, 2026, against the PCI Security Standards Council documents linked below. This post is engineering guidance, not compliance or legal advice. Confirm scope decisions with a Qualified Security Assessor (QSA) or your acquirer.

Most teams add payments late in the roadmap. If your agent will take payments over the phone, it looks like one more tool call: collect a card, call the gateway, say "all set." It is not. Every system that hears or stores those digits can deepen your card-data obligations. One retry bug can charge a customer twice.

This guide is for teams that built their own agent inside a larger product, such as a billing portal, POS or membership platform. It covers what the PCI Security Standards Council (PCI SSC) says, three capture designs, leak points, charge safety and a copyable test matrix. For trade detail, see our posts on failed gym payment calls, AI payment arrangement calls and FDCPA risk and escrow and payoff answers. We skip their detail here.

Why AI voice agent payments differ from other tool calls

A scheduling error is annoying. A payment error moves money and creates a regulated data trail. AI phone payment processing is harder than the rest of your agent for three reasons.

First, the input is a long digit string with no redundancy. A single misheard digit gives a different card number, and the caller cannot see the screen. Our alphanumeric capture post covers why digit strings break. Second, the data is toxic. Spoken digits land in audio, transcripts, logs and model prompts by default. Third, the action is hard to undo. A refund is a new transaction, not an undo.

So treat the payment step as its own module with its own tests. General checks like tool call accuracy are necessary but not enough.

What PCI SSC documents say about phone card data

Each claim below comes from a PCI SSC page we opened.

Sensitive authentication data (SAD) after authorization. Card data in call recordings has its own PCI SSC FAQ. FAQ 1210, last updated June 2025, says storing card validation codes in any form of digital audio recording after authorization violates the requirement. If SAD is collected on a call, "every effort must be made to prevent the data from being recorded." Where technology exists to suppress or redact audio during data entry, "it should be enabled." If recording cannot be prevented, the data should be securely deleted immediately after authorization. See the PCI SSC FAQ on audio recordings.

Encryption does not rescue stored SAD. PCI SSC FAQ 1533 says SAD must not be stored after authorization even if encrypted, including where no card number is present. It names card verification codes and PIN blocks as examples. It also notes that card-on-file and recurring transactions do not require the verification code. See the PCI SSC FAQ on SAD storage.

Before authorization is murkier. PCI SSC FAQ 1154 says the standard has no specific rule on how long SAD may be held before authorization. Such data "would need to be protected according to PCI DSS," and "the individual payment brands determine whether SAD is permitted to be stored before authorization." Read the FAQ on pre-authorization storage and ask your acquirer.

Masking is not truncation. PCI SSC FAQ 1146 says the two terms are not interchangeable. Masking hides digits when a number is displayed. The full number may still be stored. Truncation removes digits from stored data. A transcript that shows "•••• 7731" may be masked on screen while the raw digits sit in a log. See the FAQ on masking and truncation.

The telephone supplement. The PCI SSC information supplement "Protecting Telephone-Based Payment Card Data," version 3.0, dated November 2018, is the main guidance on this topic. It says PCI DSS applies to all system components included in or connected to the cardholder data environment. It says that if SAD is received and recorded, the entity must render it unrecoverable after authorization. It also says IVR-type systems should not output cardholder data to logs. And it defines the two DTMF terms we use below. The supplement predates the current standard version, so ask your QSA how it applies today. See the telephone supplement PDF.

We read the supplement's main sections, not every page. None of this tells you whether your design is in scope. Only your assessor can. Scoping a PCI DSS voice agent starts with mapping where digits travel.

Three ways to capture card digits

The supplement's own examples include transferring the caller to an automated system and keypad entry that bypasses the agent. For an AI agent, the same choice shows up as three designs.

Design A: speak the digits to the model. The caller says the number. Speech-to-text hears it, the LLM sees it, and your tool call sends it on. Every hop holds the digits: audio, transcript, prompt, tool arguments, traces. This design has the widest footprint and the worst accuracy, because speech models drop and swap digits.

Design B: keypad tones, masked from the agent. The caller presses digits. The telephony layer collects the tones itself and passes them to the payment processor. The agent only hears a placeholder or silence, and receives a result and a token. One telephony vendor's `` documentation describes this shape: keypad entry only, captured digits redacted from logs, and webhook results that show only the last four digits of the card with the security code redacted. Its docs are not fully consistent about which payment types return the card number field. We only opened that vendor's `` page. It does not say whether the full number ever reaches your server, so ask. See Twilio's Pay docs.

Design C: transfer to a separate payment flow. The agent hands the call to an isolated line or IVR, then takes the caller back with a result. The agent never touches the digits, but the handoff is a new failure surface.

For AI voice agent payments, Design B is the sane default. It also fixes the accuracy problem, since tones are exact. Avoid Design A unless your assessor has signed off on the whole chain.

DTMF masking: what it does and where it leaks

The supplement defines the terms precisely. DTMF suppression removes the tones. DTMF masking replaces them with a random or flat tone. It says storing only suppressed tones rather than original tones can reduce PCI DSS applicability, and that unaltered DTMF tones are fully in scope. It also warns that the first part of the tones may go unmasked, which it calls "DTMF bleed."

That last point is the one to test. Masking is a stream operation with a start time. If your agent's recording or speech-to-text begins before masking engages, the first digit or two can leak into audio. If you start masking on the model's cue ("go ahead and enter your card"), you inherit the model's timing, interruptions and mistakes.

Other places masking fails in practice (our engineering opinion, not from the supplement):

• Caller speaks anyway. Callers say digits aloud while pressing keys. Masking tones does not mute speech.
• Barge-in during the prompt. A caller who interrupts and starts early can beat the "begin masking" event.
• Fallback to speech. An error path that says "tell me your card number instead" quietly switches to Design A.

Our post on testing DTMF navigation covers tone timing and inter-digit gaps. Reuse those harness pieces here.

Where digits leak

Card digits do not stay in one place. Treat each of these as a surface to scan, whether it holds the full primary account number (PAN) or a fragment. For general PII scanning beyond card data, see PII leakage detection.

1. Call recordings. Spoken digits or DTMF bleed. Check with speech-to-text run over the payment segment, then look for digit runs.

2. Transcripts. The speech-to-text output. Regex for digit runs, including spoken forms ("four one one one").

3. Application and trace logs. Tool arguments, webhook bodies, retries, error dumps. This is where the supplement's IVR warning applies to your code.

4. LLM prompts and context. Conversation history sent to the model on every turn. One spoken card number is resent for the rest of the call.

5. Analytics and observability. Event streams, session replays, support tickets created from call summaries.

A Luhn check filters random digit runs, so you flag only strings that could be card numbers.

import re

DIGITS = re.compile(r"(?:\d[ -]?){13,19}")
SPOKEN = {"zero":"0","oh":"0","one":"1","two":"2","three":"3","four":"4",
          "five":"5","six":"6","seven":"7","eight":"8","nine":"9"}

def luhn_ok(s: str) -> bool:
    nums = [int(c) for c in s if c.isdigit()][::-1]
    total = sum(n if i % 2 == 0 else (n * 2 - 9 if n * 2 > 9 else n * 2)
                for i, n in enumerate(nums))
    return len(nums) >= 13 and total % 10 == 0

def normalize_spoken(text: str) -> str:
    return " ".join(SPOKEN.get(w, w) for w in text.lower().split())

def find_pan_like(text: str) -> list[str]:
    hits = []
    for src in (text, normalize_spoken(text)):
        for m in DIGITS.finditer(src):
            if luhn_ok(m.group()):
                hits.append(m.group())
    return hits

This is simplified. It misses digits split across turns ("four one one one... one one one one") and partial numbers. Run it over joined turn text, not single utterances, and treat any hit as an incident. Never paste real card numbers into test fixtures; use the test numbers your processor publishes.

Audio is the hard surface. A transcript scan will not see a masked-tone failure that the transcript never captured. This is the "the referee is deaf" problem: tools that judge only transcripts cannot see DTMF bleed or digits that speech-to-text skipped. Evalgent evaluates from the audio, not only the transcript, and lets you push production recordings for transcription and judging that flags PII leakage. We would not call that a PCI control. It is a way to catch drift between what you configured and what callers actually produce.

Charge safety: amount, idempotency and dropped calls

Security is half the job. The other half is charging the right amount exactly once through your payment gateway.

Confirm the amount before the charge. The agent reads back the amount, the account or invoice and the date, and waits for an explicit yes. Make this a code gate: the tool will not run until a confirmation flag set from the caller's affirmative turn is true. A prompt instruction alone is not a gate. Common failures: "eighty-four" heard as "eighteen four," a yes to a different question, and a partial payment mistaken for a full balance.

Use an idempotency key. Payment APIs support keys so a retry does not create a second charge. For its API v1, one processor's documentation says it saves the status code and body of the first request made with a key, returns that saved response on retries, and compares parameters on a retry, returning an error if they differ. It also notes that keys can be pruned after at least 24 hours. Its newer API v2 retries failed work to completion instead, so check which version you use. See Stripe's idempotent requests docs. Derive the key from the call and the payment intent, for example call ID plus invoice ID plus confirmed amount. Generate the key once per payment intent, store it before calling the gateway, and reuse it on every retry. Do not generate a new random key per attempt, because a retry then looks like a new charge. Keep card data and emails out of the key.

Plan for the dropped call. The dangerous case is the charge that succeeds while the call ends. The agent never says "approved." The caller calls back and pays again. Worked example, illustrative numbers: with 10,000 payment calls a month and 1.5% ending between charge request and confirmation, that is 150 calls where the record and the caller's belief disagree. Without a reconciliation job, some of those become duplicate payments or disputes.

Fixes to test:

• Persist the intent and key before calling the gateway.
• On call end, run a reconciliation step that checks the gateway and updates the record.
• Send the receipt by SMS or email even when the caller dropped, if consent allows.
• On callback, look up open intents for that caller before starting a new charge.

This is the payment version of post-call write-back testing and silent tool failures. For general retry cases, see voice agent tool-calling test cases.

Receipts, verification and limits

A few design choices reduce harm without adding scope.

• Tokenization over storage. Store the token, not the card. Keep a processor token, the last four digits and the brand. PCI SSC FAQ 1533 notes card-on-file flows do not need the verification code, so never keep it.
• Say what was charged, with masked digits. Read back only the last four digits. Remember FAQ 1146: masked display is not the same as truncated storage.
• Verify before a stored-card charge. If the agent charges a saved card, require identity checks the business owns, such as account PIN or last invoice amount.
• Set limits. Cap the amount per call and the number of attempts per caller per day. Escalate above the cap to a human.
• Extra authentication. We did not verify how 3-D Secure applies to phone orders, so we leave it out. Ask your processor.
• Regulated debt calls. Payment promises on collections calls bring other rules. See our FDCPA post.

A test matrix for payment calls

Run these AI voice agent payments tests on every prompt, model and telephony change. Each row has one pass condition.

A copyable scenario shape for your harness:

- id: pay-drop-after-charge
  caller: {accent: us-south, pace: fast, noise: cafe}
  steps:
    - say: "I want to pay the full balance"
    - agent_reads_back: {amount: "84.00", last4_not_spoken: true}
    - say: "yes"
    - keypad: "<test card from processor docs>"
    - hangup_after: charge_request_sent
  expect:
    gateway_charges: 1
    record_status: paid
    receipt_sent: true
    leak_scan: {recording: clean, transcript: clean, logs: clean, prompts: clean}

Rows 2, 3 and 12 depend on audio, so a transcript-only judge will pass them wrongly. Evalgent generates test scenarios from the agent's prompt and flows, and its caller profiles cover accent, speech pace, interruption level, response delay and background noise. That is the shape of rows 3 and 12. It also runs custom metrics on every call, which is where a per-call leak check belongs. For general harness design, see AI voice agent testing and STT entity accuracy.

How to test a payment voice agent before it ships

1. Pick the capture design and write it down. Name where digits travel and which systems see them. Get your QSA or acquirer to confirm scope.

2. Build a fixture set. Use processor test cards only. Include declines, a Luhn failure and a three-attempt lockout.

3. Run the matrix above across accents, pace, noise and interruptions. Repeat each row several times, since voice failures vary run to run.

4. Scan every surface. After each run, scan the recording segment, transcript, logs, model prompts and analytics events with the scan above.

5. Inject failures. Drop the call at each step, time out the gateway, return a decline, and replay a retry.

6. Reconcile. Compare the gateway ledger with your records and the receipts sent. Any mismatch is a bug.

7. Gate releases. Block any prompt or model change when a leak scan hits or a duplicate charge appears.

8. Monitor in production. Sample real calls for leaks and charge-versus-record drift. See production monitoring and recording consent.

Frequently asked questions

Can an AI voice agent take credit card payments over the phone?

Yes, technically. The question is design. The safer pattern collects digits as keypad tones outside the model, returns a processor token, and confirms the amount before charging. Speaking digits to the model works, but it widens where card data lives. Confirm your design with a QSA or acquirer.

Is it PCI compliant for an AI voice agent to hear card numbers?

We cannot say for your setup. PCI SSC's telephone supplement says PCI DSS applies to system components in or connected to the cardholder data environment, and spoken data brings systems into scope. Whether your agent, speech-to-text and model provider are in scope is a question for your assessor, not a blog post.

How do you stop card numbers appearing in call transcripts?

Keep digits out of the speech path by using masked keypad entry, then scan transcripts, logs and prompts for Luhn-valid digit runs. Transcript redaction after the fact helps, but it can leave raw copies elsewhere. Test with callers who speak digits while keying them, since that is the common leak.

What is DTMF masking?

DTMF masking replaces keypad tones with a random or flat tone so the recording cannot reveal digits. PCI SSC's supplement distinguishes it from suppression, which removes the tones. It also describes "DTMF bleed," where the start of the tones goes unmasked, and says it must not be present. Test the first digit explicitly.

Should an AI voice agent pause call recording during payment?

PCI SSC FAQ 1210 says to enable suppression or redaction where it exists. The supplement notes manual pause and resume recording relies on the agent remembering to pause. That risk carries over if a model decides when to pause. Prefer automatic masking tied to the capture step, and test it.

What happens if the call drops after the card is charged?

The charge may stand while your record shows unpaid. Persist the payment intent and idempotency key first, reconcile with the gateway when the call ends, and send a receipt anyway. On callback, look for open intents before starting a new charge. Test by hanging up at every step.

How do you test a voice agent that takes payments?

Run a matrix covering keypad entry, spoken digits, interruptions, wrong digits, amount mismatches, timeouts, retries and dropped calls. After each run, scan recordings, transcripts, logs and prompts for card-like digits, and reconcile the gateway ledger against your records. Repeat across accents and noise.

Can a voice agent store a card security code?

No. PCI SSC FAQ 1533 says sensitive authentication data, including card verification codes, must not be stored after authorization, even if encrypted. FAQ 1210 applies this to audio recordings. Card-on-file and recurring payments do not need the code, so keep only a token.

The bottom line

AI voice agent payments should flow only through a design where the model never hears the digits, and every recording, transcript, log and prompt is scanned to prove it. Charge once, confirm the amount in code, and test every dropped call, because the failures that cost money are the ones the caller never hears.