Twilio Stripe Pay Connector: What It Does, Its Limits, and the Multi-Gateway Alternative

The Twilio Stripe Pay Connector is Twilio's native integration between the <Pay> verb and Stripe. It lets you capture card details during a phone call via DTMF and process the charge through your Stripe account, without card data ever touching your servers. If you use Stripe and Twilio, it is the obvious first thing to evaluate.

**Quick answer:** if you have one Stripe account, your call flows charge or tokenise in-call and nothing more, and you run in Twilio's US1 region, the native Stripe connector is the simplest way to start. It is a first-party integration and the only connector supported by Twilio Studio's Capture Payments widget. If you need refunds and post-payment operations tied to your call platform, pre-auth and capture, multiple merchants or gateways, tokens you can reuse across web and payment links as well as voice, or you operate in Twilio's Ireland (IE1) or Australia (AU1) regions, you will outgrow it. In that case the Shuttle Pay Connector does the same job through your same Stripe account, plus 30+ other gateways, without changing your Twilio call flow structure.

This guide covers both honestly: what the native connector does well, where its documented limits are, and what changes when you put Shuttle between Twilio and Stripe instead.

What the Twilio Stripe Connector Supports

The native connector is a solid piece of infrastructure for its core job. According to Twilio's docs, it:

• Processes charge and tokenisation transactions via Stripe, supporting credit cards and ACH debit. One caveat from the connector's own Marketplace listing: ACH can be tokenised in-call, but creating an ACH charge is marked not supported, so ACH collection means tokenise on the call and charge afterwards.

• Supports three token types: one-time and reusable (both returning a Stripe Token id), plus a Stripe-only payment-method type that returns a Stripe PaymentMethod id for saved-card reuse in Stripe.

• Installs via Stripe Connect OAuth. You authorise Twilio's Stripe Connect platform against your Stripe account in a couple of clicks. No API keys to copy, no middleware to deploy.

• Works natively with Twilio Studio. Studio's Capture Payments widget supports only the Stripe Pay Connector, so if your IVR is built entirely in Studio's visual editor, the native connector is the path of least resistance.

• **Sits on Twilio's PCI-certified capture path.** Twilio Voice `<Pay>` is PCI DSS Level 1 for capture, with DTMF tones suppressed from agents and recordings. (Twilio's Pay terms are clear that using `<Pay>` does not by itself make you PCI compliant; see our guide to Twilio PCI compliance for what your responsibilities remain.)

Pricing is straightforward: after being free until 17 January 2024, the Stripe connector now costs $0.15 per successful transaction for the first 10,000 per month, tiering down to $0.04 above 1 million (Twilio changelog, "Changes to Stripe Connector billing behavior"). Stripe's own processing fees apply on top, exactly as they would for any Stripe charge.

For a single-merchant business taking straightforward in-call payments on Stripe, that is a genuinely good setup. Many teams should start here.

Where Teams Outgrow It

The limits below are all documented Twilio behaviour, not speculation. Each tends to surface as a concrete operational problem at a specific stage of growth.

Refunds and post-payment operations live in Stripe, not your call platform

The connector processes charges and tokenisations. Refunds, voids, and any post-payment operation happen directly in the Stripe dashboard or API, disconnected from the call that took the payment. For a support team that takes a payment on a call and then needs to refund it on the next call, that means a second system, separate permissions, and a manual reconciliation step between "what the agent sees" and "what Stripe shows".

No auth-only / capture split

The native connector has no authorise-now-capture-later mode. If you take deposits, bookings, or variable-amount transactions (hotel holds, hire deposits, estimates confirmed after the call), you cannot place a hold during the call and capture the final amount later through the connector. You either charge the full amount up front or build the hold logic yourself directly against Stripe.

No 3DS or SCA option

Twilio tags Stripe (and CardConnect) <Pay> payments as MOTO, telephone order transactions exempt from PSD2 Strong Customer Authentication (Twilio changelog, September 2019). That is a legitimate exemption, and it keeps call flows simple. But it is the only mode: there is no way to step up to authentication when you want it, and the MOTO exemption shifts liability considerations onto the merchant. EU businesses with SCA-sensitive risk policies have no authentication lever to pull.

One Stripe account, no multi-merchant routing

Installation authorises Twilio's Stripe Connect platform against your Stripe account. Routing to your own Stripe Connect sub-accounts or connected accounts is not documented. If you are a platform, marketplace, or BPO taking payments on behalf of multiple clients, each with their own Stripe account, the native connector gives you no way to route call payments to the right merchant.

Not available in IE1 or AU1

Twilio's <Pay> documentation lists the connectors available in the Ireland (IE1) and Australia (AU1) regions as Base Commerce, Braintree, CardConnect, Chase Paymentech, Generic Pay Connector, and Shuttle. Stripe is absent from that list. If data residency requirements put your voice traffic in IE1 or AU1, the native Stripe connector is simply not an option there.

