Tomcat
Professional
- Messages
- 2,689
- Reaction score
- 963
- Points
- 113
A number of mandatory restrictions are imposed on the CCD application related to the implementation of certain decisions of the issuer about how to process a transaction. Let's list them.
1. In case the 'Issuer Authentication not Performed' bit in CVR is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing a transaction in an online capable terminal (a terminal capable of processing a transaction in real time).
In addition, if it is impossible to send an authorization request to the issuer (for example, an offline only terminal is used), the issuer must be able to define one of two solutions in the application - reject or approve the transaction.
2. In case the 'Issuer Authentication Failed' bit in CVR is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing the transaction in an online capable terminal.
In addition, if it is impossible to send an authorization request to the issuer, the issuer must be able to determine on the card one of two solutions - to reject or approve the transaction.
3. In case the CVR 'PIN Try Limit Exceeded' bit is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to reject the transaction offline.
In addition to this solution, in this case, the issuer must be able to configure a decision on the card to send a transaction for authorization to the issuer, if the terminal is able to process the transaction online. If the terminal cannot send an authorization request to the issuer (for example, an offline only terminal is used), the issuer must determine one of two solutions on the card - reject or approve the transaction.
The CCD application must not block itself or the card if the 'PIN Try Limit Exceeded' bit is set to 1. For example, the VSDC application allows the application to be blocked if the PTL limit is exceeded.
4. In case the 'Last Online Transaction Not Completed' bit in CVR is equal to 1, the issuer must be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing the transaction in the online store terminal.
In addition, if it is impossible to send an authorization request to the issuer, the issuer must be able to determine on the card one of two solutions - to reject or approve the transaction.
5. If the 'Upper Offline Transaction Count Limit Exceeded' bit in CVR is equal to 1, when processing the transaction in an offline only terminal or the inability to send an authorization request to the issuer, the CCD application must reject the transaction.
The issuer must be able to define in the configuration of the CCD application the decision not to reject the transaction for terminals of the Terminal Type = '26'h type (i.e., for an unattended offline only terminal, or otherwise a CATZ terminal).
6. If the CVR's 'Lower Offline Transaction Count Limit Exceeded' bit is set to 1, the CCD application MUST send the transaction for authorization to the issuer when processing the transaction in the online terminal.
7. If the 'Lower Cumulative Offline Amount Limit Exceeded' bit in CVR is equal to 1, the CCD application must send the transaction for authorization to the issuer when processing the transaction in the online store terminal.
8. If the 'Upper Offline Transaction Count Limit Exceeded' bit in CVR is 1, in the case of an offline only terminal or the impossibility of sending an authorization request to the issuer, the CCD application must reject the transaction.
The issuer should be able to define in the configuration of the CCD application the decision not to reject the transaction for terminals of Terminal Type = '26'h.
9. If the 'Issuer Script Processing failed' bit in CVR is 1, the CCD application must, in the case of an online terminal, send the transaction to the issuer for authorization.
10. In the case when the 'Go Online on Next Transaction was set' bit in CVR turned out to be 1, when processing a transaction in an offline only-terminal or when it is impossible to send an authorization request for processing to the issuer in real time, the issuer must define in the configuration CCD- applications, one of two solutions is to reject or approve the transaction.
It should be noted that all of the above requirements can be implemented by a card application using three Card Issuer Action Code-Decline (CIAC-Decline), Card Issuer Action Code-Online (CIAC-Online), and Card Issuer Action Code - Offline (CIAC-Offline) objects. ).
Note that the term Card Issuer Action Code came from the M / Chip applications of the MasterCard payment system, and the above CIAC objects are not used in the applications of the VISA payment system. Instead, the VIS 1.4.x specification uses an Application Default Action data object (Tag '9F52', 4 bytes) that defines the actions that the card should initiate when certain conditions are met, mainly captured in the CVR object. According to the Application Default Action (ADA), the card can reject the transaction, force it to be processed in real time, and prepare an advice message for the card issuer. Here is an example of an ADA object taken from the VIS 1.4.x specification:
• Byte 1:
bit 8: 1 = if the issuer authentication failed, the next operation should be processed online;
bit 7: 1 = if the issuer authentication fails, the transaction should be rejected;
bit 6: 1 = if issuer authentication is required but no ARPC item was received, the transaction should be rejected; as of VSDC 2.5, this bit is 0 and is reserved for future use;
bit 5: 1 = if the transaction is declined offline, a notification to the issuer is required;
bit 4: 1 = if the PTL limit is exceeded during the execution of the current transaction, a notification to the issuer is required;
bit 3: 1 = if the transaction is declined due to failure of issuer authentication or failure of issuer authentication, a notification to the issuer is required;
bit 2: 1 = if the card is new, the transaction must be processed online;
bit 1: 1 = if the card is new and the terminal is unable to send an authorization request to the issuer, the transaction must be rejected.
• Byte 2:
bit 8: 1 = if the PTL limit is exceeded during the execution of the current transaction, the application must be locked;
bit 7: 1 = if the PTL limit is exceeded during the execution of a previous transaction, the current transaction should be rejected;
bit 6: 1 = if the PTL limit was exceeded during the execution of a previous transaction, the transaction must be processed online;
bit 5: 1 = if the PTL limit is exceeded during the execution of a previous transaction and the transaction cannot be processed online, the transaction must be rejected;
bit 4: 1 = if Issuer Script Processing failed during a previous transaction, the transaction must be processed online;
bit 3: 1 = if the PTL limit was exceeded during the execution of a previous transaction, the current transaction should be rejected and the card application blocked;
bit 2: 1 = do not reset the Cumulative Total Transaction Amount (CTTA) value when processing the AC GENERATE command. The CTTA value is set to 0 when the issuer command PUT DATA [CTTA Limit] is executed;
bit 1: 1 = do not reset the VLP Available Funds value when processing the AC GENERATE command. The VLP Available Funds value is set equal to the VLP Funds Limit when the issuer command PUT DATA [VLP Funds Limit] is executed.
• ByteZ:
bit 8: 1 = do not include transactions successfully authorized in offline mode in the transaction log;
bit 7: 1 = do not include in the transaction log file transactions successfully authorized online;
bit 6: 1 = include rejected transactions in the transaction log;
bit 5: 1 = VLP Available Funds must be reset if PIN Offline check is successful;
bits 1-4: reserved for future use.
• Byte 4: All bits of this byte are reserved for future use.
The ADA object is used if the card supports the issuer authentication procedure (ARPC verification is optional in the EMV standard).
Now we will describe how the card uses CIAC objects to make its decision on how to continue processing the transaction after receiving the first GENERATE AC command. Let's illustrate the choice of solution using the example of the M / Chip 4 application. In the M / Chip 4 application, CIAC objects are 3 bytes each. In this case, the CIAC byte structure displays the structure of the last three bytes of the CVR object (bit x (x = 1, ... 8) byte y (y = 1,2,3) of the CIAC object and bit x of byte y + 3 of the CVR object have the same semantic content ).
From fig. 4.7 it can be seen that if the terminal requests the AAC cryptogram from the card, then the card generates the requested cryptogram without analyzing the CVR object.
If the terminal requests the TC cryptogram from the card, then the CIAC objects are used in accordance with the algorithm described below.
Step 1. The card selects all equal '1' CVR bits (one bits). Further, for each such bit, the CVR card checks the values of the bits of the same type for it (the CVR and CIAC bits are called the same type if the bit number is the same, and the CVR byte number is 3 higher than the CIAC byte number) in the CIAC-Decline object. If for some single bit of CVR the same type of bit in CIAC-Decline is 1, trans-
Rice. 4.7. Diagram of decision making by the map after the first command GENERATE AC
The transaction must be rejected without attempting online authorization, and the terminal asks the card for the AAC cryptogram. Otherwise (for all CVR one bits, the same bits in the CIAC-Decline are 0), the card proceeds to step 2 if the terminal is capable of performing a transaction in real time, and to step 3 otherwise.
Step 2. By analogy with step 1, the card checks the CVR against the CIAC-Online object. If, as a result, for some single CVR bit, the same type of bit in CIAC-Online is equal to 1, the card considers that the transaction must be sent for authorization to the issuer and generates the ARQC cryptogram. Otherwise (for all single bits of CVR, the same type of bits in CIAC-Online are equal to 0), the card considers that the transaction must be approved in offline mode, and generates a TS cryptogram.
Step 3. By analogy with step 1, the card checks the CVR against the CIAC-Offline object. If, as a result, for some single bit of CVR, the same type of bit in CIAC-Offline is equal to 1, the transaction must be rejected, and the card generates an AAC cryptogram. Otherwise (for all single bits of CVR, the same type of bits in CIAC-Offline are equal to 0), the card offers to approve the transaction in offline mode and generates a TS cryptogram.
If the terminal requests the ARQC cryptogram from the card, then transaction processing is performed as follows. In the case of an offline terminal, the transaction is rejected and the card generates an AAS cryptogram. If the terminal is online capable, the transaction is sent for authorization to the card issuer.
If in the second GENERATE command the AC terminal requests a vehicle, the card uses only the CIAC-Offline object when making a decision. The card performs a CVR check against the CIAC-Offline object. If, as a result, for some single bit of CVR, the same type of bit in CIAC-Offline is equal to 1, the transaction is rejected, and the card generates an AAC cryptogram. Otherwise (for all single bits of CVR, the same type bits in CIAC-Offline are equal to 0), the card approves the transaction in offline mode and generates a TS cryptogram.
The process of making a decision by the map after receiving the second GENERATE AC command is schematically shown in Fig. 4.8.
Let's go back to the cards that support the CCD application. If in the second GENERATE AC command such a card receives the Issuer Authentication Data, then this data element contains the Card Status Update (CSU) element, the structure of which is shown in Table. 4.24-4.27.
Tab. 4.24. Byte 1 CSU (leftmost)
Tab. 4.25. Byte 2 CSU
Tab. 4.26. Byte 3 CSU
Tab. 4.27. Byte 4 CSU (rightmost)
The use of the CSU element is an alternative to the Issuer Script Processing procedure, which will be discussed in section 4.13. With the help of this element, the issuer is able to change the state of the card and change the values of its parameters.
If the issuer authentication is successful and the terminal requests a vehicle from the card, and bit 8 of byte 2 'Issuer Approves Online Transaction' in the received CSU element is 1, then the card approves the transaction and returns the vehicle cryptogram.
If the issuer authentication is successful and bit 8 of byte 2 of the 'Issuer Approves Online Transaction' in the received CSU is 0, then the card rejects the transaction and returns the AAC cryptogram.
Thus, the use of the CSU and ARPC cryptogram format 2 ensures the integrity of the exchange of information between the issuer and the card. In particular, the impossibility of unauthorized modification of the issuer's decision on the result of the operation is ensured.
If the issuer authentication is successful and bit 7 of Byte 2 of the 'Card Block' in the received CSU is 1, then all card applications are blocked. The card shall respond to all subsequent SELECT commands using the SW1SW2 value of '6A81'h.
If the issuer authentication is successful and bit 6 of Byte 2 of the 'Application Block' in the received CSU is 1, then the selected card application is blocked. The card shall respond to all subsequent SELECT commands using the SW1SW2 value equal to '6283'h, and return the AAC cryptogram to the terminal to the AC GENERATE commands.
If the issuer authentication is successful and bit 5 of byte 2 of the 'Update PIN Try Counter' in the received CSU is 1, then the PTC value in the CVR is set to the number specified in bits 4-1 of the first byte of the CSU.
If the issuer authentication is successful and bit 5 of byte 2 'Update PIN Try Counter' in the received CSU element is 0, then the PTC value does not change and the values of bits 4-1 of the first byte of CSU are not used by the CCD application in any way.
If the issuer authentication is successful and bit 4 of byte 2 'Set Go Online on Next Transaction' in the received CSU is 1, then the card sets the corresponding CVR bit to 1 and sends the next transaction for authorization to the issuer if the terminal is able to process the transaction online. The card will continue to route transactions for online authorization in the case of an online terminal as long as the value of bit 2 of byte 4 of CVR 'Go Online on Next Transaction' is 1.
If the issuer authentication is successful and bit 3 of byte 2 'CSU created by Proxy for Issuer' in the received CSU element is 0, then depending on the value of bits 2 and 1 of byte 2, the CSU card will reset the VCC and SOTA parameters, as indicated in these bits :
1. In case the 'Issuer Authentication not Performed' bit in CVR is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing a transaction in an online capable terminal (a terminal capable of processing a transaction in real time).
In addition, if it is impossible to send an authorization request to the issuer (for example, an offline only terminal is used), the issuer must be able to define one of two solutions in the application - reject or approve the transaction.
2. In case the 'Issuer Authentication Failed' bit in CVR is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing the transaction in an online capable terminal.
In addition, if it is impossible to send an authorization request to the issuer, the issuer must be able to determine on the card one of two solutions - to reject or approve the transaction.
3. In case the CVR 'PIN Try Limit Exceeded' bit is equal to 1, the issuer should be able to define in the configuration of the CCD application its decision to reject the transaction offline.
In addition to this solution, in this case, the issuer must be able to configure a decision on the card to send a transaction for authorization to the issuer, if the terminal is able to process the transaction online. If the terminal cannot send an authorization request to the issuer (for example, an offline only terminal is used), the issuer must determine one of two solutions on the card - reject or approve the transaction.
The CCD application must not block itself or the card if the 'PIN Try Limit Exceeded' bit is set to 1. For example, the VSDC application allows the application to be blocked if the PTL limit is exceeded.
4. In case the 'Last Online Transaction Not Completed' bit in CVR is equal to 1, the issuer must be able to define in the configuration of the CCD application its decision to send a transaction for authorization to the issuer when processing the transaction in the online store terminal.
In addition, if it is impossible to send an authorization request to the issuer, the issuer must be able to determine on the card one of two solutions - to reject or approve the transaction.
5. If the 'Upper Offline Transaction Count Limit Exceeded' bit in CVR is equal to 1, when processing the transaction in an offline only terminal or the inability to send an authorization request to the issuer, the CCD application must reject the transaction.
The issuer must be able to define in the configuration of the CCD application the decision not to reject the transaction for terminals of the Terminal Type = '26'h type (i.e., for an unattended offline only terminal, or otherwise a CATZ terminal).
6. If the CVR's 'Lower Offline Transaction Count Limit Exceeded' bit is set to 1, the CCD application MUST send the transaction for authorization to the issuer when processing the transaction in the online terminal.
7. If the 'Lower Cumulative Offline Amount Limit Exceeded' bit in CVR is equal to 1, the CCD application must send the transaction for authorization to the issuer when processing the transaction in the online store terminal.
8. If the 'Upper Offline Transaction Count Limit Exceeded' bit in CVR is 1, in the case of an offline only terminal or the impossibility of sending an authorization request to the issuer, the CCD application must reject the transaction.
The issuer should be able to define in the configuration of the CCD application the decision not to reject the transaction for terminals of Terminal Type = '26'h.
9. If the 'Issuer Script Processing failed' bit in CVR is 1, the CCD application must, in the case of an online terminal, send the transaction to the issuer for authorization.
10. In the case when the 'Go Online on Next Transaction was set' bit in CVR turned out to be 1, when processing a transaction in an offline only-terminal or when it is impossible to send an authorization request for processing to the issuer in real time, the issuer must define in the configuration CCD- applications, one of two solutions is to reject or approve the transaction.
It should be noted that all of the above requirements can be implemented by a card application using three Card Issuer Action Code-Decline (CIAC-Decline), Card Issuer Action Code-Online (CIAC-Online), and Card Issuer Action Code - Offline (CIAC-Offline) objects. ).
Note that the term Card Issuer Action Code came from the M / Chip applications of the MasterCard payment system, and the above CIAC objects are not used in the applications of the VISA payment system. Instead, the VIS 1.4.x specification uses an Application Default Action data object (Tag '9F52', 4 bytes) that defines the actions that the card should initiate when certain conditions are met, mainly captured in the CVR object. According to the Application Default Action (ADA), the card can reject the transaction, force it to be processed in real time, and prepare an advice message for the card issuer. Here is an example of an ADA object taken from the VIS 1.4.x specification:
• Byte 1:
bit 8: 1 = if the issuer authentication failed, the next operation should be processed online;
bit 7: 1 = if the issuer authentication fails, the transaction should be rejected;
bit 6: 1 = if issuer authentication is required but no ARPC item was received, the transaction should be rejected; as of VSDC 2.5, this bit is 0 and is reserved for future use;
bit 5: 1 = if the transaction is declined offline, a notification to the issuer is required;
bit 4: 1 = if the PTL limit is exceeded during the execution of the current transaction, a notification to the issuer is required;
bit 3: 1 = if the transaction is declined due to failure of issuer authentication or failure of issuer authentication, a notification to the issuer is required;
bit 2: 1 = if the card is new, the transaction must be processed online;
bit 1: 1 = if the card is new and the terminal is unable to send an authorization request to the issuer, the transaction must be rejected.
• Byte 2:
bit 8: 1 = if the PTL limit is exceeded during the execution of the current transaction, the application must be locked;
bit 7: 1 = if the PTL limit is exceeded during the execution of a previous transaction, the current transaction should be rejected;
bit 6: 1 = if the PTL limit was exceeded during the execution of a previous transaction, the transaction must be processed online;
bit 5: 1 = if the PTL limit is exceeded during the execution of a previous transaction and the transaction cannot be processed online, the transaction must be rejected;
bit 4: 1 = if Issuer Script Processing failed during a previous transaction, the transaction must be processed online;
bit 3: 1 = if the PTL limit was exceeded during the execution of a previous transaction, the current transaction should be rejected and the card application blocked;
bit 2: 1 = do not reset the Cumulative Total Transaction Amount (CTTA) value when processing the AC GENERATE command. The CTTA value is set to 0 when the issuer command PUT DATA [CTTA Limit] is executed;
bit 1: 1 = do not reset the VLP Available Funds value when processing the AC GENERATE command. The VLP Available Funds value is set equal to the VLP Funds Limit when the issuer command PUT DATA [VLP Funds Limit] is executed.
• ByteZ:
bit 8: 1 = do not include transactions successfully authorized in offline mode in the transaction log;
bit 7: 1 = do not include in the transaction log file transactions successfully authorized online;
bit 6: 1 = include rejected transactions in the transaction log;
bit 5: 1 = VLP Available Funds must be reset if PIN Offline check is successful;
bits 1-4: reserved for future use.
• Byte 4: All bits of this byte are reserved for future use.
The ADA object is used if the card supports the issuer authentication procedure (ARPC verification is optional in the EMV standard).
Now we will describe how the card uses CIAC objects to make its decision on how to continue processing the transaction after receiving the first GENERATE AC command. Let's illustrate the choice of solution using the example of the M / Chip 4 application. In the M / Chip 4 application, CIAC objects are 3 bytes each. In this case, the CIAC byte structure displays the structure of the last three bytes of the CVR object (bit x (x = 1, ... 8) byte y (y = 1,2,3) of the CIAC object and bit x of byte y + 3 of the CVR object have the same semantic content ).
From fig. 4.7 it can be seen that if the terminal requests the AAC cryptogram from the card, then the card generates the requested cryptogram without analyzing the CVR object.
If the terminal requests the TC cryptogram from the card, then the CIAC objects are used in accordance with the algorithm described below.
Step 1. The card selects all equal '1' CVR bits (one bits). Further, for each such bit, the CVR card checks the values of the bits of the same type for it (the CVR and CIAC bits are called the same type if the bit number is the same, and the CVR byte number is 3 higher than the CIAC byte number) in the CIAC-Decline object. If for some single bit of CVR the same type of bit in CIAC-Decline is 1, trans-
Rice. 4.7. Diagram of decision making by the map after the first command GENERATE AC
The transaction must be rejected without attempting online authorization, and the terminal asks the card for the AAC cryptogram. Otherwise (for all CVR one bits, the same bits in the CIAC-Decline are 0), the card proceeds to step 2 if the terminal is capable of performing a transaction in real time, and to step 3 otherwise.
Step 2. By analogy with step 1, the card checks the CVR against the CIAC-Online object. If, as a result, for some single CVR bit, the same type of bit in CIAC-Online is equal to 1, the card considers that the transaction must be sent for authorization to the issuer and generates the ARQC cryptogram. Otherwise (for all single bits of CVR, the same type of bits in CIAC-Online are equal to 0), the card considers that the transaction must be approved in offline mode, and generates a TS cryptogram.
Step 3. By analogy with step 1, the card checks the CVR against the CIAC-Offline object. If, as a result, for some single bit of CVR, the same type of bit in CIAC-Offline is equal to 1, the transaction must be rejected, and the card generates an AAC cryptogram. Otherwise (for all single bits of CVR, the same type of bits in CIAC-Offline are equal to 0), the card offers to approve the transaction in offline mode and generates a TS cryptogram.
If the terminal requests the ARQC cryptogram from the card, then transaction processing is performed as follows. In the case of an offline terminal, the transaction is rejected and the card generates an AAS cryptogram. If the terminal is online capable, the transaction is sent for authorization to the card issuer.
If in the second GENERATE command the AC terminal requests a vehicle, the card uses only the CIAC-Offline object when making a decision. The card performs a CVR check against the CIAC-Offline object. If, as a result, for some single bit of CVR, the same type of bit in CIAC-Offline is equal to 1, the transaction is rejected, and the card generates an AAC cryptogram. Otherwise (for all single bits of CVR, the same type bits in CIAC-Offline are equal to 0), the card approves the transaction in offline mode and generates a TS cryptogram.
The process of making a decision by the map after receiving the second GENERATE AC command is schematically shown in Fig. 4.8.
Let's go back to the cards that support the CCD application. If in the second GENERATE AC command such a card receives the Issuer Authentication Data, then this data element contains the Card Status Update (CSU) element, the structure of which is shown in Table. 4.24-4.27.
Tab. 4.24. Byte 1 CSU (leftmost)
| B8 | B7 | B6 | B5 | B4 | B3 | B2 | NS | Meaning |
| 0 | 0 | 0 | 0 | Reserved for use | ||||
| X | X | X | X | Low Order Nibble of PIN Try Counter (second least significant nibble of the PIN Try Counter parameter) |
Tab. 4.25. Byte 2 CSU
| B8 | B7 | B6 | B5 | B4 | B3 | B2 | NS | Meaning |
| 1 | Issuer Approves Online Transaction | |||||||
| 1 | Card Block | |||||||
| 1 | Application Block (application is blocked) | |||||||
| 1 | Update PIN Try Counter (the card must reset the Pin Try Counter parameter) | |||||||
| 1 | Set Go Online on Next Transaction (CVR 'Set Go Online on Next Transaction' must be set to 1) | |||||||
| 1 | CSU created by Proxy for Issuer | |||||||
| X | X | Update Counters | ||||||
| 0 | 0 | Do not update Offline Counters | ||||||
| 0 | 1 | Set Offline Counters to Upper Offline Limits | ||||||
| 1 | 0 | Reset Offline Counters to 0 (set counter values to 0) | ||||||
| 1 | 1 | Add Transaction to Offline Counters (change the counter values as if the transaction were offline) |
Tab. 4.26. Byte 3 CSU
| B8 | B7 | Bb | B5 | B4 | B3 | B2 | NS | Meaning |
| 0 | 0 | 0 | 0 | 0 | 0 | 0 | 0 | Reserved for use |
Tab. 4.27. Byte 4 CSU (rightmost)
| B8 | B7 | Bb | B5 | B4 | B3 | B2 | NS | Meaning |
| X | X | X | X | X | X | X | X | Issuer-discretionary bits (data at the discretion of the issuer) |
The use of the CSU element is an alternative to the Issuer Script Processing procedure, which will be discussed in section 4.13. With the help of this element, the issuer is able to change the state of the card and change the values of its parameters.
If the issuer authentication is successful and the terminal requests a vehicle from the card, and bit 8 of byte 2 'Issuer Approves Online Transaction' in the received CSU element is 1, then the card approves the transaction and returns the vehicle cryptogram.
If the issuer authentication is successful and bit 8 of byte 2 of the 'Issuer Approves Online Transaction' in the received CSU is 0, then the card rejects the transaction and returns the AAC cryptogram.
Thus, the use of the CSU and ARPC cryptogram format 2 ensures the integrity of the exchange of information between the issuer and the card. In particular, the impossibility of unauthorized modification of the issuer's decision on the result of the operation is ensured.
If the issuer authentication is successful and bit 7 of Byte 2 of the 'Card Block' in the received CSU is 1, then all card applications are blocked. The card shall respond to all subsequent SELECT commands using the SW1SW2 value of '6A81'h.
If the issuer authentication is successful and bit 6 of Byte 2 of the 'Application Block' in the received CSU is 1, then the selected card application is blocked. The card shall respond to all subsequent SELECT commands using the SW1SW2 value equal to '6283'h, and return the AAC cryptogram to the terminal to the AC GENERATE commands.
If the issuer authentication is successful and bit 5 of byte 2 of the 'Update PIN Try Counter' in the received CSU is 1, then the PTC value in the CVR is set to the number specified in bits 4-1 of the first byte of the CSU.
If the issuer authentication is successful and bit 5 of byte 2 'Update PIN Try Counter' in the received CSU element is 0, then the PTC value does not change and the values of bits 4-1 of the first byte of CSU are not used by the CCD application in any way.
If the issuer authentication is successful and bit 4 of byte 2 'Set Go Online on Next Transaction' in the received CSU is 1, then the card sets the corresponding CVR bit to 1 and sends the next transaction for authorization to the issuer if the terminal is able to process the transaction online. The card will continue to route transactions for online authorization in the case of an online terminal as long as the value of bit 2 of byte 4 of CVR 'Go Online on Next Transaction' is 1.
If the issuer authentication is successful and bit 3 of byte 2 'CSU created by Proxy for Issuer' in the received CSU element is 0, then depending on the value of bits 2 and 1 of byte 2, the CSU card will reset the VCC and SOTA parameters, as indicated in these bits :
- if b2 = O, N = O, then the parameter values do not change;
- if b2 - 0, bl - 1, then the parameter values are set equal to the corresponding limits; after resetting the values, offline card transactions can occur within the established limits;
- if b2 = 1, bl = 0, then the parameter values are set equal to 0; after resetting the values, offline card transactions become impossible;
- if b2 = 1, bl = 1, then the parameter values, despite the fact that the operation is online, are reset according to the rules adopted for offline operations.
- the values of the VCC and SOTA parameters do not change;
- the values of the VCC and SOTA parameters are set equal to their upper limits;
- the values of the VCC and SOTA parameters are set equal to 0;
- the values of the VCC and SOTA parameters are reset according to the rules adopted in the case of processing an offline operation.
- the terminal requests the vehicle's cryptogram from the card;
- one of two conditions is met:
- Issuer authentication was successful and the 'Issuer Approves Online Transaction' bit in the CSU is 1;
- no issuer authentication has been performed and the CCD card does not require issuer authentication to be performed to successfully authorize a transaction.
