What Is eCheck?

How eCheck Works

An eCheck digitizes the familiar paper-check experience, replacing physical handling with secure electronic transmission over the ACH network. The payer provides their bank routing and account numbers along with proper authorization; the merchant submits the transaction to their payment processor, which routes it through the ACH network to the payer's bank. Settlement typically completes within 3–5 business days under the standard rail.

Why eCheck Matters

eChecks occupy a strategically important position in the payments mix, particularly for high-ticket B2B transactions and subscription billing where credit card interchange fees erode margin. Understanding the scale and economics behind electronic funds transfer helps merchants make smarter payment routing decisions.

According to NACHA, the ACH Network processed 31.5 billion payments worth $80.1 trillion in 2023 — a 4.8% increase in volume year-over-year — with B2B ACH payments growing at an even faster 9.6% rate. eChecks drive a meaningful share of that volume, powered by the insurance, utilities, healthcare, and SaaS sectors.

A Federal Reserve Payments Study found that ACH debit transactions — the category that encompasses eChecks — grew at a compound annual rate of 6.2% between 2018 and 2021, outpacing both paper check decline and card volume growth in the same period. Return rates for well-managed eCheck programs average just 0.5–1%, making them competitive with card chargeback rates for merchants who invest in upfront bank account verification.

eCheck vs. Credit Card

Both eChecks and credit cards handle one-time and recurring payments, but they serve different use cases and carry very different cost structures. The right choice depends on transaction size, customer relationship, and tolerance for settlement delay.

For merchants processing large recurring invoices, eChecks consistently win on economics. For consumer impulse purchases or cross-border transactions, cards remain the more practical choice.

Types of eCheck

The ACH network defines several Standard Entry Class (SEC) codes that determine how an eCheck is authorized and processed. Selecting the correct type is a NACHA compliance requirement — using the wrong SEC code can trigger fines and return rate penalties.

ACH debit transactions fall into distinct categories based on the authorization channel and the nature of the parties involved:

WEB (Internet-initiated) — The most common type for ecommerce and SaaS. The payer authorizes the transaction online. NACHA requires merchants using WEB entries for recurring transactions to perform annual account validation.

TEL (Telephone-initiated) — Used when authorization is collected verbally over the phone. The merchant must record the call or send written confirmation within 2 days. Limited to situations where the payer has a pre-existing relationship with the merchant.

PPD (Prearranged Payment and Deposit) — Used for consumer recurring payments backed by a signed standing authorization. Common in utilities, insurance, mortgage, and gym membership billing.

CCD (Corporate Credit or Debit) — The B2B equivalent, used for payments between companies. No consumer-level protections apply; both parties are assumed to be sophisticated principals.

ARC (Accounts Receivable Conversion) — Converts a paper check received by mail or at a drop box into an ACH debit. The original paper check itself serves as the authorization document.

Best Practices

Implementing eChecks correctly requires attention to both operational workflow and technical integration. Mistakes at either layer drive up return rates and create NACHA compliance exposure.

For Merchants

• Verify bank accounts before charging. Use instant bank verification (IBV) via services like Plaid or MX to confirm the account exists and has sufficient funds. This single step typically cuts return rates by 50% or more.
• Store authorizations securely. NACHA rules require merchants to retain proof of authorization for 2 years from the last transaction date. Digital agreements must include timestamps and IP addresses.
• Set clear settlement expectations. Communicate the 3–5 day settlement window to customers upfront to prevent confusion, disputed charges, and chargeback-equivalent return codes.
• Monitor return codes actively. Build alerts for R01 (NSF), R02 (Account Closed), and R10 (Unauthorized). Elevated R10 rates in particular attract NACHA audit scrutiny and processor fines.
• Use direct debit mandates for recurring billing to ensure each payment cycle is covered by a standing authorization — not one-off authorizations collected at each renewal.

For Developers

• Implement idempotency keys when submitting ACH entries to prevent duplicate transactions during network retries or timeout recovery flows.
• Handle return file processing as a first-class feature. Subscribe to return and NOC files from your processor and react to them programmatically — not via a manual ops queue.
• Validate routing numbers server-side using the ABA check digit algorithm before submission to catch typos before they generate returns.
• Support webhook events for settlement state changes so downstream systems — inventory, fulfillment, CRM — stay synchronized with actual fund availability rather than optimistic projections.
• Test against sandbox return codes. Most ACH processors simulate R-codes in their test environments. Cover at least R01, R02, R04 (invalid account number), and R10 in your QA suite before going live.

Common Mistakes

Even experienced payment teams make avoidable errors when adding eCheck support. These are the most costly patterns to avoid.

1. Skipping bank account verification. Submitting eChecks without verifying the account exists is the fastest path to elevated return rates and NACHA scrutiny. Verification adds minimal customer friction and dramatically reduces failures.

2. Using the wrong SEC code. A WEB entry submitted as a PPD — or vice versa — violates NACHA rules and can result in fines. Audit your transaction types against NACHA's SEC code definitions before going live.

3. Charging before authorization is confirmed. Initiating a debit before a digital authorization is explicitly confirmed — checkbox clicked, form submitted, timestamp recorded — exposes merchants to R10 unauthorized return codes and potential regulatory action.

4. Ignoring Notifications of Change (NOC). When a customer's routing or account number changes, their bank sends an NOC file. Merchants who ignore these continue submitting to stale data, generating preventable returns and degrading their ODFI relationship.

5. Treating returns as edge cases. A 1% return rate means 1 in 100 transactions fails. Build return handling — retry logic, customer notifications, revenue recovery — into your core payment flow from day one, not as a manual remediation process.

eCheck and Tagada

Tagada's payment orchestration layer supports eCheck processing as part of a multi-rail payment strategy. When card declines occur — particularly on high-ticket recurring invoices — Tagada can automatically route retry attempts to an eCheck or bank transfer rail, recovering revenue that would otherwise be lost without any manual intervention.