Stripe stopped falling back to the bank account on file, and never published your deadline

The month the money did not arrive

The subscription is active. The customer has a bank account on file, the same one that has paid every month for three years. The invoice went out on the first. And the money did not come.

In the Stripe dashboard, the payment is not declined. It says Incomplete. There is no decline reason, no red banner, no email. The invoice is unpaid and something is quietly retrying it every night at the same hour.

This is what happens when Stripe stops honouring a fallback that your billing has been relying on without anyone deciding it should. The change is real, it is documented, and the one thing it does not have is a date you can look up.

What was actually removed

Stripe's migration guide describes the exact circumstances in which the old kind of ACH payment gets created. Three bullets, and only the middle one is invisible to a business owner:

A legacy ACH payment is created when a legacy BankAccount is the payment source. This happens when:

• You call the Create Charge API.

• A Subscription or Invoice charges a customer whose default_source is a legacy BankAccount, and no default_payment_method is set on the customer, subscription, or invoice.

• You call the PaymentIntent API with a payment_method_type of ach_debit.

• Migrate to new APIs for ACH Direct Debit, Stripe documentation

The middle bullet is a fallback. If nothing on the invoice says which payment method to use, and nothing on the subscription says it, and nothing in the customer's invoice settings says it, Stripe would reach for whatever bank account was attached to the customer and charge that. Nobody configured that behaviour. It was what happened when nothing was configured, which is why so much billing runs on it.

That last step is what has been taken away. The scope is narrower than "ACH is breaking", and the difference matters: this only bites when the payment goes through an old-style bank account and no default payment method is set at any of the three levels. Either condition on its own is fine. The other two paths in Stripe's list — a direct Charges API call, or a payment intent asking for the legacy method by name — close regardless of what is set where.

Zapier, which published the clearest public write-up of the change, states the consequence plainly:

Today, if a Stripe customer does not have a payment method explicitly set on a subscription or invoice, Stripe can fall back to a bank account already stored on the customer's record. This is a legacy ACH Direct Debit mandate.

[…] After August 24, 2026, Stripe removes that fallback entirely. Any payment that would have used that fallback will fail.

• Stripe legacy ACH Direct Debit change, Zapier Help Center, published 20 August 2026

The date is not on any Stripe page

The date is where this gets hard to plan around, and it needs precision rather than a repeated number.

That 24 August date comes from Zapier. Across eighteen Stripe pages covering this migration — the documentation, the API reference, the support articles and the changelog — the date appears on none of them. In the changelog, across the whole 2026 release history, the letters ACH do not appear once. Four of those pages use the word "deadline", and not one of the four says when it falls.

Stripe explains why in two of its own support articles:

If you have an existing Stripe integration with legacy ACH Direct Debits and have started receiving errors, check the email address associated with your Stripe account. We've contacted all users with information regarding their migration deadline.

• Handling API errors for legacy ACH Direct Debits, Stripe support

The deadline is per-merchant and it was mailed to you. Which means the useful question is not "when is the Stripe deadline" but "what did Stripe send to the address on our account, and who reads that inbox".

The evidence that these dates really do differ is not theoretical. Three separate dates for the same deprecation have surfaced in public:

By the time you are reading this, all three of those dates are behind you.

And at least one live account started failing between them — months after the earliest of the three, months before the two later ones. In a bug report against an open-source invoicing product, the person filing it wrote that the same customers "had successful ACH auto-bills earlier, then failures started Jun 9+ on new invoices with the same ba_ token".

The verbatim wording of the merchant email, from the one copy posted publicly, is also broader than the Zapier description:

Hello, [ ] is currently accepting ACH Direct Debits using the Charges API, a legacy integration that will no longer be supported on May 15, 2026. After this date, if you do not upgrade your integration, any Charges API calls for ACH Direct Debits will fail.

• Stripe email quoted by a merchant on an open-source invoicing product's forum, 20 November 2025

What the failure looks like from your side

Not like a decline. That is the whole problem.

The error code in Stripe's own reference names the situation exactly:

billing_invalid_mandate — The Subscription or Invoice attempted payment on a PaymentMethod without an active mandate. To create Subscription or Invoice payments with this PaymentMethod, it must be confirmed on-session with a PaymentIntent or SetupIntent first.

• Error codes, Stripe API reference

On the wire, as one merchant's logs recorded it, it reads as a 400 with a message that tells a developer what to do and tells a business owner nothing: "This PaymentIntent requires a mandate, but no existing mandate was found. Collect mandate acceptance from the customer and try again, providing acceptance data in the mandate_data parameter."

