Welcome to switstack moka documentation 
Introduction
EMV debit and credit card processing corresponds to a series of services that facilitate businesses in accepting card present transactions. It involves several parties including the cardholder, the merchant, the acquirer, the issuer and payment networks.
What is switstack moka?
switstack moka
is an EMV Level 2 stack, the cornerstone of in-person payment architectures 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 switstack moka fix?
switstack moka
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 Application).
This documentation presents switstack moka
's requirements and 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 payment networks documentation.
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).