Taking Card Payments Through an AI Voice Agent: A PCI DSS Guide

You can take card payments inside an AI voice agent call without dragging your telephony provider, your speech pipeline, and your AI stack into PCI DSS scope. The safe pattern is to keep spoken card numbers out of the call entirely: capture digits through the keypad with DTMF masking, hand off to a payment link, or skip cards and push a mobile money prompt to the caller's phone. This post walks through the PCI DSS ground rules for telephone payments, three architectures that work in production, what each costs, and the mistakes that quietly put your recordings and transcripts in scope.

Why payment capture is where voice agents meet PCI DSS

A voice agent that answers questions, books appointments, or checks an order status touches no regulated payment data. Teams are already running agents like this in production for customer service; our voice AI customer service implementation guide covers that build. The moment the agent asks for a card number, the rules change.

The PCI Security Standards Council is blunt about it in its guidance for telephone-based payments: accepting spoken account data over the telephone puts the personnel, the technology used, and the infrastructure that technology is connected to into the scope of PCI DSS (PCI SSC, Protecting Telephone-Based Payment Card Data). Swap "call centre agent" for "AI voice agent" and nothing changes. If your speech-to-text engine transcribes a spoken card number, that transcript is cardholder data. If your call recording captures it, the recording is in scope. If the audio passes through your media server, that server is in scope.

This is the trap most voice AI projects fall into. The demo works beautifully: the caller reads out a Visa number, the agent confirms it, a charge appears. Then someone asks about PCI DSS and you discover the LLM context window, the STT provider's logs, the recording bucket, and half a dozen webhooks all just became part of your cardholder data environment.

The fix is not to abandon payments on calls. It is to design the payment step so sensitive data never enters your stack in the first place.

The ground rules PCI DSS sets for telephone payments

Four rules from the PCI SSC guidance drive every architecture decision below.

Sensitive authentication data must never be stored after authorization. SAD includes the card security code (CVV2/CVC2/CID), full track data, and PINs. This applies to call recordings exactly as it applies to databases. A recording that contains a spoken CVV is a violation you cannot encrypt your way out of, because the prohibition is on storage, not on unencrypted storage.

DTMF suppression and masking are the recognized way to keep keypad entry out of scope. The PCI SSC defines DTMF suppression as removing the keypad tones and DTMF masking as replacing them with a random or flat tone, so recordings and eavesdroppers cannot recover the digits. Tones matter because DTMF digits are trivially recoverable from audio by anyone with basic tooling.

Scope follows the data. Anything that stores, processes, or transmits cardholder data is in the cardholder data environment. Segment the payment step onto infrastructure that never touches the rest of your voice pipeline and the rest of the pipeline stays out of scope.

Pause-and-resume is a legitimate but fragile fallback. Stopping the recording while the caller speaks card details is an accepted scope-reduction technique, but it only protects the recording. The spoken digits still transit your telephony and speech stack, which remains in scope. Pause-and-resume solves the smallest part of the problem.

Architecture option 1: capture DTMF inside the call with masking

The strongest pattern keeps the caller on the line and takes the card digits through the telephone keypad, on a media path that is PCI certified, with the digits never reaching your AI agent.

Twilio's implementation is the clearest documented example. You enable PCI Mode on the account, which redacts payment information from recordings, automatically pauses and resumes recording around card entry, and restricts retention of those PCI Mode recordings to one year (Twilio Help: PCI-compliant payment workflows). The capture itself uses the TwiML <Pay> verb, which accepts DTMF input only, redacts all captured digits from Twilio's own logs, and forwards the card data directly to your payment processor through a configured Pay Connector (Twilio TwiML <Pay> docs).

A minimal payment segment looks like this:

<Response>
  <Say>Your renewal total is forty nine dollars.
       Please enter your card number, then press star when finished.</Say>
  <Pay chargeAmount="49.00"
       currency="USD"
       paymentConnector="stripe_connector_1"
       action="https://voice.example.com/payment-result"
       validCardTypes="visa mastercard amex"
       maxAttempts="2" />
  <Say>Your payment has been submitted. A receipt will follow by text.</Say>
</Response>

Details worth knowing before you build:

