Logical Model
Following industry’s paradigm, Agnos Framework is made of 3 distinct layers aligned on EMVCo definitions and industry certification processes cycles:
L1 | LEVEL 1 EMV Card interface and other platform level services. Agnos HAL (GPI) provides a full set of platform services (like display, keypad, RTC, HSM, SRED, etc…) |
|---|---|
L2 | LEVEL 2 EMV “API”, or “Kernel”, or “library”, or “stack”. Back to the origin of the Agnos Framework, the brand “Agnos” was the name of an EMVCo certified Level2 library compliant with contact and contactless processing. This library still exists and shall be introduced as an EMV Level2 dual library because it supports both EMV contact and EMV/Magstripe contactless card processing independent from the device. This layer factorizes EMV processing defined in EMVCo books I/II/III/IV and A/B/C/D. It supports any ICS combination except “CDA mode 4”. Please contact us for any support or questions related to your specific project |
L3 | LEVEL 3 Applicative level. L3 term is not a standard term. AgnosMW, AgnosGE and AgnosEP are part of the framework's Level3 components. This level also takes care of the acquirer/processor protocols and business rules implementations. Protocols and rules are outside the scope of Agnos Framework even if it provides all mandatory services and data as specified by standards and Payment Networks. All L3 examples are provided in the scope of certification projects requiring payment test applications to validate Agnos L2 and a L1 combination |
Note: Payment applications are not necessarily clearly identified in that 3-tier model. Level3 is not an official term used in the industry. In that document, it is used to discriminate what pertains to the low level layer (i.e. platform services) versus the EMV contact certifiable libraries (i.e. the “kernels”). Level 3 may be hosted on a mobile phone, a secured payment device, a remote host server or split between an acceptance client and a server depending on architecture and security constraints of the payment solution. Agnos supports any type of architecture and has been ported onto different platforms, OS, and device contexts.
As depicted above:
GPI is the sole library depending on the hardware platform (OS & Firmware). It behaves as a HAL. It is linked onto the operating system’s API provided by the device manufacturer
Agnos is linked onto the GPI Interface
AgnosMW is linked onto the GPI Interface, and AGNOS Interface
AgnosEP is linked onto the GPI Interface, AGNOS Interface and AGNOSMW Interface
It is up to the application developer to interface with any of the 5 interfaces available when developing Level3 applications. An EMV contact development project doesn't need the entry point.
Integration Process
The success of an Agnos project lies – at least – on a good understanding of Agnos Framework, underlying EMV concepts, and configuration model. However, the product has been designed to avoid having a deep knowledge on the EMV and payment network specifications. Key components have been certified against major organizations of the industry like American Express, Discover, EMVCo, Interac, MasterCard, Visa, … so that they can be reused in customers’ specific environments. However, it is important to understand that the product is independent from acquirers/processors infrastructures meaning that the major questions to address during the design stage are:
⇒ How to adapt the framework to a specific platform?
⇒ How to fetch acquirers/processors parameters and to configure Agnos Framework so that it complies with acquirers/processors business and operational rules?
⇒ How to send acquirers/processors transactional information from Agnos Framework data that have been collected during and after a transaction?
⇒ What is specific in the processing implementation so that it would go beyond the standards (user interface, merchant’s payment process, regional rules, etc…)?
⇒ How to interface with the Sale system (physically and logically)?
⇒ What are the acquirer security’s scheme parameters? How are they managed?
Note: Payment brands CL specifications are constantly changing. Agnos Framework is base-lined once a year to reflect the most up-to-date requirements validated during CL TA sessions, and to provide improvements on API. However, it’s impossible to have an on-the-shelf product matching all very last requirements all along the year because each brand moves at different a pace. So, Agnos and underlying CL payment applications are part of an internal qualification process to keep them in sync with the specifications. The product can’t be base-lined every month (to costly to do so) but there is a systematic monitoring on specs changes and maintenance on current base-line to avoid gaps. Consequently, customers’ project dates will define which versions are going to be used depending on the project timing and specs sunsets/releases. Updates will be delivered on purpose.