When using the CreditCall EMV.LIB kernel, the terminal application will use the
Hardware Abstraction Layer functions to detect and read cards.
When using the CreditCall EmvX kernel, this processing will be performed in the
card reader drivers.
The 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 CreditCall EmvX kernel has a single function that will build the candidate list,
and the pinpad driver will be used to allow the cardholder to select an application.
In the CreditCall EMV.LIB kernel, all these processing steps will be performed in
a single function. 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 authorisation with the card issuer.
In the CreditCall EmvX kernel, all these processing steps can be performed in a
single function. When required, EmvX will use the 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 authorisation with the card issuer. 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 using the 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 CreditCall EmvX kernel, the card reader drivers will detect the card
removal and the terminal application can retrieve any required data from the kernel.
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.
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.
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.
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.
These steps can be performed in any order
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.
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).
Processing restrictions allow the terminal to determine the compatiblity 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.
To safeguard against fraudulent use, the terminal will manage the level of risk
by requiring certain transactions to be online authorised 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.
The terminal will analysis 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 authorisation of the transaction, or to complete it offline
by accepting or declining the transaction locally.
"During the first Card Action Analysis step, the card will analysis the results
of all the previous steps and this will result in the card requesting the terminal
to either seek online authorisation 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
authorisation).
The terminal must perform the action that the card requested during card action
analysis.
Online processing enables the card issuer to analysis 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.
During the second Card Action Analysis step, after online processing has been performed,
the card will analysis 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).
When the card processing has been completed, the card may be removed. If the transaction
has been authorised then payment can be submitted for settlement and any goods or
services can be provided.