Quick answer: yes, you can take ACH payments over the phone. The caller keys their bank routing number and account number into the keypad, the digits are captured inside a PCI-compliant environment, and the payment is debited directly from their US bank account. The catch is connector support: some Twilio Pay Connectors can tokenise a bank account in-call but cannot actually charge it. This guide covers how phone ACH capture works, which connectors do what, and the compliance points to get right.
What Is ACH, Briefly
ACH is the US bank-to-bank payment network, governed by NACHA. Instead of a card number, the payer provides two things: a bank routing number and an account number. The debit pulls funds directly from their checking or savings account.
Three properties make ACH interesting for phone payments:
Lower cost. ACH fees are typically flat or capped rather than a percentage of the transaction, so the saving over cards grows with the amount. On a $5,000 invoice, the difference is real money.
No card expiry churn. Bank accounts don't expire every three years. For payment plans and recurring billing, an ACH mandate keeps working long after a card on file would have failed.
Slower settlement. ACH is not instant. Debits typically settle in one to a few business days, and a payment can still be returned after that (insufficient funds, closed account, disputed authorisation). ACH has a defined set of return codes for these cases, so your reconciliation needs to treat "submitted" and "cleared" as different states.
None of this changes on a phone call. What changes is how you capture the account details securely, which is the rest of this guide.
Why Take ACH by Phone
Most phone payment guides assume cards. But there are call types where ACH is the better default:
Bill pay and utilities. Callers paying a monthly bill often prefer their bank account, and billers prefer the lower processing cost on high-volume, repeat payments.
**Collections and payment plans.** Debt collection agencies live on multi-month instalment plans. A card set up on a collections call has a meaningful chance of expiring, being reissued, or being cancelled before the plan completes. A bank account rarely does. Lower fees also matter when margins on recovered debt are thin.
Insurance premiums. Annual and monthly premium payments are large, recurring, and price-sensitive on fees. Premium finance especially suits ACH mandates agreed on a call.
Large B2B amounts. When a customer phones to settle a $20,000 invoice, 2.9% card fees are hard to justify. A flat ACH fee is not.
The common thread: high amounts, repeat payments, or both. That is exactly where ACH's economics beat cards, and exactly the kind of payment that often happens on a phone call with an agent or an IVR.
How Phone ACH Capture Works
The mechanics mirror card capture over the phone, with bank details in place of a PAN.
On Twilio, the <Pay> verb supports paymentMethod="ach-debit". The flow:
The call reaches the payment step. Your IVR flow, Studio flow, or agent screen triggers
<Pay>with the ACH payment method.The caller keys in their details. They enter their bank routing number, then their account number, on the phone keypad (DTMF). No reading digits aloud.
The tones are suppressed. The DTMF tones are captured inside Twilio's PCI-compliant environment and suppressed from the agent's audio and from call recordings. The agent stays on the line but never hears or sees the account number.
The connector processes the payment. The captured bank details pass to your Pay Connector, which either charges the account or tokenises it for later use. Your systems receive a result and a redacted reference, never the raw account number.
Agent-assisted vs IVR
Both modes use the same capture flow:
Agent-assisted: the agent stays on the call, triggers the payment step, and talks the caller through it while the keypad entry is masked. Best for collections and negotiated payment plans, where the payment follows a conversation.
IVR / self-service: the caller pays without an agent, prompted by the IVR. Best for bill pay lines that run 24/7. ACH prompts in Twilio
<Pay>are available in English language variants.
One practical note for ACH specifically: routing plus account number is more digits than a card number, and callers are less likely to know their account number from memory than to have a card in hand. Good prompt design ("you'll find both numbers at the bottom of a check, or in your banking app") measurably improves completion rates.
Connector Support: The Part That Bites
This is where most "twilio pay ach" research ends up, because ACH support varies sharply by Pay Connector. Twilio's <Pay> verb defines two operations: creating a charge, and tokenising a payment method for later use. For cards, most connectors support both. For ACH, they diverge:
**Stripe Pay Connector.** The Twilio Marketplace listing for the Stripe connector supports ACH tokenisation in-call, but marks ACH "Creating a Charge" as not supported. So you can capture and tokenise a bank account during the call, but the debit itself has to be created afterwards through Stripe's API, from your own systems. The listing also requires `AVSName`, `AVSCountry`, and `AVSCurrency` parameters when creating ACH tokens, so budget for the extra plumbing. We cover this connector in depth in the Twilio Stripe Pay Connector guide.
Braintree Pay Connector. Braintree's Marketplace listing does not list ACH support at all. Cards only. If your gateway is Braintree and you need phone ACH, you need a different connector in front of it or a different rail.
**Shuttle Pay Connector.** Shuttle supports both ACH charge and ACH tokenisation in-call. Twilio's changelog for the Shuttle connector describes support for "credit card and ACH-debit payment methods", and Shuttle's own docs cover the `ach-debit` flow, including the `bankAccountType` parameter for consumer or business checking and savings accounts. The caller keys in their details, and the debit is created on the same call, with the confirmation read back before they hang up. ACH bank debits through Shuttle are US only; cards work internationally through 30+ gateways from the same connector.
The difference matters operationally. Tokenise-only means you build and maintain a second leg: a service that takes the token after the call and creates the charge, handles failures, and reports back to the agent or CRM. Charge-in-call means the payment either succeeds or fails while the caller is still on the line, which is precisely when you want to know.
If none of the managed connectors fit and you're considering Twilio's Generic Pay Connector, note that for ACH it posts the raw `bankaccountnumber` and `routingnumber` to an endpoint you host. That endpoint is now handling sensitive bank data, with the scope implications covered in our Generic Pay Connector guide.
ACH Payment Plans on a Call
The strongest phone ACH pattern is not the one-off payment. It's the plan.
A collections agent agrees a plan on the call: $200 a month for 12 months. With Shuttle's connector, the agent captures the bank account once via <Pay>, and the recurring schedule is set in the same TwiML using <Parameter> values:
``xml <Pay paymentConnector="shuttle-pay-connector" paymentMethod="ach-debit" chargeAmount="200.00" action="/payment-complete"> <Parameter name="frequency" value="MONTHLY"/> <Parameter name="occurrences" value="12"/> </Pay> ``
The first debit is taken on the call, the remaining eleven run on schedule, and no one re-keys anything. Because it's a bank account rather than a card, the plan is not exposed to expiry churn: no month-seven failure because the card was reissued.
The same pattern fits premium finance (monthly instalments on an annual premium agreed with an agent), utility budget plans, and B2B instalment agreements. For teams running this at scale, BPOs and contact centres can run card and ACH plans through the same connector, choosing the rail per merchant or per call.
Alternatively, tokenise the account without charging it (omit the charge amount), store the vaulted token, and drive the schedule from your own billing system via Shuttle's API. Shuttle also supports ACH via payment link if the caller would rather complete the details after the call.
Compliance Notes
Two regimes apply to phone ACH, and they cover different things.
**PCI DSS covers the capture environment.** Strictly, PCI scope is about card data, but the same architecture question applies: where do the sensitive digits land? With Twilio `<Pay>` plus a certified connector, DTMF capture and suppression happen in Twilio's PCI-compliant environment, processing happens in Shuttle's (PCI DSS Level 1), and your systems only ever see redacted references. For card payments through the same flow, that keeps you at SAQ-A, the lightest self-assessment. The full picture is in our Twilio PCI compliance guide.
NACHA rules cover the authorisation. ACH debits initiated over the phone come with authorisation requirements under NACHA's operating rules. In broad terms: the caller must clearly and unambiguously authorise the debit, and an oral authorisation must be recorded or confirmed in writing, with the authorisation evidence retained. The exact requirements depend on the entry type and your setup, so confirm the specifics with your payment processor or ODFI before you launch. Practically, most teams handle this with a scripted authorisation statement on the call plus either the (payment-redacted) call recording or a follow-up confirmation email.
Neither regime is a reason to avoid phone ACH. Both are solved problems, but they're solved by design decisions you make before the first call, not after.
Phone ACH Payments FAQ
Can you take ACH payments over the phone? Yes. The caller keys their routing number and account number into the phone keypad, the digits are captured in a PCI-compliant environment with tones suppressed from agents and recordings, and the debit is processed against their US bank account. Both agent-assisted and self-service IVR flows work.
Does Twilio Pay support ACH? Yes. Twilio's <Pay> verb supports paymentMethod="ach-debit", capturing the routing and account number via DTMF. But charge and tokenisation support varies by Pay Connector, so check your connector's Marketplace listing before you design the flow.
Why can't the Stripe connector charge ACH in-call? The Twilio Stripe Pay Connector's Marketplace listing supports ACH tokenisation but marks ACH "Creating a Charge" as not supported. It's a boundary of that connector's design: you tokenise the bank account during the call, then create the debit afterwards through Stripe's API from your own systems. Shuttle's connector supports both operations in-call.
Is phone ACH PCI compliant? The PCI DSS framework is card-focused, but the capture architecture is the same one PCI demands: with Twilio <Pay> and a certified connector, bank details are keyed via DTMF, suppressed from agents and recordings, and never touch your systems. Separately, NACHA rules require that oral authorisations for phone ACH debits be recorded or confirmed in writing; confirm specifics with your processor.
Can I set up recurring ACH from a call? Yes. With Shuttle's connector you capture the bank account once via <Pay> and set the schedule in the same TwiML using <Parameter> values for frequency and occurrences, for example monthly for 12 payments. Because bank accounts don't expire like cards, ACH plans avoid mid-plan card-expiry failures.
Related Reading
Twilio Pay Connectors: How to Connect Any Payment Gateway: the complete guide to connectors, including the Generic Pay Connector's data implications
Twilio Stripe Pay Connector: Setup and Limits: what the Stripe connector supports, in detail
Twilio Pay Error Codes Explained: diagnosing failed captures and declined payments
Secure Payment Collection for Debt Agencies: compliant collections payments across channels
Payment Collection for BPOs: multi-client payment operations at scale
Contact Centre Payments: the full guide to taking payments in a contact centre
Twilio PCI Compliance: Payments Without Handling Card Data: how to keep your PCI scope at SAQ-A
Twilio Pay: Connect Any Payment Gateway to Twilio: all supported gateways, pricing, and setup
*Take ACH and card payments over the phone with Shuttle's Pay Connector: PCI DSS Level 1, $0.20 per successful transaction, no setup fees. Install on Twilio or book a discovery call.*