If you take ACH payments online, especially via bank account debits for subscriptions, invoice pay links, or one-time checkout, your biggest hidden risk is not fees. It is authorization. When a customer later claims they did not authorize a debit, the return can come back as an unauthorized code and you can lose the funds long after you thought the payment cleared.
This guide explains what the ACH Network expects for WEB debits (internet or mobile initiated ACH debits), what information must be included in a compliant authorization, what to store as proof, and how to lower your rate of unauthorized returns like R05, R07, R10, and R11 without adding too much friction.
A WEB debit authorization is the customer's agreement that you can pull money from their bank account using ACH, and that agreement was obtained online or through a wireless network.
For merchants, the practical meaning is simple: if you cannot show a clear agreement to the amount and timing, plus evidence tying that agreement to the customer, you are exposed when the customer disputes the debit with their bank.
If you use open banking or account linking to obtain routing and account numbers, that consent to share data is not the same thing as consent to debit the account. Your checkout still needs a separate and clear payment authorization.
A valid authorization is one that is clear, readily understandable, and "signed or similarly authenticated" by the consumer. In practice, that means the customer must take an affirmative action online that shows assent, and you must be able to reproduce a record of what they agreed to.
Nacha has also emphasized that a debit authorization to a consumer account needs specific core information elements so the originator can create a compliant authorization and later prove it.
At minimum, your WEB authorization should include these elements, presented in a way that is obvious to a normal buyer:
You should also include operational details that reduce disputes and reduce bank confusion, even if they are not strictly required in every situation:
The short answer is: the customer must be "similarly authenticated," meaning the authorization is in writing but completed electronically and tied to an authenticated session or identity check.
Common patterns that work well in practice include:
Avoid weak patterns like burying the authorization inside a generic terms-of-service link with no explicit assent to ACH debits.
Store enough detail to recreate three things: (1) the words the customer saw, (2) the action they took to agree, and (3) why you believe it was that customer.
Nacha's industry practices guide for WEB proof of authorization describes a mix of records that can help show an authorization took place, including screenshots of the authorization language plus audit logs like date and time, IP address, and the authentication steps used to link the authorization to the consumer.
Store these items for every WEB debit relationship, organized by customer and by mandate version:
If you work with higher risk products, consider storing an additional customer intent artifact such as a confirmation email that repeats the amount and timing.
Nacha's calculation guidance lists unauthorized return reason codes as including R05, R07, R10, R11, R29, and R51. These codes matter because they can trigger fees, monitoring, and in severe cases loss of ACH origination privileges.
For WEB consumer debits, the most relevant are:
For ACH returns, consumer debits can have an extended return window for unauthorized claims. Practically, you should assume a customer dispute can come back weeks later, not just in the first couple of days.
Separately, under Regulation E, a consumer must report an unauthorized electronic fund transfer that appears on a periodic statement within 60 days of the financial institution's transmittal of the statement to avoid liability for subsequent transfers.
Nacha's Account Validation Rule makes it explicit that account validation is part of a commercially reasonable fraudulent transaction detection system. For the first use of an account number (or when the account number changes), you must validate the account using a commercially reasonable method.
Nacha describes common validation options like prenotes, micro-transaction verification, or commercially available validation services.
Account validation helps confirm the routing number and account number belong to a real account and can receive debits. It does not prove the person paying is the rightful accountholder. That is why identity checks and proof-of-authorization logging still matter.
Start with controls that reduce confusion, because confusion turns into disputes. Then add checks that reduce true fraud.
Here is a merchant-friendly stack that usually performs well:
| Scenario | Recommended friction | Why |
|---|---|---|
| Low dollar, logged-in returning customer | Checkbox plus full logging | Low fraud risk, focus on clarity |
| High dollar first purchase | OTP plus account validation plus manual review on mismatch | Reduces account takeover and bad bank data |
| Subscription with free trial | Stronger disclosure plus reminder before first paid debit | Trials cause disputes |
| Marketplace or complex balance adjustments | Explicit consent plus post-transaction notice | Complex flows get challenged more |
Treat it as a risk signal, not just a failed payment.
Operationally:
When return rates rise, when an RDFI challenges a debit, or when an ODFI is doing risk management on its originators, you may be asked to produce evidence.
Nacha's WEB proof of authorization guidance notes that originators must retain the original or a copy of each written authorization, or a readily and accurately reproducible record evidencing another form of authorization, for two years from termination or revocation of the authorization, and be able to provide those records to the ODFI upon request.
It can, as long as the authorization is presented in a readable form, the customer takes an affirmative action to agree, and you store a record that links that assent to the consumer and the session.
Yes. Nacha has stated that an originator must provide a copy of the authorization to the consumer for their records and be able to provide proof of authorization to the ODFI upon request.
It requires originators of consumer WEB debits to validate the account on first use of an account number, or when the account number changes, using a commercially reasonable method.
Nacha's calculation guidance lists unauthorized return reason codes as including R05, R07, R10, R11, R29, and R51.
Nacha's WEB proof of authorization guidance notes that originators must retain authorization records for two years from termination or revocation.
You can apply for a merchant account through Easy Pay Direct or another processor that fits your model. Other options worth a look:
Sources:
- Nacha: https://www.nacha.org/rules/supplementing-fraud-detection-standards-web-debits
- Nacha: https://www.nacha.org/news/importance-compliant-ach-authorizations
- Nacha PDF: https://www.nacha.org/system/files/2022-11/WEB_Proof_of_Authorization_Industry_Practices.pdf
- CFPB Regulation E: https://www.consumerfinance.gov/rules-policy/regulations/1005/6
- CFPB Regulation E: https://www.consumerfinance.gov/rules-policy/regulations/1005/11
- Nacha PDF: https://www.nacha.org/system/files/2024-01/Calculate_Unauthorized_Return_Rate.pdf