Metadata is a workaround, and the customer field is out of reach

Passing your own reference data (an order id, case number, or database GUID) with the payment is a documented pain point: Twilio's docs cover the `<Parameter>` noun only for the Generic Pay Connector. There is a partial workaround that Twilio support shares when asked (and that surfaces on Stack Overflow): a <Parameter> whose name is prefixed with metadata_ lands in Stripe's metadata for charges and reusable tokens. It does not work for one-time tokens. For customer fields, the connector's Twilio Marketplace listing shows one option: an optional CustomerPhone parameter on reusable tokenisation (with the PII retained for 120 days). Beyond that, customer details and statement descriptors cannot be set from the call. What you do get back on reusable tokenisation is the Stripe customer resource id, returned as ProfileId in the callback, so the usual pattern is to update that Customer afterwards in your webhook via the Stripe API. Teams that reconcile call payments against internal records end up leaning on the description field or matching downstream in Stripe rather than tagging the transaction properly at capture time.

This is a place where the Shuttle connector is concretely different: it supports the `<Parameter>` noun directly, with `account_` names for customer details (first name, last name, email) and `metadata_` names for your own reference data, documented in Shuttle's Twilio integration guide.

Tokens are Stripe-shaped and Stripe-scoped

The reusable and payment-method token types return Stripe token and PaymentMethod ids. That is exactly right if your whole payment estate is Stripe. But the token reuse story stops at Stripe's edge: there is no cross-gateway token, and reuse across other channels is whatever you build against Stripe yourself.

None of these are flaws in what Twilio built. They are the natural boundary of a single-gateway, charge-and-tokenise connector. The question is whether your requirements sit inside that boundary.

Twilio + Shuttle + Stripe: What Changes

Shuttle is Twilio's payment partner and provides its own Pay Connector, launched on Twilio in December 2023 (Twilio changelog) and listed by name in Twilio's `<Pay>` TwiML documentation for the IE1 and AU1 regions. The important thing to understand: Stripe stays your gateway. Shuttle routes the same transaction to your own Stripe account, and your Stripe fees are unchanged. You are not switching processors; you are swapping the connector that sits between Twilio and Stripe.

What you gain by making that swap:

• **Refunds, pre-auth and capture, and richer payment operations** run through Shuttle's dashboard and API, rather than requiring gateway-by-gateway work outside the call flow. Take a deposit hold on the call with `<Parameter name="action" value="AUTH"/>`, capture the balance later, refund from the same place your team manages call payments. See post-payment operations in Shuttle's docs.

• Recurring payments set up in the call itself. Pass <Parameter name="frequency" value="MONTHLY"/> (with an optional occurrences) in your TwiML and the caller's card is charged on a schedule from that single call. On the native connector, recurring means tokenising in-call and then building the subscription yourself in Stripe afterwards.

• **30+ gateways through the same connector.** Start with Stripe, then add, switch, or route to others without changing the Twilio call flow. The `paymentConnector` attribute keeps pointing at Shuttle; routing is configuration. This matters most when enterprise customers mandate a specific PSP or when a second acquirer improves authorisation rates in a new market.

• Multi-PSP routing by merchant, region, amount, or failover.

• **Multi-merchant and multi-tenant management.** Platforms and BPOs can hold each client's own Stripe account (or any other gateway account) as a separate payment profile and route each call payment to the right merchant.

• **Cross-channel tokens.** Capture a card once on a call and reuse the token across web, mobile, voice, and payment links. Shuttle also supports sending a payment link as a fallback when a caller cannot complete DTMF entry.

• IE1 and AU1 availability. Shuttle is one of the connectors Twilio documents for both regions, so data-residency-constrained deployments can still take Stripe payments in-call.

• **PCI posture stays clean.** Shuttle is a PCI DSS Level 1 Service Provider; card data flows Twilio to Shuttle to Stripe, your systems see only redacted results, and you stay at SAQ-A. See PCI scope for what that means in practice.

The honest trade-offs in the other direction: Twilio Studio's Capture Payments widget supports only the Stripe connector, so Studio-built flows using that widget favour native. And on price, at entry volume the native connector is cheaper per transaction.

Comparison: Native Stripe Connector vs Shuttle Pay Connector

On pricing, be clear-eyed: at entry volume the native Stripe connector costs less per transaction ($0.15 vs $0.20), and the tiers descend differently at scale. The case for Shuttle is capability and flexibility, not entry price. If the native feature set covers you, it is the cheaper connector.

How to Switch

Moving from the native Stripe connector to Shuttle is a connector swap, not a migration:

1. Install the Shuttle Pay Connector from the Twilio Marketplace.

