Using APDU Commands: EMV Transaction Flow (Part-3)

Terminal -> Card

Photo by Yoco Photography on Unsplash

Intro:

In the previous part we have learned about APDU command and different types of commands involved in EMV Transaction Flow in the continuation of the series in this part we are going to learn how we can use these APDU command what is the sequence we need to follow in order to create an ISO8583 request (In coming parts we going to learn how we can prepare this request) this request is the final block of our EMV Transaction Flow series.

Let’s Move to steps to send the APDU commands to in order to prform the transaction

Step 1:

As soon as card is inserted it emits ATR (Answer To Reset) and with this ISO 7816 protocol starts. Bluntly, the ATR is a step where a card «declares» that it is ready for exchange. During this process, approval of a version of subprotocol (T=0 or T=1) takes place. Those concerned with the detailed description of T=0 and T=1 can find it in the first part of the EMV Book.

when we have received ATR then we can start sending APDU commands to perform the transaction very first command is SELECT PSE command to know which directory to refer for the AID (Application Identifier) details.

Step 2:

Now, we know which directory in card we need to read to get the AID So, we are going to send READ PSE command to the card from terminal this command wit give AID at tag “4f” in the Application Template of EMV Proprietary.

Step 3:

Now, we know AID of the then we can select the application to use in order the start the transaction process we need send the SELECT AID command and response of this command we are going to get the Application Label, PDOL and Language Preferences.

PDOL (Processing Options Data Object List) is an essential set of parameters that a device needs to transmit to a card for further processing in the next command. The card stores this information within the 9F38 tag.

For example, the value of PDOL is 9F 1A 02 03 56. When we decode it using TLV (Tag-Length-Value) encoding, we can identify that it represents the 9F1A tag, which is 2 bytes long. The 9F1A tag refers to the Terminal Country Code. Therefore, the card expects the terminal to provide information about its location.

If the terminal fails to transmit the Terminal Country Code information to the card, the transaction will be aborted. It is worth noting that PDOL may contain elements (tags) that are unknown to the terminal. In such cases, the specifications of payment systems typically define a standardized algorithm for the POS or ATM software. According to this algorithm, the terminal will respond with a value of “0” to any unclear information.

In our specific example, if the terminal does not transmit the 9F1A tag at all in the next command, the exchange will be aborted. However, if the terminal transmits the 9F1A tag with a value of 020000 (where 0000 represents the “zero” code of the country), the exchange will continue as if the terminal had sent a tag like 9F1A=020356 (where 0356 represents the code of the India) to the card. However, it’s important to note that issues may arise at later stages of the exchange if the “zero” country code is used.

Step 4:

Now, we have the PDOL and we need this back to card in the next command along with country code then next command will be GET PROCESSING OPTIONS(GPO) It enables the terminal to understand the capabilities and parameters of the card. In Response of the command we going get below data:

• Application Transaction Counter (ATC): Which tell us the total number of transactions, can be used to create Application Cryptogram (AC).
• Track 2: This has information about Card Number, CVV, expiry month and expiry year also it
• Issuer Application Data (IAD) : This tell us the information about card issue i.e. bank code or issuing country this is also can be the part of Application Cryptogram generate command
• Application Cryptogram : This field varied depending to card type and issuer card can send it in this response if it is present then OK else we need to send GENERATE AC command.
• Application Primary Account Number (PAN) Sequence Number: This Field represents that how many bank accounts are associated with this PAN number or card
• Cardholder Name: As name Specifies we going to get the card holder name

Now, We have all the required data to create ISO8583 request if the card is of online type but if the card is offline type we also need call VERIFY PIN command which will have the pin in (plain or encrypted format) request and give success or failed response if the pin is correct or not. depending on this Cardholder Verification Method (CVM)[we will talk about this later in this series] is going to get calculated.

Flow Chart for EMV Transaction Flow:

Conclusion:

The EMV transaction process involves several important steps that enable secure and efficient payment processing. From the initial ATR communication to the selection of the application, retrieval of necessary data, and generation of the application cryptogram, each step plays a crucial role in ensuring a successful transaction. By understanding these steps, businesses can implement robust payment systems and provide secure payment experiences for their customers.

References:

1. EMVCo: The official website of EMVCo, the global standard for secure payment transactions: https://www.emvco.com/
2. ISO 7816 Standard: The official ISO standard document for smart card communications: https://www.iso.org/standard/54554.html
3. EMV Book: A comprehensive guide to EMV transaction processing and specifications: https://www.emvco.com/emv-technologies/book-2/
4. Payment Card Industry Data Security Standard (PCI DSS): A set of security standards for protecting cardholder data during payment transactions: https://www.pcisecuritystandards.org/
5. GlobalPlatform: An industry association that standardizes the management of secure chip technology: https://www.globalplatform.org/