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. |