2. **Add your Stripe keys as a payment profile** in the Shuttle dashboard. Same Stripe account, same fees; full setup steps in our Stripe + Twilio integration guide.

3. Change the `paymentConnector` attribute in your TwiML from the Stripe connector to shuttle-pay-connector. The rest of your <Pay> flow stays as it is.

Your existing Stripe reporting continues uninterrupted, because the transactions still land in your Stripe account. Test in Stripe's test environment first, then flip the connector attribute in production.

Twilio Stripe Connector FAQ

Does Twilio support Stripe? Yes. Twilio has a native Stripe Pay Connector for the <Pay> verb that processes charges and tokenisations through your Stripe account, supporting credit cards and ACH debit. One caveat from the connector's own Marketplace listing: ACH can be tokenised in-call, but creating an ACH charge is marked not supported, so ACH collection means tokenise on the call and charge afterwards. Shuttle's Pay Connector also supports Stripe, alongside 30+ other gateways, through the same <Pay> integration.

What does the Twilio Stripe connector cost? $0.15 per successful transaction for the first 10,000 per month, tiering down to $0.04 above 1 million (it was free until 17 January 2024). Stripe's processing fees apply on top. The Shuttle connector is $0.20 per successful transaction for the first 50,000 per month, tiering down to $0.05 above 1 million.

Can Twilio Pay do refunds? Not through the Stripe connector. It processes charge and tokenisation transactions; refunds and other post-payment operations happen directly in Stripe. With the Shuttle connector, refunds and pre-auth/capture run through Shuttle's dashboard and API.

Does Twilio Pay support 3D Secure? No. Twilio tags Stripe and CardConnect <Pay> payments as MOTO (telephone order), which is exempt from PSD2 SCA, and no authentication option exists. If you want an authenticated flow for specific transactions, a payment link sent during the call is the usual pattern.

**How do I pass additional information (like an order id or metadata) through the Twilio Stripe connector?** Officially, the `<Parameter>` noun is documented only for the Generic Pay Connector. In practice, Twilio support confirms a workaround: add a `<Parameter>` with a name prefixed `metadata_` (for example `<Parameter name="metadata_orderId" value="1234" />`) and it lands in Stripe's metadata for charges and reusable tokens. It does not work for one-time tokens. Customer fields are limited to an optional `CustomerPhone` parameter on reusable tokenisation (shown in the connector's Marketplace listing); everything else is updated in your webhook via the Stripe API using the `ProfileId` the connector returns. The Shuttle connector supports `<Parameter>` directly: pass customer details with `account_` names (such as `account_first_name`, `account_email`) and your own reference data with `metadata_` names, and they flow through with the transaction. See Shuttle's Twilio integration docs for the full parameter reference.

**Can I use multiple payment gateways with Twilio Pay?** Not with the native Stripe connector, which is Stripe-only. The Shuttle Pay Connector connects one Twilio integration to 30+ gateways with routing by merchant, region, amount, or failover, so platforms and BPOs can run every client's own gateway account through one call flow. See Twilio Pay Connectors for the full picture.

Can Twilio Pay take ACH payments? It depends on the connector. The Stripe Pay Connector can tokenise ACH in-call (with AVS name, country, and currency parameters) but its Marketplace listing marks ACH charging as not supported, so collecting an ACH payment means tokenising on the call and charging afterwards in Stripe. The Braintree connector does not support ACH at all. The Shuttle connector supports both ACH tokenisation and ACH charges in-call.

Does Twilio Pay support recurring payments? Not through the native Stripe connector: you tokenise on the call, then build the subscription yourself in Stripe. With the Shuttle connector, pass <Parameter name="frequency" value="MONTHLY"/> (and optionally occurrences) in your TwiML and the recurring schedule is created from that single call.

How do I switch Pay Connectors? Install the new connector from the Twilio Marketplace, configure it (for Shuttle, add your gateway credentials as a payment profile), and change the paymentConnector attribute in your TwiML. Your <Pay> flow structure does not change.

Related Reading

• Twilio Pay Connectors: How to Connect Any Payment Gateway - the complete guide to Twilio Pay Connectors and multi-PSP routing

• How to Connect Stripe to Twilio for Voice Payments - step-by-step Stripe + Twilio setup via Shuttle

• Twilio Generic Pay Connector: Build vs Buy - what building your own connector actually involves

• Twilio PCI Compliance: Payments Without Handling Card Data - keeping your PCI scope at SAQ-A

• Stripe via Shuttle - how Shuttle supports Stripe across voice, links, and web

• When Enterprise Customers Mandate a PSP - why gateway flexibility becomes a sales requirement

*Keep Stripe, gain routing, refunds, and 30+ gateways through one Twilio connector. Install on Twilio or book a discovery call.*