A WEB entry allows a merchant to debit a customer's bank account after receiving authorization via the Internet or Wireless Network.
Obtaining strong authorization for your ACH transactions and keeping the authorizations on file is the most important step you can take to protect yourself against customer disputes and returns. Plus, you'll be in compliance with Nacha rules!
In this article, you will learn:
What must be included in a WEB Authorization?
Other important things you should know about WEB Authorization
The Best Practices for obtaining a WEB Authorization
Sample WEB Authorization forms
What to do after collecting WEB Authorizations?
What is a WEB Authorization?
A WEB (Internet-Initiated/Mobile) entry allows you (the merchant) to debit a customer's bank account after receiving authorization from the customer over the Internet or Wireless Network. The authorization must be written and signed or similarly authenticated by the customer. To meet this requirement, the customer must be able to read the authorization language displayed on a computer screen or other device.
- "Signed or similarly authenticated" may include an electronic signature as long as it evidences the identity of the customer signing it and their assent to the authorization. Example methods used to similarly authenticate can include the use of digital signatures, codes, PINs, etc.
When to use WEB:
- WEB is appropriate to use for any form of authorization that is communicated from the customer to you over the Internet or Wireless Network.
Example: A customer's authorization for a payment (debit) is obtained over the Internet accessed from a device that uses a wired or Wireless Network. - WEB is appropriate if the customer's instructions for initiating the payment (debit) is communicated to you via a Wireless Network, even if the authorization has been given in some other manner.
Example: An authorization was obtained from the customer in person or via a telephone call, but the customer sends a text message to communicate when to initiate the debit to their account. - WEB is appropriate if the customer's authorization for a payment (debit) is provided orally, other than via a telephone call, over a Wireless Network.
Example: A customer provides payment instructions during a video chat, or a customer provides an oral instruction to a virtual voice assistant to pay a bill or place an order. - WEB may be used in certain situations involving the initiation of a subsequent payment under the terms of a standing authorization if either the customer's standing authorization was obtained via the Internet or if the customer's agreed upon method of initiating a subsequent payment is communicated via the Internet.
Example: You obtain a customer's standing authorization orally via a telephone call. The terms of the standing authorization specify that the customer can initiate subsequent payments via an Internet communication to you. You may identify the subsequent payments as either TEL (based on the standing authorization) or WEB (based on the initiation of the subsequent payment).
When NOT to use WEB:
- Do not use WEB if the customer's authorization for the payment (debit) is provided orally via a telephone call. (For oral authorizations over the telephone, see TEL Authorization for more details)
Example: Authorization is given during a telephone conversation via a device over a Wireless Network. - Do not use WEB for business bank accounts, even when the business customer provides authorization for the transaction via the Internet. This type of authorization for payment is only valid for an individual's personal checking or personal savings account and not for business bank accounts. (For business customers, see CCD authorization)
What must be included in a WEB Authorization
Although the Nacha rules do not require specific authorization language for WEB transactions, the authorization must include at a minimum:- Language clearly stating whether the authorization is for a one-time payment, a recurring payment, or for one or more subsequent payments initiated under the terms of a standing authorization.
- Amount of transaction(s) or a reference to the method of determining the amount of the transaction(s)
- Timing of the transactions, including the start date, number of payments, and frequency of transactions
- Customer's name
- Bank account to be debited, including type of account (i.e., checking, savings, etc.)
- Date of the customer's authorization
- Language that instructs the customer on how to revoke the authorization directly with the merchant. This should include the time and manner the customer must communicate the revocation to the merchant. For a one-time payment, the right of the customer to revoke authorization must give the merchant a reasonable opportunity to act on the revocation prior to initiating the transaction.
Other important things you should know about WEB Authorization
- For all debit WEB transactions, you are obligated to ensure that commercially reasonable methods have been put into place to verify the identity of the customer.
- You must have commercially reasonable procedures to verify that the routing number used in debit WEB transactions is valid.
- You must also establish a commercially reasonable fraudulent transaction detection system. At a minimum, this system must validate the bank account to be debited for the first use of the account, and for any subsequent changes to the account number.
- In order to be in compliance with Nacha rules, you are required to conduct, or have conducted on your behalf, an annual audit to ensure that your customers' financial information is protected. The minimum levels of security include:
- physical security to protect against theft, tampering, or damage
- personnel and access controls to protect against unauthorized access and use
- network security to ensure secure capture, storage, and distribution.
iCG provides third-party services that can assist you with meeting these Nacha requirements for debit WEB transactions. Our hosted payment portals and invoices automatically validate the routing number used for the ACH transaction.
iCG Verify is a solution we provide which can be enabled to verify every ACH transaction processed OR to verify a stored bank account the 1st time only (when the token is created). Verifying every ACH transaction will reduce the risk for the merchant; however, the rule only requires the first time a bank account is used for a debit WEB transaction.
The Best Practices for obtaining a WEB Authorization:
- According to Nacha, all authorizations must be readily identifiable as an authorization and have clear and readily understandable language for your customers.
- The customer must be provided a copy of the authorization. This can be either a paper copy or an electronic copy. The customer should be encouraged to print their authorization and retain a hard copy or electronic copy of it.
- Use authorization language similar to the following samples on your WEB applications:
ACH WEB Authorization
Recurring Option Authorization
By selecting this option, you instruct and authorize us to debit your checking or savings account for the transaction entered above according to the schedule selected below. Please call (888) 123-4567 to revoke or modify this recurring payment authorization.
What to do after collecting WEB Authorization?
You are required to keep a copy of the authorization you receive and be able to provide it in a timely manner if proof of the authorization is requested by the bank. If asked for proof of authorization, you will need to provide:
- A screenshot of the authorization language provided to your customers on a computer screen or other device
- The transaction details including the time/date stamp
Single, one-time transactions: Retain a copy of the authorization for 2 years from the date of the authorization.
Recurring transactions: Retain a copy of the authorization for 2 years from the last payment date (termination) or from the date the customer cancelled the authorization (revocation of authorization).