| Table of Contents |
|---|
Over the years, card processing has become more and more complicated. From the legacy magnetic stripe swipe to the tap-on-phone use case, acceptance systems have suffered from a lack of definition and standardization, leading to a complexity impacting costs, delays, and risks of software projects integrating the card-present payment function.
...
Its integration
Its certification
Its maintenance
Integrability, Certificability, and Maintainabilityare 3 key concepts related to the card processing.
Integrability
The integrability of a card processing system is its ability to provide a series of services so it can be seamlessly integrated onto a platform, into a test environment, or into a payment application. That characteristic is at the core of this documentation. There is no common API shared across “L2” providers and payment system vendors. Several API are proposed at different levels of the architecture.
Certificability
The certificability of a card processing system is its ability to pass test procedures proposed by payment networks to validate its implementation. That characteristic lies on 3 rules:
Identity: the ability to certify a L2 system is linked to the ability to define it. There is no existing definition of a card processing stack. The different specifications released by payment networks don’t provide a common view on the L2. Agnos identity is defined by its structure (see Data model section), and its behavior (see Open L2 API [1]). This concept answers to the question ‘’WHAT shall we certify’’.
Testability: given the lack of definition of the L2 across payment networks’ specifications, there are different ways to test a L2 system. Testability is proprietary and differs from labs to labs, from tools to tools, from stack to stack. Hence, Agnos requires a specific testing environment, ACE, that is provided to labs to certify the software. So, the testability is the responsibility of the stack provider. This concept answers to the question ‘’HOW shall we certify’’.
Stability across the time: the stability of a L2 system dependents of its maturity ad is important in regards with re-certification rules. L3 requirements are very challenging and sometimes could impact some L2 implementations (for example, see regional EMV applications selection requirements). Consequently, L2 stack providers must anticipate or they may need to modify their implementations once L2 LoA are granted with the risk to go through a re-certification process. This concept answers to the question ‘’WHEN shall we certify’’.
Maintainability
The maintainability of a card processing system is its ability to change across the time without impacting its certificability and integrability. In average, a “L2” software editor receives one update per week if we consider the specifications, the test plans, and the tools updates. In order to mitigate the potential risks of regression, different methods are put in place, including tests automation. As there is no common definition of the “L2”, test automation is proprietary, and maintainability depends on each stack.