Contactless EMV Test Cards and Tools

by: tim.littlefair@gmail.com

Who is this article for and what is it about?

This article is a brief personal note to help businesses intending to accept Contactless EMV payments (and vendors working to deliver integrated systems for those businesses) to make good choices in relation to purchases of test cards and/or test tools to support the integration of the payment capability into the business’s existing or new systems.

The experience of the author of this page has been predominantly in the field of contactless payment for public transport services, so content in this document is most likely to be appicable in that context and may not be so applicable in retail or other contexts.

For the remainder of this document the term ‘Contactless EMV’ will be abbreviated cEMV.

Who’s Who in cEMV?

It may help to understand testing processes associated with Contacless EMV to be aware of some of the corporate bodies involved, and terms for the roles of those bodies:

Payment Card brands

Visa, Mastercard, American Express, Discover/Diners and China Union Pay are the major global payment card brands. Each of these companies operates a payment processing data network that banks are able to connect to in order to make and accept payments on behalf of their customers. Both Visa and Mastercard have implemented sub-brands (Maestro for Mastercard, VPAY and Visa Electron for Visa), which are generally issued as debit cards. In addition to the major global brands, there are a number of smaller payment card brands operating their own networks, mostly restricted to a geographical region, for example EFTPOS in Australia, Carte Bancaire in France, Bancontact in Belgium. As well as operating their data networks, payment card brands are responsible for defining the behaviour of card-hosted cEMV applications which generate transactions to be processed by the network, and for specifying test criteria in relation to their own brands covering the EMV level 2 (hardware type approvals for terminals) and EMV level 3 (end-to-end operational testing of integrations of terminals to acquirer systems).

EMVCo

EMVCo is a consortium consisting of Mastercard, Visa and a number of other Payment Card brands which manages publication of framework documents for the cEMV ecosystem. EMVCo does not have any authority over the individual brands, but the frameworks EMVCo has established provide some degree of consistency of process and terminology across the different brands.

The EMVCo framework covers three layers of specification and testing:

  • EMV level 1 is a type approval related to the communication protocols underlying all cEMV operations from the physical layer up to and including message framing.

  • EMV level 2 is a set of type approvals (one per payment card brand) related to the business rules covering a specific brand’s payment applications.

  • EMV level 3 is a framework (not a specific approval) related to testing a fully integrated cEMV acceptance environment for a single brand for a single merchant customer.

Banks (in the role of card issuers)

All or nearly all banks in the world these days want to be able to offer payment cards to customers, and do so by issuing (contactless or contact, but usually dual-interface) EMV cards containing applications licensed from one or more of the payment card brands. A single card is effectively a small computer with one or more programs (‘applications’) which can exchange messages locally with an EMV payment terminal in order to generate a package of data which can be trusted by the card issuer’s bank as evidence that the payment transaction was done using the physical card and that all business rules governing the transaction were complied with.

Banks (in the role of payment acquirers)

By issuing cards, banks enable their customers to make EMV payments, but banks providing services to business (particularly retail and service businesses) also need to enable some of their customers to receive payments. When a bank is receiving payments for a business customer the bank is said to be the acquiring bank for those transactions, the business customer is referred to as a merchant.

Merchants

A merchant is a business which accepts cEMV payments. In order to do this a merchant will need to decide which brand’s cards will be accepted, will need to set up a transaction acquiring facility with a bank, and will probably need to engage a terminal hardware vendor to supply and support a fleet of terminals. The merchant is also likely to require a payment service provider to

Terminal Hardware vendors (THVs)

THVs supply terminals, and possibly supply or operate supporting infrastructure which support the capture of cEMV transactions (‘taps’) and forward them to a payment service provider so that the merchant can collect payment.

Payment Service Providers (PSPs)

A PSP is the operator of a service which feeds payment transactions captured at a payment terminal to the merchant’s acquirer interface. The role of the PSP in some integrations may be blurred into the supporting infrastructure provided by the THV, but it is important that the PSP must exist as the collection of payment for the merchant is generally a two-step process, with the relaying of the tap for the payment to the acquirer’s system as the first step, with a second separate step called ‘settlement’, where the debt established by the tap is claimed, usually in an end-of-day batch process. The terminal is not expected to be involved in settlement.

