Twilio Pay Error Codes Explained: What Your Pay Connector Actually Supports

If Twilio's <Pay> verb just threw a 64xxx error at you, here's the thing to understand before you touch any code: these errors split into two kinds.

Integration errors are mistakes in your TwiML or connector configuration. You fix them by correcting an attribute, adding a <Parameter>, or updating credentials. Errors 64001, 64003, 64004, 64014, and 64015 live here.

**Capability errors** mean your Pay Connector does not support the operation you asked for. No TwiML change fixes these, because the limit is in the connector itself. Errors 64005, 64006, 64007, 64011, and 64013 live here. If you hit one of these, the honest fix is either changing what you're asking for or changing connector.

Quick answer: Error 64007 ("Connector does not support creating charge") and error 64006 ("Connector does not support token type") are usually not bugs. Each Pay Connector supports a specific set of operations, payment methods, and token types. If you request an ACH charge through a connector that only tokenises ACH, Twilio returns 64007 by design. Check your connector's Twilio Marketplace listing for its capability table before debugging your TwiML.

Every code below is documented on Twilio's official error pages (twilio.com/docs/api/errors). Here's what each one means and what to do about it.

Quick Reference: The 64xxx Pay Error Series

Error 64007: Connector does not support creating charge

This is the one that sends most developers to Google. Twilio's official description: "the request to create a charge on the credit card failed because the connector does not support making charges." The documented cause: "The paymentConnector attribute points to a Connector that does not support charging."

You set a chargeAmount, so Twilio tried to create an immediate charge, and your connector said it cannot do that for this payment method.

When it's expected behaviour, not a bug: connectors declare, per payment method, whether they support tokenising, charging, or both. The Stripe Pay Connector's own Twilio Marketplace listing marks ACH "Creating a Charge" as not supported: on that connector, ACH can only be tokenised in-call, with the actual debit created later through Stripe's API. So if you send paymentMethod="ach-debit" with a chargeAmount through the Stripe connector, 64007 is the connector working exactly as designed. That's a design boundary, not a flaw.

Your options:

1. Tokenise instead of charging. Remove chargeAmount (or set it to 0) and set tokenType. You get a token back and create the charge server-side via your gateway's API.

2. Switch to a payment method the connector can charge. Card charges work on all the branded connectors.

3. Switch connector. If your business flow genuinely needs in-call ACH charges, you need a connector that supports them (see the capability table below).

Error 64006: Connector does not support token type

Official description: the "request to tokenize credit card failed because the connector does not support tokenization," with the cause given as "The paymentConnector attribute points to a Connector that does not support the requested type of tokenization."

The <Pay> verb's tokenType attribute accepts values like one-time and reusable. Not every connector supports every value for every payment method. Twilio's documented fix is twofold: "Make sure that the paymentConnector matches a <Pay> Connector that supports the tokenization type you want" and "Make sure you specify the tokenType that matches what you want to perform."

Fix: check the connector's Marketplace listing for which token types it supports, then either change your `tokenType` value to one it accepts, or change connector. Its sibling, error 64005 ("Connector does not support tokenization"), fires when the connector cannot tokenise at all; Twilio also notes it can fire when "the chargeAmount attribute in the Pay Verb TwiML was 0 (or omitted) and you intended to charge," so double-check you didn't drop the amount by accident.

Error 64013: Connector does not support supplied paymentMethod attribute

Official description: "the provided paymentMethod attribute was not supported by the Connector." Twilio's own example: "a credit card might have been supplied but the Connector did not support Credit Cards."

In practice this is the ACH wall. The Braintree Pay Connector does not support ACH at all, per its Twilio Marketplace listing, so paymentMethod="ach-debit" through Braintree fails regardless of whether you're charging or tokenising. Again: capability limit, not misconfiguration. The fix is a payment method the connector supports, or a connector that supports your payment method.

Errors 64001, 64004, 64009: configuration problems

These three are fixable in the Twilio Console without touching your call flow.

• 64001 (Configuration Error): something is wrong with the connector configuration itself. Twilio lists credentials removed, credentials that don't match the connector type, missing credentials, or invalid attributes. Re-open the connector in the Console and re-enter credentials.

• 64004 (Invalid paymentConnector attribute): the value in your paymentConnector attribute "does not match to a Pay Connector configuration." Usually a typo. The attribute must match the connector's Unique Name exactly, so check your list of installed connectors in the Console.

• 64009 (Twilio no longer authorised): the credentials in the connector configuration "no longer allow Twilio to perform requests on behalf of your account," typically because access was revoked on the gateway side. Recreate the connector configuration and re-authorise.

Errors 64003, 64014, 64015: TwiML fixes

