Services
Each switstack moka 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.
Entry Point
Data model
| Tag | Name | Type | Set | Get | Description |
|---|---|---|---|---|---|
| 0x71 | Issuer script #1 | TLV | n/a | n/a | This tag may be provided at start D |
| 0x72 | Issuer script #2 | TLV | n/a | n/a | This tag may be provided at start D |
| 0x87 | Priority indicator | Byte value [0..15] |  |
 |
Selected candidate's AID priority |
| 0x8A | ARC | TLV | n/a | n/a | This tag may be provided at start D. Example: 8A 02 30 30 (accepted) |
| 0x91 | IAD | TLV | n/a | n/a | This tag may be provided at start D. Format depends on payment network |
| 0x96 | Kernel identifer-terminal | TLV | |
|
Selected candidate's kernel identifier-terminal |
| 0xE1 | Combination | TLV string | |
|
Contactless combination for a given {AID - Kernel ID - Transaction Type} triplet |
| 0xE2 | Selected candidate combination | TLV string | |
|
Contactless combination sent by emtry point during kernel activiation |
| 0xE4 | FCI | TLV string | |
|
Selected canddiate's final select response |
| 0xE5 | Transaction related data | TLV string | |
|
Data used to trigger a transaction during start A |
| 0xEC | DEK signal | TLV String | n/a | n/a | This tag may be received at start D |
| 0xED | DET signal | TLV String | n/a | n/a | This tag may be provided at start D |
| 0x9F06 | Matching AID | TLV | |
|
Selected candidate's AID |
| 0x9F0A | ASPRD | TLV | |
|
Not support yet |
| 0x9F29 | Extended selection | TLV | |
|
If exetended selection supported, AID post-fix |
| 0x9F3E | Terminal categories supported list | TLV | |
|
Not support yet |
| 0x9F3F | Selection data object list | TLV | |
|
Not support yet |
| 0x9F66 | TTQ | TLV | |
|
Selected candidate's TTQ |
| 0xBF0C | FCI issuer data | TLV string | |
|
Selected candidate's FCI issuer data |
| 0xDFA021 | Signal mode | Enum{C2=0, Other=1} | |
|
Signal management is not normalized between kernel specifications. Some cases such as Application Not Allowed or Empty Candidate List require to know in which mode the entry point shall formats output signal. Default value: C2 |
| 0xDFA025 | Reference transaction type | Byte value mirroring EMV tag 0x9C | |
|
Shall be defined before adding the first combination to filter combinations corresponding to actual transaction type. Default value is 0x00 (purchase) |
| 0xDFA00A | Entry point pre-procesing indicators | TLV | |
|
Selected candidate's pre-processing indicators |
| 0xDFA00B | Autorun support | Boolean | |
|
Starting condition for entry point, i.e. how a transaction is initiated |
| 0xDFA011 | ASPRD support | Boolean | |
|
Support application selection registered proprietary tag 0x9F0A |
| 0xDFA013 | TIDAS support | Boolean | |
|
Support terminal information during application selection tag 9F3E and 9F3F |
| 0xDFA039 | Kernel C-8 support | Boolean | |
|
Entry point supports kernel C8 |
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. |
Card Processing Application (CPA) Service
Data model
Each CPA's data model is specific. Refer to CPA_Name_data_model.h to get how it is structured, However, all CPA all built from the same pattern:
- A CPA is a state machine. A CPA State realizes a card processing step that consists in analyzing the last APDU response, and preparing the next one. For some states, it is a simple implemetation of a processing flow's step. Refer to
CPA_Name_card_processing.c. - A CPA manages an internal dashboard to raise errors under the tags DFA009 and DFA028. These 2 tags are bitmaps similar to TVR. Tag DFA009 is dedicated to ODA whereas DFA028 depends on the CPA. Refer to
CPA_Name_data_model.h to get the list of bits. - A CPA implements procedures. Whereas states represents flow steps and raise outcomes, procedures are standalone algorithms required by steps to implement EMV logic. Refer to CPA/procedures directory.
- A CPA supports a list of tags declared in
CPA_Name_tags.c. Each tag is defined by a rule indicating its source, type, length, ... When a tag is fetched from the configuration, the payment application, or the card, the CPA validates that it is valid against its definition.
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_PRE_PROCESSING |
Optional. Compute indicators to prepare card processing. |
CPA_NAME_SERVICE_ACTIVATE |
Activate a kernel as per EMVCo definition. |
HSM
To be completed...
Data model
Functional services
Logger
To be completed...