The contact chip interface takes priority over the contactless interface during the processing of a transaction. When a contact transaction is initiated it cannot be interfered with by presenting a contactless card – the reader ensures this by powering down the contactless interface during all contact transactions. However, the converse is not true; if a contact card is inserted prior to the completion of a contactless transaction then the contactless transaction is terminated and the terminal will then proceed with the transaction using the contact interface.
It is not permitted to present more than one card for the transaction, and the terminal is required to check for card collision and display an error message if it is detected. This ensures that the cardholder has intentionally selected which card to use and does not accidentally charge the payment to an unintended card.
The RF field can either be activated (on) or deactivated (off) between transactions, as determined by the acceptance environment. The POS System controls the field between transactions and a new transaction can only be started once the original card has been removed from the RF field.
For terminals that only support Mag-Stripe Mode transactions, an optional Auto-run feature can be used, which will keep the RF field powered after card removal and will then automatically start the detection of a card for the next transaction.
There are a variety of different types of transaction which can potentially be performed over the contactless interface. The requirements for each transaction type may vary by card scheme and operating environment; this may also require some of the configuration data to be set differently for specific transaction types. Some common examples of transaction types are:
There are two types of data that are required in order to initiate a new contactless transaction – Kernel Configuration Data and transaction-specific data.
Kernel Configuration Data persists between transactions and contains information such as the Cardholder Verification Methods supported, the Terminal Country Code, the online/offline capabilities of the terminal, and a list of each supported Application Identifier (AID). Each AID indicates a specific card scheme product that is supported, such as Visa, MasterCard and Maestro. If offline data authentication is supported then the kernel configuration data will also need to contain every Certification Authority Public Key (CAPK) that is defined by each of the supported card schemes.
Transaction-specific data is generated for each new transaction and includes the Transaction Type and Amounts, along with the Date and Time. As mentioned in the section on Transaction Types, although the Kernel Configuration Data is persistent, some of the values within that data are transaction-type specific and so a subset of the configuration data may be applied to any given transaction. For example, different transaction limits may apply to refund and cashback transactions.
The cardholder must be made aware of the transaction amount (known as the “Amount, Authorised”) and Transaction Type when the transaction is being initiated if the reader has this information. These values can be given to the cardholder either through the devices display or by physical labels if appropriate. This information is commonly available prior to the transaction being initiated but, in some environments such as transportation, this may not always be known at this stage.
Another function that may be required by the system is the ability to cancel a transaction after it has started. This could be necessary for situations where a card is not presented to the system within a predefined period of time – in such a case the system could either terminate the transaction or request that the customer uses another interface to proceed with the transaction (if the reader supports this option).
Cardholder verification is a function performed by the system which is designed to verify the identity of the cardholder. In some cases the kernel may request the cardholder to perform a specific Cardholder Verification Method (CVM) or it may indicate that Cardholder Verification has already been performed. There are a number of different CVMs and the method selected during a particular transaction is determined by various factors. These factors include the possible methods mutually supported by the terminal and the card, and transaction parameters such as the Transaction Amount, the Transaction Type or the configuration mode being used. The different methods of Cardholder Verification and when they might be required are as follows:
The transaction outcome (also known as the transaction disposition) is the result of the transaction and must be expressed to the cardholder by the POS System. If the transaction is completed without any online authorisation then the transaction outcome can be returned immediately. If online authorisation is required then the communications with the issuer must be completed before this information can be retrieved.
Each card scheme defines rules as to when receipts are required, and these may vary depending upon the operating environment and geographical region where the terminal is deployed. In situations where the card scheme does not require a receipt, the POS System may be required to apply its own rules.