Architecture

Acceptance Domain

switstack moka is a software system taking place in the acceptance or merchant domain. It sits between a Payment Application that is most of the time a regional implementation specific to a vertical, and a Payment Terminal that is a hardware system embedding a set of firmware driving different peripherals (such readers, pinpad, display, ...).

In that representation, switstack moka is presented as a modular system that is logically outside the Payment Terminal. This is key for the project. An EMV Level 2 system is an abstraction that shall be modeled as an independent component to enable a software-defined approach. It is a system that a single software development team is building, owns, has responsibility for, and can see the internal implpementation details of (see C4 Modeling - Software System Definition).

Also, no hypothesis is made on the physical architectures that host switstack moka. This lies on 2 conditions: 1. switstack moka - or any EMV Level 2 - should be agnostic to Payment Terminal; 2. switstack moka - or any EMV Level 2 - should expose a clear API;

Whereas (1) is probably a condition that has been followed by EMV Level 2 implementers, (2) is an actual problem because the lack of API definition at this level of the architecture has been leading to technical dependencies (and ultimately business dependencies) preventing Payment Application from being designed on top of a normalized API. Hence, switstack moka is delivered with a Generic Level 2 API (GLA) implementation.

Typologies

The discussion on the Typologies leads us to the next level of abstraction: the containers (see C4 Modeling - Container Definition). Since its inception, EMVCo has been taking into account different architectures by introducing different sub-systems such as the Reader, the Terminal, or the POS. These sub-systems are meant to contextualize the topic of EMV Level 2. In particular, they help to understand how it can be integrated into payment solutions. They can take different forms, and an EMV Level 2 should be able to fit into different physical environments. That's why switstack moka implements a Message Broker.

Thanks to its message broker, switstack moka enables different typologies of payment solutions:

Typology	Description
Embedded	switstack moka runs in a COTS, or a PCI-PTS device.
Centralized	switstack moka runs in a server with a remote component to realize the coupling with the card.
Distributed	switstack moka is distributed at the Point Of Interaction (POI) to support a specific logical or physical constraint (for examples: dual-chip architecture, mPOS system, external entry point integration, ...).
Componentized	An external entry point integrates one or more switstack moka's kernel(s).

Typology 1: Embedded

That typology corresponds to legacy architectures. switstack moka runs is a secured container that can be hardware (PCI-PTS), or software (PCI-MPoC).

Here below, an example of an Android POI architecture. switstack moka's core is deployed at the NDK level whereas a set of Kotlin classes encapsulate it to ease the integration.

Typology 2: Centralized

That typology is inherited from EMV contact, and thin-client architectures. With the emergence of softPOS, it is now possible to design similar solutions because EMV Level 2 certifications can be granted without any EMV Level 1 approvals attached to a COTS device (open mobile phones are not subject to EMV Level 1 processes). switstack moka run on the server side as a service, and is reached from a web API. All the logic is executed on the server whereas the client implements the NFC coupling, i.e. performs APDU exchanges through a secure link.

Typology 3: Distributed

That typology takes into account pre-existing EMV Level 2 systems, alias Entry Point SDK. switstack moka runs on on a COTS and exposes a single API that is a proxy to a contactless entry points providing new card brand capabilities. Previous EMV Level 2 certifications can be kept with the pre-existing SDK, and new ones added by switstack moka.

Here below, a pre-existing EMV Level 2 system is modeled as an external entry point SDK. switstack moka is deployed like for an embedded system but switstack moka has the ability to switch seamlessly on Start B outcome received from switstack moka's entry point to an external entry point SDK (like a fallback to an entry point).

Typology 4: Componentized

That typology is dedicated to any entry point looking for a functional extension with a new kernel. Based on simple API, a switstack moka kernels can be plugged-in on existing stack as soon as the entry point can be acccessed and modified.

Design

That section digs into the next level of abstraction: the components (see C4 Modeling - Component Definition). switstack moka uses 3 types of components that collaborate to process an EMV card:

1. A Message broker;
2. A set of Services;
3. A set of Libraries;

Message Broker

The message broker is the cornerstone of switstack moka. It doesn't implement any business logic. It allows to de-couple the services, and enables the implementation of complex physisal architectures. It roles is to manage the registration of services, and foward messages from one service to another. There is no queue management because the card processing doesn't require concurrent threading.

(see also Appendix for more details).

Services

A service is a compilable unit that provides a functional solution to a business problem. It exposes a set functions to other services to perform generic, and specific operations.

Service	Description	Purpose
GLASe	Implements GLA specifications	To provide an abstraction for EMV Level 2 implementations to enable certification, test automation, and integration.
entry-point	Implements EMVCo Books A and B.
mastercard	Implements Mastercard specifications.	a.k.a. Mastercard contactless kernel.
visa	Implements Visa specifications .	a.k.a. Visa contactless kernel.
amex	Implements American Express specifications.	a.k.a. Amex contactless kernel.
hsm	Implements a CAPK container.	To store CAPK required for EMV card processing.
logger	Implements logging routines for specialized EMV tags/bitmaps.	To produce machine readable logs used to analyze and replay transactions.
reader	Implements the coupling with payment cards.	To capture card's information. Includes a SRED module to protect sentitive data at the source.
manager	Implements a set of primitives to setup the message broker.	To encapsulte complexity of the message broker.

(see also Appendix for more details).

Libraries

A library is a compilable unit that provides tools to help developpers to realise services.

Library	Description	Purpose
hal	Exposes a generic platform API	To keep switstack moka's services independent from terminals' firmware.
util	Packages a series of libraries: TLV parser, conversion routines, EMV toolbox, etc...	To facilitate the implementation of EMV card processing logics.

(see also Appendix for more details).

Performance

A contactless EMV Level 2 stack may be described as following:

• It is a state machine;
• It transitions from one state to another by mainly interpreting TLV streams:
  • The initial state is provided by a TLV configuration;
  • The final state is represented by a series TLV encapsulting the transaction outcome.
  • Intermediate states are specific to each payment network, and match brand's logics. These logics don't cost in terme a transaction time given the fact the RSA computation is performed once the NFC card is removed from the field (excepted for the Interac debit network ).

Hence, the best EMV Level 2 performance will be achieved when TLV structures are efficiently managed (i.e. multi-threading doesn't solve any problem). switstack moka's TLV parsing lies on static allocation to avoid costly lookups. That way, EMV tags can be directly accessed.