Can an AI Voice Agent Take Card Payments?

Technically yes, and almost always you should not. A spoken card number lands in at least four stores a keypad press never reaches: the speech-to-text transcript, the model context window, the platform system logs and the call recording. The PCI SSC’s 2018 telephone-payments supplement puts spoken account data in PCI DSS scope. Use a PCI-validated DTMF masking service.

That category has real vendors in it — PCI Pal, Eckoh and Sycurio sell DTMF masking, and Twilio sells a card-capture verb inside a voice product it states is PCI DSS Level 1 compliant. Zian AI is not one of those vendors and has published no PCI DSS attestation; this page is scope analysis, not a compliance claim. What none of them document well is which components of an AI voice stack enter PCI DSS scope. Every statement below is quoted from the PCI Security Standards Council’s own document or the named vendor’s own docs, dated.

What “taking a card payment” means in PCI DSS terms

The governing text is the PCI SSC’s Information Supplement: Protecting Telephone-Based Payment Card Data, version 3.0, November 2018. It carries its own qualifier on every page: The intent of this document is to provide supplemental information. Information provided here does not replace or supersede requirements in any PCI SSC Standard. It is scope guidance, not the standard.

Which version this page is talking about, checked 12 September 2026. Version 3.0 is still the current edition of the supplement — the only Request for Comment the PCI SSC has published on it ran 28 February to 31 March 2017 and produced this edition. The standard underneath it has moved, though: the PCI SSC published PCI DSS v4.0.1 on 11 June 2024 and states that after 31 December 2024 it is the only active version of the standard supported by PCI SSC. So the supplement’s requirement numbers are stale — it points at Requirement 3.4 for rendering stored PAN unreadable, which is Requirement 3.5.1 in v4.0.1 — while its scope reasoning is not. This page uses it for scope reasoning only, and quotes no requirement numbers from it.

Section 2.3 gives the rule in two sentences. PCI DSS applies to all system components included in or connected to the cardholder data environment (CDE). Then, decisively: Accepting spoken account data over the telephone puts personnel, the technology used, and the infrastructure to which that technology is connected into scope of PCI DSS.

The boundary — where it stops. Section 7.1 says a telecommunications company providing just the communication link would not be considered a service provider for that service, and that such a carrier may not have any PCI DSS responsibilities. Note the hedge: not out of the picture, just not a service provider — the same section requires the entity to treat that carrier network as a public or untrusted network and to protect account data crossing it. Section 7.1 then closes the gap: Carriers or other entities providing services such as call center services, call-recording technologies, call-recording storage … or other functionality that impacts account data would be considered service providers for PCI DSS purposes. An AI voice platform transcribes, records and stores. It is on the second list.

Every component that enters scope the moment card digits are spoken

The component list is not ours. It is the published pipeline in Vapi’s Data Flow documentation, read 12 September 2026: transport, speech-to-text transcriber, a proprietary orchestration layer, the language model, text-to-speech, then four artifacts — call recordings, transcripts, call logs and usage metrics.

Component	Caller speaks the digits	Digits clamped upstream	What takes it out of scope
Carrier / SIP trunk	Carries PAN audio	Carries masked tones	Not a service provider for that service, if it supplies the link and nothing else
Telephony platform	In scope — transmits account data	In scope, holds no recoverable digits	Vendor validation for that product
Speech-to-text transcriber	In scope. Turns the PAN into searchable text	Never receives digits	Nothing, once it has heard them
Orchestration (endpointing, barge-in)	Processes audio; Vapi documents this as ephemeral	Processes masked audio	Documented non-persistence
LLM context window	In scope. PAN sits in the prompt and every later turn	Never populated	Nothing — you cannot unsend a prompt
Text-to-speech read-back	In scope. Re-voices the PAN into the audio	Last four only	Never read the full number aloud
Transcript store	In scope. Retained per platform default	Empty of account data	Disable transcripts for that leg
Call recording and its bucket	In scope. PAN and security code in audio	Flat tones only	Suppression narrows which requirements apply; only not recording the leg removes it
Platform system logs	In scope and usually not yours to redirect	No digits to leak	Only the vendor can descope this
Observability traces / eval store	In scope. Traces replay the context window	Nothing sensitive captured	Exclude the payment leg from tracing
CRM / ticket write-back	In scope if the agent writes digits to a field	Token or last four	Token only, never the PAN

