Voice AI Payments: 14 Data-Exposure Tests Before Any Card Is Entered

A voice agent should never become the place where a caller dictates a card number. Before a telephone-payment journey goes live, make the payment path demonstrate that the general-purpose speech model, transcript, call recording, analytics, observability tools, support console and downstream CRM do not receive account data or sensitive authentication data. The best acceptance result is not “the model knows how to redact”; it is that the design routes entry through a separate, assessed capture path and the team can prove what each component received.

The production voice AI guide explains how to define a voice workflow, verify its final action and hand a call to a person when a case falls outside the approved scope. This article applies that operational discipline to a narrower, higher-risk boundary: card entry over the telephone. It adds a reproducible fourteen-case synthetic exposure test. No payment cards, live callers, vendor systems, recordings, or production environments were used. The cases are a buyer-side design and test fixture, not a PCI assessment or a certification.

Do not let a general-purpose voice AI collect or repeat a primary account number, expiry date, security code, PIN, or full magnetic-stripe equivalent. The default safe design is a separately controlled payment capture flow: the caller enters data through a validated keypad or payment IVR, or moves to a hosted payment page, while the conversational agent receives only a deliberately minimized status such as “payment authorized,” “payment declined,” or “try another method.” The exact flow must be assessed against the payment provider, telephony configuration, PCI DSS requirements and local recording law.

A suppression, masking, or -and-resume feature is not accepted because a product page says “PCI compliant.” It must pass tests across caller audio, agent audio, recording, transcript, model request, tool arguments, logs, support interface, transfer, retry and export. Ask your payment assessor to identify current requirements and scope for this exact topology. A feature name is not evidence that a downstream recorder, transcript or support tool stopped receiving the input.

If the vendor cannot explain which components receive data, cannot produce trace evidence for a synthetic payment, or cannot guarantee a staffed non-AI fallback, keep card collection out of the voice agent. You can still automate payment reminders, direct the caller into a secure IVR, or offer a link to a hosted payment page, provided those actions are separately approved and tested.

Speech recognition and language models are probabilistic transforms. Redaction is a downstream behavior; it does not establish that the source audio was never captured, that intermediate text was not stored, or that an exception path did not bypass masking. A system can produce a clean customer-facing transcript and still have sent raw audio to speech recognition, a provider’s debug trace, a vendor support tool or a third-party analytics service. The control objective is data-flow exclusion before the model and each nonessential recorder, not cosmetic removal from the final answer.

This distinction matters because calls have parallel paths. A caller can be audible in one media stream while a telephony gateway sends DTMF events in another. A recording system may tap the stream upstream of a suppression service. A transcript service may use a separate copy. A warm transfer can open a new recording segment. A retry after a timeout can replay a previous audio buffer. Each connection can have its own configuration, credentials, retention and failure behavior. A design diagram must show all of them.

The test matrix treats the first DTMF event, transfer boundary, recording tap and /resume edge as high-risk checkpoints. That is a test-design choice, not a claim that one masking implementation meets a standard. A supplier must demonstrate the exact version and topology you operate; an assessor must determine applicable scope.

The security question is not whether the conversational model can infer a card number from a text prompt. It is whether any component outside the approved payment capture boundary can observe, store, replay, derive or retrieve the sensitive input. For each component, ask for the data class received, the time window, the storage and export path, the permitted readers, and what happens when a downstream dependency is unavailable.

Define the flow before testing it. A practical reference model has five zones. The conversational zone handles intent, explanations and non-sensitive routing. The payment zone captures sensitive data inside a validated payment environment. The connector zone carries only narrow, typed commands such as “start payment session” or “read payment status.” The evidence zone stores minimal operational events with correlation identifiers that are not card data. The human support zone provides controlled troubleshooting without revealing the account data to the agent or support staff.

flowchart LR
  Caller -->|ordinary speech| VoiceAgent
  VoiceAgent -->|start session, opaque id| PaymentRouter
  Caller -->|keypad input| SecureCapture
  SecureCapture -->|tokenized authorization request| Processor
  Processor -->|status only| PaymentRouter
  PaymentRouter -->|approved / declined / retry| VoiceAgent
  VoiceAgent -->|minimal outcome| CRM
  VoiceAgent -. raw card audio blocked .-> Recording
  VoiceAgent -. raw digits blocked .-> Transcript
  SecureCapture -. PAN and SAD excluded .-> Analytics

The diagram is only a design target. It does not prove the wiring. Ask the vendor to map every real service, subprocessor, API, storage location and operator interface to these zones. Include carrier, SIP trunk, contact-center platform, speech-to-text, voice activity detection, agent orchestration, model provider, tool gateway, payment provider, call recorder, quality-monitoring vendor, data warehouse and backups. If a feature changes providers by region or plan, record that variant as a separate route.

