ACH and eCheck debit a customer’s bank account directly. For invoices, memberships, payment plans and larger tickets that is often a better fit than a card — a different cost structure, a different timetable and different rules.
Illustrative diagram of a bank debit. Settlement and return timeframes are set by the ACH network and by your account setup.
ACH is not a cheaper card. It is a different payment method with its own authorization, its own timetable and its own failure mode — a return rather than a decline. These are the situations where that trade is usually worth making.
Business customers often will not leave a card against a recurring invoice, and card limits get in the way of larger balances. A bank debit — or a pay-by-bank link on the invoice itself — closes that gap without adding a system to reconcile.
Cards expire, get reissued and go stale; bank accounts change far less often. For memberships, retainers and service plans billed month after month, that removes most of the churn nobody chose.
When a customer agrees to pay over several months, each installment becomes a scheduled debit rather than another phone call. The schedule, the amount and the authorization sit in one record — which is what answers a question about it later.
Rent, association dues, tuition and standing charges are the cleanest use of ACH there is: a predictable amount, a predictable date and a payer who expects it. Cards can sit alongside for the people who prefer them, on the same account.
Deposits on custom work, wholesale orders and equipment purchases regularly exceed a customer’s card limit, and card cost on a large ticket is hard to absorb. A bank debit moves the same money without either problem.
On your payment page, eCheck appears beside the card fields: the customer enters bank details instead. It suits higher-value baskets and repeat customers, and runs on the same merchant relationship as your card acceptance.
Six stages. The important difference from a card sits at the end: an ACH entry can be returned after the money has already moved, which is why the authorization at the start carries so much weight.
The customer agrees to the debit — the amount, how often, and how to stop it — and that agreement is recorded and kept.
Routing and account numbers are captured through your checkout, a payment link, or keyed by your staff, and encrypted immediately.
The ACH entry is built, your risk and velocity settings are applied, and it joins the next origination batch.
The batch travels the network to the customer’s bank, which posts the debit against the account or rejects it.
Funds move to your bank account on the ACH timetable set at account setup — a different schedule from cards, not a slower version of the same one.
A returned entry — closed account, insufficient funds, a disputed authorization — comes back with its reason so it can be retried or resolved.
ACH is not instant, and it is not a card. Settlement timing, return windows and retry rules are set by the ACH network and by your account configuration. Nothing here should be read as a guarantee of when funds arrive.
Invoices, retainers and payment plans for businesses with no storefront and no appetite for chasing a card.
Trade accounts, purchase orders and balances larger than a card will comfortably carry.
Monthly dues billed across hundreds of members, where a stale card is the main source of churn.
Rent, dues and assessments collected on the same day from a fixed roll of residents.
Bank payments for the parts of a retail business that do not happen at the till — house accounts, deposits and large orders.
ACH usually sits alongside card acceptance rather than replacing it. The work is in the workflow, not the technology.
The decision is rarely “cards or ACH”. It is which customers, which invoices and which amounts are better served by a bank debit — and what happens on the days one does not go through. Settling that before launch is what separates a clean bank-payment program from one that generates support calls.
Availability, limits and settlement timing depend on your account setup and are confirmed during underwriting.
Running ACH through a separate provider means two logins, two reconciliations and two support numbers for one customer’s payments. Here both methods sit on one merchant relationship and report in one place, so “did they pay?” has a single answer.
If the question is about your own billing, the useful answer comes from someone looking at the invoices you actually send.
Talk to SalesA payment that moves directly between two bank accounts over the ACH network, rather than across a card network. You collect the customer’s authorization and their bank details once; the debit is then created against their account and settled to yours. It is the same rail behind direct deposit and automatic bill payment — used in the other direction.
Three ways that matter. It is authorized differently — you keep a record of what the customer agreed to, rather than an approval code. It settles on its own timetable rather than at card speed. And when it fails it fails afterwards, as a return, rather than as a decline at the moment of payment. That last difference is why the authorization at the start carries so much weight.
In practice, very little. Both move money from a customer’s bank account to yours across the ACH network. “eCheck” usually describes the customer-facing version — entering bank details on a checkout page instead of writing a paper check — while “ACH” describes the network the payment travels on. They are set up, authorized and settled the same way.
Yes — it is one of the strongest reasons to use it. A stored authorization is charged on the schedule you agreed, and unlike a card it does not stop working because the card expired or was reissued. The authorization has to cover the amount, the frequency and how the customer cancels, and it needs to stay valid for the whole arrangement rather than just the first charge.
Differently, and it depends on your volume, your typical amount and your return history — which is why no figure appears on this page. ACH does not carry card interchange, so the two cannot be compared line for line. The honest way to answer it is to look at your current statements and at the payments you would actually move to a bank debit, rather than to quote a number first.
On the ACH timetable, which is set by the network and by your account configuration rather than by us — and it is not card speed. Your settlement schedule is confirmed when the account is set up and is visible in reporting. Treat any timing mentioned before then as an expectation rather than a commitment.
You are notified with the return reason — most often insufficient funds, a closed account, or a customer saying they did not authorize it. From there the entry can be retried within the network’s rules, or the payment becomes a conversation with the customer. Agreeing that process before you launch is worth more than any feature on this page.
A record of the customer agreeing to the debit: the amount or how it is calculated, how often it will be taken, when it starts and how they cancel it. For recurring payments that record has to survive the whole arrangement, not just the first charge. It is the single thing that decides a disputed debit, so it is worth setting up properly at the start.
Yes, and that is the usual arrangement. Card acceptance and bank debits run on the same merchant relationship and report through the same place, so a customer can pay by card at the counter and by bank debit on their monthly invoice without you running two systems or reconciling two reports.
What you bill for and how you bill for it — invoices, dues, installments, one-off large tickets — plus business and ownership details for underwriting, and how you collect customer authorization today. If you already take cards, a recent processing statement helps show which payments are worth moving to a bank debit and which are better left where they are.
Bank to bank, on the same account.
Restaurant-ready POS, pay-at-table handhelds and equipment with no upfront cost for qualifying merchants. We start with a statement analysis — nothing changes until the numbers make sense.
Promotional terms and eligibility apply. Estimates only. Final pricing requires statement analysis and approval.