Two rows have no useful remedy. Once a transcriber has produced text and an LLM has seen a prompt, the digits exist outside the audio path, and deleting the recording does nothing about either. Read “no remedy” precisely: it means nothing takes them back out of scope after the fact. You can still run them inside a compliant environment with providers that carry their own validation — that is exactly what Twilio’s Conversation Relay guidance describes, and it is covered below.

The four-store rule

The four-store rule: a spoken card number lands in at least four stores a keypad press never reaches — the speech-to-text transcript, the model context window, the platform system logs, and the call recording. A control that only addresses the recording has addressed one of four.

The context window is the store teams forget, because it feels ephemeral and is not: it is replayed into every later turn, forwarded on handoff, and captured by whatever tracing is enabled. Vapi’s PCI documentation says handoffs default to forwarding everything — By default, handoffs use contextEngineeringPlan type all, which transfers the entire conversation history, tool call results included.

System logs are the least discussed. Vapi’s data-flow page states that System Logs are strictly internal to Vapi and are never shared with customers or uploaded to custom storage buckets. That is a normal design, and it means that if card digits reach them, only the vendor can remove them. Our post on what an AI agent trace actually records walks the same layer from the operations side.

Why DTMF clamping works and speech does not

DTMF masking is the only mature control here, and it works because the digits never become data. Eckoh’s DTMF masking page, read 12 September 2026, describes the mechanism: DTMF suppression and/or masking simply replaces the audio tone value with a single mono-tone preventing downstream systems from being exposed to this sensitive data. Eckoh states on the same page that Every Eckoh service is built on secure infrastructure, audited to PCI DSS Level 1 and SOC 2 standards. PCI Pal’s DTMF masking page names the constraint that matters most here: In DTMF masking, the consumer enters their card number, expiry date and security code using their telephone keypad, rather than speaking their payment card data.

Section 6.4.1 explains both the descoping and its limit. Clamped: Storing only suppressed tones rather than original DTMF tones can reduce applicability of PCI DSS requirements for call recordings. Unclamped: Where the DTMF tones are not replaced with flat, token, or random sounds, the specific numbers associated with each key press can be recovered, meaning that PAN and SAD is retrievable and the unaltered DTMF tones are fully in scope for applicable PCI DSS requirements.

Keep the carve-out in the same section, because it is the part vendors leave out: Even if only suppressed tones are stored and are not subject to Requirement 3.4, recording systems may still be in scope for other PCI DSS requirements if they have connectivity to the systems where CHD is present. Suppression narrows which requirements apply to the recordings. It does not on its own lift the recording system out of scope.

There is a precondition nobody mentions: the caller must be able to send DTMF and your agent must receive it. If keypresses are already unreliable on your calls, clamping will not save you — read why DTMF digits go missing on AI voice calls and fix the transport first.

Why pause-and-resume is the weakest control on the list

Teams reach for pause-and-resume because it is free and already in the contact-centre software. The PCI SSC is direct about its limit in section 6.5.1: whilst a properly implemented pause-and-resume solution could reduce applicability of PCI DSS by taking the call-recording and storage systems out of scope, the technology does not reduce PCI DSS applicability to the agent, the agent desktop environment, or any other systems in the telephone environment. Section 6.4 adds the consequence: the agent will hear all of the CHD and SAD. In an AI pipeline, the agent means the transcriber and the model, and pausing the recorder does not pause them.

The resume test — two questions. First: apart from the recorder, can any component reconstruct the digits? If yes, pause-and-resume has reduced nothing. Second: is the pause triggered by a machine event or by someone remembering? The supplement recommends that entities using pause-and-resume verify that call recordings do not contain cardholder data or sensitive authentication data on a regular basis, and names the cadence it prefers: weekly. A control that needs a weekly audit to prove it worked is not really a control.