• <Pay> charges or tokenizes. Set chargeAmount above zero to charge immediately; omit it or set it to zero to tokenize for later use, which is the right pattern for saving a card on file.
• The result arrives by webhook. Twilio posts a confirmation code or a payment token to your action URL. Your agent logic reads the outcome, never the digits.
• Keypad only. There is no spoken-card-number mode. The star key terminates entry, and maxAttempts bounds retries.
• Transcription trade-off. Twilio's native transcription is not available in PCI Mode, so plan your conversation logging around redacted events rather than full transcripts for the payment leg.

The same pattern exists elsewhere. Amazon Connect's PCI guidance recommends collecting payment data through encrypted DTMF, scrubbing anything sensitive that does reach recordings, and encrypting stored recordings and logs with KMS (AWS Connect PCI best practices). Specialist vendors such as KeyIVR sell the equivalent as a managed overlay: DTMF-suppressed keypad capture where tones are masked so agents and recordings never see cardholder data (KeyIVR agent-assisted payments).

When to choose it: high call volumes where keeping the caller on the line matters, card-on-file and recurring payment use cases, and regulated buyers (insurers, utilities, lenders) whose compliance teams will ask exactly how the digits flow.

Architecture option 2: send a payment link mid-call

The simplest compliant pattern moves the card entry off the phone channel entirely. The voice agent confirms the amount, sends a payment link by SMS or email while the caller is still on the line, and waits for a webhook from the payment processor confirming success.

The PCI logic is the same one Stripe applies to web payments: if untokenized card numbers pass through your own systems you can end up responsible for more than 300 PCI DSS security controls, while integrations that keep card data off your servers shrink that obligation dramatically (Stripe integration security guide). A hosted payment page is the phone-call equivalent of Stripe Checkout. Your agent, your recordings, and your transcripts never see a digit.

The flow:

1. Agent confirms the amount and the caller's mobile number.
2. Agent backend creates a payment session (Stripe Checkout, a hosted page from your PSP, or your own PCI-scoped page) and sends the link by SMS.
3. Agent tells the caller the link has arrived and offers to wait.
4. A webhook from the processor updates call state; the agent confirms success or offers help if the payment fails.

The honest downsides: completion rates drop every time you move a caller to a second screen, the caller needs a smartphone and data, and the experience breaks for accessibility or feature-phone users. KeyIVR's documentation describes the same trade-off from the agent-assist side, which is why they offer the link as one of three capture methods rather than the only one.

When to choose it: lower volumes, existing hosted checkout you can reuse, callers who are already comfortable paying on their phone, and teams that want zero PCI surface in the voice stack without paying for PCI Mode telephony.

Architecture option 3: skip cards entirely with mobile money

In Kenya and much of East Africa, the best payment instrument for a voice call is not a card at all. Safaricom's Daraja platform exposes M-Pesa Express, often called STK push: the business initiates a payment prompt directly to the customer's phone, and the customer authorizes it with their M-Pesa PIN (Safaricom Daraja API catalogue).

For a voice agent this is close to ideal. There is no cardholder data at any point. The caller never speaks or keys in anything sensitive on the call. The agent says "I have sent a payment prompt to your phone for KES 2,400, please enter your M-Pesa PIN to confirm," and the Daraja callback delivers the result. PCI DSS simply does not apply, because no card data exists. What remains is ordinary data protection practice, which Kenyan readers should treat seriously for call recordings and personal data generally.

The voice side can run on regional infrastructure. Africa's Talking, for example, provides callback-driven voice APIs with DTMF input across Kenyan and regional carriers, which pairs naturally with an STK push backend (Africa's Talking voice docs). You keep telephony, agent logic, and payment confirmation in one region-appropriate stack.

The limits are real: M-Pesa transaction limits and per-transaction fees apply, the caller needs an M-Pesa-registered line, and cross-border callers are out. For card-paying diaspora or international customers you still need option 1 or 2.

When to choose it: Kenyan and East African customer bases, high mobile money penetration, and any use case where asking for a card would be asking the customer to do something unusual. If your agents handle a wider mix of tasks beyond payments, our overview of how businesses deploy AI voice agents covers the broader patterns.

What a compliant payment call actually costs

Telephony is the easiest part to price, so here is a worked example using Twilio's published US pay-as-you-go rates, current as of August 2026 (Twilio Voice pricing). Model, speech-to-text, and text-to-speech costs sit on top of this; we break those down separately in our voice AI implementation cost guide.

Assume an inbound payment and service line handling 2,000 calls per month, averaging 7 minutes each, of which roughly 2 minutes is payment capture:

