Request for Proof of Authorization

You've received a request for Proof of Authorization, now what?

In this article, you will learn:

Why is Proof of Authorization Important?

Two types of Proof of Authorization Requests:

POA Request from the Bank

POA Request from iCG

What will the POA Request look like?

What do you need to provide in response to the POA Request?

What happens if you don't respond?

Why is Proof of Authorization important?

Obtaining strong authorization for ACH transactions and keeping the authorizations on file is an important step you can take to protect against customer disputes and returns. Plus, you'll be in compliance with Nacha rules!

To dispute an ACH transaction to their bank account, the customer would need to complete a Written Statement of Unauthorized Debit (WSUD) with their bank and indicate one of the following reasons for the dispute:

1. I did not authorize the debit to my account.
2. I revoked the authorization I had previously given before this debit was initiated.
3. My account was debited before the date I authorized.
4. My account was debited for an amount different than I authorized. NOTE: The transaction must be for the exact amount authorized—it cannot be higher or lower. However, you are permitted to have customers authorize payments for variable amounts, and/or not to exceed amounts.

Based on this statement, the transaction can be returned by the bank as unauthorized.

Two Types of Proof of Authorization Requests

There are two different situations where you will be required to provide Proof that you had received Authorization prior to initiating the ACH transaction for your customer:

• POA Request from the Bank:

If a customer has gone to their bank and completed the WSUD saying that the transaction you initiated was unauthorized, their bank may request that you provide proof of that authorization. If you can provide a valid POA, the bank may not return the funds.

Please note, POA Requests are due back to the bank within 10 banking days, so you will want to be timely in replying to the request.

• POA Request from iCG:

As part of the annual review process for all iCheckGateway merchants, we request that the merchants provide proof of authorization for randomly selected transactions. This is done so that we can confirm that you are gathering authorizations for your ACH transactions that meet Nacha requirements.

What will the POA Request look like?

You will receive an email from icheck@icheckgateway.com with ICG POA Request in the subject line. The email will provide:

• The confirmation number of the transaction
• The due date for your response - 7 business days from the date of the request
• A link where you can securely upload the proof of the authorization including any supporting documentation
• An attached PDF that contains the transaction details

What do you need to provide in response to the POA Request?

You are required to keep a copy of each authorization for two years from the termination or revocation of the authorization. If proof of authorization is requested, you must provide the information in a timely manner AND the authorizations must contain all of the requirements listed in the Nacha rules.

In addition to any supporting documentation you may have, you will also want to provide the following:

• For a CCD or PPD authorization, you will need to provide the signed authorization
• For a TEL authorization, you will need to provide either a copy of the script that you use during the telephone call or an audio recording of the verbal authorization
• For a WEB authorization, you will want to provide screenshots of the authorization language provided to your customers on a computer screen or other device
• If it is a Standing authorization, be sure to provide both proof of the standing authorization as well as proof of the subsequent transaction

Make sure that all authorizations, regardless of whether they are written, verbal, online, etc., contain the following:

• 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.
• Clearly specify the action(s) that the customer can take to initiate a subsequent entry if it is a standing authorization. These actions can include, but are not limited to, a telephone call, an internet interaction, or a text message.
• 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.
• For CCD transactions, the corporate customer has agreed to be bound by the Nacha Operating Rules and the business bank account is enabled for ACH.

What happens if you don't respond?

If you don't respond to the request for proof of authorization or if your response does not contain all of the requirements, you will be considered to be out of compliance with Nacha Rules.

If this is a POA Request from the Bank, the transaction will be returned as unauthorized and the funds will be debited from your account.

If this is a POA Request from iCG, the transaction will not be returned; however, you will still be considered to be out of compliance. 

Any merchant that is out of compliance with Nacha Rules runs the risk of having their ACH processing turned off by the bank.

In our efforts to encourage everyone to take compliance with Nacha Rules seriously, a Monthly Non-Compliance Fee will be implemented and may be assessed if you do not respond or if your response does not meet Nacha requirements.