Amadis

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 3 Next »

The integration of Agnos depends on decisions to be made by the integrators at the level of their payment application’s architecture. Since Agnos lies at the Android native level (NDK), there are 2 different ways to leverage on its L2 services:

  1. Developing the payment application at the native level

  2. Developing the payment application at the java level

 

 However, that discussion shall be grounded from another discussion related to merchant applications dichotomy.

 

What Is A Merchant Application?

A merchant application essentially focuses on the merchant’s business: selling. Its responsibility is to address merchant requirements by providing appropriate UI, realizing business logics, interfacing with external systems, and ultimately triggering some actions. From that perspective, a merchant application uses the payment application as an extension of the merchant use cases that it implements. A merchant application lies at the POS level, should it be a physical or a logical abstraction.

 

What Is A Payment Application?

A payment application essentially focuses on card processing whatever the type of card it might process (EMV, magstripe, loyalty, fleet, …) and its dependencies with external sub-systems: the POS, the Acquirer/Processor Host, and optionally the TMS (including the attestation and monitoring services). In the context of this guide, the type of card is limited to EMV contactless cards. A payment application lies at the POI level, should it be a physical or a logical abstraction.

 

Architecture Considerations

That dichotomy is crucial in the objective of keeping the POS system totally separated from the POI side. Along the time, the POS will probably integrate new features or might address a different kind of business. However, these changes shall not impact the payment function realized by the card processing:

  • The payment side is certified against rules and shall not be modified after certifications (“L2/L3” constraint)

  • The payment handles data that shall not irradiate the merchant side (PCI constraint)

Note: the interface between the two systems can be either implemented through an API or a protocol.

  • No labels