• 64003 (Invalid charge amount): the chargeAmount has "a number of decimals that does not conform to the currency type," for example three decimals on USD. Fix the amount format.

• 64014 (ECP/ACH requires AVSName): ACH payments need a name. Add <Parameter name="AVSName" value="john smith" /> inside the <Pay> verb.

• 64015 (missing needed Parameter): the connector requires a <Parameter> you haven't passed. Twilio points you to the connector's own listing: "The required parameters for the connector are listed in the 'Description' section of the connector." Braintree, for instance, requires MerchantAccountId.

Errors 64002, 64008, 64010, 64012: not your code

• 64002 (Service unavailable): transient internal or gateway outage. Twilio's advice is to retry.

• 64008 (Gateway rejected charge creation) and 64010 (Gateway rejected token creation): the connector passed your request through and the payment gateway said no. Inspect the data posted to your action webhook and check with your gateway.

• 64012 (Gateway rejected the card): a plain decline. Twilio suggests checking the PaymentError in the response and re-prompting the caller.

Capability Limits by Connector

The pattern across 64005, 64006, 64007, 64011, and 64013 is the same: <Pay> is a standard interface, but each connector implements a different slice of it. Here's an honest summary of what the main connectors do:

The Generic Pay Connector deserves a note: it has no fixed capabilities because it's a framework. Twilio posts the captured payment details to an endpoint you build, and that endpoint's capabilities are yours to implement, along with the PCI obligations that come with processing card data.

When the Fix Is a Different Connector

If you keep hitting 64006, 64007, or 64013 because your flow needs something your connector doesn't do, the migration is smaller than it sounds. Pay Connectors are interchangeable behind the same <Pay> verb: swapping the paymentConnector attribute is the whole migration. Your DTMF capture, your Studio flow, your action webhook handling all stay the same.

Shuttle's Pay Connector exists for exactly this situation:

• Card and ACH, charge and tokenise, all in-call. The operations that trigger 64007 and 64013 on other connectors are supported.

• Auth/capture, scheduled, and recurring payments configured via <Parameter> elements in the same <Pay> verb.

• **Refunds, captures, and voids after the call** through the Shuttle API (docs.shuttleglobal.com/docs/twilio-integration-guide), so post-call operations don't need gateway-specific code.

• **30+ gateways behind one connector.** Shuttle routes to Stripe, Adyen, Worldpay, Braintree, and 30+ others, so a gateway change later doesn't mean another connector migration.

• PCI DSS Level 1 Service Provider, keeping card data off your systems entirely.

• $0.20 per successful transaction, installed from the Twilio Marketplace.

Twilio Pay Error Codes FAQ

What does Twilio error 64007 mean? It means the request to create a charge failed because your Pay Connector does not support charging for the payment method you supplied. It is usually a connector capability limit, not a bug: for example, the Stripe Pay Connector supports tokenising ACH in-call but not charging it. Either tokenise and charge server-side, or use a connector that supports in-call charges for that method.

Why can't I charge ACH with Twilio Pay? It depends on the connector. Per their Twilio Marketplace listings, the Stripe connector supports ACH tokenisation but not ACH charge creation, and the Braintree connector does not support ACH at all. Shuttle's connector supports both charging and tokenising ACH in-call. If ACH charges matter to your flow, pick the connector accordingly.

How do I fix "connector does not support token type" (64006)? First check that your tokenType attribute (one-time or reusable) matches what your connector's Marketplace listing says it supports for that payment method. If the token type you need isn't supported, no TwiML change will fix it; you'll need a connector that supports that token type.

Can I use a different Pay Connector without rewriting my call flow? Yes. The <Pay> verb is connector-agnostic: change the paymentConnector attribute to the new connector's Unique Name and the rest of your TwiML, Studio flow, and webhook handling stays the same. Install the new connector from the Twilio Marketplace, add your gateway credentials, and update the attribute.

Which Twilio Pay errors should I retry automatically? Only 64002 (Service unavailable) is a genuine retry candidate. Gateway rejections (64008, 64010, 64012) need the webhook's PaymentError detail before retrying, and capability errors (64005, 64006, 64007, 64011, 64013) will fail identically every time until the request or the connector changes.

Related Reading

• Twilio Pay Connectors: How to Connect Any Payment Gateway - how connectors work and how to choose one

• Twilio Stripe Pay Connector: Setup and Limits - what the Stripe connector does and doesn't support

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

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

• Twilio Pay - Connect Any Payment Gateway to Twilio - Shuttle's connector, supported gateways, and pricing

*Hitting connector capability walls? Shuttle's Pay Connector supports card and ACH charge and tokenise in-call, plus auth/capture, scheduled, and recurring payments, across 30+ gateways at $0.20 per successful transaction. Install on Twilio or book a discovery call.*