Building an IVR on Twilio is the easy part: menus, routing, and personalisation are all a few lines of TwiML. Taking a payment inside that IVR is where most teams stall, because card data brings PCI DSS into the picture and nobody wants their infrastructure anywhere near a card number.
The good news: Twilio solved the capture side with the <Pay> verb, and a Pay Connector solves the processing side. Wired together properly, your IVR takes card and ACH payments while your systems never see a single digit, which heavily reduces your PCI scope. Here is the full setup, current as of July 2026.
This tutorial covers the build. For the compliance side (where PCI scope is created on Twilio, SAQ A versus SAQ D, and how to keep card data out of your IVR logs and recordings), see Twilio PCI Compliance.
What You Need Before You Start
A Twilio account with Programmable Voice
A payment gateway account (Stripe, Adyen, Worldpay, Cybersource, or any of 30+ supported gateways)
A Shuttle account at merchant.shuttleglobal.com/twilio ($49 per live instance per month, plus from $0.20 per transaction, falling with volume, billed through your Twilio account, see pricing)
Step 1: Enable PCI Mode on Your Twilio Account
Twilio requires PCI Mode before <Pay> will run. In the Twilio Console:
Navigate to Voice Settings
Click "Enable PCI Mode"
Accept the terms and save
PCI Mode redacts sensitive payment details from your logs and recordings account-wide. Note that it applies per Account SID and enabling it is a deliberate, one-way choice, so do it on the right account.
Step 2: Install the Shuttle Pay Connector
In the Console, type <Pay> Connectors in the "Jump to" search box and select the Shuttle Pay Connector from the catalogue. Configure it with:
Unique Name:
shuttle-pay-connector(note this down, your TwiML references it)Username: your Shuttle instance key
Password: your Shuttle secret key
Both keys come from your Shuttle dashboard.
Step 3: Connect Your Payment Gateway
Log into the Shuttle dashboard and create a payment profile with your gateway credentials (for example your Stripe secret key, or your Adyen API key and merchant account). This is the piece that makes the integration gateway-agnostic: your IVR code never changes if you later add a second gateway or route different calls to different merchant accounts.
Step 4: Add the Pay Verb to Your IVR
Wherever your call flow reaches the payment step, return TwiML like this:
<Response>
<Say>Please enter your card number followed by the hash key.</Say>
<Pay paymentConnector="shuttle-pay-connector"
chargeAmount="49.99"
currency="GBP"
description="Invoice payment"
action="/payment-complete">
<Parameter name="metadata_invoiceId" value="INV-1234"/>
</Pay>
</Response>The caller keys in their card number, expiry, and CVV. Twilio captures the digits inside its PCI-certified environment, so they never reach an agent or a recording, and passes the card data to Shuttle, which processes it through your gateway.
A few options worth knowing:
Tokenise instead of charge: omit
chargeAmountto save the card without charging itTake a deposit hold: add
<Parameter name="action" value="AUTH"/>to authorise now and capture laterSet up a recurring payment from the call: add
<Parameter name="frequency" value="MONTHLY"/>Attach your own references:
metadata_parameters flow through to your webhook for reconciliation, andaccount_parameters (first name, last name, email) attach customer detailsTake ACH instead of card (through Authorize.net): set
paymentMethod="ach-debit"and the caller enters routing and account numbers instead (see our guide to ACH payments over the phone)
Step 5: Handle the Result
Twilio POSTs the outcome to your action URL: the result status, masked card number, card type, and a confirmation code you can use to find the transaction in your gateway. Update the order, confirm to the caller with a <Say>, and carry on with the call. Refunds, captures, and voids afterwards run through the Shuttle API rather than the phone flow.
Step 6: Test Before You Go Live
Shuttle provides a demo application so you can test the full flow without writing your webhook first: map a Twilio number to the demo URL shown in the Shuttle dashboard, call it, and make a test payment against your gateway's sandbox credentials. Then swap in your own TwiML and go live.
If you hit an error during testing, it is usually one of Twilio's <Pay> error codes: 64001 means the connector configuration is wrong, 64004 means the paymentConnector name in your TwiML does not match the Unique Name you set, and the 64006/64007 family means the connector you are using does not support what you asked for. We keep a full reference of all 15 Twilio Pay error codes and what each one means.
Beyond Basic IVR
The same setup extends to:
Agent-assisted payments: contact centre agents trigger secure capture mid-conversation using Twilio's Payments API, staying on the line while the customer keys in details they never hear. See contact centre payments.
AI voice agents: autonomous agents hand the payment step to the same secure flow, so card data never enters the AI pipeline. See how AI voice agents take PCI-compliant payments.
Payment links as a fallback: if a caller cannot complete keypad entry, send an SMS payment link mid-call and watch it complete in real time.
The Compliance Position
With this architecture, Twilio handles DTMF capture and suppression, Shuttle (a PCI DSS Level 1 Service Provider) handles the card data and gateway processing, and your application only ever receives redacted results. That heavily reduces your PCI scope compared with card data touching your systems. 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.
Ready to take payments on your Twilio IVR? Install the Shuttle Pay Connector from the Twilio Marketplace, or book a discovery call.