Dear Readers,
Process Description |
EMV Steps |
NMI’s Kernel Process |
| 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. | Card Detection and Reset | When using the NMI (formerly Creditcall) EMV.LIB Kernel, the terminal application will use the Hardware Abstraction Layer functions to detect and read cards.
When using the NMI (formerly Creditcall) EmvX Kernel or the NMI (formerly Creditcall) EmvJ Kernel, this processing will be performed in the card reader drivers. |
| 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 list asking the card whether it supports each individual AID.
If there are multiple applications in the completed candidate list, or the application requires it, then the cardholder will be asked to choose an application; otherwise it may be automatically selected. |
Candidate List Creation | The NMI (formerly Creditcall) EMV.LIB Kernel has a single function that will build the candidate list, and the terminal application can then use the Hardware Abstraction Layer to allow the cardholder to select an application.
The NMI (formerly Creditcall) EmvX Kernel and the NMI (formerly Creditcall) EmvJ Kernel both have a single function that will build the candidate list, and the PIN-pad driver will be used to allow the cardholder to select an application. |
| When 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. | Application Selection | In all of the NMI (formerly Creditcall) Kernels, all of these processing steps can be performed in a single function. However, if the payment application wishes to pause execution after any step then a break state can be set, and once the application has performed any necessary processing, then the Kernel will resume the processing.
When required, EMV.LIB will call the Hardware Abstraction Layer functions to communicate with the card, perform secure PIN entry, perform RSA and SHA-1 encipherment and to perform an online authorization with the card issuer.
When required, EmvX and EmvJ will use the card reader, PIN-pad and display driver interfaces to communicate with the card, perform secure PIN entry and to update the display. If provided, it will also use the EFT interface to perform an online authorization with the card issuer. |
| Once the application has been selected, 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. | Read Application Data | |
| 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. SDA – Static Data Authentication of the card data (e.g. account number and expiry date) to verify that it has not been modified. DDA – Dynamic Data Authentication of card and terminal data to verify that the card application and data are genuine. CDA – Combined DDA and Application Cryptogram Generation. | Data Authentication | |
| Cardholder verification checks that the person using the card is the cardholder. The card contains a list of 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 PIN (if unattended cash), offline PIN (if supported), signature (always). | Cardholder Verification | |
| 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. | Processing Restrictions | |
| To safeguard against fraudulent use, the terminal will manage the level of risk by requiring certain transactions to be online authorized that would otherwise have been authorized 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 Risk Management | |
| The terminal will analyse the results of the previous verification, authentication and risk steps and this will result in the terminal informing the card that it proposes to either seek online authorization of the transaction, or to complete it offline by accepting or declining the transaction locally. | Terminal Action Analysis | |
| During the first Card Action Analysis step, the card will analyse the results of all the previous steps and this will result in the card requesting the terminal to either seek online authorization of the transaction, or to complete it offline by accepting or declining the transaction locally. This request may differ from the action that the terminal proposed following Terminal Action Analysis, but is subject to certain logic rules (e.g. the card is not permitted to request offline acceptance of the transaction if the terminal proposed online authorization). | Card Action Analysis | |
| The terminal must perform the action that the card requested during card action analysis. | Online Offline Decision | |
| Online processing enables the card issuer to analyse the transaction details and 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. | Online Processing | |
| During the second Card Action Analysis step, after online processing has been performed, the card will analyse the result of the online processing and will authenticate data received from the card issuer. This will result in the card requesting the terminal to complete the transaction by either accepting or declining the transaction. This request may differ from the result of online processing, but is subject to certain logic rules (e.g. the card is not permitted to request acceptance of the transaction if the host declined the payment). | Second Card Action Analysis | |
| When the card processing 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 Completed | When using the NMI (formerly Creditcall) EMV.LIB Kernel, the terminal application will use the Hardware Abstraction Layer functions to detect the card removal, and can retrieve any required data from the Kernel.
When using the NMI (formerly Creditcall) EmvX Kernel or the NMI (formerly Creditcall) EmvJ Kernel, the card reader drivers will detect the card removal and the terminal application can retrieve any required data from the Kernel. |
About Ambimat Electronics:
With design experience of close to 4 decades of excellence, world-class talent, and innovative breakthroughs, Ambimat Electronics is a single-stop solution enabler to Leading PSUs, private sector companies, and start-ups to deliver design capabilities and develop manufacturing capabilities in various industries and markets. AmbiIoT design services have helped develop Smartwatches, Smart homes, Medicals, Robotics, Retail, Pubs and brewery, Security.
Ambimat Electronics has come a long way to become one of India’s leading IoT(Internet of things) product designers and manufacturers today. We present below some of our solutions that can be implemented and parameterized according to specific business needs. AmbiPay, AmbiPower, AmbiCon, AmbiSecure, AmbiSense, AmbiAutomation.
To know more about us or what Ambimat does, we invite you to follow us on LinkedIn or visit our website.
