Beyond Cards and Terminals: Considerations for Testing Host-to-Host EMV Processing

EMV transactions begin with a data exchange between the card and the terminal.
1. When a customer uses a chip card at the terminal, the terminal communicates with the card to obtain all the information needed to determine if the transaction can be processed offline or must be processed as an online transaction.
2. If the terminal determines the transaction must be processed online, the terminal sends a Read Record Command to the card to retrieve the Card Data Objects List (CDOL1). The CDOL contains a list of EMV tags and value lengths that the card needs from the terminal.
3. The terminal uses information from the CDOL to compile a list of ‘values only’ that is sent to the card in an authorization request cryptogram (ARQC) Generate AC command.
4. The card validates the information from the terminal and, if the data is formatted correctly, sends a response to the terminal containing the ARQC, Application Transaction Counter, and Issuer Application Data.
The terminal uses the information from the card, as well as the tags and values that the terminal sent to the card previously, and sends a request to the Acquirer.
The Acquirer maps the message from the terminal into the message format required by the Issuer or designated Gateway.
The Gateway/Interchange/Switch must send the tags and values from the terminal to the Issuer unchanged. If the values are modified in any way, the Issuer will not be able to validate the ARQC.
The Issuer receives the message and generates a response using the following process.
1. When the Issuer receives the message, the Issuer generates its own ARQC by reconstructing the block of data used when the card generated the ARQC. The Issuer then validates that its Issuer-generated ARQC matches the card’s ARQC (sent in the message).
  
  About the 9F10 tag in the request message: The 9F10 tag is used to identify what key file index should be used (that is, it identifies the keys on that card), and also contains the cryptogram version number (CVN). The Issuer uses the CVN to determine the type of algorithm to use when generating a session key and the cryptogram’s block of data.
2. The Issuer uses the request message’s ARQC, as well as the Authorization Response Code (ARC) when generating the authorization response cryptogram (ARPC).
3. The Issuer sends the ARPC and any Issuer scripting back to the card in the response.
Again, it’s imperative that the information sent back to the terminal and card for the cryptogram goes through the Gateway/Interchange/Switch and the Acquirer unchanged. If anything is modified or changed during the transfer process, the card cannot validate the ARPC.
When the terminal gets the response, it sends the card the ARPC in an external Authentication command.

The terminal can now send the card any applicable Issuer script commands (that is, Application Protocol Data Unit [APDU] commands such as PIN change, application block, or card block) to be processed, or to be used in the completion message. If the card approves the ARPC and an APDU command has been sent to the card, even though an Issuer script may not be relevant to the current transaction, the command will be executed. The card then responds to the device with a status command that indicates whether or not the command was executed successfully.

(This example addresses only Issuer Script APDU commands. There are other APDU commands as well, but those commands occur offline between the Card and the terminal—that is, those commands are not sent by the Issuer.)

Page 3 of 10

< Previous Page 1 2 3 4 5 6 7 8 9 10 Next >