In the dashboard, the person who cares about the money sees something much emptier. The reporter in that bug thread described a single fifty-dollar invoice that had been attempted more than nineteen times over about three weeks — one attempt a day, each producing a new PaymentIntent, all sitting at Incomplete with, in their words, an "empty decline reason". The invoice stayed unpaid the whole time.

That is the difference between this and an ordinary failed card. A declined card produces a reason, an email, a dunning sequence, and a customer who hears about it. This produces a row that says Incomplete, forever, at one row per day, in a list nobody opens unless they are already looking for something. If the same customer has ever been charged twice by an automation, you already know how long that kind of thing can run before anyone notices.

The maintainer of that project, announcing in the same thread how their own product would handle it in the next release, described where those old bank accounts end up:

for any tokens that do not have a valid mandate, they'll flip to inactive, and they will require customer present mandate acceptance again during checkout - or - via the Payment Method tab using the Verification workflow… Inactive tokens will not be available for autobilling unless valid mandates are present.

• the maintainer, in that product's issue tracker, 18 August 2026

"Not available for autobilling" is the sentence to carry. It is one billing product's answer to the new mandate rules rather than Stripe's own wording, but it is the shape every answer takes: the customer is still a customer, their bank details are still on file, and the automatic part has stopped being automatic.

You cannot query your way to the answer

The instinct of anyone technical is to list the affected subscriptions and count them. That is not available, and it is better to know that before spending an afternoon on it.

Stripe's list endpoint for subscriptions accepts filters for things like status, price, customer, collection method and creation date. There is no filter for default_source and none for default_payment_method. The Search API is narrower still: for subscriptions it indexes created, metadata, status and canceled_at, and nothing about payment methods. Searching charges by payment method type does not help either — the documented values there are card and Terminal methods.

Somebody asked exactly this question on a billing product's forum, right after getting their Stripe email:

Is there any way on my end I can get a list or flag the customers that are linked on the legacy system?

• a merchant, on the same forum, 20 November 2025

The answer from the product's maintainer was "Maybe you can run a report in Stripe to see?" That is not a failure of that project. It is what the API affords.

The one place that does answer

Stripe built a tool for this, it lives somewhere nobody visits, and it is the single highest-value ten minutes in this whole article:

You can use the migration insight tool in the Stripe Dashboard to see exactly how your integration is affected and track your migration progress.

1. From Stripe Dashboard's Developer Settings, go to Workbench.

2. Go to the Insights tab.

3. Click the ACH Direct Debit deprecation insight to view your usage breakdown and migration status.

• How can I check how my integration is impacted, Stripe support

What it shows is a scoreboard rather than a warning. In Stripe's description of the tooling, the Summary tab "indicates with a red x which integration path(s) you have used to accept legacy ACH Direct Debits in the last 3 days, in the last 7 days, or in the last 31 days". When you are done, everything shows a green check instead — "all payment methods will show green check marks, confirming you've completed the migration".

Two facts make this safe to poke at, and both are Stripe's words. Backfilling mandates for your existing bank accounts does not change how anything charges: "The bank account will remain active and chargeable on legacy integrations so the conversion won't disrupt your payment flows." And the whole thing can be rehearsed first, because the tool runs against a sandbox from the account picker.

There is also an extension, exactly one:

Each merchant is limited to a single extension; no additional extensions will be granted. You can request a one-time extension for processing legacy ACH Direct Debits.

• Can I request a migration extension, Stripe support

Stripe does not say how long an extension runs for. If you need one, that is a reason to open the dashboard today rather than in November.

The fix is one field, in three possible places

The failure is caused by an absence, so the fix is to stop leaving the field empty. Stripe's ordering, from the API reference for subscriptions, is that default_payment_method "takes precedence over default_source", and if neither is set, invoices fall through to the customer's invoice settings. Setting it explicitly anywhere above the fallback removes the dependency on the fallback.

In practice that means one of three things, depending on where your billing is driven from:

1. On the customer, as invoice_settings.default_payment_method, which covers everything that customer is billed for.
2. On the subscription, which covers that subscription regardless of what the customer record says.
3. On the invoice, for one-off billing.

The bank account itself has to have a valid mandate attached before it can be used this way, and the migration tool's backfill step exists for exactly that. Stripe documents recording that acceptance through a SetupIntent — its one-off "confirm this mandate" request — and the migration guide gives the exact calls for each of the three levels.

The important thing about all of this is that it is data work, not code work. Nothing in your automation platform has to change for existing customers. The values in your Stripe account have to change.

Where your automation platform sits

