Acquiring: Errors, Automatic Reversals, SMS Notifications

Introduction

In this article, we will consider the situations that arguably any merchant/acquirer/cardholder comes across, namely the technical failures and denial responses when using the cards. In addition, we will address the matters of SMS notifications and automatic reversals.

Terms and Definitions

Authorization is the process of data exchange between the parties of a transaction through a bank card or other means of payment (e.g. mobile wallet, etc.). A standard exchange chain is as follows: An acquirer (see below) sends an authorization request to the Payment system (hereinafter referred to as PS), and the PS sends it to the issuer. The issuer performs all the necessary checks such as security checks, checks of funds available on the card account, and other checks based on which a response (affirmative or denial) to the authorization request will be sent. The response to the authorization request will be sent on the return route. I.e., to the PS first and then to the acquirer.

POS-terminal (POS - Point Of Service) is a device providing the capability to service the cards and other means of payment.

The issuer is a financial institution (bank or another financial organization) that has issued a card.

The acquirer is a financial institution (bank or another financial organization) that ensures the cards servicing by the merchant.

The issuer and the acquirer have the name common to them from the viewpoint of the payment systems: Party. Hereinafter we will use all three terms depending on the context.

The merchant is a retail and service outlet (hereinafter the RSO) with the capability to take bank cards.

The cardholder is a holder of a card with the right to perform a set of transactions permitted by the issuer.

The processing center (PC) is the software and hardware appliance providing the technological capability of the information exchange between the internal and external parties of the settlements within one or another service (acquiring, in our case).

Another relatively common designation of the PC is the «Banking Host», or simply the «Host». I.e., a node serving as the server within the classic customer-server architecture. In the hereafter, we will use both the PC acronym and the term «host» and its derivatives.

Response codes

A response code (RC) is the result and the success criteria of any transaction. Within the scope of ISO 8583 protocol, it is transmitted to field 39 of the response message. The format of an RC depends on the version of ISO 8583: it is two-digits for ISO 8583:1987 version, and three-digits for ISO 8583:1993 version. We will essentially consider the exchange within the scope of the 1987-year version due to its greater prevalence. In addition, note that each developer of the PC uses various approaches to ensure compatibility between the versions: certain hosts transfer three RC characters within the scope of P2H. However, if the exchange is made within the scope of the 1987-year version by filling the leading character (the leftmost) with zero. In other cases, the PC converts the 1993-year version three-digits RC into its ISO 8583:1987 two-digits equivalent and sends it to the POS like this.

The response codes can be divided into the approval and denial responses. Any response, save for the clear «Approved» response or its semantic equivalent, is a denial response. This can be caused by either a technical error or the issuer’s refusal to perform one or another transaction.

Hereunder, we will list the most common RCs and divide them into two conventional groups, namely the technical RCs and the service RCs.

Technical RCs

This group includes the primary response codes received due to certain technical failures or errors in the messages filling. Note that the causes of any of the below-listed RCs are more or less variable and are only given in this article for the purpose of example.

00 - Approved. The transaction is completed successfully.

12 - Invalid Transaction. Certain parameters of the transaction are invalid. Suppose that the message fields are filled in a way implying that the Cash withdrawal transaction is to be carried out in the trade POS terminal, which is, generally, unacceptable.

12 - Invalid Transaction. Certain parameters of the transaction are invalid. Suppose that the message fields are filled in a way implying that the Cash withdrawal transaction is to be carried out in the trade POS terminal, which is, generally, unacceptable.

14 - Invalid Card Number. Field 2 (Card Number) is filled incorrectly or there is an attempt to perform the card transaction that is not in the issuer’s database.

15 - Invalid Issuer. Such RC is usually sent by the authorization platform of the PC and means that the route of the transaction sending to the issuer is not found (in most cases it is due to an invalid BIN of the card).

30 - Format Error. This occurs due to one or another error when the message is filled in line with a certain dialect. For example, some field exceeds the admissible quantity of digits or there is none at all or filled using an incorrect format and/or character set. However, in case of such RC sending, a number of PCs sends an additional field in the response message specifying the incoming message’s element in error.

88 and 89 - Cryptographic Failure. The transaction is declined due to the cryptographic errors. For example, such errors as the PIN block encryption error, digital signature check error, etc.

96 - System Error. In general, this error shows that a failure occurred at one of the stages of the exchange. As a rule, this occurs within the acquirer’s PC. However, there were cases when this RC was also transmitted within the H2H.

Service RCs

Service RCs are the response codes of the transactions within which no technical errors were present and the denial was due to the limitations of access to one or another service caused by the issuer or the PC or due to other conditions not related to the technical issues.

00 - Approved. The transaction is completed successfully.

01 - Refer to Call Issuer. To complete the transaction, it is necessary to contact the issuer.

04 - Capture Card. The Issuer or the PC has sent the card capture command.

05 - Do Not Honor. Denial without explanation. In most cases, the issuer sends such an RC. Refer to the issuer to clarify the causes.

41 - Lost Card. Attempt to perform a transaction using a card marked as lost in the issuer’s or the PC’s databases.

43 - Stolen Card. Attempt to perform a transaction using a card marked as stolen in the issuer’s or the PC’s databases.

51 - Not Sufficient Funds. The amount of the transaction exceeds the amount of the funds available on the card account.

52 and 53 - No Checking/Saving Account. Attempt to perform a transaction with an incorrect card account.

54 - Expired Card. Attempt to perform a transaction using an expired card.