Minimize the conversational agent’s authority as well as its data. It may create a payment session, state that the transaction was accepted or declined, and offer an approved next step. It should not retrieve full account details, read a security code aloud, change the amount, retry indefinitely, or create a payment link to a caller-supplied destination. A narrow tool schema reduces the impact of a mistaken interpretation or a malicious instruction inside a call. CISA’s secure-by-design guidance is general software-security material, not payment validation, but its emphasis on secure defaults as a product responsibility is relevant: the buyer should not compensate for an unsafe default with prompt instructions alone. See CISA Secure by Design.

Use a test environment, synthetic caller audio and provider test tokens. Never put live PAN, CVV, PIN, track data or a real customer’s recording into a test script, issue tracker, prompt, dashboard, screenshot or analytics event. The matrix is intentionally about observable exposure, not whether the conversation sounds polished. Record a case as passed only when the expected behavior and the supporting artifact both exist.

The expected-behavior column is not a universal implementation prescription. A payment provider may use a different secure route. What matters is that the organization writes down its own expected result, verifies it in the deployed topology and has a traceable exception process. A vendor may propose an alternate architecture; require equivalent evidence for every data path rather than accepting an exception by name.

Start with a written scope. Name the business owner, payment assessor or security lead, telephony owner, privacy owner, vendor contact and person authorized to stop the test. Set a non-production test window and list the exact service versions, regional endpoints, recording configuration, AI model, transcription path, payment provider and integrations. Freeze these versions during the run. If any component changes, mark affected cases stale and repeat them.

Create synthetic fixtures that cannot be mistaken for real credentials. Use labels such as TEST_CARD_FIELD_A and provider-issued test tokens, not a syntactically valid account number or security code. Confirm that the provider explicitly supports the chosen test mode. Avoid a production billing account or real caller number. Keep the test itself out of a public demo environment. The aim is to trace whether a marker or test event crosses a boundary, not to create a realistic card credential that might accidentally be accepted or retained.

For each scenario, capture four items: stimulus, expected state transition, observed behavior and evidence artifact. Store the artifact in a restricted location. Use an opaque case identifier, not caller identity or payment value. If raw test audio is needed to inspect routing, use a synthetic recording and delete it according to a short, documented test-retention period. Do not paste raw audio or transcripts into an LLM-based ticketing assistant to ask it to analyze the incident; that creates a new data path.

Run cases from the caller’s perspective and inspect both ends. A green “payment complete” prompt does not prove a recording tap was protected. Compare the synthetic sequence at the input boundary with recording, transcript, model request, tool payload, analytics export and support view. Ask for a test endpoint or redacted trace. If the vendor cannot provide a trace without exposing real data, resolve that design gap before launch.

Test success and failure paths. A control that works only when the payment provider responds quickly is not a full control. Force timeouts, rejected sessions, carrier reconnects, call holds, transfers, retries, agent restarts and late webhooks. The expected result for an ambiguous payment state is “verify before retry,” not “try until the caller hears approval.” The idempotency key or payment-session identifier should be visible in evidence without exposing account details.

Separate critical failures from quality improvements. If raw account data or sensitive authentication data reaches an unapproved AI, transcript, recorder, support interface, export or backup, the case fails. A pleasant voice, fast response, high speech-recognition accuracy or strong business outcome cannot offset that failure. If the system cannot show whether a path was exposed, treat it as unproven rather than pass.

For noncritical usability issues, record a separate score: time to payment handoff, repeated prompts, completion of non-sensitive intents, caller abandonment in the synthetic run, or staff effort. These are local operational measures. They do not establish security or PCI scope. Define denominator and measurement window before the pilot, and keep decisions separate: security acceptance is a hard gate; usability determines whether the safe route is workable.

This separation prevents a procurement mistake: rolling a red security case into an average score. If thirteen cases pass and one leaks input into a recording, the result is not “93% compliant.” It is a failed release gate with one known exposure path. Block the path, fix the design and rerun the affected case plus dependent cases.

A case should include a versioned expected result, not just a tester’s recollection. Example: “For route build R7, when a synthetic keypad event is entered during payment state, transcription receives no audio frames for the sensitive interval; recording contains only a constant replacement tone; agent receives payment_pending only.” Attach a timestamped log and version identifier. This record lets later reviewers reconstruct what was tested and whether the current production configuration still matches it.

A defensible proof pack records route version, service build, test case ID, environment, configuration hash, start/end time, tester role, expected result, observed state, evidence location, exception owner and release decision. Log tool names, permission decisions, session transitions and payment outcome codes only when values are minimized and approved. Use an opaque test-session reference that cannot be reversed into card details by ordinary operators.