Can my AI agent read the card number back to confirm it?

No, and this is the most common way a compliant design gets broken by a well-meaning prompt. Reading the number back re-voices the PAN into the audio path, putting the text-to-speech provider, the recording and the transcript straight back into scope.

Vapi’s PCI Compliance documentation, read 12 September 2026, shows the safe version in its own payment-squad example: the payment assistant collects the card through a keypad input plan rather than speech, runs with recording, logging and transcripts disabled, and passes forward only an extracted lastFourDigits variable. Last four, never the PAN.

When “just send me a payment link” is the right answer

For most Australian businesses running an AI receptionist or appointment setter, this is the correct answer and it costs nothing. The agent handles the conversation, then sends a hosted payment page by SMS and stays on the line. No component in your voice stack meets a card number.

Section 6.3 covers the pattern: Sending a link to an online secure payment system to a customer via a messaging service may be considered the same as an e-commerce entity using redirection to third-party payment pages. The impact of such a system on the entity’s PCI DSS scope would need to be evaluated. Read the qualifier: evaluated, not eliminated. Stripe’s Share a payment link docs, read 12 September 2026, list text messages among the channels for a Stripe-hosted page.

One line from section 5.2 decides whether this is safe or a breach: Never send CHD over an unencrypted, end-user messaging medium such as chat, social media, SMS (short message service)/text, or e-mail, or other non-encrypted communication channel. Sending a link by SMS is the pattern. Sending or collecting a card number by SMS is not.

Who in the chain actually holds the attestation

Twilio states on its PCI compliance page that Twilio Programmable Voice is Payment Card Industry Data Security Standard (PCI DSS) Level 1 compliant — the most rigorous certification level available. Its <Pay> reference notes the verb supports dtmf only and that <Pay> redacts all digits captured from the logs. You cannot speak a number into it. That is the point.

Twilio’s PCI workflows guide is the most useful page published by anyone on the AI layer: Conversation Relay supports PCI-compliant Voice workflows when configured with PCI-compliant TTS and transcription providers. Not all TTS providers and transcription providers available for Conversation Relay are guaranteed to be PCI compliant. It adds that Native and Marketplace transcriptions are not available when PCI Mode is enabled, that Conversation Intelligence (classic) is not PCI compliant and must not be enabled in Conversation Relay workflows that are subject to PCI, and — plan for this — that Once PCI Mode is enabled, it cannot be disabled for that Account.

Vapi documents PCI as a per-assistant toggle, noting that The default value for compliancePlan.pciEnabled is false and that By default, Vapi enables call recording, logging, and transcription features to enhance service quality. Retell AI sits differently: its security and compliance page says Retell maintains the following certifications and attestations and lists HIPAA, SOC 2 Type 1 and Type 2, and GDPR. PCI DSS is not among them, and its documentation index — 337 pages as at 12 September 2026 — lists no PCI page. Scope that narrowly: it is the absence of a PCI DSS attestation from the vendor’s own certifications list, not a claim that Retell publishes nothing on the subject and not a claim it cannot sit in a payment flow. It is a signal about the role a platform is designed to play, not a criticism. Its data retention page also states the default you would change anyway: By default, data is kept indefinitely (no automatic deletion).

Section 7.1 says where responsibility stops: The use of a third-party service provider does not relieve the entity of ultimate responsibility for its own PCI DSS compliance. Section 2.6 says who decides: entities should understand their reporting obligations before scoping, by consulting with their acquirer or the payment brands to confirm their validation requirements. A qualified security assessor determines your scope. A blog post, including this one, does not.

What this page is not claiming

Zian AI has published no PCI DSS attestation, and nothing above should be read as one. We build autonomous AI sales agents, and the design we would use where a card must be taken is the one described here: the agent runs the conversation and the qualification, and card capture goes to a PCI-validated party, either a masked DTMF leg or a hosted payment link. The same reasoning applied elsewhere is in our note on compliance architecture for AI agents in regulated industries.

