Skip to content

Appendixes

Appendix Title
Appendix-1 Architecture Decision Record (ADR).
Appendix-2 About services.
Appendix-3 About Logger.

ADR

This section documents decisions about architecture and decision to help readers understand how switstack moka is built.

Decision #1 EMV Level 2 Certifications
Context EMVCo Books follow a writing pattern that helps to normalized EMV Level 2 implementations. But for a given brand, a C-x book diverges from the payment network's specification which imposes a dual reference complicating code documentation, design, and test plan realization.
Decision switstack moka targets payment networks certifications, excepted for EMVCo contact and EMVCo Book C-8.
Consequences No impact on EMVCo Book C-2 as the payment network aligned their specifications already. For other networks, code documentation refers to requirements coming from the payment networks specifications.

Services

Each switstack moka's software component is a service that follows the same architecture pattern.

  • A service is encapsulated by a proxy that can be reached by any other service through a message broker (the proxy is registered onto the message broker at the setup time);
  • A service implements a set of generic services, and a set of functional services that are specific to the service.
  • A service runs on top of a data model that rules service's states that generic and functional services navigate;

All services support the following generic services:

Generic Service Description
GENERIC_SERVICE_GET_NAME --
GENERIC_SERVICE_GET_IDENTIFIER --
GENERIC_SERVICE_GET_VERSION --
GENERIC_SERVICE_GET_CHECKSUM --
GENERIC_SERVICE_GET_SETUP --
GENERIC_SERVICE_GET_INITIALIZE --
GENERIC_SERVICE_SET_PARAMETERS --
GENERIC_SERVICE_GET_PARAMETERS --
GENERIC_SERVICE_GET_CLEANUP --
GENERIC_SERVICE_GET_RELEASE --

Then, each service may expose a series of functional services depending on its purpose. The following sections present each service along with its data model.

HSM

Data model

Functional services

Entry Point

Data model

Functional services

Entry Point Service (see entry_point.h) Description
EMVCO_ENTRY_POINT_SERVICE_START_A implements EMVCo start A.
EMVCO_ENTRY_POINT_SERVICE_START_B implements EMVCo start B.
EMVCO_ENTRY_POINT_SERVICE_START_C implements EMVCo start C.
EMVCO_ENTRY_POINT_SERVICE_START_D implements EMVCo start D.
EMVCO_ENTRY_POINT_SERVICE_START_RESUME resumes card processing application service from the state it stopped.

Card Processing Application (CPA) Service

Data model

Functional services

A CPA is a kernel that implements EMVCo's or payment networks' specifications.

CPA Service (see cpa_name.h) Description
CPA_NAME_SERVICE_ACTIVATE activate a kernel as per EMVCo definition.

Logger

Data model

Functional services