How AI Voice Agents Take PCI-Compliant Payments

By Shuttle Team, February 19, 2026

Your AI voice agent is impressive. It handles intent recognition, sentiment analysis, conversational routing, customer lookup against your CRM, scheduling, and escalation, all in real time, all without a human agent. Then the customer says: "Yes, I'd like to pay now."

And your stack hits a wall.

Taking a card payment during a live AI voice call isn't a product problem or a UX problem. It's an infrastructure and compliance problem. This guide explains exactly what the architecture looks like, why the naive approaches don't work, and what a correct integration actually involves.

The Problem: AI Can Do Everything Except Take a Payment

The moment a customer agrees to pay, your voice agent needs to capture a 16-digit card number, a 4-digit expiry, and a 3-digit CVV. That's sensitive cardholder data under PCI DSS. And PCI DSS has a very clear rule: any system that stores, processes, or transmits cardholder data is in scope for full compliance.

Here's what that means in practice for a CCaaS platform:

If card data enters your AI model, even as audio that gets transcribed, your entire voice infrastructure is in PCI scope. That includes your ASR pipeline, your LLM inference layer, your call recording system, your data lake, your transcription storage, your model training pipelines, and every network segment they touch.

PCI DSS Level 1 certification for that kind of footprint is expensive in the first year and every year after, with quarterly vulnerability scans, annual penetration testing, and a Qualified Security Assessor (QSA) who will not be cheap or fast.

That's the compliance burden of getting this wrong. Most CCaaS companies, even well-funded ones, cannot absorb it, nor should they. The goal is to keep cardholder data out of your platform entirely.

The Architecture: Secure Payment Handoff

The correct architecture is a clean handoff: your AI agent orchestrates the conversation, a separate payment layer handles all card data capture, and your platform never sees, stores, or processes cardholder data. Here's the step-by-step flow:

  1. Intent recognition: The AI agent identifies payment intent from the customer's speech ("I'd like to pay my bill" / "Can I settle this now?").

  1. Amount confirmation: The agent confirms the payment amount with the customer and explains that they'll be prompted to enter their card details via their keypad.

  1. Session initiation. Your platform makes an API call to the payment layer with the amount, currency, and the end-customer's PSP configuration. The payment layer returns a session token and signals that it's ready to capture.

  1. Secure capture takes over at the point of payment: When it's time to pay, a secure, PCI DSS Level 1 card capture takes over the payment step. Today this runs over Twilio Pay, with the payment layer as the certified gateway connector, so the card is captured through Twilio Pay and passed to the payment layer's certified environment rather than to your platform.

  1. Card data entry: The payment layer plays a secure prompt to the caller ("Please enter your 16-digit card number followed by the hash key"). The caller enters digits via their phone keypad.

  1. Card captured in isolation: The card is captured through Twilio Pay and passed to the payment layer's certified environment. The digits do not enter your CCaaS platform. They do not reach your AI model. They do not appear in call recordings.

  1. Tokenisation and authorisation: The card is tokenised with the customer's PSP, which authorises the payment.

  1. Result returned: The PSP returns an auth result to the payment layer. The payment layer fires a webhook to your platform with success/failure, a transaction ID, and a masked card reference (e.g., ****4242). No card data.

  1. Your application continues. Your platform reads the result and your AI agent continues, for example: "Your payment of £150 has been processed. Your reference number is TXN-9821." (See the note below on returning the caller to the same agent.)

The entire card capture happens in a certified environment your platform never touches. Your PCI scope is limited to the API calls between your platform and the payment layer, which is a dramatically smaller, more defensible surface area.

What's live today (the honest version)

The secure card capture at the point of payment is available now, and today it runs on Twilio Pay, or on Telnyx through the Pay verb in TeXML, with Shuttle as the payment connector. Returning the caller to the same AI agent afterwards works today: you program the return route in your Twilio flow and pass a conversation ID, so the agent resumes the conversation with context. The payment layer being present for the entire call is not available today. Today the secure capture is scoped to the point of payment, not the whole conversation. Where building the return leg isn't viable for your flow, payment links sent mid-call by SMS are the turnkey alternative.