Frequently asked questions

Is it illegal for an AI voice agent to take a spoken card number?

No. PCI DSS is a contractual standard enforced by the card brands and your acquirer, not legislation. Taking spoken digits is permitted; it simply pulls the transcriber, the model, the logs and the recording into your cardholder data environment, which is expensive to secure and to assess. Section 2.6 of the PCI Security Standards Council supplement tells entities to confirm validation requirements with their acquirer or the payment brands before scoping anything.

Does disabling call recording make my AI voice agent PCI compliant?

No. Recording is one of four stores. The PCI SSC telephone-payments supplement, section 6.5.1, states that a properly implemented pause-and-resume solution could take call-recording and storage systems out of scope but does not reduce PCI DSS applicability to the agent, the agent desktop environment, or any other systems in the telephone environment. In an AI stack the transcript and the model context window are untouched.

Which is safer, DTMF masking or a payment link by SMS?

Both keep card data out of your stack. Masking keeps the caller on the line and suits cases where abandonment matters or the caller has no smartphone. A hosted link is cheaper and suits most small businesses. Section 5.2 of the same supplement separates a safe link flow from an unsafe one: never send cardholder data over an unencrypted end-user messaging medium such as SMS. The link is fine. The number is not.

Can I just tell the model in the prompt not to store the card number?

No. A prompt instruction is not a control. By the time the model can be instructed about the digits, the transcriber has already produced them as text and the context window already contains them. Scope follows where account data actually travels and rests, not what the system prompt asks for.

Who decides whether my setup is in scope?

A qualified security assessor or an internal security assessor, working from your documented call flow and your acquirer requirements. The PCI SSC document lists QSAs and ISAs among its intended audience because scope decisions are theirs. Build the data-flow diagram first, mark where each provider responsibility starts and ends, and take that to the assessor.

Who owns each figure on this page

Quoted claim	Owner (organisation)	Source URL	Date checked
Spoken account data in scope; pause-and-resume limits; DTMF suppression; link by messaging; never send CHD by SMS; acquirer confirms validation	PCI Security Standards Council	Protecting Telephone-Based Payment Card Data v3.0, ss 2.3, 2.6, 5.2, 6.3, 6.4, 6.4.1, 6.5.1, 7.1	12 Sep 2026
Programmable Voice PCI DSS Level 1 statement	Twilio	twilio.com/en-us/pci-compliance	12 Sep 2026
PCI Mode transcription limits; Conversation Relay caveat; PCI Mode is irreversible; <Pay> supports dtmf only and redacts digits from logs	Twilio	docs/voice/pci-workflows, docs/voice/twiml/pay	12 Sep 2026
pciEnabled default false; artifacts on by default; handoff context default; keypad payment-squad example; pipeline components; system logs never uploaded to customer buckets	Vapi	security-and-privacy/pci, security-and-privacy/data-flow	12 Sep 2026
Certifications listed; indefinite default retention	Retell AI	general/compliance, accounts/data-retention	12 Sep 2026
Masking replaces the tone with a mono-tone; PCI DSS Level 1 and SOC 2 audit statement	Eckoh	eckoh.com/dtmf-masking	12 Sep 2026
Keypad rather than speaking; masking versus pause and resume	PCI Pal	pcipal.com DTMF masking	12 Sep 2026
PCI DSS v4.0.1 published 11 June 2024; only active version after 31 December 2024	PCI Security Standards Council	blog.pcisecuritystandards.org, Just Published: PCI DSS v4.0.1	12 Sep 2026
Sells DTMF masking for phone payments	Sycurio	sycurio.com/blog/dtmf-masking	12 Sep 2026
Payment links shareable by text message to a Stripe-hosted page	Stripe	docs.stripe.com/payment-links/share	12 Sep 2026
The four-store rule and the resume test	Zian AI (this page)	Assembled from the sources above; the framing is ours, the facts are theirs	12 Sep 2026