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, secure element, ...).
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. Example:

• switstack moka runs on on a COTS, and exposes a single API (GLA) that is a proxy to a contactless entry points providing 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.