CPoC stands for Contactless Payment on COTS (where COTS means Customer Off-The-Shelf), and it is a term related to a new generation of merchant’s payment solutions deployed on open mobile devices (as of today, Android platforms). In that context, the contactless card processing functionality (Agnos framework) is exactly same as for conventional terminals, the payment functionality is very similar. The main change of paradigm is on the security side where there is a shift from the hardware to the software layer. Consequently, there is no dongle involved in this kind of payment architecture. The security is supported through the combination of 2 features:
...
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:
Developing the payment application at the native level
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:
...
Note: the interface between the two systems can be either implemented through an API or a protocol.
Design Considerations
So, depending on integrator’s architecture, there are two possible ways to integrate Agnos:
Develop the payment application at Native level
Develop the payment application at Java level
Native Architecture
The native architecture consists in deploying all the payment related components at the NDK level where a C tool chain is available. A JNI bridge (blue) is required at the Java level to enable communication between the two levels and connect the Sales Logic (yellow) to the “L3” Application (green). POS services are exclusively in the Java layer.
...
Java Architecture
The Java architecture consists in deploying exclusively the card processing related components at the NDK level where a C tool chain is available. A JNI bridge (blue) is required at the Java level to enable communication between the two levels and connect the “L3” Application (green) to the OLA API. POS and POI services are deployed in the Java layer.
Native Option
Pros |
|
Cons |
|
Java Option
Pros |
|
Cons |
certificability is exposed as new POS features might impact the certified POI mechanisms (exposes certificability)
|