Overview

Introduction

EMV debit and credit cards processing corresponds to a series of services allowing businesses to accept card present transactions. It involves several parties including the cardholder, the merchant, the acquirer, the issuer and payment networks as depicted in the 4 tiers model hereafter:

EMV debit/credit card processing

What is `switstack moka`?

It is an EMV Level 2 stack, the cornerstone of in-person payment infrastructures deployed on the merchant's side to accept debit and credit cards. It implements a set of specifications developed and maintained by EMVCo and payment networks. These specifications are released as a set of books that cover contact (CT) and contactless (CL) (see EMVCo).

Which problems does it fix?

It unlocks organizations who develop PCI-PTS or COTS terminals,

The project has emerged from a set of observations:

EMV is long and costly to develop and maintain.
There is no leverage of differentiation in developing an EMV Level 2 stack on its own.
With the worldwide acceleration of EMV acceptance, the demand of EMV Level 2 is growing.

switstack moka aims at accelerating EMV acceptance by breaking barriers at entry.

Why yet another EMV Level 2 stack project?

Developing a new EMV Level 2 stack was driven by the need to reach specific goals that recently emerged from the industry:

Enable kernel on cloud solutions: the emergence of COTS terminals along with M-PoC requirements open the space to an EMV acceptance that doesn't depend on EMV Level 1 certifications. Hence, it is technically possible to centralize EMV Level 2 processing (with some compromises on performance). An appropriate architecture is required and couldn't be anticipated years ago.
Improve the security of EMV implementations: as every one knows, security is not an EMV Level 2 requirement in a sense that security is not assessed by EMV Level 2 certification processes beyond Offline Data Authentication (ODA). But the experience shows that sensitive data should be managed in a way that they don't need to be dissemimated all around an EMV Level 2 architecture. As a result, this would limit the risk of breaches and it becomes particularly relevant in the context of open mobile acceptance.
Enhance code maintainance: there are more and more organizations dealing with EMV acceptance. In a long term, these organizations need to rely on a code base that they can manage autonomously. Until now, this reality has been addressed from a licensing perspective. But that autonomy can be truly granted only if a testing ecosystem is delivered along with the stack itself. This imposes a complete reinvention of the developer user experience when time comes to implement EMV solutions.

Who is the audience?

Software builders who want to take control of their in-person payment architecture (switstack moka stands for My Own Kernel Applications).

This documentation presents how an overview of switstack moka, how to get started, and other resources such as business requirements and the architecture. It is the reference guide to develop, maintain and integrate switstack moka. However, all functional aspects can be found in the corresponding EMVCo books and/or payment networks documentation.

You may find additional information here.

Beside this initiative, switstack moka is also promoting the importance of a Level 2 abstraction layer. EMV specifications don't define any API. As a result, payment applications (a.k.a EMV Level 3) that are developed on top of proprietary Level 2 are tighly coupled with terminal vendors' SDKs. The last section of this guide proposes GLAse that may be used on top of switstack moka (and any other EMV Level 2).

Key features

This section presents the main features coming with switstack moka. It aims at simplifying EMV Level 2 development, maintenance, and integration. EMV Level 2 is only a means to reach business goals. We make it a commodity. Use switstack moka project as a shorcut to accelerate your in-person payment projects.

Portable C Code

switstack moka's code is provided through an account on a switstack's github repository after having followed the on-boarding process. The code comes with an access to a community. and a CI that performs different tests including unit tests, functional tests, and EMV Level 2 certification tests.

Generic Level 2 API (GLA)

GLA is a specification that aims to abstract EMV Level 2 card prcoessing. At switstack, the GLA implementation is called GLAse. It sits on top of switstack moka to provide a straight forward integration for test and payment application developments. The advantages to use GLA are:

To use an API that is independent from a proprietary SDK;
To normalize EMV Level 2 API for PCI-PTS and COTS terminals;
To enable an interoperability within EMV Level 2 test ecosystems;
To enable an interoperability with EMV payment applications;

In summary, GLA provides a simple way to integrate any EMV Level 2 stack without having to understand the complexity of kernels implementations.

Entry Point Framework

Above all, switstack moka is an entry point framework. It supports all EMV Level 2 contactless kernels. Current version integrates Mastercard, Visa, American Express, and Discovery. The next release will include CPACE, Rupay, JCB, and CUP.

Security

Switstack moka is desgined to run on any device whatever its security architecture (harware or software). Sensitive data are captured at the source to avoid dissemination accross software components and facilitate PCI audits.

See Security for mor details.

Test Automation

Each kernel comes with a test automation libray emulating an accreditated tool used during official certifications.

Memory Footprint

switstack moka's memory management is based on static allocation to avoid runtime concerns, and to enable a fast card processing. Static memory can be fine tuned by implementers by adjusting a set of constants defined in the framework (see memory_footpring.h file). So, the footpriint depends on requirements, i.e. the number of kernels, EMV application, and transaction types to be supported.

See Performance for mor details.