ACH Payment Failures for SaaS: Why Bank Debits Are a Different Beast Than Card Declines

The 30-second answer

ACH bank debits fail on a delay. A card decline tells you instantly; an ACH debit can sit in your dashboard looking successful for up to about 5 business days, then reverse with a return code like R01. That delay changes everything about recovery — your dunning starts late, your access decisions are riskier, and the retry rules are different. Treat ACH failures like card failures and you'll mishandle all of them.

If you offer bank debit as a payment method on Stripe (us_bank_account), this post is your field guide. If you don't, file this under 'things to know before you enable it' — because ACH's lower fees come with this delayed-failure quirk attached.

The dangerous part: the success illusion

When a customer pays by card, Stripe knows in about a second whether it worked. The card network approves or declines, done. When a customer pays by ACH debit, Stripe submits the debit into the ACH network — a batch system that settles between banks on a timeline of days, not seconds.

During that window, the payment shows as processing or even succeeded. Then the customer's bank can come back — day 2, day 4 — with a return. Insufficient funds. Account closed. Authorization revoked. The money you thought you had leaves, and Stripe flips the payment to failed. I have watched founders discover this the hard way: revenue looked great on Monday, and by Friday a chunk of it had un-happened.

"A card decline is a locked door. An ACH return is a door that was open for four days and then slammed shut behind you."

The return codes that matter

ACH failures come back with 'R-codes' instead of card decline codes. You don't need all of them — these cover almost everything you'll see:

• •R01 — insufficient funds. The account was short when the debit hit. This is the ACH soft decline: retryable, timing-sensitive, most common by far.
• •R02 — account closed. The bank account doesn't exist anymore. Hard failure. Only a human with new details fixes this.
• •R03 / R04 — no account found / invalid account number. The routing or account details are wrong. Also hard — someone fat-fingered the details or the account was never real.
• •R07 — authorization revoked. The customer told their bank to block your debits. Do not retry this. This person is one step from a dispute; handle with direct, human contact.
• •R08 — payment stopped. The customer placed a stop-payment on this specific debit. Same rule: don't retry, talk to them.
• •R29 — corporate account not authorized. Business bank accounts can reject debits that aren't pre-registered. The customer needs to give their bank your company ID. Fixable, but only by them.

How ACH recovery differs from card dunning

• •The clock starts late. Your recovery flow can't begin until the return arrives — possibly 5 business days after the charge. Meanwhile the customer may have had full access the whole time. Build your dunning triggers off the failure event, not the original charge date.
• •Retries have hard rules. The ACH network (NACHA rules) limits how many times you can reinitiate a returned entry — historically two reinitiations for an R01. You don't get Stripe-style 'retry for weeks.' Spend your retries on good timing, like right after the customer's next payday.
• •Soft vs hard is sharper. R01 means 'try again later.' R02, R07, R08 mean 'trying again makes it worse.' Retrying a revoked authorization isn't just useless, it's the kind of thing that turns a churned customer into a complaint.
• •The email framing is different. With cards, 'update your card' is the fix. With ACH, the fix is usually 'move money into the account' or 're-authorize us with your bank.' An email demanding new payment details makes no sense for an R01 — the details are fine.

Should you even offer ACH?

Fair question, given everything above. The case for: fees are dramatically lower than cards — on a $500 invoice the difference is real money — and bank accounts don't expire, so the entire card-updater failure category disappears. The case against: this post. Delayed failures, R-code complexity, settlement risk, and customers whose banks make re-authorization a chore.

My take: for high-ticket B2B plans where invoices run into the hundreds or thousands, offering ACH is often worth it — the fee savings alone justify the extra failure-handling discipline, and business customers often prefer paying straight from the company account. For a $19/mo self-serve plan, card rails are simpler and the failure modes are faster. Know which business you're in before you enable the checkbox. And whichever you choose, write the failure flow before you flip the switch — the first R01 arrives sooner than you think — usually in week one, usually from a customer you didn't expect, and almost always right after you've mentally booked the revenue.

One more timing trap: weekends and holidays

The ACH network runs on banking days. A debit submitted Friday afternoon doesn't really move until Monday, and a bank holiday pushes it further. Your 5-business-day failure window can stretch across a full calendar week. If your dunning automation counts calendar days, an ACH 'failure' detected on day 6 might actually be a normal return arriving right on schedule. Build your ACH flows around business days — or at least don't panic-email a customer whose return simply hasn't landed yet.

The access question you have to answer

Because ACH settles slowly, every SaaS that accepts it has to pick a policy: do customers get full access while the debit is in flight? Delaying access until settlement is the safe play — no reversals to claw back — but it adds days of friction to signup. Granting instant access is better for conversion, and you eat the occasional reversal. There's no universal right answer, but there IS a wrong one: never deciding, and letting a wave of R01s teach you your policy after the fact. For most low-priced subscriptions, instant access plus a solid failure flow wins. For high-ticket annual plans, waiting for settlement is worth a serious look.

A sane ACH failure flow

• •On R01: email the customer day-of ('your bank declined the debit — usually a timing thing'), then reinitiate once, aimed a few days out near a payday boundary.
• •On R02/R03/R04: email immediately asking for corrected bank details or a card instead. No retries.
• •On R07/R08: personal email, human tone, no automation feel. 'Your bank says you stopped this payment — if that's a mistake here's how to fix it; if you meant to cancel, just reply and I'll sort it.' These are salvageable conversations, not dunning cases.
• •On any return: audit what access they had during the float. If your model can't absorb that, revisit the access-timing decision above.

The common thread: ACH failures need judgment per code, which is exactly what generic retry-everything tooling gets wrong. It's why StayPaid's recovery flows key off the actual failure reason instead of treating every decline as identical — a revoked authorization gets a human conversation, an R01 gets patience and a well-timed retry. If you're running this by hand, start with one rule: read the R-code before you do anything. That alone puts you ahead of most recovery setups.