In addition to the test case updates to validate the implementations of all the EMV specification update bulletins that have been published during the past year, test cases are now also provided for American Express. This is the first EMVCo Level 2 test plan released since they joined MasterCard, Visa and JCB as EMVCo’s fourth member last year.

With over 100,000 users of the Kernel in Europe alone, and with customers in most regions of the world where Chip and PIN is mandated, CreditCall expects to be certifying new integration of its EmvX, EmvJ and EMV.LIB as soon as March 2010.

Link to EmvCo Bulletins

When there are multiple payment applications present on an EMV card, or the card configuration requires cardholder confirmation, payment terminals will display the list of applications to the cardholder to allow them to select an EMV application to use for the transaction.

EMV cards will often include an ‘application preferred name’, which is the name of the card application in the cardholder’s local language. Although this is the preferred name to display to the cardholder, it will not always be possible to do so as the name may use an ‘issuer code table’ that is not supported by the terminal. For example,  a terminal in Europe may not contain a display font that allows Arabic characters to be displayed.

Therefore, normally all EMV card applications will contain an ‘application label’ which contains only characters in the common character set that all EMV-capable terminals are required to support, which should ensure that there will always be a name that can be displayed to the cardholder.

Unfortunately, although the presence of the application label on the EMV card is mandatory when using the PSE directory method during application selection, it was only defined as optional when selecting the application using the list of Applications method. Therefore  it has never been possible to guarantee the presence of the application label on a chip card – until now! EMVCo have finally resolved this by issuing Specification Update Bulletin No. 71 that now makes the application label mandatory on all new EMV-compliant cards. This will finally mean that EMV Level 2 Kernels used by payment terminal vendors will always have a name to display during application selection, and should no longer need to implement default name processing.

The CreditCall EMV kernels are compliant with all the latest industry requirements, and provide a simple but powerful way to add EMV Level 2 compliance to payment devices. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

Whenever an EMV transaction is performed, the terminal’s EMV Level 2 Kernel processes the CVM list in order, until it finds a CVM that it supports and can process. In the event that no supported CVM is found or an error occurs during CVM processing (e.g. the PIN-Pad was malfunctioning), the EMV kernel will flag this in the Terminal Verification Results, which may cause the transaction to be declined or sent online for authorisation by the card issuer.

The CVM that EMV currently supports are Online PIN (required in certain countries for all transactions, and also for all ATM cash withdrawals), Offline PIN verified by the chip card (required in certain countries for all payment transactions), signature (for attended payment terminals in some countries), or a combination of both PIN and signature if additional verification is required.

Also, in some environments it is permissible to use no CVM for low-value transactions or for terminals that do not support any of the CVM on the cards.

CreditCall’s EMV Kernels support every EMV-defined CVM, and provide a simple yet powerful way to add EMV level 2 to payment devices. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

An EMV card generates a unique “Authorisation Request Cryptogram” for each transaction that requires online authorisation. This is calculated by encrypting the card and transaction data using a secret key that is known only to the card and the card issuer. When the transaction details are sent to the issuer during the authorisation process, the issuer can then use its copy of the secret key to verify that the cryptogram for the transaction is correct, and that therefore the card is genuine.

Once the issuer is satisfied that the request is genuine and they wish to authorise the transaction, they will generate an authorisation response cryptogram, which the card can then use to authenticate that the authorisation for the payment came from the genuine issuer of the card.

These checks allow the EMV card and the issuer to verify the authenticity of each other, and thus protect the cardholder from being debited for fraudulent transactions.

This is just one of the many benefits that EMV migration can bring. The CreditCall EMV kernels provide a simple but powerful way to add EMV level 2 to ATMs, PoS devices and unattended payment terminals such as kiosks.

Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

It is of course possible to update an existing EMV solution to meet the latest specifications, but the sheer volume of specification changes means that this is a significant task. A better approach therefore, is to migrate to an EMV Kernel that is compliant with the latest EMV standards, such as the CreditCall EMV Kernels. Check out www.emvx.co.uk for further details of these EMV Level 2 Kernels.

Found this Interesting, but struggling with the terminology? Why not consult the helpful Glossary of Terms at http://www.emvx.co.uk/glossary.aspx EMV de-mystified!