Deferred Authorizations

 Table of Contents

1. Overview
2. Implementation
   1. Deferred Authorization Event
   2. Continue Deferred Authorization Method
3. Requirements

Overview

Deferred Authorizations are transactions that are processed offline at the merchant's own risk when internet connectivity is not available. More information and how to enable Deferred Authorizations can be found here.

Assuming everything has been correctly configured (both enabled on TMS and implemented as described below), the Payment Device SDK will prompt the merchant to accept the deferred authorization. This will store the authorisation request and try to send the transaction online over a 24 hour period. The transaction must go online within the 24 hour period or it will move into a failed queue. If you try to confirm a transaction that has expired (after the 24 hours), a DeferredAuthorizationExpired error will be thrown.

Implementation

Deferred Authorization Event

The Payment Device SDK will fire a DeferredAuthorization event when the Payment Device SDK determines that a deferred authorization is possible, and verification from the merchant is required: event EventHandler<EventParameters> DeferredAuthorizationEvent

• PinBlockPresent (always present) - Returns true or false depending if the transaction data contains an online PIN block.

• DeferredAuthorizationReason (always present) - Returns the reason why a deferred authorization is possible. See below for the enumeration notes:
  • ConnectionFailed
    the Payment Device SDK was unable to initialize a connection to the NMI payment gateway. No data was sent to the gateway and the transaction exists entirely offline.
  • CommunicationFailed
    An error occurred during communication with the Credticall gateway. This can happen for multiple reasons with the most common being that the Payment Device SDK was not able to send its request or did not receive a response within the allowed timeout.
  • ProcessingFailed
    There was no issue between the communication of the Payment Device SDK and the Credticall gateway but there was a communication error between the gateway and the payment processor. This could happen in the rare event that the processor is experiencing connectivity issues.
  • None
    Default state which will never be sent as part of a deferred authorization event.

Continue Deferred Authorization Method

If the Payment Device SDK is configured to support deferred authorizations, the ContinueDeferredAuthorization method should be called to continue the transaction after a DeferredAuthorizationEvent by either approving or declining the transaction. ContinueDeferredAuthorization requires the following parameters:

• DeferredAuthorizationApproved (required) - Parameter key for the deferred authorization result. The value can be true or false.

The following response will be returned only when an error condition has been encountered:

• Errors - Values may come from ValidationErrorCode, ChipDnaErrorCode and PaymentDeviceErrorCode.

Once a Deferred Authorization is accepted, the transaction will be added to the pending offline queue which will attempt to send the transaction to our platform once internet connectivity is re-established for a period of 24 hours. If the transaction does not get sent to our platform within the 24 hour period, it will be moved from the pending queue to the failed queue.

*Transactions that get sent to our Platform and get declined will be placed back in the pending queue to be retired (every 8 hours by default) until the 24 hour period is reached. This is a scheme recommendation. 

Requirements

• Payment Device SDK 2.03 has support for deferred authorizations on the following devices:
  • Ingenico RAM, RBA, UPP
  • Miura MPI
  • Verifone VIPA
  • CPI eChoice
  • MEI 5in1
  • Verifone XPI

Please refer to the Payment Device SDK Windows or Linux release notes for more information on when specific device support was added.