Skip to content

Entry Point Framework

The term of 'entry point framework' is used in EMV to refer to the software components that encapsulate (or "drive") EMV Level 2 contactless kernels (a.k.a. card processing applications). Its role is to:

  1. Pre-process EMV contactless configurations and identify which combination(s) is(are) available for a transaction.
  2. Detect card presentment.
  3. Select mutual supported applications between a terminal and a card.
  4. 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 (source: EMVCo Book A, section 5.3, v2.11)

Implementation Challenges

That model presents different limits:

  1. 'Terminal' and 'Reader' map to physical components. Hence, this model promotes a hardware centric perspective that doesn't help to build robust software systems, including testing tools. Software systems boundaries are approximativley defined from a legacy perspective where a payment terminal usually integrates a nfc reader running the EMV Level 2 stack. But which interface(s) shall be exposed to certify an entry point? Which interface(s) shall be exposed to integrate a kernel? What if the stack is distributed accross a server and a client?

  2. There is no modelization of the payment application and the corresponding interface required to interact with an entry point. This lack of definition questions the integratility and testability of an EMV contactless Level 2 framework. This level of absraction is left to implementers who are asked to implement their testing tool to configure, triger, and interpret entry point's outcomes during official certification. That situation leads to proprietary API where a payment application will depend on a specific entry point.

  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 kernels' testability. Kernels should be testable outside an entry point. And an entry point should be able to drive any kernels from different providers.

  4. There is no modelization of the platform 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 consequence. functionnal tests certifications shall be performed on a hardware leading to long and complicated laboratory sessions. Functional certifications should be software-based, fully automated whereas performance and combination tests left to laboratories representing only a small piece of the existing test plans.

As a result, implementers take arbitrary decisions on their designs 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, etc...)?

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