• Inbound minutes: 2,000 calls x 7 minutes x $0.0085 per minute = $119.00
• Local phone number: $1.15 per month
• Call recording: 2,000 x 7 minutes x $0.0025 per minute = $35.00
• Recording storage: 14,000 minutes x $0.0005 = $7.00 per month

Total telephony and recording: about $162 per month. Even at 10,000 calls a month the same arithmetic lands near $810, which is rarely the deciding line item. The real cost drivers are the AI stack per minute and the engineering to wire payment webhooks into your order, billing, or policy systems.

Two pricing caveats. First, outbound calls cost more than inbound ($0.0140 per minute for US local), so payment reminder campaigns priced on outbound rates come out higher. Second, transcription at $0.05 per minute on Twilio would add $700 per month to the example above, and it is unavailable in PCI Mode anyway, so design logging around structured events instead.

Common mistakes that pull you into scope

Letting callers speak card numbers to the agent. This is the big one. Spoken digits flow through STT, land in transcripts, sit in LLM context, and echo into logs. The PCI SSC guidance puts spoken account data squarely in scope, and no AI vendor's terms change that.

Recording the payment leg without controls. A recording that captures a CVV violates the prohibition on storing sensitive authentication data after authorization. Use PCI Mode or equivalent automatic pause-and-resume, and verify with test calls that the redaction actually works.

Assuming your telephony provider's certification covers you. Stripe's guide states the shared-responsibility model plainly: the provider maintains its own PCI Level 1 certification, and you must still accept payments in a compliant manner and attest to it annually.

Keeping full PANs when you only need metadata. Card brand, last four digits, and expiry are safe to store per Stripe's documentation. Build your CRM and reconciliation around those, never around the full number.

Logging DTMF digits in your own application. Twilio redacts captured digits from its logs; your webhook handlers, analytics events, and error trackers need the same discipline. Audit every place the payment result object travels.

When taking payment on the call is the wrong choice

Voice payment capture earns its complexity when the caller's intent to pay is highest during the conversation: renewals, arrears collection, booking deposits, policy reinstatement. It is the wrong choice when payment is not time-sensitive, when your callers skew toward channels with better completion (a follow-up SMS link may convert fine), or when your volumes are so low that a human agent with an existing PCI-scoped payment terminal is cheaper than building anything. For a SACCO or insurer testing demand, a link sent after the call is a perfectly good first version. Build DTMF capture when the drop-off data justifies it.

Frequently asked questions

Can an AI voice agent legally take card payments over the phone? Yes. Phone payments are a long-established channel and PCI DSS has explicit guidance for them. The requirement is that cardholder data is captured, transmitted, and stored compliantly, which in practice means keypad capture on certified infrastructure or an off-call payment page.

Is it PCI compliant for a customer to read their card number aloud to an AI? It drags everything that audio touches into PCI scope: your STT provider, transcripts, recordings, LLM context, and logs. The PCI SSC treats spoken account data as fully in scope for telephone environments. Use DTMF capture or a payment link instead.

What is DTMF masking? The caller enters card digits on their phone keypad, and the dual-tone signals are suppressed or replaced with flat tones so recordings and listeners cannot recover the numbers. The digits travel on a certified media path straight to the payment processor, bypassing your systems.

Can we record calls that include payment capture? Only if sensitive authentication data is never stored. That means automatic pause-and-resume or redaction around card entry, verified with test calls. Twilio PCI Mode handles this and limits those recordings to one year of retention.

How much does PCI compliant payment capture cost? Telephony for an inbound line is cents per minute: our worked example of 2,000 seven-minute calls came to roughly $162 per month including recording. The larger costs are AI inference per minute and integration engineering, not PCI compliance itself.

Can we use M-Pesa instead of cards on a voice call in Kenya? Yes, and it is often the better design. M-Pesa Express sends a payment prompt to the caller's phone during the call and they authorize with their PIN, so no card data exists and PCI DSS does not apply. The caller needs an M-Pesa-registered line, and transaction limits and fees apply.

Where to go from here

If you are scoping a voice agent that needs to take payments, the decision framework above will get you to the right architecture; the build is telephony integration, payment webhooks, and compliance hygiene rather than anything exotic. We design and build voice agents and payment workflows like this as part of our custom AI builds, and for banks and insurers the governance side sits within our enterprise AI work. If you want to sanity-check an architecture before committing, talk to an engineer.