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 costs roughly $500,000 in the first year. Ongoing annual costs run $200,000 or more, plus 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:
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?").
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.
Session initiation — Your platform makes an API call to the payment layer: `POST /payment-session` 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.
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 capture and gateway connector, so the card is captured inside the certified environment rather than inside your platform.
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.
Card captured in isolation — The card is captured exclusively inside 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.
Tokenisation and authorisation — The payment layer tokenises the card data and sends it to the customer's PSP for authorisation. This entire operation happens within the payment layer's PCI DSS Level 1 certified environment.
Result returned — The PSP returns an auth result to the payment layer. The payment layer fires a webhook to your platform: `payment_completed` with success/failure, a transaction ID, and a masked card reference (e.g., `**4242`). No card data.
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 (so using it for voice means being a Twilio customer). 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. What is not yet turnkey: the payment layer being present for the entire call. Today the secure capture is scoped to the point of payment, not the whole conversation. A carrier-agnostic version that removes the Twilio requirement, and moves toward fuller call control, is landing later in 2026. 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 by the payment layer at the point of payment, so the decodable digits never enter your call audio, your platform, or your recordings.
No card data in recordings: because the card is captured inside 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. The payment layer decodes the tones directly. 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 20 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 QSA scope is minimal. Your compliance burden is minimal.
The payment layer — Shuttle, in this context — carries the PCI DSS Level 1 certification. That's the certification that covers the card capture, tokenisation, vault, and PSP routing. You inherit the compliance posture without the certification cost. 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 40+ PSPs. 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: ~$500K in year one, $200K+ annually thereafter
Tokenisation vault design, implementation, and auditing
PSP integrations: each one is 2-4 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: 12-18 months 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 compliance carried by the payment layer, so you stay out of scope
40+ PSP integrations available without building them yourself (a few gateways, such as Braintree, work for links but not voice)
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, and most CCaaS companies are, 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:
```
POST /payment-session
Body: { amount, currency, merchant_id, psp_config } Response: { session_id, dtmf_ready: true }
[Secure card capture handled by the payment layer at the point of payment]
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" }
[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 within seconds of 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:
AI agent handles conversation and identifies payment intent
Platform initiates a payment session via API
The payment layer captures the card inside its certified environment at the point of payment (today, via Twilio Pay)
Card data never enters your platform, your recordings, or your AI pipeline
Payment layer handles tokenisation and PSP routing
Webhook returns success/failure and your application continues
PCI scope stays with the payment layer. 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), with the carrier-agnostic version landing later in 2026.
Related Reading
Embedded Payments for CCaaS — the business case for CCaaS operators
The CCaaS Payments Revenue Opportunity — the math on monetising payment volume through your platform
AI Payment Security: How AI Agents Handle Card Data — broader AI agent PCI guide
Voice AI Is Booming — But Can It Take a Payment? — the market context
Agentic Payments in 2026: The Infrastructure Guide — the broader infrastructure landscape for AI agent payments
Chat Agent Payments — the chat channel equivalent
What Is Embedded Payments? — the fundamentals
PCI-Compliant Payments for Contact Centres — the broader contact centre payment guide (human agents, AI agents, evaluation criteria)
Secure Payment Collection for Debt Agencies — AI agent payments applied to debt collection
PCI-Compliant Payment Architecture for Insurance Platforms — zero-scope architecture for insurance voice payments
What Are Voice Payments? — the complete guide to IVR, agent-assisted, and AI voice payments
AI Voice Payments for Hotels & Travel — voice payment architecture for hotel chains and OTAs
How Voice AI Ordering Platforms Handle Payments — PCI challenges specific to restaurant voice AI (SoundHound, ConverseNow, Kea)
Twilio Pay Connectors: How to Connect Any Payment Gateway to Twilio — connecting Twilio to any PSP for voice agent payments
Twilio PCI Compliance: How to Take Payments Without Handling Card Data — PCI scope and compliance architecture for Twilio-based voice agents
How to Connect Stripe to Twilio for Voice & IVR Payments — Stripe + Twilio integration for voice payments
Twilio Pay — Connect Any Payment Gateway to Twilio — install the Pay Connector to connect your gateway
Ready to add PCI-compliant payments to your voice agents?
Install on Twilio | Book a Demo | See How It Works