Consecutive Offline Transaction Amount – COTA

Each of the counters has two limits defined by the Issuer: the lower limit and the upper limit. The card sets the CVR signs of exceeding the specified limits. Any of the counters can be used to limit the amount of money spent in consecutive offline transactions performed by the card. For example, the Issuer wants to use the number of consecutive operations performed offline for this purpose

The logic of limiting offline transactions performed sequentially by the card can be described as follows: if the counter is less than or equal to the lower limit, the transaction must be performed offline, and when the counter is greater than the lower limit, but not higher than the upper limit, the transaction must be authenticated by the Issuer on the terminals, which are able to go online, or must be approved offline if an online operation is not possible

Because the terminal only works offline, or because the terminal can’t currently perform a transaction online (unable to go online). If the counter exceeds the upper limit, the transaction must be performed online on terminals that are able to go online, or it must be rejected if the online operation is not possible

In order for the card to support this logic of limiting consecutive offline transactions, the Issuer must set the CIACOnline bits “exceeded the lower limit of offline transactions” and “Exceeded the upper limit of offline transactions”, and the CIAC-Default bit “Exceeded the upper limit of offline transactions”. Then, if the terminal requests a TC cryptogram, the card increases the counter value by 1, checks its limits, and sets the CVR to “Exceeded the lower limit of offline transactions” if the counter is greater than the lower limit, and the “Exceeded the upper limit of offline transactions” if the counter is greater than the upper limit. If none of the signs of exceeding the limit is set in the CVR, the card will generate a TC cryptogram regardless of the terminal type. If you set the CVR to exceed the lower limit (but not the upper limit), the online terminal will match the CVR and CIAC-Online signs, and the card will return the ARQC cryptogram, and the TC cryptogram for the offline terminal, since the CIAC-Default attribute “Exceeded the lower limit of offline transactions” is not set. Finally, if both limits are exceeded in the CVR, the card will generate an ARQC cryptogram for the online terminal and an AAC cryptogram for the offline terminal, since the CIAC-Default attribute is set to “exceeded the upper limit of offline transactions”.

Online transaction processing Actions performed by the servicing Bank or Issuer should not be described in this document. At least because the ECV terminal emulator is not intended for communication with the servicing Bank and the Issuer. However, for many reasons that will be explained later, you should explain the logic of processing a transaction online. Keep in mind that the following is the most General description that may not apply to a number of payment applications. If the card in response to the first GENERATE AC command indicates that the transaction should be sent to the Issuer for authorization, the terminal sends a message to the host of the servicing Bank that contains information related to the card and the results of processing the transaction. Based on this data, the host of the servicing Bank generates an authorization request to the Issuer (ISO 8583 message x100) containing such data:
▪ cryptogram ARQC
▪ card information (PAN, card expiration date, etc.))
▪ information about the terminal (ID, type, etc.)
▪ serial number of the ATC transaction
▪ the Issuer Authentication Data element generated by the card

When receiving an authorization request, the Issuer checks whether the card used for the transaction is genuine. To do this, the Issuer calculates the session key for generating the cryptogram, and then uses it and the transaction data to obtain the cryptogram. The resulting cryptogram is compared with the provided ARQC value. If the values match, the card authentication is considered successful, and the card itself is considered authentic. Further, the Issuer performs standard checks (checking the card activity, card usage history, absence of the card in the list of blocked cards, availability of funds in the card account, etc.). The data received by the Issuer in the authorization request allows it to make the correct decision on how to complete the current operation, influence the execution of the next transaction, and correct the card data using the script processing commands and / or the Card Status Update (CSU) data element.

After making a decision about the result of the operation, the Issuer generates the Issuer Authentication Data item. This element contains the Issuer’s ARPC cryptogram, which is used by the card to authenticate the Issuer, and the Card Status Update (CSU), which indicates whether the transaction was approved or rejected by the Issuer, and also defines the actions that the card should perform from the Issuer’s point of view. The authorization response to the servicing Bank (message X100 of the ISO 8583 standard) contains the Issuer Authentication Data element, the Issuer’s authorization code, and the script processing commands if they are to be transmitted to the card. If the terminal did not receive an authorization response or received it too late, the terminal continues to process the transaction, considering that the request cannot be sent to the Issuer (this situation is usually called “unable to go online”). In any case, the terminal must get the application cryptogram from the card using the second GENERATE AC command. However, before executing this command, the terminal must pass critical script processing commands to the card, if they are present in the authorization response. In the second GENERATE AC command, the terminal transmits data received from the Issuer to the card (the Issuer’s authorization code, the Issuer element, the CSU data elements, and the Issuer Authentication Data Are not mandatory for the payment application. For some applications, only the Issuer’s cryptogram is required.