Skip to content

Entry Point Framework 📐

Entry point framework is the generic term used in EMV to refer to the software component that encapsulates (or "drives") EMV contactless Level 2 kernels (a.k.a. card processing applications). Its role is to:

  • Pre-process EMV contactless configurations and identify which combination is available for a transaction
  • Detect card presentment
  • Select mutual supported applications between a terminal and a card
  • Activate the corresponding kernel

Its behavior is specified by EMVCo Books A and B and may be subject to certification if implementers contemplate Book C-x Certifications following EMVCo process:

EMVCo Entry Point - Logical Architecture

Implementation Challenges

As specificed, that model presents different limits:

  1. 'Terminal' and 'Reader' are physical components. Hence, this model promotes a hardware centric perspective that doesn't help to build software systems, including testing tools.
  2. There is no modelization of the payment application and the corresponding API required to interact with an entry point. This lack of definition questions the integratility and testability of an EMV contactless Level 2 framework.
  3. There is no modelization of the kernel and the corresponding API required to activate a card processing. This lack of definition questions the interoperability between entry points and kernels, and also kernels' testability.
  4. There is no modelization of the platofrm and the corresponding API required to interact with a card coupler. This lack of definition questions the portability and the testability of an entry point.

As a result, implementers take arbitrary decisions on their design and are exposed to different challenges depending on the solutions they implement:

  1. How to develop a payment application that is independent from a specific entry point?
  2. How to integrate a kernel coming from a provider into an existing entry point?
  3. How to test, then certify an entry point?
  4. How to test, then certify a kernel?
  5. How to manage EMVCo and payment networks application selection processes?
  6. How to deploy this EMVCo logical architecture on different phyiscal architecuture (COTS, stand alone PCI-PTS, cloud-based, dongled-based, ...)?

Examples of Challenges

This section presents different use cases illustrating why the lack of definitions may lead to pitfalls.

Dynamic Configuration

Start A, B, C specifications are based on the hypothesis that the entry point gets a set of static configurations, and then performs the application selection followed by the kernel activiation on its own. That's the behavior that is certified at EMV Level 2. But some markets require to adjust static configurations based on which application is going to be selected. The consequence is that Start A, B, C shall be provided through a modular API enabling a payment application to trigger each start inndependently after the execution of a logic that is outside the scope of EMV Level 2, and modify the selected conctactless configuration before kernel activiation.

New Kernel Integration

The industry dynamic led to an important number of different kernels specifications. Today, international kernels have to co-exist with debit kernels. But it is long and costly to develop all these kernels before a first deployment that requires only a couple of them. How will it be possible to extend a current deployed solution with a new kernel? Is it possible to get a kernel from a provider and integrate it onto an existng entry point without comprising existing EMV Level 2 certifications already granted? A kernel API is not complex but it is not specified by EMVCo Books. Entry point must combine two behaviors: visa-a-like kernels (with pre-processing) and mastercard a-like kernels (without pre-processing), and in some cases, hybrid kernels performing a small part of the pre-processing. This consideration directly impacts how kernels are activated at start D. and consequently how an entry point may be extended.

Entry Point Duality

Duality is probably the most tricky challenge because it is a problem of card issuance legacy that cannot be solved by a smart set of API. Most of the EMV Level 2 implementers decide to go through payment networks certifications. As a consequence, they have to support a set of proprietary selection rules. Since implementers use an entry point, all these rules lie in that same software component which creates a coupling between the certification paths. Let's take the example of PPSE selection. When the PPSE APDU command fails, payment networks don't suport the same logic. Mastercard will terminate the transaction whereas Amex will initiate an explicit selection process... This situation questions how to trigger the good rule considering that the PPSE failed and the entry point can't detect what the current card's brand is. The other challenge is on the number of regression tests to perform each time a new kernel is added or the entry point modified.

How does moka help?

In order to support EMVCo A/B specifications and help to address these challenges, moka proposes:

moka features Description
GLASe EMV Level 2 API to encapsulate any entry point
Kernel as a Service Enable plug-and-play kernels
Software-defined An ecosystem enabling full EMV test automation for developers