Payment Card Industry (PCI)

PCI is an industry body which is responsible for developing and managing standards in relation to secure operation of payment systems. The standards managed by PCI are almost completely orthogonal to those managed under the EMVCo framework - indeed the tools and techniques used for EMVCo level 2 and level 3 testing would be inherently PCI-violating if they were applied to a live payment environment.

What kinds of testing are discussed here?

Integration of contactless payment into an existing or new system will involve more than one sort of testing. It’s important to know the differences between the sorts of testing which might be involved in such a project.

EMV Level 3 testing

EMV level 3 is a framework defined by EMVCo for certification of a specific integration between a payment application hosted by or for a specific merchant running on one or more types of hardware with the front end systems provided by a specific acquiring bank. Each of the card brands to be accepted (i.e. Visa, Mastercard, EFTPOS) will define their own suite of EMV level 3 tests. The main focus of the EMV level 3 tests is to ensure that the integration correctly implements the expected business rules governing whether cards are accepted or declined when presented on the system under specific conditions. These business rules relate to the risk management profile for the specific acquiring arrangement, which in turn reflect a wide population of cards issued under the specific brand at different prior time, including some types of cards with restrictions on where they may be used or what kinds of goods or services they may be used to pay for.

For Visa and Mastercard in transit, EMV level 3 testing generally consists of around 20-25 test cases, each of which is a single card presentation with specific expectations around the transaction outcome (accept, graceful decline or error rejection), and around supporting data recorded alongside the outcome. EMV level 3 testing is generally done using a test tool with a probe or programmable card which can be configured to emulate a cEMV card which conforms to the conditions, defined in the test specification, and which will capture a downloadable log of the data exchanged between terminal and (emulated) card during the tap.

Examples of the sort of tool used at level 3 are:

cEMV UX testing

The merchant will generally want to ensure that the payment process is a good user experience (UX) for their customers, and this is a very different kind of testing from EMV level 3. It is possible to purchase card sets which cover a range of different card brands and specific types of cards (debit vs credit, different cardholder currency or country of issue, high-value, ‘online-only’ etc.), for example:

Although these packages seem to support testing a wide range of conditions, up to half of the cards in any given set may be unusable for one reason or another including:

  • cards for brands which the merchant does not want to accept

  • cards which are designed to fail under cEMV so that retail employees can be trained in how to handle failures (e.g. fallback to contact EMV insertion or magnetic stripe swipe)

  • cards from this set can also become unusable as a result of card expiry dates being reached (for example the version of this card set offered for sale in April 2023 contained some cards expiring in December 2024, others expiring in December 2025 and May 2026)

  • some cards from this set have become unusable over time (probably as a result of counters on the cards exceeding some threshold)

  • the PANs on cards in the B2 test sets reflect PANs specified in specific L2 or L3 test cases specified by brands, and there are some cards in these sets which have the same PAN/PSN/expiry date (which can cause problems for PSP systems, which generally need to maintain distinct accounts for each physical card, with PAN/PSN/expiry date being the primary key which should be unique per card)

Alternatively, a merchant can purchase cards from this vendor:

While Merchant Test Cards do not offer specific variants of cards, their cards are probably better for customer UX testing, as they can be ordered with varying PANs, and may have longer lives before expiry than the cards in B2 card sets.

EMV Level 1 and 2 testing

EMV level 1 and 2 testing are the sole responsibility of the THV, and the tests need to be completed and the necessary hardware type approvals gained before the hardware can be included in a plan for EMV level 3 testing in the context of a specific merchant’s integration.

In general, merchants should not need to have any involvement in level 2, apart from being aware that the integration will not be allowed to enter EMV level 3 testing and will be unable to go live unless all required L1 and L2 approvals are in place before L3 starts.

Merchants should also be aware that L1 and L2 approvals have expiry dates, and under the letter of EMVCo’s framework L3 can only go forward if all L1 and L2 approvals are still current. In practice, although EMVCo publishes the rules, EMVCo has no real authority over acquirers or brands, and hardware for which some approvals are expired may be allowed to enter L3, providing both the acquring bank and the brand(s) whose approvals are out of date are willing to let this happen.