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.
Get Started with Twilio Pay →
The shift
Payments moved inside the call.
Not "after the call." Not "we'll send you a link." Inside it. The customer keys in a number, the system captures it, the payment confirms, and the conversation continues. No handoff. No second session. No human in the loop.
This happened because voice platforms matured. IVR gave way to intelligent routing. Intelligent routing gave way to AI agents. And AI agents hit the same wall every time. The ones handling collections, renewals, order confirmations, insurance claims. The customer is ready to pay, and the platform has nowhere to send them.
For CPaaS providers, CCaaS vendors, and AI voice platforms, this is no longer a feature request. It's an architecture decision. And the wrong one costs years.
Why platforms can't ignore this
Your customers are already solving this problem. They're solving it badly.
Collections teams are saying "I'll send you a link" and losing payment commitments in the handoff. Contact centres are asking callers to read card numbers over open lines, pulling PCI scope into systems that were never designed for it. AI agents are hitting a dead end the moment money enters the conversation, because there's no payment surface inside the call flow.
These aren't edge cases. They're the default experience for any platform running voice at scale.
The question for platform teams isn't whether your customers need payments inside voice. They do. The question is whether they solve it inside your platform or outside it.
Outside means third-party bolt-ons, compliance risk you can't control, and a customer experience your platform gets blamed for but can't fix.
Inside means you own the integration point. You control the experience.
Three architecture patterns
Every platform that confronts this problem lands on one of three approaches. Two of them fail at scale.
Pattern 1: Transfer-out
The call hits a payment moment. The system transfers the caller to a separate IVR. A standalone payment line operated by a third party. The caller re-authenticates, enters card details, and either gets transferred back or hangs up.
This is the legacy model. It works for low-volume, low-expectation use cases. It fails everywhere else.
Transfer-out breaks the conversation. The AI agent loses context. The caller loses patience. Completion rates drop because the friction of being bounced between systems is enough to make people give up.
For AI voice platforms, transfer-out is structurally incompatible. The entire value proposition of an AI agent is that it handles the conversation end-to-end. Transferring to a separate IVR for payment is an admission that the agent can't do its job.
Pattern 2: Bolt-on
The platform integrates a single PSP's payment API directly into the call flow. Stripe, or Worldpay, or whichever PSP the first customer required. Card capture happens inline, maybe via DTMF, maybe via a pause-and-link flow. It works for that one PSP.
Then the second customer needs Adyen. The third needs Checkout.com. The enterprise prospect mandates their existing acquirer relationship and won't negotiate.
Bolt-on creates a linear scaling problem. Every new PSP requires a separate integration, a separate certification process, and ongoing maintenance as APIs change. By the third PSP, payments are consuming product and engineering resources that should be building the platform's core product.
Worse, bolt-on usually means the platform is handling card data. Or at minimum, sitting in the PCI scope chain in ways that weren't planned for. One PSP integration is manageable. Five is a compliance programme.
Pattern 3: Embedded layer
A dedicated payment layer sits between the voice platform and any compatible PSP. The platform makes one integration. The layer connects each customer to its own gateway and limits the platform's PCI scope.
The voice platform never touches card data. The AI agent never sees a card number. Card digits are captured by keypad in a PCI-certified environment (for Shuttle, that is Twilio Pay today). The payment is confirmed in real time and the result returns to the call flow. The agent says "your payment of £247 has been confirmed" and the conversation moves on.
This is the only pattern that scales across customers, PSPs, and compliance requirements without turning payments into a permanent line item on the product roadmap.
The PCI wall
PCI compliance is where most platform teams underestimate the problem.
The moment card data touches any system, even transiently, that system is in PCI scope. The voice platform, the call recording infrastructure, the AI model, the logging pipeline. All of it.
For voice, the architecture has to enforce hard boundaries.
DTMF capture must be separated. When a caller enters card digits via keypad tones, those tones must be intercepted and processed in a PCI-certified environment before they reach the platform's audio stream. The digits never reach the AI agent. The recording holds nothing usable.
AI agents must never process card data. The language model handles the conversation. The payment layer handles the card. These two systems must be architecturally isolated. Not just logically separated, but running in different environments with different compliance boundaries. An AI model that has access to card data is a PCI problem that no QSA will sign off on.
The real question is scope reduction, not scope management. The difference between full scope and reduced scope is the difference between an audit programme covering your own capture systems and one that does not. Platform teams complete SAQ-D either way. Those that build payment capture in-house carry full scope; those that use an embedded layer carry far less PCI scope.
This isn't a configuration decision. It's an architectural boundary that determines your compliance posture for years.
The multi-tenant PSP problem
Voice platforms are multi-tenant by nature. You don't serve one customer. You serve hundreds or thousands, each with their own payment stack.
The mid-market customer uses Stripe because it was easy to set up. The enterprise customer mandates Worldpay because they negotiated rates across their entire business. The regulated customer requires a specific acquirer for compliance reasons. The international customer needs local acquiring in markets where your default PSP doesn't operate.
A platform that supports one PSP serves one segment. A platform that supports any compatible PSP serves a much wider market.
This is the multi-tenant PSP problem, and it's unique to platforms. A single merchant picks one PSP and moves on. A platform must support any compatible PSP its merchants require, without building and maintaining each integration.
In voice, this compounds. Each PSP has different tokenisation flows, different API patterns for authorisation, different webhook formats for confirmation. Building DTMF capture that works with Stripe is one project. Making it work with Stripe, Adyen, Worldpay, Checkout.com and the other PSPs your customers use is a programme.
The embedded layer pattern solves this. The platform integrates once. Each merchant is configured against their own PSP. Adding a supported PSP for a new customer is configuration, not engineering.
Build vs partner
Every platform team's first instinct is to build it. "We'll integrate Stripe's API, add DTMF capture, handle PCI ourselves." The instinct is understandable. The maths isn't.
Timeline: months to production for a single PSP with PCI-compliant voice capture. DTMF integration, PCI audit preparation, acquirer certification, production hardening, edge case handling. Each step takes longer than expected.
Cost: engineering time, an annual PCI QSA assessment, infrastructure for a PCI-certified capture environment, and ongoing maintenance as PSP APIs evolve. A second PSP adds more months and more cost.
Compliance burden: PCI DSS Level 1 assessment is not a one-time event. It's an annual cycle. Audit preparation, evidence gathering, remediation, assessor engagement.
The build path makes sense in exactly one scenario: payments are your core product and PSP integration is your competitive advantage. For every other platform, it's a misallocation of engineering resources toward a solved problem.
This is what Shuttle does. One integration. 30+ PSPs for voice. Keypad capture through Twilio Pay, kept separate from the platform. The platform stays out of the card data flow.
What production looks like
In production, the payment confirms inside the natural pause of the conversation. The agent says "please enter your card number on your keypad." The caller enters digits. The digits never reach the agent. The recording holds nothing usable. The payment processes. The agent confirms and moves on.
No transfers. No separate IVR. No card data in the platform's environment.
The platform receives structured webhook events. Payment initiated, payment confirmed, payment failed, refund processed. Enough to update CRM records, order status, customer accounts. The payment layer handles the transaction. The platform handles the business logic.
The customer never knows the layer exists. The experience is branded as the platform's. The merchant portal is the platform's. The infrastructure is invisible.
Decision framework
Build if:
Payments are your core product, not an adjacent feature
You need exactly one PSP and will never need another
You have dedicated PCI compliance staff and budget for annual assessment
You're prepared for a timeline of months before your first production transaction
Partner if:
Your customers use different PSPs and you need to support many of them
You'd rather limit your PCI scope than carry all of it
Your engineering team should be building your core product, not payment infrastructure
Do nothing if:
You're comfortable with customers solving payments outside your platform
You're not competing with platforms that have embedded payments
Doing nothing is a valid choice. It just becomes less valid every quarter as more platforms ship native payment capabilities and your customers start asking why you haven't.
Shuttle is the payment layer for voice, links, and embedded checkout. PCI DSS Level 1. 40+ PSPs (30+ for voice). One integration. shuttleglobal.com