DTMF vs Speech Recognition for Card Capture

When engineers first think about AI voice agent payments, the obvious question is: "Why can't the AI just listen to the customer read out their card number?" It understands speech. It can transcribe numbers.

It can, technically. But compliance architecture doesn't care what the AI can do: it cares what data flows where.

If a customer reads their card number aloud and your ASR pipeline transcribes it, that audio and that transcript both contain cardholder data. Your entire ASR infrastructure is now in PCI scope. Your call recording system is in scope. Your transcription storage is in scope. Your model training data, if you're using call audio for fine-tuning, is in scope.

DTMF (Dual-Tone Multi-Frequency) keypad entry solves this at the architecture level:

  • Captured inside the certified environment: the card is captured through Twilio Pay at the point of payment and passed to the payment layer, so the decodable digits never enter your call audio, your platform, or your recordings.

  • No card data in recordings: because the card is captured through Twilio Pay and passed to the payment layer rather than your stack, your call recordings contain no decodable card data for the card-entry window.

  • No transcription: There's no speech-to-text step for card data. No LLM, no ASR, no transcript.

  • Caller familiarity: Customers are used to entering card details via keypad. It's the standard IVR flow they've been doing for years. There's no UX friction.

Speech capture of card numbers is a compliance anti-pattern. Keypad capture inside a certified environment is the industry-standard, compliance-correct approach. Any architecture that routes spoken card numbers through your AI pipeline is building a very expensive PCI scope problem.

PCI Scope: What Changes and What Doesn't

This is worth being precise about, because "PCI compliance" gets hand-waved in a lot of vendor conversations.

Without a payment handoff architecture:

If your agents, human or AI, hear or process card numbers, PCI DSS scope expands to include:

  • All call recording infrastructure

  • All transcription services and storage

  • All ASR pipelines

  • All AI model inference infrastructure

  • All data warehouses or lakes that receive call data

  • All networks connecting these systems

  • All personnel with access to those systems

That's essentially your entire platform. PCI DSS Level 1 certification for a footprint that size is not a checkbox exercise. It's a multi-year program with dedicated compliance staff.

With a payment handoff architecture:

Your PCI scope shrinks to:

  • The API connection between your platform and the payment layer (TLS in transit: table stakes)

  • The payment layer itself (which carries its own PCI DSS Level 1 certification)

You don't handle card data. You don't store it. You don't transmit it. You send a payment session request and receive a success/failure webhook. Your PCI scope is heavily reduced, and so is your compliance burden.

The payment layer (Shuttle, in this context) carries the PCI DSS Level 1 certification. That certification covers Shuttle's part of the flow: receiving the card from the capture, tokenising it with the gateway, and routing the payment. Shuttle has no card vault of its own. Your PCI scope is limited without you funding that certification yourself, though you still validate your own compliance. For a detailed walkthrough of how this works specifically on Twilio infrastructure, see Twilio PCI Compliance: How to Take Payments Without Handling Card Data.

Multi-PSP: Why Your Customers' Gateway Matters

Here's a practical problem that most "just add Stripe" thinking ignores: your enterprise CCaaS customers already have PSP relationships.

An insurance company processing 50,000 premium collections a month has a negotiated rate with their acquirer. A utility company has a direct integration with a specific gateway. A debt collection agency is contractually required to process through a particular payment provider. None of them want to move off their existing PSP to use whatever you've embedded.

A correct payment layer needs to be PSP-agnostic. When a payment session is initiated for a given end-customer, the payment layer routes to that customer's configured PSP, not to a single hardcoded gateway.

