|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.|
|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.|
|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 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||EMVCo (www.emvco.com), which is jointly owned by Visa, MasterCard, JCB, UnionPay, Discover and American Express, manage the EMV standards and associated compliance processes.|
|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.|
|Kernel||An EMV Kernel is a set of functions that provides all the necessary processing logic and data that is required to perform an EMV transaction. The Kernel will be called from the terminal's payment application and will interface to any external terminals that are required.|
|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 analysis the transaction details and then decide whether it wishes to 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 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.|
|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.|
|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.
|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 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.|
|Give us a call||UK +44 117 930 44 55|
|USA +1 800 868 1832|
EMV Software for US EMV Migration
The US migration to EMV Chip Technology is imminent - we can help hardware manufacturers for Point of Sale devices, ATMs, vending machines, kiosks, ticketing machines etc. reduce risk, complexity, cost, and time-to-market. Find out more [+]
Simple and rapid way of adding EMV Level 2 functionality to payment applications within the Windows environment. Read more [+]
Add card support to payment applications independent of device manufacturers. Read more [+]
Add EMV Level 2 functionality to Java based payment applications. Read more [+]
Support for new generation payment applications requiring contactless (NFC) card acceptance. Read more [+]
Copyright © 2001 - 2013 CreditCall All Rights Reserved | site map | privacy | terms & conditions