• What is EMV?
>
• World of Contactless
>
• EMV Contactless System Functions and Configurations

EMV Contactless System Functions and Configurations

Non-interference with Contact Chip Interface

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.

Card collision

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.

Field Management

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.

Supported Transaction Types

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:

• Goods and Services – this is a typical purchase transaction where the cardholder exchanges money for goods or services only.
• Cash Advance (cash withdrawal) – this is a transaction in which the cardholder withdraws money from their account but does not receive goods or services, for example at an ATM.
• Purchase with cashback – this is a transaction where the cardholder simultaneously exchanges money for goods or services and withdraws money from their account, for example when using a debit card in a retail store.
• Refund – this is a transaction in which the merchant reimburses the cardholder for a transaction which had previously taken place, for example if a customer returns faulty goods and wishes to get their money back.
• Balance Enquiry – this is where a cardholder checks what funds they have available but no fund transfer takes place, for example at an ATM.

Transaction Initiation Data

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.

Displaying Amount

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.

Cancellation

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

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:

• No CVM: For some transactions it may not be necessary to perform any specific method of cardholder verification. This is commonly used to increase the transaction speed, for example in some toll booths or for low-value contactless transactions in Europe.
• Online PIN:  After the device request the cardholder’s PIN, it is encrypted and sent to the bank as part of the online authorisation request, in the same way as for traditional magnetic-stripe and EMV contact transactions.
• Signature:  A signature can be obtained in two ways depending on the supported features of the terminal. Terminals which support receipt printing can add a line to the receipt requesting that it is signed by the cardholder. An alternative method is for the signature to be obtained digitally via touchscreen; terminals which support this method will display a signature screen requesting the cardholder’s signature.  Signature CVM is commonly used for cardholder verification in the United States of America.
• Consumer Device CVM (CDCVM): This CVM is used when the cardholder is verified via their consumer device instead of being verified by the payment terminal, such as a smartwatch or smartphone for Apple Pay and Android Pay. The actual method used may vary depending upon the type of consumer device but could, for example, require the cardholder to enter a four-digit code on their Apple Watch or perform a fingerprint scan on their iPhone/Android phone. On some consumer devices the cardholder may be required to perform CDCVM before initiating the transaction. If the cardholder has not already performed CDCVM when they present their “card” and it is required for the transaction, the terminal will instruct the cardholder to follow the instructions on their device in order for the cardholder to perform the necessary method. Following this, the cardholder will then be required to re-present their “card”. CDCVM may also be referred to as On-Device CVM or Mobile CVM.

Transaction Outcome

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.

Receipts

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.