The three big platforms are in three different positions here, and only one of them has said anything to its users.

Zapier published the article quoted above and changed its app. The Create Subscription action now has a Default Payment Method field whose help text says, in part, that leaving it empty means Stripe falls back to the customer's invoice settings "or ultimately to their legacy default source, which can fail once Stripe removes support for that path". Zapier is also honest about the limits of that: mapping the field "only covers Zap runs where you map the field" and "does not retroactively fix existing customer data".

Look at the same screen a little longer and you find the other half of the story. The neighbouring Collection Method field on that same action still explains the old model: charging automatically means Stripe "will attempt to pay this subscription at the end of the cycle using the default source attached to the customer". One screen, two fields, two different worlds — which is what a deprecation looks like while it is being absorbed.

Make has published nothing about this. Its Stripe app documentation contains no mention of the deprecation, and its customer module still offers a Source ID field whose help text explains that passing a source "will create a new source object, make it the new customer default source, and delete the old customer default if one exists". That is the exact path that produces the problem. The good news is that the same module also has a Default Payment Method ID field, so the fix is available in Make — it is just not signposted.

n8n is in the strangest position, because its Stripe node has no subscription or invoice resource at all. Its resources are Balance, Charge, Coupon, Customer, Customer Card, Meter Event, Source and Token. So the Stripe node cannot be the thing that creates a failing subscription, though a hand-built HTTP request from n8n still can. What it can be is the thing that charges a customer directly through Charge: Create, whose required Source ID field is the first bullet of Stripe's list — the Charges API path.

The more useful role for n8n here is as a watchman. Its Stripe Trigger carries the event invoice.payment_failed, described in the node itself as occurring "whenever an invoice payment attempt fails, due either to a declined payment or to the lack of a stored payment method". This failure is the neighbouring case — the payment method is stored, and what is missing is the mandate behind it. If you take one automation away from this article, it is that one: somebody or something has to be watching the runs, because the failure will not raise its hand.

What else moves when you migrate

Two of these show up in the accounting rather than in the code.

Payouts change shape. On the legacy path, funds settle in a bank-account balance; on the new one they settle in the same balance as cards. Stripe warns that "during migration, you receive one payout for each balance type until all new payments use the new API". For a while you get two payouts where you used to get one. That is the kind of thing that makes a month look wrong to whoever reconciles it, the same way a report that quietly changed shape does.

Balance transactions arrive later. On the legacy path they were created when the charge was created and present in the API response. On the new path they are created when the payment is submitted to the banking partner, and Stripe notes they appear in the charge.updated event "but not the API response". Anything that reads a balance transaction id straight back from a charge needs looking at.

Settlement gets faster, which is the one piece of good news. Money lands six business days after the charge on the old path, four on the new one, or two with faster settlement switched on.

And your existing webhooks mostly survive. Stripe still sends charge.succeeded and charge.failed alongside the new payment intent events, explicitly so that integrations do not have to be rewritten. The new event with no old equivalent is mandate.updated, sent when a mandate becomes inactive — which is precisely the signal that would have told you about this a month early.

What to do this week

1. Open Workbench, then Insights, then the ACH Direct Debit deprecation insight. Red crosses mean you are still taking payments through a legacy path. Green ticks mean you are done. This is the only definitive answer available.
2. Search the inbox on your Stripe account for the migration email. Your date is in it, and there is a real chance it went to a founder's address that nobody reads any more.
3. Run the Migrate tab in a sandbox first, then for real. Backfilling mandates does not change how anything charges, and re-running the tool is safe because it skips accounts it has already done.
4. Set default_payment_method explicitly on customers, subscriptions or invoices. This is the actual fix; everything before it is diagnosis.
5. Fix the pipeline that creates new customers too. Migrating today's customers does nothing for the ones you sign next month, and in Zapier and Make that means filling in the Default Payment Method field rather than leaving it empty.
6. Put a watch on invoice.payment_failed. Whatever else you do, do not let the next occurrence of this be discovered by a bank reconciliation.
7. If you take ACH through a plugin — WooCommerce, Magento, PrestaShop, WHMCS, Shopware — check its version. Stripe lists the affected plugins, with minimum versions for some of them, and says you will need the latest one before your migration deadline.
8. If you cannot finish in time, request the extension from the ACH banner in Workbench. Stripe caps it at one per merchant and does not publish how long it runs, so treat it as a request rather than a right.

When this is a job to hand over

The question here is not how many customers you have. It is how much of one month you can afford to reconstruct afterwards.

