Agnos is a software framework that can be reused to build any acceptance system. It requires good software skills, basic EMV payment expertise, and a good knowledge of the API to start (reading documentation should be enough even if we recommend to follow a course). In average, between 8 and 12 weeks are required to port the system onto a new platform to be ready to start a qualification
The advantages of using that framework are:
The system has already been certified in the past on different platforms
The system is already deployed on the field in major markets
The system is versatile and may be adapted to any Level3 contexts
The system’s version that is purchased is maintained against the very last specs and test plans updates (that are frequent)
However, note that:
The system is complex and usually requires a 3-day training session
The system needs to be qualified before being submitted to a TA
The system doesn’t implement any specific processor/acquirer security scheme (not standardized)
This section provides a high level description of the framework:
Agnos Ecosystem model
Libraries enumeration
Development Steps presentation
Development Environment presentation
Memory Foot Print example
Agnos Ecosystem
Other products are also available to extend the framework (see Agnos ecoystem below):
Agnos Automation (alias Atmos), a tool automating contact and contactless tests. It is used by development teams to prepare kernels for certification sessions performed by accredited laboratories
Agnos Certification Environment (alias ACE), a tool used during contact/contactless qualification and certification sessions including an engine used to generate binary configuration files (RAW and TLV formats) based on acquirer/processor parameters
Agnos Switch (alias AKTio): a transactional switch at the core of Agnos ecosystem supporting different applications
Agnos Payment Solution (alias Arkos), a payment solution targeting different architectures
Additional libraries and executables may be provided depending on the project's context. See Components page.
Libraries
Here is a brief description of the main libraries available when purchasing the product. Concerning the GPI, depending on the agreement, a specific library may be supplied. Else, it is customer’s responsibility to develop this part based on the GPI’s interface and examples developed on a given platform.
Library | Description |
---|---|
GPI/Platform | GPI module supported RTC, shared RAM, file system, debug, … related services |
GPI/CAD | GPI module supporting card acceptance device dual related services (CT + CL) |
GPI/HSM | GPI module supporting cryptographic related services |
GPI/SPED | GPI module supporting pinpad and display related services |
AgnosDB | A transient database containing all the data objects used during a transaction by card and terminal. This information is never persisted in the acceptance system |
Agnos | Dual EMV Library supporting EMVCo’s standard required to support EMV contact card processing, and EMV/Magstripe contactless card processing. That library is EMVCo Level2 certified. It is independent from the hardware thanks to the GPI |
AgnosMW | Library providing a set of services such as configuration management, payment control flow management, data processing |
AgnosEP | Single entry point to trigger CL payment transactions. Previous Agnos Framework versions included the triggering of any technology. This is not more possible from version 3.2 for flexibility reasons |
AgnosGE | Library providing an API to generate configuration binary files to be used in conjunction with AgnosMW |
ACE2P | Library used to interface Kizis (Level3 application) to ACE |
EMVCo | Test payment application used to certify the EMV Level2 library |
C-1 | n/a |
C-2/MasterCard | Alias payPass or Mastercard Contactless |
C-3/Visa | Alias PayWave Contactless VSDC or VISA-qVSDC and/or VISA-MSD |
C-4/American Express | Alias ExpressPay |
C-5/JCB | Alias JSpeedy |
C-6/Discover | Alias ZIP and/or DPAS |
C-7/CUP | Alias QuickPass Overseas |
PURE | White Label Kernel from Gemalto |
EFTPOS | Kernel Library used in Australia domestic market (Direct Debit Payment Network) |
Interac | Alias Flash (Canada; Pan Nordic Domestic Debit Payment Network) |
RuPay | Alias qSparc for Indian market (NPCI Domestic Debit Payment Network) |
Wise | White Label Kernel from Idemia (white-label & Open License) |
Bancomat | White Label Kernel for Italian market (Domestic Debit Payment Network) |
TestKernel | Library providing a specific implementation to pass EMVCo Book B certification test plan |
DualCertificationLevel3 | Alias Kizis. Main test and model application driving the framework and interfacing onto ACE through ACE2P |
Development Steps
Here are the major steps to cross in order to port the framework in preparation to qualification tests.
Step 1: Read Manuals
This step is used to know what the documents contain to use them later as reference.
The Wiki is the main source of information. There are 2 others documents available for implementation purposes:
[1]: Agnos Framework - L1 - Integration & Certification Guide (provided on demand) ⇒ to get details on GPI primitives
[4]: Agnos Framework - L3 - ACE2P Protocol (provided on demand) ⇒ to integrate ACE protocol
Don’t forget that the code is also a good source of information to know how a software system works: use header files to understand API contracts (especially for the GPI and Agnos).
In order to improve our manuals, please use them as references to send us requests for support on API integration. To help us , send questions by emails and include some of the following artifacts (depending on the context):
Tagged email’s object (mandatory): [Company name][Project name][Software component] Topic
Reference of the unclear / incomplete section of a document
Software components versions (mandatory)
EMV Logs
Card’s reference that is used
Configuration files
Step 2: Play with the AVT
See Agnos Virtual Terminal page.
Step 3: Study the Logical Model
Step 4: Study the Physical Model
Step 5: Start Porting
See Agnos Framework Porting and/or Agnos CL Kernel Porting pages.
Development Environment
According to the license agreement, a corresponding set of artifacts is delivered. Software components have been prepared to fit to your platform and operating system:
Use binary components for your deployment model implementation
Use binary and development components for your implementation
The most popular platforms and operating systems of the industry are supported by Agnos (WinCE/Wndows7/Linux/Android/iOS/FreeRTOS), and proprietary environments have already been targeted. Note that all the components described above can be packaged to support your development (Eclipse IDE along with Eclipse projects) on flexible platforms like PC (Windows/Linux). Thanks to the level of abstraction that Agnos provides, it is recommended to develop on such platforms to accelerate development and test phases: AVT is a reference implementation available on Windows that can be used along with a specific Agnos integration project targeting an embedded platform. Also, systematic use of the GPI abstraction layer is a must to achieve high level of portability.