55 - Incorrect PIN. Incorrect online PIN code when performing a transaction with the online PIN code.

57 - Transaction Not Permitted to Issuer/Cardholder. Attempt to perform a transaction not permitted to a specific issuer or cardholder.

58 - Transaction Not Permitted to Acquirer/Terminal. Attempt to perform a transaction not permitted to a specific acquirer or terminal.

Such is the list of the most common response codes the values of which are the same for all the leading PCs. Note that their number is somewhat greater and varies depending on a specific dialect of the PC. For example, the specification of Visa can include the RCs that are not included in the specification of Mastercard and vice versa.

Offline response codes

We should also, in broad strokes, address the offline RCs. These include the codes generated by the software of the POS terminal. Since in this case, the exchange is carried out without the scope of ISO 8583, and the conditions of such RCs generation occur during the so-called EMV Transaction Flow, let us limit ourselves to a general description (The matters of the APDU/EMV exchange will be clarified in more detail in future articles).

Z1 - OFFLINE DECLINED. The decision was made to decline the transaction without sending an online message.

Z3 - NO ONLINE, DECLINED. POS terminal attempted to send an online request that failed due to the lack of online communication. The transaction was declined offline.

Y1 - OFFLINE APPROVED. A transaction was approved without the online query to the issuer. This is true for the terminals supporting the offline transactions.

Y3 - NO ONLINE, APPROVED. POS terminal attempted to send an online request that failed due to the lack of online communication. The transaction was approved offline. This is true for the terminals supporting the offline transactions.

SMS Notifications

Many cardholders use the SMS notifications service, which is very popular nowadays. While obviously convenient, in some cases it is a cause of disputes and sometimes scandals between the merchant and the cardholder. Let us consider the most typical case:

• A customer uses a credit card to pay.
• Then he receives an SMS informing that the cost of service/purchase has been debited.
• The terminal does not print the receipt/ freezes up/ restarts.
• The merchant has no successful transaction receipt in hand.
• The customer says that the transaction has been successful referring for that purpose to the SMS notification.

The scenario of further development depends on the RSO staff’s experience level and many other factors.

The first and the most important thing that we should consider in such a situation is that: a card transaction success criterion is a receipt (or its electronic counterpart, if the case in hand is a terminal approved by the PC and not equipped with a POS printer) containing a successful response code and/or its transcription. The SMS notifications received by a customer are not the transaction success criterion. No dispute cycle will deem an SMS notification received by the cardholder to be an argument under any claim. This is mainly because such service as the SMS notification is in no way included in the PCs’ specifications, meaning that the technical tools used to achieve it, including the protocols/format of exchange, depending on each specific issuer. In particular, it may be implemented using various logger solutions. In general, some hypothetical «SMS server» analyzes the requests to the card contract and records the changes in its available balance. Beyond that, in most cases, fields 41 (Terminal ID), 42 (Merchant ID) and 43 (Card Acceptor Name/Location) from the incoming acquirer’s request can be analyzed. After that those data are introduced in the SMS message «body» and sent to the telephone number specified by the cardholder during the issue of the card. The output is an SMS message having approximately the following format: «CARD, DATE/TIME, Transaction type, Amount, NAME OF THE RSO, AVAILABLE BALANCE».

Let us highlight some important things: in fact, the SMS server functioning principle is based on the trigger action. It can be set to action in case of the Payment transaction performing but fail to act in case of the Payment reversal transaction; furthermore, the SMS server «knows» nothing of the condition of the communication lines at the time of the transaction performance. Consequently, it is unable to «understand» whether or not the response to the authorization was successfully delivered to the POS terminal. The amount and the combination of all those factors as well as the absence of specifications of the PCs result in the SMS info being an extremely unreliable source. This should be taken into account by both the merchants and the cardholders. Certainly, the quality of provision of such a service as the SMS notification has significantly increased over the last years. However, all of the above-said remains true.

Automatic reversals

An automatic reversal is a reversal originated by the device or the acquirer’s PC in case of certain conditions occurrence and not involving the RSO’s staff. The most common causes of the automatic reversals are:

• timeout of response from the PC/ from the issuer (so-called «response timeout») at the level of the acquiring host or timeout at the level of the POS terminal.
• error of the response analysis by the acquiring host or, more commonly, by the POS terminal.
• card denial due to the issuer’s cryptographic analysis failure (ARPC) (only true in the cases of the contact chip cards).
• other errors at the level of the terminal’s software operation logic (e.g., run out of the paper during the receipt printing, there are issues with the communication line, etc.).

In all those cases, the acquirer generates the Automatic reversal. The typical signs of such message at the level of ISO 8583:1987 are the following:

1. MTI=0400 (Reversal), or 0420 (Reversal Advice).

2. Field 39 = 06 (Error), or 82 (Timeout At Issuer). In addition, field 39 for the MTI 04xx messages are interpreted not as the Response code, but as the Reason code, meaning the reason for the automatic reversal.

At the level of the end device, i.e., the POS terminal, the automatic reversal is interpreted depending on the specific software and/or the configuration of the terminal. I.e., the terminal can both print the automatic reversal receipt and simply display the information message on the viewscreen. The actual information content of the receipt or the automatic reversal messages can also vary. There is only one factor in common: the transaction is originated by the device (i.e., the PC or the terminal), and not by the merchant (i.e., the cashier).

Such is, in general, the range of the issues and specific features of the acquiring that all the Parties come across one way or another.

Thank you for your attention and see you next time!

Our Payment Solutions