Twilio PCI compliance comes down to whether card data ever reaches your application, your agents or your call recordings. Twilio's <Pay> verb, run with PCI Mode on as Twilio requires for Pay Connectors, is built so it does not, but the Pay Connector you choose and how your call flow is built decide how much PCI scope stays with you. This guide covers how Twilio handles card data, where scope gets created, how Shuttle limits it, and what to check before you go live.
If you're taking payments over Twilio (through IVR, agent-assisted calls, or AI voice agents), you have PCI compliance obligations. The question is how much of that burden falls on you. For the automated, no-agent flow specifically, see IVR Payments.
The answer depends entirely on your architecture. Done right, you can collect card payments over Twilio with zero card data in your environment and a heavily reduced PCI scope: merchants complete SAQ-A, the lightest self-assessment questionnaire, and platforms complete SAQ-D. Done wrong, card data lands in your environment and the full weight of SAQ-D applies, with the risk of fines if something goes wrong.
This guide explains how Twilio handles PCI compliance for voice payments, where the gaps are, and how to close them. For the product setup, supported gateways, and pricing, see Twilio Pay.
How Twilio Handles Card Data
Twilio's <Pay> TwiML verb is designed to capture card details during a phone call without exposing them to your application or agents.
Here's what happens during a payment:
The call enters a secure segment. When
<Pay>is triggered, Twilio activates DTMF capture mode.The caller enters card details via keypad. They key in card number, expiry, and CVV using the phone's number pad.
The digits never reach the agent. The agent stays on the line, and the card digits never reach them or the recording.
Card data stays in Twilio's PCI environment. The captured digits are passed directly to a Pay Connector, never to your application, your servers, or your call recording system.
Only redacted data is returned. Your webhook receives the last four digits, card brand, and transaction result. No full card numbers.
This architecture means card data never touches your infrastructure. Twilio's PCI-certified environment handles capture, and the Pay Connector handles processing.
Where PCI Scope Gets Created
Twilio's <Pay> verb handles the voice-side PCI requirements. But PCI compliance for the full payment chain depends on every component involved:
Your PCI Scope With <Pay> + Shuttle
Component | Who handles it | PCI impact on you |
|---|---|---|
Twilio | None: the digits never reach the agent | |
Call recording | Twilio | None: card tones excluded |
Agent audio | Twilio | None: the digits never reach the agent |
Card data processing | Shuttle (Pay Connector) | None: PCI DSS Level 1 |
Transaction routing | Shuttle | None: gateway connection is Shuttle's scope |
Webhook results | Your application | Minimal: redacted data only (last 4 digits) |
Your PCI scope | Merchants: SAQ-A. Platforms: SAQ-D. |
SAQ-A is the lightest PCI self-assessment, and it is the form merchants complete; platforms complete SAQ-D. It's a short questionnaire, mostly confirming that you don't store, process, or transmit card data. Compare that to SAQ-D's hundreds of requirements, which apply when card data touches your systems.
What Breaks PCI Compliance
Common mistakes that put you back in full PCI scope:
Recording calls without DTMF suppression. If your recording system captures the payment segment of a call and DTMF tones aren't stripped, those recordings contain card data. You're now storing PCI data.
Building your own payment capture. If you bypass <Pay> and capture card digits through your application logic, even temporarily, card data flows through your infrastructure. Full PCI scope.
Hosting a Generic Pay Connector endpoint yourself. Twilio's Generic Pay Connector sends the captured card data, including the full card number and CVV, to an endpoint URL you supply. If that endpoint runs on your infrastructure, your servers are receiving cleartext cardholder data: they become part of your cardholder data environment, and Twilio requires an Attestation of Compliance before the connector goes live. This is the single most common way Twilio payment builds end up in SAQ-D territory.
Using a non-certified Pay Connector. The connector processes the actual card data. If it's not PCI DSS Level 1 certified, there's a gap in the compliance chain. Your auditor will flag it.
Logging card data in error handling. If your webhook error logs capture raw card data from failed transactions (instead of redacted responses), you've created a data store. Even accidental storage counts.
Agent screens showing card numbers. If your CRM or agent desktop displays full card numbers during the payment flow, agents have visual access to card data. That's scope.
PCI DSS Level 1 vs Level 2: Why It Matters
PCI DSS has four merchant levels and two service provider levels. For payment infrastructure like Pay Connectors, the distinction that matters is:
Level 1 Service Provider: annual on-site audit by a Qualified Security Assessor (QSA), penetration testing, continuous monitoring, and a formal Report on Compliance (ROC). This is the highest certification and is expensive to achieve and maintain.
Level 2 Service Provider: self-assessment questionnaire. No on-site audit. Less rigorous.
When you're evaluating a Twilio Pay Connector, Level 1 is the standard to look for. Shuttle is PCI DSS Level 1 certified as a Service Provider.
Twilio PCI Compliance Checklist
Use this to check your Twilio payment implementation:
[ ] Using
<Pay>verb for all card capture (not custom DTMF handling)[ ] DTMF suppression enabled: the digits never reach the agent
[ ] Call recordings exclude the payment segment, or contain no card digits
[ ] Pay Connector is PCI DSS Level 1 certified (e.g., Shuttle)
[ ] No card data in your logs, databases, or error handlers
[ ] Agent screens show redacted data only (last 4 digits, card brand)
[ ] Webhook responses contain only redacted payment data
[ ] SAQ-A (merchants) or SAQ-D (platforms) completed and filed with your acquiring bank
[ ] Twilio account settings reviewed for recording and monitoring configuration
If all boxes are checked, your PCI scope is heavily reduced (merchants complete SAQ-A, platforms complete SAQ-D) and card data never enters your environment.
Beyond PCI: Additional Security Standards
PCI DSS is the floor, not the ceiling. For enterprise and regulated industries, look for:
ISO 27001: international standard for information security management systems. Covers operational security controls beyond payment data.
SOC 2 Type II: independent audit of security, availability, and confidentiality controls. Especially relevant for SaaS and platform businesses.
Cyber Essentials Plus: UK government-backed certification for cyber security. Required for many UK government contracts and increasingly expected by enterprise buyers.
Shuttle holds ISO 27001 and SOC 2 Type II in addition to PCI DSS Level 1.
PCI Compliance for AI Voice Agents on Twilio
AI voice agents create a specific PCI challenge: the AI model must never process card data.
When an AI agent (from platforms like PolyAI, or custom agents built on Twilio) needs to collect a payment, the architecture looks like this:
AI agent recognises payment intent: the caller says "I'd like to pay" or the conversation reaches a payment step
Agent triggers
<Pay>: the Twilio call flow activates the secure payment segmentCaller enters card details via DTMF, and the digits never reach the agent or the recording
Shuttle processes the payment: card data goes from Twilio's PCI environment to the gateway via Shuttle's connector
Result returns to the AI agent ("Payment of £49.99 approved") and the agent confirms in natural language
The critical point: the AI model never receives, processes, or has access to card data. The payment happens in a parallel PCI-compliant environment. The AI handles the conversation. The Payment Layer handles the money.
For a deeper technical dive, see how AI voice agents take PCI-compliant payments.
FAQ
Is Twilio PCI compliant? Twilio is PCI DSS Level 1 compliant for its voice and messaging infrastructure. For payments specifically, PCI compliance also depends on your Pay Connector. Using a PCI DSS Level 1 certified connector like Shuttle limits your PCI scope.
What PCI SAQ do I need with Twilio payments? If you're using Twilio's <Pay> verb with a PCI DSS Level 1 certified Pay Connector and no card data touches your systems, merchants typically qualify for SAQ-A, the lightest self-assessment, and platforms complete SAQ-D. Everyone taking card payments has to be PCI compliant, and your acquirer confirms which form applies to you.
Can agents hear card details during Twilio payments? No. When <Pay> is active, the card digits never reach the agent or the recording. The agent stays on the line throughout card entry.
Are Twilio call recordings PCI compliant? Twilio excludes DTMF tones from recordings during <Pay> segments. However, you should verify your recording configuration: if you're using a third-party recording solution, ensure it also suppresses payment audio.
What happens if I build payment capture without <Pay>? You're processing card data through your own infrastructure. That puts you in full PCI scope (SAQ-D: hundreds of requirements). Don't do this.
How much does PCI DSS Level 1 certification cost? Achieving and maintaining PCI DSS Level 1 as a Service Provider is expensive every year, covering the QSA audit, infrastructure, penetration testing, and operational controls. Using a pre-certified provider like Shuttle means you don't need to carry this cost.
Related Reading
What Is Twilio Pay? How It Works, Pricing, and Connectors - the plain-English explainer of the product itself
Twilio Pay Connectors: How to Connect Any Compatible Payment Gateway: the complete guide to Twilio Pay Connectors and multi-PSP routing
Twilio Generic Pay Connector: PCI Scope and Alternatives (why self-hosting the endpoint puts you in SAQ-D territory)
Twilio Stripe Pay Connector: Features, Limits and Alternatives (the native Stripe connector compared with Shuttle)
How to Connect Stripe to Twilio for Voice Payments: step-by-step Stripe + Twilio setup
What Are Voice Payments? The Complete Guide: IVR, agent-assisted, and AI voice payment models
How AI Voice Agents Take PCI-Compliant Payments: DTMF capture and secure handoff architecture
PCI DSS Compliance for Service Providers: what PCI DSS means for payment service providers
Contact Centre Payments: agent-assisted and automated payment flows
Twilio Pay: Connect Any Compatible Payment Gateway to Twilio: install Shuttle's Pay Connector
Shuttle is PCI DSS Level 1 certified. Collect payments over voice calls with zero card data in your environment. Install on Twilio or book a discovery call.