|Action Codes||There are 2 sets of action codes; the Terminal Action Codes and the Issuer Action Codes, and each of these sets contains 3 codes which are compared to the TVR during Terminal Action Analysis. The Denial action codes are used to determine if the transaction should be declined, the Online action codes are used to determine if the transaction required online authorization, and in the event that the terminal is unable to go online then the Default action codes are used to determine if the transaction should be declined.|
|Answer To Reset||ATR||The ATR is the response from the card when it is reset during Card Detection and Reset, and specifies how the terminal must interface with the card, including which transmission protocol will be used to send and receive APDU between the terminal and the card.|
|Application Cryptogram||AC||The Application Cryptogram is generated by the card during Card Action Analysis. This cryptogram is sent to the card issuer in online authorization and clearing messages, and can be verified by the issuer to confirm the legitimacy of the transaction. There are 3 different types of application cryptogram that can be generated by the card, and the type is indicated in the Cryptogram Information Data.|
|Application Authentication Cryptogram||AAC||An AAC is a type of Application Cryptogram that is generated whenever a card declines a transaction during Card Action Analysis.|
|Application File Locator||AFL||The AFL is a list of application data records present on the card, and the terminal will use the AFL to Read Application Data from the card. The AFL will also indicate which, if any, of the data records should be used by the terminal as part of the input to the data authentication process.|
|Application Identifier||AID||An AID is used to uniquely identify each EMV application that a terminal supports, and every AID has an associated card scheme and parameters relating to how the application needs to be processed. A terminal may contain any number of such applications, and the list of each supported AID is used during Candidate List Creation to generate a list of applications that are mutually supported by both the terminal and the card.
Every AID is formed by the concatenation of a RID and a PIX (the PIX is optional, but is normally present).
|Application Interchange Profile||AIP||The AIP indicates which processing steps (e.g. cardholder verification, data authentication) are supported and which should be applied to the current transaction.|
|Application Protocol Data Unit||APDU||An APDU is a data unit transferred between the terminal and card. Any exchange of data is started by the terminal sending a Command-APDU, to which the card will reply with a Response-APDU. Every EMV transaction will consist of multiple APDU exchanges to read the data from the card and perform the necessary processing steps.
The ATR from the card determines which transmission protocol is used for APDU exchanges.
|Application Selection||Application selection is performed after the candidate list has been created and the application to use has been chosen.
The terminal must select the application on the card, so that the card can supply the correct data records for the transaction. Following successful completion of this step, the terminal proceeds to read application data.
|Application Selection Indicator||ASI||Each AID supported in the terminal has an associated Application Selection Indicator. During candidate list creation, if the AID matches an application on the card but the card's application name is longer than that of the AID, the terminal may only add the application to the candidate list if the Application Selection Indicator is set for that AID.|
|Application Usage Control||AUC||The Application Usage Control specifies any restrictions that may apply to the card that prevent the card from being used for certain types of transaction (e.g. cash-back) domestically or internationally, or at certain types of terminals (e.g. ATMs). The terminal will apply these checks during Processing Restrictions.|
|Authorization Response Code||ARC||The ARC is a value that is returned from the card issuer during online processing, or is generated by the terminal in the event that the terminal makes a decision as to the final transaction outcome during Terminal Action Analysis. The value of the ARC indicates to the card whether the transaction was authorized or declined, and which entity made that decision. The card may still choose to override this result during Card Action Analysis.|
|Authorization Response Cryptogram||ARPC||An ARPC is a cryptogram that is generated by the card issuer during online processing, in response to an ARQC generated by the card.|
|Authorization Request Cryptogram||ARQC||An ARQC is a type of Application Cryptogram that is generated whenever the card requests online authorization during Card Action Analysis.|
|Basic Encoding Rules - Tag Length Value||BER-TLV, TLV||
Most data processed during an EMV transaction is encoded according to BER-TLV, as defined in the international standard ISO/IEC 8825-1. Each TLV data object consists of:
A tag, which is used to uniquely identify the data object from the list of tags defined in EMV. All tags currently defined in the EMV specification are encoded over either 1 or 2 bytes (although cards may also contain proprietary data objects that can theoretically be longer).
|Candidate List Creation||
The terminal has a list containing the Application Identifier (AID) of every EMV application that it is configured to support, and the terminal must generate a candidate list of applications that are supported by both the terminal and card. The terminal may attempt to obtain a directory listing of all card applications from the card's PSE. If this is not supported or fails to find a match, the terminal must iterate through its AID list asking the card whether it supports each individual AID.
|Card Action Analysis||During Card Action Analysis, the terminal will issue a command to the card requesting that it generates an Application Cryptogram for the transaction. Based upon the type of cryptogram requested by the terminal, and the result of any additional risk analysis that the card chooses to perform, the card will decide what type of cryptogram to generate, subject to certain logic rules (e.g. the card is not permitted to request offline acceptance of the transaction if the terminal requested an online authorization).
If the card decides to authorize or decline the transaction then the terminal will proceed directly to transaction completion.
During the first Card Action Analysis, the card may also decide that online authorization is required; the terminal will then proceed to online processing followed by a second Card Action Analysis stage.
|Card Detection and Reset||Card detection and reset needs to be performed by the card interface functions specific to the hardware device being used. When a card is reset, it will respond with an Answer To Reset (ATR) that specifies how the terminal must interface with the card.
Following successful completion of this step, the terminal proceeds to perform candidate list creation.
|Card Risk Management Data Object List||CDOL||A CDOL is a list of data that the card requires during Card Action Analysis, and there are 2 different CDOL that may be required during the course of a transaction. CDOL1 is used during the first card action analysis, and if a second card action analysis is required then CDOL2 is used.
The terminal uses the DOL processing rules to format the requested data and then sends it to the card in the Generate Application Cryptogram requests.
|Cardholder Verification||Cardholder verification checks that the person using the card is the cardholder. The card contains a list of cardholder verification methods that it supports, and the conditions under which they should be applied. The terminal must navigate through this list and attempt the first method it finds for which the condition is met. If a method fails, the terminal must check whether additional methods are allowed.
For example, a list might contain:
Online enciphered PIN [if unattended cash], Offline plain-text PIN [if supported], signature [always].
|Cardholder Verification Method||CVM||A CVM is a means of checking that the user of a card is the genuine cardholder and, during Cardholder Verification, the terminal will determine which CVM (if any) is required for the transaction. Common methods of cardholder verification include signature checking, and PIN entry.|
|Certification Authority Public Key||CAPK||In order to support Data Authentication or Offline enciphered PIN , the terminal must store a collection of public keys for each RID . When required, the card will supply a CAPK index which is used to identify which of these keys should be used for that transaction.|
|"Chip and Pin"||"Chip and PIN" is a marketing term used to describe the process of credit and debit card transactions using EMV-compliant microprocessor "chip" cards at a payment terminal and requiring the cardholder's PIN to be entered for verification.|
|Combined DDA and Application Cryptogram Generation||CDA||Combined DDA and Application Cryptogram Generation.|
|Command - Application Protocol Data Unit||C-APDU||A C-APDU is an APDU that is sent from the terminal to the card whenever the terminal needs to communicate with the card.|
|Contactless Symbol (Contactless Only)||
The contactless symbol is the EMVCo-defined symbol displayed on contactless readers at the centre of the landing zone to indicate to cardholders where they should tap their card.
|Contactless Indicator (Contactless Only)||
The contactless indicator is the EMVCo-defined symbol on a contactless card, to indicate that the card supports contactless payments.
|Contactless Path (Contactless Only)|
|Cryptogram Information Data||CID||The Cryptogram Information Data contains the type of Application Cryptogram generated by the card during the Card Action Analysis stage. In addition, the card may also return a reason or advice code (e.g. service not allowed, or issuer authentication failed) to allow the terminal to perform any additional processing that may be required.
There are 3 type of cryptogram that can be generated by the card:
- An AAC is generated whenever a card declines a transaction.
- An ARQC is generated whenever a card requests online authorisation.
- A TC is generated whenever a card approves a transaction.
|Data Authentication||DA||There are three types of offline Data Authentication that can be performed, but the method to be used depends on the capabilities of the card and terminal. Online-only terminals are not required to support data authentication, but all other terminals must support both SDA and DDA and may also support CDA.
If both the terminal and the card support CDA then CDA should be used. If CDA is not supported but DDA is, then DDA should be used. If neither CDA nor DDA is supported but SDA is, then SDA should be used.
|Data Object List||DOL||At several key stages of a transaction, the card requires data to be supplied from the terminal. Each of these stages has a specific DOL which is a list containing one or more pairs of tags and lengths (both encoded according to BER-TLV rules) but not values. When required, the terminal will process this list in order, appending each of the requested values (without tags or lengths) into a buffer which it will then send to the card. The card can then extract the value of each of these tags by using the DOL.|
|Discover Zip (Contactless Only)||
Discover ZIP is the specification for performing MSD-Mode contactless transactions for Discover cards.
|Dynamic Data Authentication||DDA||Dynamic Data Authentication of card and terminal data to verify that the card application and data are genuine.|
|Dynamic Data Authentication Data Object List||DDOL||The DDOL is a list of data that the card requires if the DDA method is used during Data Authentication, and the terminal may also store a default DDOL that can be used if the DDOL is not present in the data from the card.
The terminal uses the DOL processing rules to format the requested data and then sends it to the card in the Internal Authenticate command.
|EMV||EMV||EMV are the international industry standards that define the rules for processing chip cards, originally named after the 3 organisations (Europay, MasterCard and Visa) that produced the specifications. The EMV standards and associated compliance processes are now managed by EMVCo. EMV is a registered trademark or trademark of EMVCo LLC in the United States and other countries.|
|EMV Mode (Contactless Only)||
An EMV mode transaction is a contactless payment, designed for markets that support the necessary infrastructure and protocols to meet all the EMV transaction data requirements.
|EMV Level 1||EMVL1||EMV Level 1 covers the electrical and physical interfaces, and the transmission of data, between the terminal and the card. There is an extensive EMVCo defined level 1 approval process, which requires every card reader to have completed laboratory type approval before they can be used to perform EMV transactions. EMVCo also require this approval to be renewed at defined intervals to retain compliance.|
|EMV Level 2||EMVL2||EMV Level 2 covers the set of functions that provide all the necessary processing logic and data that is required to select and process a card application in order to perform an EMV transaction.
There is an extensive EMVCo defined level 2 approval process, which requires every EMV Kernel to have completed laboratory type approval before they can be used to perform EMV transactions. EMVCo also require this approval to be renewed at defined intervals to retain compliance.
|EMVCo||EMVCo (www.emvco.com), which is jointly owned by American Express, Discover, JCB, MasterCard, UnionPay and Visa - manage the EMV® standards and associated compliance processes.|
Entry Point is the common reader processing that determines the supported applications on a contactless card by analysing the card’s PPSE to find the reader combinations that are mutually supported by the card and the reader. Once a reader combination has been chosen, the processing continues according to the card scheme rules associated with the Kernel ID.
ExpressPay is the specification for performing contactless transactions for American Express cards.
fDDA is an optimised form of Data Authentication that is performed during qVSDC transaction to allow the reader to obtain DDA related data from the card but to perform the cryptographic calculations after the card has been removed from the RF field.
|HAL||In computers, a hardware abstraction layer (HAL) is a layer of programming that allows a computer operating system to interact with a hardware device at a general or abstract level rather than at a detailed hardware level.|
|Integrated Circuit Card||ICC||An ICC is a card that contains a microprocessor chip. This chip can be used to perform EMV transactions on a payment terminal, and such a card is commonly referred to as a "Chip and PIN" card.|
|Issuer Action Codes||IAC||A set of action codes supplied by the card application and used during Terminal Action Analysis.|
|Issuer Script||Sequence of Command-APDUs that the host sends to the terminal during online processing. These commands may be used for operations such as unblocking the PIN on a card, and the terminal must send each of these commands unaltered to the card. The issuer script results should then be reported to the acquirer in the clearing messages.|
The IFD is the hardware part of a terminal that is used to physically read a chip card during an EMV transaction.
An EMV Kernel is a set of functions that provides all the necessary processing logic and data that is required to perform an EMV contact or contactless transaction. The Kernel will be called from the terminal's payment application and the Kernel will utilise the IFD to perform the necessary data exchanges with the card.
|Kernel Identifier (Contactless Only)||Kernel ID||
The Kernel Identifier is used to uniquely identify each of the card scheme kernels that may be supported by the reader and card.
|Landing Zone (Contactless Only)||
The Landing Zone is the area on a contactless reader, indicted by the contactless symbol, at the centre of the RF field.
|Magnetic Stripe Data Mode (Contactless Only)||MSD-Mode||
An MSD transaction is a Contactless payment that is processed using either Track 2 Equivalent Data or Track 1 data, designed primarily for use with cards or terminals in markets that do not support EMV Mode data.
|MasterCard Contactless (Contactless Only)|
|Offline enciphered PIN||A CVM that verifies the cardholder's PIN by encrypting the entered PIN before sending it to the card. Terminals that support Offline enciphered PIN must also support the less secure Offline plain-text PIN method.|
|Offline plain-text PIN||A CVM that verifies the cardholder's PIN by sending the unencrypted PIN to the card. This is commonly used by cards that can not support the more secure Offline enciphered PIN.
Terminals that support Offline plain-text PIN must also support the Offline enciphered PIN method.
|Online enciphered PIN||A CVM that verifies the cardholder's PIN by encrypting the entered PIN before sending it online to the card issuer.|
|Online Offline Decision||The terminal must perform the action that the card requested during card action analysis by either performing online processing or proceeding directly to transaction completion.|
|Online Processing||Online processing enables the card issuer to analyse the transaction details and then decide whether it wishes to authorise or reject the transaction. This allows the issuer to check the account status and apply criteria based upon acceptable limits of risk defined by the card issuer, the payment scheme and the acquirer. If no valid response is received from the host (e.g. due to communications failure) then the terminal is required to perform additional Terminal Action Analysis to manage the increased level of risk, and this will result in the terminal informing the card that it proposes to either accept or decline the transaction locally.
The result of the online processing (or communications failure processing) will be used as an input during the second card action analysis.
|Payment Account Reference||PAR||Payment Account Reference (PAR) is a data element released by EMVCo to address some of the challenges Tokenisation has introduced to the payment ecosystem whilst maintaining the current level of security provided by tokens.|
|Payment Card Industry PIN Entry Devices||PCI-PED||Requirements specified by the PCI Security Standards Council (www.pcisecuritystandards.org), which cover the security of PIN Entry Devices.|
|Payment System Environment||PSE||The PSE is an optional mechanism for the card to store a directory structure that holds records containing a number of applications that are available on the card. When present, it is used during Candidate List Creation.|
|Personal Identification Number||PIN||A secret number of between 4 and 12 digits that are known only by the cardholder and may be used during cardholder verification to confirm that the user of the card is the cardholder. The methods of PIN verification supported by EMV are Offline plain-text PIN, Offline enciphered PIN, and Online enciphered PIN.|
|PIN Entry Device||PED||Device used by the cardholder to enter their PIN during cardholder verification, which may be integrated into the payment terminal or be a separate device. There are many industry mandates that cover the security of such devices, such as PCI-PED.|
|Proximity Payment System Environment (Contactless Only)||PPSE||
The PPSE on a contactless card contains the list of all card applications supported by the contactless interface, and is returned from the card in response to the reader issuing a SELECT command for the PPSE.
|Primary Account Number||PAN||The number found on every payment card that is linked to the cardholder's account and is used to identify where the transaction funds should be transferred to or from.|
|Processing Options Data Object List||PDOL||The PDOL is a list of data from the terminal that is required by the card at the beginning of the Read Application Data stage. The terminal uses the DOL processing rules to format the requested data and then sends it to the card in the Get Processing Options request.|
|Processing Restrictions||Processing restrictions allow the terminal to determine the compatibility of the applications on the card and terminal. This involves checking if their Application Version Numbers match, if the card application is expired or pre-valid, and whether the Application Usage Control (AUC) permits the current transaction to be performed.|
|Proprietary Application Identifier Extension||PIX||The PIX is an optional, variable length, suffix that may be allocated by card schemes to differentiate between multiple applications (e.g. credit and debit applications) provided by that scheme. The value of any PIX is proprietary for each scheme, and if present is appended to the RID to create the AID of each application.|
|quick Visa Smart Debit/Credit (Contactless Only)||qVSDC|
|Radio Frequency Field (Contactless Only)||RF Field||
The RF Field is the 3-dimensional space projecting from the landing zone on the contactless reader in which contactless cards can be detected and processed. It is also known as the contactless field or contactless interface.
|Read Application Data||Following application selection, the terminal provides the card with any data that it requests in the PDOL and gets the processing options. The card will supply the Application File Locator (AFL), which is used by the terminal to read the application data records from the card. These records contain the card PAN and expiry date, plus many other tags of information that are used for transaction processing such as cardholder verification and card authentication.
Following successful completion of this step, the terminal has sufficient data to proceed with the transaction processing, and may then perform data authentication, cardholder verification, processing restrictions and terminal risk management in any order.
|Reader Combination (Contactless Only)|
|Registered Application Provider Identifier||RID||The RID is a fixed length unique identifier allocated to each card scheme to identify EMV applications provided by that scheme. The schemes may then suffix this with an optional PIX to further differentiate between multiple products supported by the scheme, and together they form the AID.|
|Response - Application Protocol Data Unit||R-APDU||An R-APDU is an APDU that is sent from the card to the terminal in response to a C-APDU received from the terminal.|
|Static Data Authentication||SDA||Static Data Authentication of the card data (e.g. account number and expiry date) to verify that it has not been modified.|
|Status Bytes||SW1 SW2||The last 2 bytes of the R-APDU at the end of every APDU exchange between the terminal and the card will contain 2 status bytes, SW1 and SW2, which are used by the card to indicate the result of the processing to the terminal.
If the status bytes are '90 00' then the process has completed. Other values of the status bytes may denote a warning or error, or may have a specific meaning for the particular C-APDU that was sent from the terminal.
|Terminal Action Analysis||Following completion of data authentication, cardholder verification, processing restrictions and terminal risk management, the terminal will analysis the results of that processing and this will result in the terminal informing the card that it proposes to either seek online authorisation of the transaction, or to complete it offline by accepting or declining the transaction locally. This is achieved by comparing the TVR against the Denial and Online IAC and TAC, and triggers the appropriate action if any bits match. In the event of multiple matches, the denial action codes take precedence.
If the terminal is unable to go online then further terminal action analysis will be performed, with the TVR being compared against the Default IAC and TAC, and triggering the declining of the transaction if any bits match.
The outcome of terminal action analysis is used as an input during card action analysis.
|Terminal Action Codes||TAC||A set of action codes stored by the terminal for each supported AID and used during Terminal Action Analysis.|
|Terminal Risk Management||To safeguard against fraudulent use, the terminal will manage the level of risk by requiring certain transactions to be authorized online that would otherwise have been authorised locally.
This involves comparing the transaction amount against floor limits, and detecting when the number of consecutive offline transactions on a card has reached a defined limit. In addition, offline-capable terminals will also randomly select certain transactions to go online.
|Terminal Verification Results||TVR||The TVR is a collection of indicators that the terminal will set to show what incidents have occurred whilst processing the current transaction (e.g. card is expired, cardholder verification has failed, or online floor limits have been exceeded). Together with the TSI, this information enables the card and the host to manage risk and determine the correct outcome for the transaction.
The TVR is also used using Terminal Action Analysis in order
|Track 1 data (Contactless Only)||
The track 1 data (or more accurately, the track 1 equivalent data) is data that is formatted similarly to the data that would typically be found on the track 1 of a magnetic stripe card, and may be generated by a contactless reader or provided by a contactless card for an MSD-Mode transaction.
|Track 2 equivalent data||A Magnetic stripe transaction is typically processed using only the track 2 data from the card, containing the card number and validity dates. Although EMV transactions have significantly more data and functions to process, the chip will normally provide the equivalent data to that which would be found on the magnetic stripe, and this can then be used in the authorisation and clearing messages with the acquirer in the same way as for magnetic stripe transactions.|
|Transaction Certificate||TC||A TC is a type of Application Cryptogram that is generated whenever a card approves a transaction during Card Action Analysis.|
|Transaction Certificate Data Object List||TDOL||The TDOL is a list of data that the terminal must use as the input when it needs to calculate a transaction cryptogram hash, and the terminal may also store a default TDOL that can be used if the TDOL is not present in the data from the card. The terminal uses the DOL processing rules to format the requested data, but this is only required if the transaction cryptogram hash is required by either of the CDOL.|
|Transaction Completed||When the Card Action Analysis (and any online processing, if required) has been completed, the card may be removed. If the transaction has been authorized then payment can be submitted for settlement and any goods or services can be provided.|
|Transaction Status Information||TSI||The TSI is a collection of indicators that the terminal will set to show what processing steps have been performed on the current transaction (e.g. Cardholder Verification, Data Authentication). Together with the TVR, this information enables the card and the host to manage risk and determine the correct outcome for the transaction.
|Terminal Transaction Qualifiers (Contactless Only)||TTQ||
The TTQ is a collection of indicators that the terminal will set to show the reader capabilities, requirements, and preferences to the card. The TTQ is only supported by certain card schemes and is only used for contactless transactions.
|Visa Contactless Payment Specification (Contactless Only)||VCPS|