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.

In the meantime (approximatively from the mid 90’s, under the influence of organizations such as Rational), software engineering has been developing structured approaches and state-of-the-art methods to address what is the nature of the software activity: users’ requirements management and their implementation. Consequently, software life cycle, modelization, architecture patterns, virtualization, tests automation, … are some of the fundamental concepts on which software developers’ community leverages nowadays.

Entering in a new era of opened systems, the payment industry will have to match new expectations and to provide clarifications on its ecosystem. Beyond and independently from the security challenges, it is important to set a common background and share a common representation of the card-present payment function.

To start and in order to integrate Agnos properly, let’s share a common definition of the card processing.

At a first glance, card processing might encapsulate the business logic that is specified inside “L2” specifications. However, payment networks have different views on this level of abstraction. So, it is impossible to rely on such definition. For example, “exception file list management” is one option part of some contactless “L2” ICS but it is a feature that is typically dependent on acquirer/processor context.

Hence, it would be more accurate to define the card processing as being the business logic that is stable whatever the merchant environment that will integrate it. And the stability of the “L2” is crucial in the context of terminal approval processes managed by payment networks.

This definition leads us to three distinct perspectives of the card processing, a.k.a. the “L2”:

• Its integration

• Its certification

• Its maintenance

Integrability, Certificability, and Maintainability are 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.