March 11, 2021

Visa Deferred Authorization

Visa previously announced that it would require merchants and acquirers to identify deferred authorization transactions being processed, but what constitutes a deferred auth, and what does that mean for merchants? Let’s briefly explore.

A deferred authorization occurs when a merchant cannot complete an authorization at the time of the transaction with the cardholder due to connectivity, systems issues, or other limitations and then later completes the authorization when it can do so. Specifically, marking these “delayed” transactions is meant to help alleviate the confusion sometimes caused to card Issuers during the course of transaction processing.

To fulfill this Deferred Auth directive, acquirers have provided instruction for changes to our middleware so that MCM may transmit deferred transactions with their specific identifiers within the formatted message to the host processor.

What will this change entail?

Our middleware product specifications will, along with other communications, outline the details of the change. Still, as an overview, we will be implementing a Request Only token to indicate that any given authorization request is a deferred authorization.

If you’re familiar with the process—and if your business rules allow for it— a transaction that has not been authorized in real-time will be placed in a Store-and-Forward (SAF) mode. The transactions are then held on record until such a time that they can be cleared, based on a merchant’s business process and configured environment. Since the mandate requires these deferred transactions to be flagged with an identifier, the SAF framework will allow for the labeling of each of the eligible deferred transactions with a Deferred Authorization Indicator—or DF token. In turn, this will enable the payments systems process to recognize them and facilitate their journey into final authorization.

A Preview of Some Functional Requirements

The transaction request is created at the Clear SAF time and will be implemented according to each host processor’s message format. The requirements will chiefly apply to Clear SAF, Trickle SAF, and Auto SAF for Retail and Restaurant environments, where the DF token will be added in the clearing of “SAFed” transaction requests for all supported entry modes: card present, token, and manual entry.

Impact on Merchants

The totality of this change will be contained within the MCM middleware. This means that there is no expected impact on the POS or other system(s) interfacing to MCM. The update—and any interaction with it—would strictly be limited to communication between MCM and the intended acquirer, therefore requests from, and responses to, the point-of-sale system would remain unaffected for this mandate.

For more detail on exceptions, exclusions, all there is to know on this mandate or MCM versions affected, please contact our Client Services team.