Skip to main content

Deferred Authorizations

Updated

Table of Contents

  1. Overview
  2. Before You Start
  3. What Is a Deferred Authorization?
  4. What Are the Risks of Deferred Authorization?
  5. The Deferred Process

 

Overview

The following article details Deferred Authorizations. Please ensure you read the article in full, as misuse of the Deferred Authorization feature can result in loss of funds.

 

 

Before You Start

WARNING - Important Information

Deferred Authorization support and integration should be discussed at length with both NMI and any processors your solution utilizes so-as to ensure the risk is fully understood. Deferred Authorization cannot be utilized until enabled on the NMI Gateway, and attempting to do so without this in place will result in the transactions being rejected. Further, Deferred Authorizations should ideally only be utilized in an environment where expensive physical goods are not provided to ensure loss is kept to a minimum.

 

What Is a Deferred Authorization?

At the time of sale, a card may request online authorization as a means to verify the transaction which may not be possible due to a communication error between the solution and NMI Gateway. In circumstances where a response has not been received from a request, or a request is not possible, the solution powered by Direct Connect may defer the authorization.

When communication has been restored, the solution may then send the deferred authorization in an attempt to process the funds.

 

What Are the Risks of Deferred Authorization?

Deferred Authorizations are a merchant accepted risk and could result in loss of funds. A deferred transaction could be declined for the following reasons as an example:

  • Lack of funds in the account
  • Incorrect PIN
  • Blocked card
  • Voice Referral required
  • Fraud

 

The Deferred Process

A Deferred Authorization should only be attempted in instances where an online authorization is required but no response was available from the NMI Gateway due to a connection error. In this instance, your solution should check against predetermined variables agreed with the merchant, such as total volume and value of transactions currently deferred, to ascertain if it is advisable to continue.

If within the scope of acceptable loss, as deemed by the merchant, then your solution should store the transaction information securely to be re-attempted once communications are restored. Once communications have been restored, the solution should re-attempt the transaction with the following:

  • MessageType should be changed from Auth to DeferredAuth
  • OfflineDateTime should be included in the request with the original date and time the transaction was attempted

If no response is provided, you may repeat the process for 24 hours until a response is received, at which point the process should cease. Where a hard decline response is received, it may be possible to re-attempt the Deferred Authorization, however, this should be discussed with your processor to ensure your process is in line with scheme rules.

It should also be noted that a Deferred Authorization request will automatically be marked for settlement if approved, and does not require manual confirmation. Automatic confirmation can be disabled by setting the autoConfirm element to false in the Deferred Auth request; the transaction will then require manual confirmation before being sent for settlement.