This is why "add Stripe" doesn't solve the problem for CCaaS operators. Stripe is a single gateway. Your enterprise customers need their own gateway. The payment infrastructure needs to support multi-tenancy at the PSP level: each customer of your platform routes through their own PSP, using their own merchant credentials, with their own settlement.

Shuttle supports 30+ PSPs for voice. When you initiate a payment session, you pass the end-customer's PSP configuration and the payment layer handles the routing, so you never need to build a new PSP integration for a new customer. (One caveat: a few gateways, such as Braintree, won't allow raw card data over voice, so they work for payment links but not for keypad capture.) If you're building on Twilio, Pay Connectors make this simpler: a single Marketplace install connects Twilio to a supported gateway.

Build vs Buy

Let's be direct about what building this in-house actually requires:

Build:

  • DTMF capture with audio stream isolation (non-trivial telephony engineering)

  • PCI DSS Level 1 certification: a large cost in year one, then annual costs thereafter

  • Tokenisation vault design, implementation, and auditing

  • PSP integrations: each one is weeks of engineering, plus ongoing maintenance as PSP APIs change

  • Ongoing quarterly vulnerability scans, annual penetration tests, key rotation schedules

  • A dedicated compliance function or expensive external QSA relationship

  • Timeline to first production payment: months, at minimum

Buy (integrate a payment layer):

  • A single integration against the payment layer's capture, IVR, and APIs, where you build your own agent-side interface (effort depends on your stack)

  • PCI DSS Level 1 carried by the payment layer, which limits your PCI scope

  • 30+ PSP integrations available without building them yourself (a few gateways, such as Braintree, work for links but not voice)

  • Its own compliance, auditing, pen testing, key rotation: the payment layer's problem

  • Far faster than the build path, though the exact timeline depends on your platform, so ask for a scoped estimate rather than a headline number

For a CCaaS company under 500 people, this calculus is not close. The build path is a multi-year distraction from your core product. The buy path lets you ship a payments feature, close enterprise deals that require payment capabilities, and keep your engineering team focused on the AI and conversation capabilities that actually differentiate your product.

What the Integration Actually Looks Like

Stripped to its essentials, the integration is three API calls and a webhook. The endpoint and event names below are illustrative:

1. POST /payment-session
   Body: { amount, currency, merchant_id, psp_config }
   Response: { session_id, dtmf_ready: true }

2. [Secure card capture handled by the payment layer at the point of payment]

3. Webhook received: POST /your-webhook-endpoint
   Body: {
     event: "payment_completed",
     session_id: "sess_abc123",
     status: "success",
     transaction_id: "txn_xyz789",
     masked_card: "****4242",
     amount: 15000,
     currency: "GBP"
   }

4. [Your application reads the status from the webhook and continues]

No card data flows through your system at any point. The session ID ties the payment to the conversation. The webhook fires after the PSP authorisation. Your application reads the status and continues. (To return the caller to the same AI agent afterwards, program the return route in your Twilio flow and pass the conversation ID.)

The same secure capture and APIs serve both your AI and human-agent channels. Same API, same PCI boundary. You build your own agent-side interface once and it serves both.

Summary

AI voice agents are capable of taking payments, but the architecture has to be right, and the honest current state matters. The LLM cannot hear or process card data. Speech recognition of card numbers creates a compliance catastrophe. Capturing the card inside a dedicated, certified payment layer keeps card data entirely out of your platform.

The architecture is:

  1. AI agent handles conversation and identifies payment intent

  2. Platform initiates a payment session via API

  3. The card is captured at the point of payment, today through Twilio Pay, and passed to the payment layer's certified environment

  4. Card data never enters your platform, your recordings, or your AI pipeline

  5. Payment layer handles tokenisation and PSP routing

  6. Webhook returns success/failure and your application continues

