ACH debits are sent on faith — there is no native real-time authorization, which is why returns happen. Instant bank verification closes that gap and typically halves return rates.
Why ACH returns happen at all
Card payments are authorized in real time: the issuing bank confirms the account exists and has available credit before the sale completes. ACH was never built that way. When you originate an ACH debit, you are sending an instruction into a batch network on faith — faith that the routing number is right, the account is open, and the money is there.
When that faith is misplaced, the payment comes back days later as a return: R01 (insufficient funds), R02 (account closed), R03 (no account found), R04 (invalid account number), or the one that matters most, R10 (unauthorized). Each return means a failed payment, a fee, and a customer relationship that just got harder.
The real cost of a returned payment
The visible cost is the return fee — typically $2 to $5 per item, plus bank charges on the customer's side that sour the relationship. The invisible costs are larger: staff time chasing updated bank details, revenue recognized and then reversed, and subscription customers who silently churn after a failed debit.
There is also a regulatory ceiling. NACHA, which governs the ACH network, monitors originators against return-rate thresholds: 0.5% for unauthorized returns, 3% for administrative returns (wrong or closed accounts), and 15% overall. Merchants who drift toward those lines face remediation demands from their ODFI — and in bad cases, loss of origination privileges entirely.
What Plaid checks before the debit ever moves
Instant verification changes the sequence. Instead of typing routing and account numbers, your customer logs into their bank through Plaid at checkout. In a few seconds, three things are confirmed before any payment is created: the account is real and open, the person paying actually owns it, and — where you enable it — the balance can cover the payment.
That single step eliminates entire categories of returns. R03 and R04 returns, caused by typos and invalid numbers, essentially disappear because credentials are pulled from the bank rather than typed. R02 returns vanish because closed accounts cannot be linked. And pre-debit balance checks cut deeply into R01, the largest single return code for most merchants.
The numbers: what verification changes in practice
Across merchants moving from manually entered bank details to Plaid-verified accounts, the pattern is consistent: administrative returns fall to near zero, NSF returns drop by 30–50% with balance checks enabled, and overall return rates are routinely cut in half. One verification partner on our platform reduced returned checks for its clients by 63%.
Unauthorized-return risk falls too. Because the customer authenticated with their own bank credentials, disputes claiming "I never authorized this" are far easier to defend — you hold cryptographic proof of account ownership at the moment of authorization, which is exactly the evidence NACHA rules contemplate.
Adding verification without adding friction
The common objection is checkout friction, and it is mostly outdated. Modern bank linking uses OAuth: customers tap their bank's logo, authenticate with Face ID or their banking app, and are done in under ten seconds — faster than accurately typing a nine-digit routing number and an account number twice.
A good implementation still keeps a fallback: customers whose banks are not covered can enter details manually and verify via micro-deposits. Sterling ACH ships with Plaid verification built in — same-day settlement, balance checks, and verified authorization on every debit — so cutting your return rate is a configuration choice, not an engineering project.
Having trouble
getting approved?
Sterling Ridge approves 99% of applicants — including high-risk businesses and merchants dropped by other processors.
No long-term contracts · No setup fees