Do not put PAN, cardholder name, security code, PIN, spoken digits, original DTMF tones or sensitive audio into general-purpose observability. Keep sensitive fields out of URL parameters, event names, exception messages, model context, span attributes, screenshots and request/response dumps. A “temporary debug log” is still a data store. Inventory vendor support access, feature flags, developer traces, dead-letter queues, crash reports, call-quality analytics, data-lake copies, backups and exports.

For this test pack, define a prohibited-data inventory with your assessor before the run. Identify the payment values and audio forms that must stay outside general-purpose speech, model, transcript, observability and support systems. The fixture labels PAN, security codes, PIN values, original keypad tones and sensitive audio as forbidden outside the approved capture route; that is a conservative test boundary, not a legal interpretation.

Retention is separate from suppression. For each record type, identify the legal/business purpose, owner, systems, retention period, deletion mechanism, backup behavior and evidence of deletion. A vendor statement that “data is not used for training” says nothing by itself about transient buffering, abuse monitoring, support access, regional replication, subprocessors or backups. Ask for each one as a separate question and capture the contractual and technical answer.

Buyers hear claims that sound similar but are not equivalent: “the agent cannot hear card data,” “the call is d,” “the recording is redacted,” “the transcript is filtered,” “the payment provider is PCI compliant,” and “the whole setup is out of scope.” Each refers to a different boundary. A compliant payment provider does not automatically make a merchant’s telephony, model, recording or support stack compliant. A transcript filter does not prove raw audio never reached transcription. A d recorder does not prove a separate media tap stopped. A hosted payment page does not prove the conversational agent cannot access its state through a broad integration.

Product claims are not interchangeable: “the agent cannot hear card data,” “the call is d,” “the recording is redacted,” “the transcript is filtered,” “the processor is PCI compliant,” and “the whole setup is out of scope” describe different boundaries. Ask what exact subsystem each statement covers and request an observable trace. A public r/pcicompliance question illustrates the operational tension: one team could not or delete certain recordings and asked whether keypad masking or online payment was workable. That thread is anecdotal and its replies are not standards; it is useful as a problem statement, not proof that a particular control works. See the phone-payment discussion.

Research on voice assistants and telephony offers a different warning. A 2020 paper demonstrated a lab data-exfiltration path using inaudible audio, a voice assistant and a phone channel. It involved a crafted setup and an infected nearby computer; it is not evidence that a current payment vendor is vulnerable or that ordinary tones can be stolen in the same way. It supports a narrower design principle: audio transformations and telephony channels can behave in unintuitive ways, so inspect the actual signal path rather than assuming the model did not receive it because a cleaned transcript looks safe. See the research paper.

Consulting surveys can provide governance context but cannot validate a technical control. EY’s 2026 US AI Risk and Governance Survey reports views from more than 200 senior AI decision-makers at publicly traded US companies with at least $1 billion in annual revenue. It is not a sample of telephone-payment systems and does not test DTMF controls. Use it to motivate named ownership and recurring assurance, not to estimate the security performance of a voice agent. See EY’s survey summary.

This Node.js example checks a synthetic evidence manifest. It intentionally does not parse or mask live card data. It verifies that a run contains all fourteen case identifiers, each case has an evidence reference, and critical failures block release. Adapt the schema; this is not a PCI scanner or proof that systems are safe.

const REQUIRED = Array.from({ length: 14 }, (_, i) => `PAY-${String(i + 1).padStart(2, '0')}`);
const critical = new Set(['PAY-01','PAY-02','PAY-03','PAY-04','PAY-05','PAY-06','PAY-07','PAY-11','PAY-12','PAY-13','PAY-14']);
function releaseDecision(manifest) {
  const byId = new Map((manifest.cases || []).map(item => [item.id, item]));
  const missing = REQUIRED.filter(id => !byId.has(id));
  const noEvidence = REQUIRED.filter(id => byId.has(id) && !byId.get(id).evidenceRef);
  const criticalFailures = [...critical].filter(id => byId.get(id)?.result !== 'pass');
  const invalidResult = REQUIRED.filter(id => byId.has(id) && !['pass','fail','unproven'].includes(byId.get(id).result));
  return { release: !missing.length && !noEvidence.length && !criticalFailures.length && !invalidResult.length,
    missing, noEvidence, criticalFailures, invalidResult };
}
const result = releaseDecision(JSON.parse(require('fs').readFileSync(process.argv[2], 'utf8')));
console.log(JSON.stringify(result, null, 2));
process.exitCode = result.release ? 0 : 1;

The critical set is conservative and should be reviewed by the payment assessor and control owners. The code cannot inspect whether evidence is truthful, whether an audio route stopped, whether a provider token is valid, or whether a system copied data elsewhere. It enforces a decision-recording discipline; it does not perform a security test. A more mature harness can compare version identifiers, configuration hashes and signed test events, but it still needs independent observations at system boundaries.

