Issuer Response Timeouts

Welcome to the second article in my series, which concentrates on problems with issuer host responses.

Background and mechanics

Within Visa the name of the service which manages the handling of response times is called Assured Transaction Response (ATR). For clarity, my education series revolves around VisaNet processing. I worked for Visa for over 27 years, and although other schemes will have similar code under the ISO 8583 standard, my articles will represent (and celebrate!) Visanet processing.

The idea of ATR is to assure that the cardholder gets a response when transacting, whether it's face to face, or online. No one likes to wait around when they are waiting for an authorization, especially at a POS or ATM.

Visa has time limits set in the system and the current time limits for Visa transactions (except Visa Europe region) are as follows:

Transaction Type	Time Limit	Europe Region
ATM Cash Withdrawals (Merchant Category Code 6011)	25 seconds	5 seconds
POS transactions (including PIN@POS, and POS transactions through an ATM channel)	10 seconds	5 seconds

The limits above are for the whole round trip from Visa to the issuer, and the response coming back. A timer is set as soon as Visa sends the auth out to the issuer host and if a valid response isn't received in the time limit, then the ATR process kicks in and sends the transaction to Visanet Stand In Processing (STIP) for an authorization decision for sending to the acquirer of the transaction and onwards.

There are 3 main reasons why a valid response won't be returned:

1. Late response from the issuer host
2. No response from the issuer host
3. Rejected/discard response from the issuer host due to bad data

Example of a timeout

For an example of the first scenario above, let's see this played out with our characters from the previous article, Cardo and Swipey. Some new characters to introduce for this story, so please meet Decline-o-saurus, who just loves a declined transaction, and Timeoutina, the timekeeper and enforcer of ATR.

Let's see what happened:

For this scenario, the response was after 1 minute, but ATR cut off the transaction after 10 seconds (POS transaction) and the transaction went to STIP processing. The result from STIP was a decline and seemed to make Decline-o-saurus very happy!

Further analysis of the scenario

When a late response arrives, it is dropped entirely and STIP becomes the sole processor and responder for the authorization attempt. The fact that STIP declined the transaction is important and underscores how critical it is for the issuer to respond on time.

If the card was in good standing and the issuer's late response would have been an approval, the intended (unused) approval conflicts with the final outcome of decline and the cardholder would be left disappointed. An added and embarrassing problem for the card issuer is that they might send a text or other notification to the cardholder after they approve the transaction. I remember a scene described to me when cardholders in a grocery store were getting text with approvals, and the store staff were telling them it was actually declined. Anger and stress all around!

Another important point in late-response scenarios is that if the authorization attempt is fraudulent and the issuer intends to decline it, STIP could theoretically approve it, which affects both the issuer and the cardholder that is defrauded.

On a final point about late response, it can be astonishing how late some responses happen. For a long time, the worst I observed was about four hours late; subsequent enhanced reporting revealed even longer delays were sometimes happening.

Different scenarios causing timeouts

As mentioned, sometimes the issuer does not respond at all. This would of course need checking on the issuer host side for the reasons.

A rejected-response scenario was covered in my first educational article. The processing is the same, including the reject code sent to the client in header field 14.

Discarded responses are rarer and relate to Visa's retain-and-return fields, where the issuer must return the field exactly as received in the authorization request. Common examples include various header fields, and field 41. The key difference is that for discarded responses the issuer does not receive a notification, unlike with rejected responses.

What's next

Future articles will cover services related to these scenarios, such as STIP processing and the use of STIP advice messages.

Referencing the scenarios above, I once analyzed a batch of 3.9 million timeouts over a few months and found 1.6 million due to late responses, 600,000 due to rejected responses, and 1.7 million due to no responses.