Bank payments (eCheck / ACH)

What are bank payments?

Bank payments (also called ACH or eCheck) pull money directly from a customer's checking or savings account instead of a card. They're a good fit for larger invoices, recurring bills, and business-to-business payments where card fees add up.

Bank payments are an add-on to your account. If you don't see the ACH tools, ask your sales rep to enable them. Once on, they work alongside cards everywhere you get paid.

Get the customer's authorization first

Federal rules (Nacha) require the customer to authorize a bank debit before you take one. Merchant360 captures and stores that authorization for you, so you have a record if it's ever questioned.

1. 1You can email the customer an authorization to review and accept online, or record one they've already signed.
2. 2The authorization captures the account details, the amount or schedule, and the customer's consent, with a timestamp.
3. 3Stored authorizations live under Accept Payments → ACH Authorizations, where you can view or cancel them.

Saved bank accounts

The ACH Authorizations page also keeps your customers' bank accounts on file, so you can charge one again without re-entering the numbers.

1. 1Add a bank: on the ACH Authorizations page click Add a bank account and enter the holder name, routing, account number, type, and (optionally) an email for receipts. A zero-dollar validation runs (no charge); only the last 4 digits are shown back to you.
2. 2Charge a saved bank from the ACH terminal: use the search there to find it by customer or account last 4 – it charges the account on file directly, no re-keying.
3. 3Receipts: a bank payment settles a couple of business days out, so its receipt is emailed once the payment settles (not the moment it's submitted). A standalone charge (not tied to an invoice) sends that receipt to the email you stored on the bank account. Invoice and payment-link payments continue to receipt the customer on that document.
4. 4Set a default per customer, or remove a bank you no longer use. The full account number is always encrypted and never shown.
5. 5A customer's own bank accounts also appear on their profile (Customers → open a customer), where you can add or manage them right alongside their cards on file.

Prenotes: validating a bank account

Before the first real debit, the system can send a prenote: a zero-dollar test that confirms the routing and account numbers are valid with the receiving bank. It moves no money; it's a safety check against bad data.

A prenote takes a few banking days to clear. If the account details are wrong, the bank returns the prenote and you'll see it flagged, so you can fix the numbers before charging a real amount.

A prenote is a validation step, not a payment, so it doesn't count against payment limits. It's the responsible way to make sure the account is good before you rely on it.

See every ACH payment: the ACH Transactions page

Money → ACH Transactions is your feed of everything on the bank rail. It has two parts.

1. 1Awaiting customer authorization: requests you've sent that the customer hasn't accepted yet. You can cancel one here before it turns into anything.
2. 2ACH activity: every prenote, debit, and credit with its status – pending, processing, settled, or returned – its effective date, the customer, and the amount.
3. 3Anything that hasn't yet left for the bank shows a Cancel button, so you can stop a payment that's still queued.
4. 4If a debit is returned by the bank, the row shows the return and its reason code, so you know exactly why and can follow up.

Timing: same-day vs next-day

Bank payments settle on the ACH network's schedule, not instantly like a card authorization. Depending on how your account is set and when you submit, a debit funds the same day or the next business day.

Returns (for example, a closed account or insufficient funds) can come back a few business days after the debit, which is normal for ACH. The ACH Transactions page shows the return the moment it posts, with the reason.

When a bank payment is returned

Some returns are temporary, like insufficient funds. When a customer's bank payment comes back for a reason that's worth retrying, Merchant360 re-presents it for you automatically, up to a few attempts spaced a few days apart, following the ACH network's rules.

The customer is emailed that the payment was returned and when the retry will run, so they can make sure the funds are there. If the retries are used up, or the return is permanent (like a closed account), the automatic attempts stop and both you and the customer are emailed to arrange another payment method.

On the ACH Transactions page you'll see the returned entry with its reason code, and the follow-up attempt as its own row, so you can always see where a payment stands. There's nothing to run by hand.

Where customers can pay by bank

When bank payments are enabled, customers can choose Pay by bank on your hosted invoice pay page, alongside card. It's a low-cost option for larger invoices and business-to-business bills.

Recurring billing runs on a saved card or a customer's bank account (ACH). A subscriber can enroll with a card or, where bank debits are enabled, sign a recurring bank (ACH) authorization and be debited on schedule. Bank payments also cover one-time and invoice payments.