Keep the manifest outside the transaction data path. It should contain case IDs, result labels and links to access-controlled evidence, never a real card value or raw sensitive recording. A test runner can fail closed on missing evidence without ingesting the content it is meant to protect. The release ledger needs to know that a test occurred and where proof is held, not the customer’s payment details.

Ask the vendor to draw the call path for your account, region and subscription tier. Ask exactly where speech is transcribed, where recordings are tapped, which services receive audio, what reaches the language model, and how DTMF is handled before and after the payment handoff. Ask which data is in scope for the vendor’s PCI assessment and which remains your responsibility. Request current validation evidence and confirm with your assessor how it applies to the actual service and integration.

Ask what the AI receives after a payment attempt. The acceptable answer should be a narrow state or opaque identifier, not full card values. Ask whether failure traces, prompts, evaluation datasets or quality review can include audio or transcripts. Can support staff replay audio, query transcripts or export logs? Which role is needed, who approves access, and is every access recorded? Request the subprocessors list, region map, retention schedule, deletion behavior, backup lifecycle and incident notification process.

Ask the vendor to run the fourteen cases on a test route that mirrors production. Require the versioned configuration, case-by-case evidence, observed exceptions, and written rationale for anything marked “not applicable.” Ask how changes to telephony route, speech vendor, model, recorder or prompt trigger retesting. If a case cannot be observed because the platform is a black box, classify it as unproven and escalate; do not infer safety from the absence of a visible error.

A supplier may show a third-party certificate. That is useful input, not a substitute for determining the exact service, deployment, caller route and data-flow boundary. Scope changes with configuration. A payment processor can be compliant while the merchant still owns routing, access control, call-center operations and evidence. Avoid contract language that promises “PCI compliance” without naming assessed service, current evidence, responsibility matrix, customer configuration and limits.

Package the route diagram, data inventory, responsibility matrix, current assessment evidence, configuration versions, fourteen-case results, synthetic-only test declaration, redacted logs, unresolved exceptions, owner and due date, retention/deletion proof, and release decision. Provide an index linking each control claim to the component, case, evidence owner and status. Avoid an unstructured folder of screenshots; reviewers need a trace from claim to artifact.

Use four outcomes. Pass means expected behavior was observed and evidence is sufficient. Fail means behavior contradicted expectation. Unproven means telemetry or access was insufficient. Not applicable means the component does not exist in this route and the reason is documented. “Vendor confirmed” is not a result category. An unknown control cannot become a pass because a salesperson emailed it.

Set an expiry for evidence. Tests remain useful only while route and systems remain materially unchanged. Repeat affected cases after changes to model provider, speech recognition, carrier, recording vendor, suppression, payment gateway, tool schema, support workflow, retention, or data region. An incident, exposure alert or unexplained trace should invalidate the relevant evidence immediately. Repeating tests is a practical assurance cycle, not a claim that tests alone provide compliance.

Can payment data be excluded from ordinary speech and model context?
  No -> do not launch card collection in the voice agent.
  Yes -> Is the separate route validated and visible in traces?
          No -> keep it in test and resolve the evidence gap.
          Yes -> Did all critical synthetic cases pass on this build?
                  No -> block release, fix, rerun affected and dependent cases.
                  Yes -> Are retention, access, transfer, retry and deletion owners named?
                          No -> hold release.
                          Yes -> assessor and business owner review the proof pack;
                                 release a bounded pilot with monitoring and rollback.

This sequence is stricter than a weighted product score. It does not say which vendor is best, whether a particular implementation is compliant, or whether a payment should be automated in a jurisdiction. It prevents a smooth demonstration from being mistaken for a data-boundary test.

Research and drafting date: 10 November 2026. The original asset is a designed fourteen-case synthetic acceptance matrix and release-evidence fixture. Research included CISA secure-by-design guidance, a published controlled research demonstration involving voice assistants and telephony, an EY survey summary, the Vocalis public banking/fintech voice-agent page, and a public r/pcicompliance discussion about constrained call-recording and phone-payment options. Search snippets and supplier claims were not treated as validation. Search did not surface a directly relevant, accessible video with a transcript suitable for a technical claim, so none is cited. This is a research limit, not evidence that no such video exists.

No voice model, processor, DTMF product, recorder, route, support console or production environment was tested. No human participants or customer data were included. The matrix is a proposed buyer-side test, not a statistically sampled benchmark. No original performance or security rates were measured or calculated. The 2020 paper is a specific experiment, not evidence of a current product vulnerability. EY’s survey describes a US executive sample, not payment controls. A marketplace listing describes a supplier claim and does not establish the security or compliance of a buyer’s deployment.

Applicable payment requirements, assessor expectations, privacy rules and recording laws depend on current versions, jurisdiction, scope and implementation. Confirm the active standard and requirements with your payment assessor. This decision protocol is not legal advice, a QSA opinion, an attestation or a promise that any system is out of scope.