The payment layer limits your PCI scope. Your engineering team stays focused on your product. Your enterprise customers use their existing PSPs. One honest caveat: the secure capture at the point of payment is live now (on Twilio Pay today); returning the caller to the same AI agent after payment is return-route wiring you build in your Twilio flow (pass a conversation ID). Shuttle works with Twilio today, and any carrier coming soon.

FAQ: AI Voice Agents and PCI-Compliant Payments

Can AI agents handle PCI-compliant payments?

Yes. An AI voice agent can take a card payment during a call and stay PCI-compliant, as long as the card data never enters the AI pipeline. The agent runs the conversation, then hands off to a PCI DSS Level 1 certified payment layer that captures the card from the phone keypad via Twilio Pay today, charges it against your gateway, and returns only a masked result. The card number never reaches the AI model, the transcript or the recording.

Can voice agents process payments and complete transactions?

Yes. A voice agent can take the customer through to a completed, authorised payment in the same call. The agent confirms the amount, the card is captured via the keypad through Twilio Pay and passed to the payment layer, the transaction is authorised against your gateway, and the agent confirms success once the call returns to it (return routing you wire in your Twilio flow). No separate IVR line, no callback. Where no agent or voice bot is needed at all, an automated keypad flow does the same job: see IVR Payments.

Which voice AI tools support PCI-compliant payments over the phone?

Voice AI platforms generally leave card capture to a separate payment layer. Retell, Vapi and Bland have no native way to take a caller's card; ElevenLabs and Synthflow offer Stripe-only native payments; Cognigy routes capture to external payment tools inside its own PCI-assessed environment. In each case a dedicated payment layer handles the card. Shuttle adds PCI-compliant in-call payment capture alongside these platforms, on Twilio today, taking the card via the keypad or an SMS payment link and sending it to whichever of the 30+ voice-capable payment gateways you use. See the per-platform guides in Related Reading below.

Do PCI DSS and PSD2/PSD3 apply to AI agent payments?

PCI DSS applies the moment cardholder data is captured, whether a human or an AI agent is on the call. In Europe, PSD2's strong customer authentication rules apply to online payments such as a payment link sent by SMS, while keypad payments taken on a call are processed as MOTO transactions, which fall outside SCA; PSD3 and the Payment Services Regulation will build on this once they apply. Using a PCI-certified payment layer keeps the card data, and most of the compliance burden, off your systems; you still validate your own compliance.

What PCI rules should I watch out for when letting an AI agent collect payments?

The main risks are card data landing in call recordings or transcripts, keypad tones reaching your transcription or LLM, and card numbers being written to your CRM or logs. Avoid all three by capturing the card in an isolated PCI-certified environment so the digits never reach the audio and systems your stack sees. Done correctly, this heavily reduces your PCI scope. Merchants complete SAQ A, the lightest PCI self-assessment; platforms complete SAQ D. Everyone taking card payments has to be PCI compliant, and your acquirer confirms which form applies to you.

Can an AI voice agent split a past-due balance into a payment plan during the call?

Yes. For collections and bill-pay, the agent can agree a payment plan, take the first instalment immediately on the keypad, and save the card with your gateway so the remaining instalments your system schedules can be charged without asking for the card again. See AI Voice Payments for Debt Collection for the collections-specific workflow.

Ready to add PCI-compliant payments to your voice agents?

Install on Twilio | Book a Demo | See How It Works

Take payments over the phone

Card capture for contact centres, IVR flows and AI voice agents, connected to 30+ payment gateways including Stripe, Adyen, and Worldpay Access.

Book a Call

Related Reading

Explore More

Blog

Can You Take Card Payments on a Retell AI Voice Agent?

→
Blog

Your voice agent will take the booking. It will not take the money.

→
Blog

Voice Payments Are an Architecture Decision, Not a Feature Request

→
Blog

Agent-Ready Commerce: How SaaS Platforms Prepare for AI-Driven Payments

→
Blog

Sage Invoice Payments: How to Let Customers Pay Online

→
Blog

Agentic Payments Isn't Solved Yet

→