Stripe Will Now Take a Plaid Token Directly for ACH. Over Half Your Signups Already Have One.

Every ACH verification method Stripe has offered until now assumes the customer is starting from zero: no connection to their bank exists yet, so go build one. Microdeposits build it slowly, over one to two business days per deposit. Financial Connections builds it fast, through a bank login screen, but still makes the customer do it right there in your checkout. On October 28, 2026, Stripe shipped a third option that skips the "starting from zero" assumption entirely — if the customer already proved their bank account to Plaid for some other app, you can now hand that proof straight to Stripe and get a verified payment method back, no new verification step at all.

What actually shipped on October 28

The change is narrow and specific, which is exactly why it's easy to miss in a changelog full of bigger-sounding items. Stripe added an external_token parameter to the us_bank_account hash. Set type to plaid_processor_token, pass the token itself in plaid_processor_token, and Stripe calls out to Plaid to retrieve and verify the underlying account on your behalf before creating a verified us_bank_account PaymentMethod. You can send it when creating a PaymentMethod directly, or embed it in payment_method_data on a PaymentIntent or SetupIntent create or confirm call. It shipped under the 2026-10-28.preview API version, alongside the Wero bank redirect support we covered from the same release.

Stripe's own description of the impact is blunt about who this is for: "If your integration already uses Plaid to verify bank accounts, pass the processor token to Stripe instead of using microdeposits, Financial Connections, or bank account tokens." That's a narrower audience than every SaaS company taking ACH payments — it's specifically the ones whose product, or whose other vendors, already run Plaid for something unrelated to billing.

Why "already verified somewhere else" is a bigger pool than it sounds

That audience is larger than it looks at first glance, and it's getting larger every year. Plaid's own reporting puts roughly a quarter of U.S. bank account holders as having used Plaid in 2019, about a third by 2023, and over half by 2025. A SaaS product doesn't need to run Plaid itself to benefit from that growth — any customer who connected a bank account to Venmo, Robinhood, a budgeting app, a BNPL provider, or a payroll platform in the last few years has very likely already done a Plaid-powered verification. If your own product, or a partner product you're integrated with, captured that same processor token, you're now allowed to reuse it instead of asking the customer to prove their bank account all over again.

That trend line is the whole business case for this parameter. Every point of growth on that chart is a point where asking a customer to re-verify a bank account they've already verified elsewhere stops being a formality and starts being pure, avoidable friction. Plaid's own benchmark data claims a 23% lift in conversion for instant verification over manual micro-deposit flows — a number worth treating as a vendor claim rather than an independent audit, but directionally consistent with what you'd expect from cutting a one-to-two-day wait down to nothing.

Three paths to a verified ACH payment method, compared

We've covered the mechanics of ACH failures after the fact and the mechanics of a working bank link quietly expiring in earlier pieces. This slots in earlier than either of those — at the moment you're trying to get a verified payment method in the first place.

The row that matters is the last column. Microdeposits break down on patience — the gap between "I entered my bank details" and "I confirmed the deposit amounts" is exactly where a self-serve signup quietly disappears, because nothing in that gap feels urgent to the customer. Financial Connections removes the wait but keeps the step: the customer still has to do something, inside your flow, at signup. The processor token path is the only one of the three where, from the customer's side, nothing visibly happens at all. That's also its limit — it only applies when the Plaid relationship already exists, which rules it out as a universal replacement for the other two.

Who this is actually built for

Read Stripe's own framing again: "if your integration already uses Plaid to verify bank accounts." That's not every SaaS company — it's specifically products built on top of, or adjacent to, financial data. A few concrete shapes:

• Lending and underwriting tools that pull Plaid data to assess an applicant's bank account before approving a loan or line of credit, and then need to bill that same customer recurring fees or payments afterward.
• Expense management and corporate card platforms that already connect a company's operating account via Plaid for reimbursement or funding purposes, and separately bill that company a SaaS subscription fee.
• Neobanks and personal finance apps whose core product is built on Plaid-linked accounts, and who also run a subscription tier on top of the same linked account.
• Marketplaces or platforms with embedded finance that already verified a seller's or vendor's payout account through Plaid and now need to collect a platform fee from that same account.

If none of those describe your business and you have no existing Plaid relationship anywhere in your stack, this parameter does nothing for you directly — you're still choosing between microdeposits and Financial Connections, the same choice you had before October 28. The news here isn't "ACH got easier for everyone." It's "ACH got easier for the specific companies sitting on financial data they weren't allowed to reuse for payment verification until now."

The integration shape

Because this is additive to existing PaymentMethod, PaymentIntent, and SetupIntent creation calls rather than a new endpoint, the integration lift is smaller than standing up a fresh Financial Connections flow:

1. Pin the API version explicitly to 2026-10-28.preview or later for any request using external_token — preview-channel parameters aren't guaranteed stable until they graduate off preview.
2. Capture the Plaid processor token from whichever Plaid-powered flow already runs in your product — the same token you'd otherwise use with Plaid's own Auth or Identity products.
3. Pass it as external_token on us_bank_account when creating the PaymentMethod, with type: 'plaid_processor_token' and the token value in plaid_processor_token.
4. Treat the resulting PaymentMethod like any other verified us_bank_account for billing purposes — it attaches to a Customer and charges through Invoices or PaymentIntents the same way a Financial-Connections-verified one does.
5. Don't assume Financial Connections deactivation monitoring covers it. Until Stripe says otherwise, build your failure handling around the standard invoice.payment_failed and Nacha return-code path from our ACH dunning guide, not the 30-day warning webhooks that only fire against a Financial Connections Account.

What this doesn't fix

It doesn't help you if you don't already have a Plaid relationship — standing one up just to use this parameter defeats the point, since you'd be adding a Plaid integration cost to avoid a Financial Connections flow that already does the same job for free. It also doesn't touch what happens after the payment method exists. A Plaid-processor-token-created us_bank_account can still return R01 for insufficient funds or R02 for a closed account exactly like any other bank-debit payment method, and based on Stripe's own documentation it's genuinely unclear whether you get the same 30-day advance warning before the underlying bank connection decays that Financial Connections customers now get. Until Stripe clarifies that, the conservative move is to assume you don't, and keep your return-code-based dunning path as the real safety net regardless of which verification route created the payment method.

None of this moves the needle on a customer who's decided, on the merits, that they want to cancel — that's a cancellation flow problem, and it's what CancelFlow exists to solve. What it does move is the much earlier, much less glamorous failure point: the signup that never becomes a subscriber because the bank-verification step asked for patience the customer didn't have. If you're trying to separate how much of your early-lifecycle drop-off is genuinely involuntary versus a verification flow nobody finished, run the numbers through our churn calculator before deciding whether this is worth the integration time — for companies that already have Plaid somewhere in the stack, it's close to a free win; for everyone else, it's a parameter worth knowing about and revisiting the next time a Plaid relationship actually enters the picture.

Frequently asked questions

Stop losing subscribers today

One script tag. One function call. A live cancellation flow in under 10 minutes.