Yes, you can collect ACH authorisation online, but only if the signed or similarly authenticated electronic record, the authentication steps, and the consumer copy are retained and linked to the payer. Show clear authorisation language on your form, capture identity and authentication metadata in that same session, and keep a reproducible copy. The legal anchors are Regulation E, the ESIGN Act, and NACHA’s WEB rules.
TL;DR:
- Collecting ACH authorizations online requires retaining a signed or authenticated electronic record linked to the payer, along with proof metadata and consumer copy.
- The authorization form must include the payer’s identity, bank details, clear authorization language, payment type, amount or calculation method, cancellation instructions, and proof metadata.
- It must be obtained through a single session workflow that captures the form, authentication, validation, and consumer copy simultaneously to avoid compliance gaps.
- Authentication should involve layered, multifactor methods, and account validation must confirm the account’s ability to receive ACH debits, with timestamps and metadata stored securely.
- Failure to disclose recurring payment details clearly, or to provide the consumer copy upfront, is a common compliance trigger under Regulation E and NACHA rules.
Table of Contents
- Checklist and template for an online ACH authorisation
- What Regulation E, ESIGN and NACHA require
- Authentication and account validation methods that hold up
- Writing and delivering the consumer copy correctly
- Recordkeeping and staying ready for disputes
- Recurring versus one-time authorisations
- A single-session workflow that closes the compliance gaps
- Field-tested tips and pitfalls to avoid
- How KSign helps collect compliant ACH authorisations online
- Sources
- FAQ
Checklist and template for an online ACH authorisation
An online ACH authorisation is only as strong as the fields it captures and the proof it retains. Before you build or buy a payment page, confirm the form asks for every piece of information a payer would need to understand what they are agreeing to, and that your system stores enough evidence to defend the transaction later. The ACH Developer Guide treats a web-collected authorisation as its own entry type, known as WEB, and it must be established before the first transaction runs.
A compliant authorisation form and its supporting record should include:
- Payer identity: full name, and account holder name if different from the payer.
- Bank details: routing number, account number, and account type (checking or savings).
- Authorisation language: a clear statement that the payer is authorising an ACH debit from that account.
- Payment type: whether the debit is one-time or recurring, with the schedule spelled out if recurring.
- Amount or method: the exact amount, or the method used to calculate it when amounts vary.
- Cancellation instructions: how and when the payer can revoke authorisation.
- Proof metadata: timestamp, IP address, user agent, authentication method used, and account validation result.
Build this into a checkout page or mobile form as a discrete step, not a buried checkbox. Once the fields and proof points are in place, the same structure can be reused as a template across every customer, which is the fastest way to keep a small operation consistent.
What Regulation E, ESIGN and NACHA require
Three separate frameworks govern whether an online ACH authorisation holds up, and each covers a different part of the transaction.
Regulation E requires that a preauthorised electronic funds transfer from a consumer account be authorised by a writing that is signed or similarly authenticated. The payee also has to give the consumer a copy of that authorisation, and it must be delivered electronically or on paper: making it available on request is not enough.
The ESIGN Act sits underneath that requirement. Its consumer consent provision demands affirmative electronic consent, meaning the payer has to actively agree to receive records electronically, and the business must reasonably demonstrate the payer can access records in that format, as the FTC’s report to Congress explains. Without that consent step, an emailed or on-screen copy may not satisfy Regulation E’s writing requirement at all.
NACHA governs the mechanics of the ACH network itself. Its WEB proof-of-authorization guidance requires originators to retain an original or reproducible record of the authorisation and to document how that record links back to the accountholder, not just to a form submission. NACHA also requires commercially reasonable fraud detection for WEB debits, which includes validating the receiving account before its first use or after any change to the account number.
Put together, these three rules mean an online authorisation needs a signature-equivalent action, proof the consumer agreed to receive it electronically, and evidence the account itself was checked. Skip any one of them and the authorisation is exposed in a dispute.
Authentication and account validation methods that hold up
Capturing a checkbox is not authentication. What matters is whether the record proves the person completing the form is the account holder, and whether the bank account itself is real and open to receive ACH debits.
For authentication, small businesses typically choose from:
- In-session verification, where the payer confirms identity details already on file, such as a billing address or account number, during the same session as the authorisation.
- Multifactor checks, layering a password or PIN with a one-time code sent by SMS or email.
- Out-of-band authentication (OOBA), sending a verification code through a separate channel like a phone call or a banking app notification.
- Device and behavioural signals, such as device fingerprinting or session history, used as supporting evidence rather than a standalone method.
The FFIEC’s guidance on the ACH network/the-ach-network.aspx) points to layered, multifactor authentication as the standard for higher-risk online transactions, noting that a single password is increasingly insufficient on its own.
Account validation is a separate step and covers whether the bank account is open and able to receive ACH transfers. NACHA’s fraud-detection supplement lists prenote entries, micro-deposits, and third-party or API-based validation services as acceptable methods, and a previous successful payment on the same account can sometimes stand in for a fresh check.
Whichever methods you pick, store the timestamp, IP address, user agent, the exact consent text shown to the payer, the authentication method used, and a masked version of the account number, never the full number in plain text.
Pro Tip: Run account validation before the first debit and again if the account number ever changes, not just once at signup.
Writing and delivering the consumer copy correctly
The consumer copy is not a formality. Regulation E treats it as a required part of the authorisation, and the CFPB has flagged businesses that skip it or make it available only upon request.
The copy needs to state, in plain language:
- Who is authorising the debit and from which account.
- What the payment is for.
- The amount, or the method used to work it out if it varies.
- The timing and frequency, whether one-time or recurring.
- How to cancel the authorisation and who to contact.
Show this text on-screen in the same session the payer completes the form, then deliver a copy immediately by email or as a downloadable PDF, following the same ESIGN consent standard used for other financial disclosures. Retain the exact wording shown to the payer alongside the delivery record, since a dispute often turns on proving what the consumer actually saw and received.
Recordkeeping and staying ready for disputes
NACHA’s WEB proof-of-authorization guidance sets a two-year retention period for authorisation records, running from the point of revocation or termination, and that clock applies to the supporting evidence as much as the authorisation text itself.
A dispute-ready file should hold the authorisation record and its exact wording, the timestamp and session data from when it was signed, the authentication log showing how identity was checked, the account validation result, and the receipt or confirmation sent to the payer. Store these together under the transaction or customer record, not scattered across separate systems, so they can be pulled in minutes rather than hours. When a payer requests their copy, the same file should let you hand it over without a manual search.
Recurring versus one-time authorisations
A one-time authorisation only needs to disclose a fixed amount and date. A recurring authorisation carries more disclosure weight: it must state either the fixed amount for every debit or the method used to calculate a variable amount, plus the schedule, such as monthly on a set date.
Refresh consent whenever the amount, schedule, or account details change, and revalidate the account if the account number is updated. The most common failure the CFPB has flagged is vague disclosure, particularly language that says a copy of the authorisation is “available on request” instead of providing it upfront. Another frequent error is omitting the calculation method for variable recurring amounts, leaving the payer unable to predict what will be debited. Fixing both is straightforward: state the amount or formula plainly, and deliver the copy the moment the authorisation is signed, not after a request.
A single-session workflow that closes the compliance gaps
The cleanest way to avoid the errors above is to collect the form, the authorisation, the account validation, and the payment in one continuous session rather than across separate tools and emails.
A workable flow for a small business checkout looks like this:
- The customer completes a short intake form with billing details and account information.
- The system displays the authorisation language on-screen and requires an affirmative action to proceed.
- Authentication runs immediately, followed by account validation before the debit is scheduled.
- A consumer copy is generated and delivered the same moment, with the audit trail stored automatically.
Chaining these steps together in one session removes the biggest source of abandonment and error: a customer bouncing between a form tool, a separate e-signature platform, and a payment link, with no single record tying it all together. KSign’s form-native workflow generates the contract or authorisation directly from the form answers, captures the signature and authentication metadata in the same flow, and stores the audit trail alongside the signed record. For businesses collecting deposits or recurring payments, that means the consumer copy exists the moment the authorisation is signed rather than as an afterthought.
Pro Tip: Test your own checkout as a customer once a quarter, since the fastest way to spot a missing consumer copy or a buried authorisation clause is to try to complete the flow yourself.
Field-tested tips and pitfalls to avoid
Three mistakes come up again and again: authorisation text buried below a payment button, authentication that relies on a single password, and consumer copies offered only on request. Each takes under five minutes to fix: move the text above the fold, add a second verification step, and send the copy automatically the moment the form is signed. None of it needs new software, just a workflow that treats proof as part of the transaction, not paperwork added afterwards.
— Josh
How KSign helps collect compliant ACH authorisations online
Small businesses collecting ACH payments usually stitch together a form tool, an e-signature app, and a separate payment link, and each handoff is a place where the consumer copy or the authentication record can go missing. KSign closes that gap by generating the authorisation from the same form the customer fills out, capturing authentication metadata and account validation results in the same session, and storing everything in an audit trail that matches NACHA’s two-year retention expectation.
- Form answers can generate the authorisation and consumer copy automatically.
- Authentication and validation metadata can be captured and stored alongside the signed record.
- Payment collection can happen in the same session, following the authorisation.
Pricing and plans vary; see the provider’s pricing page for current details.
A recurring authorisation with a vague amount disclosure is one of the more common triggers for a CFPB compliance finding under Regulation E, which is exactly the gap a form-native workflow is built to close.
See pricing and plans or try the contract automation features to see how a single-session ACH authorisation flow could work for your business.
This article is general information, not a substitute for advice from a qualified financial advisor. Consult a qualified financial professional about your own circumstances before acting on anything here.
Sources
- How ACH works — ACH Developer Guide (NACHA)
- Regulation E — Consumer Financial Protection Bureau
- WEB proof of authorization industry practices — NACHA
FAQ
Can I make an ACH payment online?
Yes, ACH payments can be authorised and initiated entirely online through a WEB entry, provided the authorisation is signed or similarly authenticated as required by Regulation E. The record must link clearly to the account holder and be retained afterwards.
How can I accept ACH payments online?
You need a payment processor or gateway connected to the ACH network, a compliant authorisation form that captures the required disclosures, and an account validation step before the first debit, as outlined in NACHA’s fraud-detection standards. Many small businesses combine this with a form and e-signature workflow to keep everything in one session.
Where do I get an ACH authorisation form?
You can build one yourself using the required fields set out in NACHA’s WEB guidance, or use a platform that generates the authorisation automatically from a customer intake form. The safest option is a template that already includes the consumer copy and audit trail as part of the same document.
Does ACH require authorisation?
Yes, every ACH debit from a consumer account requires an authorisation that is signed or similarly authenticated before the first transaction runs, under both Regulation E and NACHA operating rules. Without it, the transaction is not valid and the originator carries the dispute risk.