Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

/DEVICA logical model is a representation of Agnos independently from its physical representation. Agnos Framework logical architecture is made of 4 main abstractions:

  1. AgnosEP: the entry point

  2. AgnosMW: the data manager

  3. Agnos: the EMVCo L2 Engine (using a database to store tags, AgnosDB)

  4. GPI/DEVICE: the Service Abstraction Layer provided as an interface to upper levels. The specialization is done at the Hardware Abstraction Layer by DEVICE

Image Added

The basics concepts are:

  • GPI (GPI library): also called the Hardware Service Abstraction Layer. It abstracts all the upper levels of the software architecture from the device

  • Agnos (Agnos library / see agnos.h ): also called the EMVCo kernel. It supports EMV contact, and Magstripe/EMV contactless transactions steps. It is EMVCo Level2 certified. It runs on top of the GPI so that it can be ported on any hardware platforms integrating a C compiler

  • Data Manager AgnosMW (AgnosMW library / see datamngr.h): the data manager manages the configuration contexts for TERMINAL (defining acceptance device’s contact ICS), PROCESSING (defining which AIDs the system supports for EMV contact/contactless and – for EMV contact only – related risk management parameters), ENTRY_POINT (contactless only – defining risk, business and transaction parameters), RAW SUPPORTED_AID (defining which contactless AIDId are supported), RAW COMBINATION (defining which contactless combinations are supported). All the contexts may be loaded using ACE or binary files in RAW or TLV formatsData Exchange (AgnosMW library / see datamngr.h): the data exchange is a callback-based mechanism allowing a Level3 to control the transaction flow between a card and a contactless kernel

  • EntryPoint (AgnosEP library / see entrypoint.h): the single point of interaction from L3 when performing a payment transaction. Level3 calls a dedicated service to initiate a transaction payment (being contact/contactless/magstripe). It shall prepare a specific C data structure – tPaymentContext – and analyze the outcome in return – tOutcomeParameter – once the transaction is completed. Once a transaction has been initiated, the entry point may use these structures to communicate with lower levels. This component is not used in a contact

  • Contactless kernels L2 CL Card Processing (used by AgnosEP library): application like PayPass, PayWave, etc… that have been developed and certified using the framework and its APIs. They are dynamically loaded by the entry point at the start of the system. They implement business rules according networks or EMVCo specifications. Contactless kernels are certified components. They can be developed by integrators (see Agnos Framework Service integration guide) and they can also be integrated onto other frameworks thanks to their generic API

Contact

The model below presents an example of architecture used for contact only payment acceptance solutions. The difference with the contactless lies on the entry point that is not required for EMV contact projects.

...

Contactless

The model below presents an example of architecture used for contact and contactless payment acceptance solutions. The difference with the contactless lies on the entry point that is required for EMV contactless configurations.

Agnos Framework may be used in different ways depending on physical architectures and the license purchased (contact, contactless, or dual and customers may implement and certify their own payment applications on top). But the main mechanisms are the same.

...

“L3” applications (green) can integrate Agnos without dealing with the underlying complexity. Open L2 API and the Dispatcher may be adapted depending on “L3” constraints without impacting “L2” certifications.

...