...
...
...
...
...
In contact (acronyms K or CT), configurations are AID driven. There are 2 files: TERMINAL (RAW or TLV format), and PROCESSING (RAW or TLV format)
In contactless (acronym CL), configurations are KAT driven. KAT stands for Kernel Id / AID Id / Transaction Type id. There are 5 files: TERMINAL (RAW or TLV format), PROCESSING (RAW or TLV format), ENTRY_POINT (RAW or TLV format), SUPPORTED AID (RAW format only), COMBINATION (RAW format only), and UPDATE CONDITIONS (TLV format)
For more details, see:
SUPPORTED_AID (deprecated. RAW format only)
COMBINATION (deprecated RAW format only)
UPDATE CONDITIONS (where <update conditions> ::= UC + '_' + 'C' + <kernel id>)
...
Table of Contents |
---|
Introduction
That section presents how different abstractions related to the system’s configuration are linked all together. These abstractions are usually part of a TMS system and downloaded onto the point of acceptance, i.e. the terminal running Agnos. There are different perspectives attached to a data model:
The transportation model
The persistent model
The instantiated model
Transportation Model
The transportation model is not presented in that document because it’s specific to the infrastructure integrating Agnos. Depending on the acquirer/processor TMS system, the data model may be transported using XML files, a series of protocol messages (like EPAS NEXO TMS or ISO8583), or even proprietary structures (there might be no model at all).
Persistent Model
The persistent model is specific to Agnos. It’s important to learn that model because it’s used by the framework to get ready to process transactions. That model is built from the transportation data and stored onto the terminal. From Agnos Framework 2.x.x, there are 2 persistent models:
The legacy RAW files including TERMINAL, PROCESSING, ENTRY_POINT, AID, and COMBINATION. The structures of these files are documented in Appendixes.
The TLV files including TERMINAL, PROCESSING, and ENTRY_POINT. The structures of these files are documented in Appendixes.
...
Note2: Knowing ACE2P, ACE may be used without Agnos to certify any EMV stacks on any terminal. This allows a terminal to fetch configuration data required for certification sessions (CAPK, list of AIDs and underlying parameters …).
Instantiated Model
The instantiated model is the logical view of the system’s configuration. It can be found in datamngr.h (i.e. AgnosMW library. Once RAW/TLV files are loaded, i.e when Level3 has called an initialization service, RAW/TLV data are used to set the actual Agnos Framework model that is used at running time and lives in RAM.
Note: If a L3 Application uses OLA, the persistent model depends on the payment application. In the other words, the way to store the configuration data is the responsibility of the integrators. As a reference, Agnos uses the following values for data configuration:
Data Model
Agnos Framework supports both contact and contactless transactions. The difference between the configuration paradigms is:
In contact(acronyms K or CT), configurations are AID driven. There are 2 files: TERMINAL (RAW or TLV format), and PROCESSING (RAW or TLV format)
In contactless(acronym CL), configurations are KAT driven. KAT stands for Kernel Id / AID Id / Transaction Type id. There are 5 files: TERMINAL (RAW or TLV format), PROCESSING (RAW or TLV format), ENTRY_POINT (RAW or TLV format), SUPPORTED AID (RAW format only), COMBINATION (RAW format only), and UPDATE CONDITIONS (TLV format)
For more details, see:
SUPPORTED_AID (Deprecated)
COMBINATION (Deprecated)
UPDATE CONDITIONS (where <update conditions> ::= UC + '_' + 'C' + <kernel id>)
Contact Kernel Settings
Conctact configurations are made of managed from a list of AID. Each AID comes along with a set of EMV parameters.
Contactless Kernels Settings
Conctactless configurations are made of combinations. Each combination is uniquely identified thanks to a primary called a KAT key:
K standing for Kernel Identifier
A standing for Aid Identifier
T standing for Transaction Type
...
Here is the mapping between the kernel labels and identifiers supported by Agnos Framework:
Kernel | Kernel Identifier | Kernel Default Setting |
---|---|---|
n/a | 1 | |
Mastercard Contactless | 2 | |
Visa VCPS | 3 | |
American Express ExpressPay | 4 | |
JCB J/Speedy | 5 | |
Discover DPAS | 6 | |
CUP Overseas | 7 | |
Interac Flash | 8 (Agnos Framework 3.1.x) or 65 (from Agnos Framework 3.2.x) | |
RuPay qSPARC | 13 (from Agnos Framework 3.2.x) | |
EFTPOS | 66 (from Agnos Framework 3.2.x) | |
Gemalto PURE | 67 (from Agnos Framework 3.2.x) | |
Idemia Wise | 68 (from Agnos Framework 3.2.x) | |
Bancomat | 69 (from Agnos Framework 3.2.x) |
Note: Agnos Framework supports up to 255 kernel identifiers to comply with EMVCo Book B certification requirements.
...
Here is the mapping between the AID and identifiers supported by Agnos Framework:
AID | AID Identifier |
---|---|
Any AID | Corresponding #order from the list of AID defined in PROCESSING |
Here is the mapping between the transaction type and identifiers supported by Agnos Framework (see paymentMW.h and tTransactionType enumeration type):
Transaction Type | Transaction Type Identifier |
---|---|
Purchase | 0x00 |
Cash | 0x01 |
Purchase with cashback | 0x02 |
Refund | 0x03 |
Manual cash | 0x04 |
Quasi cash | 0x05 |
Deposit | 0x06 |
Inquiry | 0x07 |
Payment | 0x08 |
Transfer | 0x09 |
Administrative | 0x0A |
House keeping (clean message) | 0x0B |
Retrieval | 0x0C |
Update | 0x0D |
Authentication | 0x0E |
Cash disbursement | 0x0F |
INI File Management
The persistent model may be generated using INI files. See INI File Management page.