A WEB entry is a transaction for which the authorization is received via the Internet. WEB should only be used for Business to Consumer transactions and can only be debits; Single or Recurring.
Authentication: Just like TEL transactions, WEB transactions require that the identification of the consumer be verified before the authorization piece takes place.*
Authorization: While there is no specific authorization language, the WEB authorization must follow these 4 basic rules:
1) be in a writing that is signed or similarly authenticated*
2) be readily identifiable as an ACH Debit authorization
3) clearly and conspicuously state its terms, and
4) must (for recurring payments only) provide the Receiver with a method to revoke their authorization by notifying the Originator in the manner prescribed.
It’s a good idea from a Proof of Authorization standpoint to capture the IP address and time/date stamp for each transaction authorized.
* Notes:
WEB entries may be either Single one-time entries or Recurring entries designated by the use of an S – for Single or R – for Recurring in the Payment Type Code Field of the Entry Detail Record.
The Originator must use a commercially reasonable procedure to verify the consumer’s Routing Number.
Authorization #1 – This means that the authorization is displayable for the consumer to read on a computer screen and the consumer should be prompted to print and retain a copy of the authorization. The consumer must then be able to demonstrate their assent to the terms and conditions of the authorization by clicking an “I Agree”, or “OK”, or some such button before moving on to complete their transaction.
The Originator must ensure that the exchange of account information is only accomplished during a secure Internet session using at a minimum 128 bit RC4 Encryption and is considered Commercially Reasonable.
Originators of WEB entries are required by the ACH Operating Rules to conduct an Annual Security Audit of their security practices and procedures that include at a minimum, adequate levels of;
1) physical security to protect against theft, tampering, or damage
2) personnel and access controls to protect against unauthorized access and use, and
3) network security to ensure secure capture, storage and distribution of financial information
You should understand that because of the anonymous nature of WEB transactions, they are considered a high risk type of ACH transaction. That doesn’t mean that they are difficult to implement or cumbersome for your customers, it’s just the nature of the beast. Stay tuned for ARC next.
Subscribe to my blog!
I liked it. So much useful material. I read with great interest.
Hi. Great blog. Lots of great information.
In the WEB record as described in the ACH Rules guide, the debit record can contain both a Receiving DFI Identification Number (the receiver’s account number in bytes 13-29) and a the receiver’s Individual Identification Number in bytes 40-54. I am not sure what the individual identification number is and how it is different than the account number. When I look it up on Google the individual ID number is defined as “in CIE entry the Individual ID Number is used by the Receiver to identify the account”. This sounds like an account number to me?
Is this correct? If not, where can I as a consumer find my individual ID number and why have no ACH processing payment systems ever asked me for it? Could you say something about this?
Thanks!
Hey Philipp,
First, let me say that I am so sorry for taking so long to respond. Now, to your question and a great one at that. The Individual ID Number is simply a number that helps the Originator identify the Receiver. Usually, an account number, but it can really be anything. The ACH Operating Rules (2009 version) page OR 97 define Individual ID Number as:
“Except as otherwise noted below, this field contains the accounting number by which the Receiver is knows to the Originator. It is included for further identification and for descriptive purposes. The RDFI should assume no specific format to be present (e.g.,presence or absence of dashes), but can assume that the field is pre-edited so that is suitable for description as is (including blanks in unused positions).” The definition then goes on to discuss it’s uses as they relate to CIE and MTE transactions.
As to why no ACH Processing Payment System has ever asked you for the number is that it doesn’t mean anything to them. It is a number unique to you and that Originator.
I hope this helps,
ACHGuy
Hello Chung,
I am working on content as I can, I apologize that there is not more at this time. I guess my paying job is taking up a lot of my time.
If you are interested in talking to someone as a consultant, let me refer you to a company called DeMatteo Monness. They are a company that works with individuals (as consultants) from a large variety of industries and I am certain they can connect you with someone to discuss ACH.
DeMatteo Monness LLC
50 Rowes Wharf, 5th Floor
Boston, MA 02110
(617) 204-3948
http://www.dmllc.com
I hope this helps and I wish you luck,
ACHGuy/Jeff Gonzales