If the answer is "all of it, easily" — a handful of ACH customers, one billing path, a bookkeeper who would notice a missing payment within a week — then this is an afternoon in the dashboard and nobody should be paid for it. If the answer is that a month of unpaid invoices would take days to untangle and somebody would have to be told, the calculation changes, because the expensive part of this failure is not the fix. It is the reconstruction: which invoices went unpaid, for how long, and who has to hear about it.

Two things push an account into that second category regardless of size. A billing stack assembled from a plugin, a Zap and a spreadsheet, where the same customer can be created three different ways and only one of them sets the field. And Stripe Connect, where it multiplies — the migration tool can backfill mandates and set the field across connected accounts in one pass, but the diagnosis, the notice to each account and any code changes still land one account at a time. The size of either is a number of subscriptions, and that number can be established before anyone touches the account, which is how the price gets agreed up front. Billing plumbing is a good chunk of the integration work we take, and it usually arrives described exactly the way this one does: nothing changed, and the money stopped.

This deprecation was announced properly, individually, by email, to the address on the account — and it still surprised people, because that address belongs to whoever signed up years ago and the failure it warned about looks like nothing at all. A notice that went to the account rather than to a person is not really a notice that arrived.

Sources

• Migrate to new APIs for ACH Direct Debit - Stripe documentation, read 7 September 2026. The three ways a legacy ACH payment is created including the subscription and invoice fallback, the behavioural differences table covering mandates, payouts, balance transactions and settlement speed, and the webhook mapping between the old and new integrations.
• Migrate existing bank accounts - Stripe documentation, read 7 September 2026. The step-by-step migration including recording mandate acceptance and setting a default payment method on customers, invoices and subscriptions.
• Subscriptions, invoices and customers API reference - Stripe, read 7 September 2026. The precedence of default_payment_method over default_source and the fallback chain through the customer's invoice settings.
• List subscriptions and Search - Stripe API reference, read 7 September 2026. The available filters, which do not include payment method fields, and the indexed query fields for subscriptions and charges.
• Error codes - Stripe API reference, read 7 September 2026. The definition of billing_invalid_mandate.
• Stripe changelog - read 7 September 2026. Checked through the 2026 releases with no mention of ACH.
• How can I check how my integration is impacted by the legacy ACH Direct Debit deprecation - Stripe support, read 7 September 2026. The Workbench insight and the three steps to reach it.
• Bank account migration tooling - Stripe support, read 7 September 2026. The Summary and Migrate tabs, the three, seven and thirty-one day windows, the safety of backfilling mandates and of re-running the tool, and sandbox testing.
• Can I request a migration extension for processing legacy ACH Direct Debits - Stripe support, read 7 September 2026. The one-extension-per-merchant limit and how to request it.
• Handling API errors for legacy ACH Direct Debits - Stripe support, read 7 September 2026. The statement that migration deadlines were communicated to users by email.
• Common third-party integrations - Stripe support, read 7 September 2026. The plugins and minimum versions affected by the migration.
• Stripe legacy ACH Direct Debit change - Zapier Help Center, published 20 August 2026 and updated 21 August 2026, read 7 September 2026. The 24 August enforcement date, the description of the fallback being removed, the two conditions that have to hold together, and the guidance per app version.
• Stripe on Zapier - read 7 September 2026. The Default Payment Method field help text warning about the legacy default source, alongside the Collection Method field still describing the old fallback.
• Stripe app documentation - Make, read 7 September 2026. The module list with no subscription modules, the Source ID field that sets a new customer default source, the Default Payment Method ID field, and the absence of any notice about this deprecation.
• n8n source, Stripe node and trigger - read 7 September 2026. The resources the node exposes, the required Source ID on Charge: Create, and the description of the invoice.payment_failed trigger event.
• A bug report in one open-source invoicing product's issue tracker - read 7 September 2026 through the GitHub API. The live Stripe error text for a missing mandate, the reporter's account of daily retries on an unpaid invoice with no decline reason, the failures beginning on 9 June 2026, and the maintainer's explanation of what happens to tokens without a valid mandate, quoted with a typo in the original closed up. The report was written with AI assistance by its author's own account, so only the vendor error text, the dated posts and the maintainer's replies are relied on here. Given without the project's name.
• A thread on the same product's forum, 20 November 2025, read 7 September 2026. The verbatim text of a Stripe migration email naming 15 May 2026, and the unanswered question about listing affected customers.
• A subscription-billing platform's community thread, June to July 2026, read 7 September 2026. A different migration deadline of 6 August 2026 given to that platform's tenants, and the ba_ versus pm_ identifier test. Given without the platform's name.