Introduction

OLA stands for Open L2 API . It (OLA) is a programmable interface normalize normalizing card processing (L2) services required by a payment application (L3).

Important: this interface has been desgined designed from a Nexo Fast perspective. OLA is a global initiative aiming to cover a missing key element in the payment ecosystem: the EMV L2 API. However, OLA is generic enough to support any kind of payment dynamic . beyond Nexo implementation implementations.

Principles

Interacting with a L2 stack is based a simple principles:

1. Set pre-conditions

2. Initiate transaction

3. EventuallEventually, complete transaction

4. Get post-conditions

Setting pre-conditions

...

There are different interfaces defined to support that sequenceconsists in pushing EMV parameters fecthed from a TMS to the L2 stacks. This step depends on the payment application implementation and the selection process that occurs during stage of the transaction.

Initiating and completing a transaction is about delegating the card processing to the L2 stack. It triggers a behavior that has been L2 certified and granted with a LoA. It is based on the configuration parameters previously pushed.

Getting post-conditionsconsists in gathering a series of information to be able to provide a final outcome for the transaction.

Hypothesis: a payment application (L3) controls the polling of the technologies, implements a specific region EMV application .selection mechanism (if needed), and owns the configuration (fetched from its TMS). Card processing (L2) is global, and only depends on an ICS that is aligned on merchant’s requirements. Consequently:

• A payment application detects whether a contact or contactless application will be triggerred

• A payment application implements the logic to select a final application based on OLA services

• A payment application configures the EMV parameters based on the final selection

Interfaces

...

Interface

...

Architecture

OLA aims:

• To break dependencies between different integration levels and L2 implementations

• To fill the gap between different objectives of testability (usually dependent on the context of integration)

• To normalize L2 API beyond certificatibility objectives

Image Added

API

See Developer's Guide for more details on OLA API.

...

...

#ifndef _OLA_H_
#define _OLA_H_

#ifdef __cplusplus
extern "C" {
#endif

//---------------------------------------------------------
//			Includes
//---------------------------------------------------------

#include "ola_tags_dictionary.h" /// Generic Public Key configuration API
#include "ola_emv.h" /// Generic EMV API
#include "ola_publickey.h" /// Generic Public Key configuration API
#include "ola_contactless.h" /// Generic Contacless Processing API
#include "ola_contact.h" /// Generic Contact Processing API

//---------------------------------------------------------
//			Definitions
//---------------------------------------------------------

typedef void (*logf_function)(char* str);

//---------------------------------------------------------
//			Primitives
//---------------------------------------------------------

/// Version of the OLA API
/// No compatiblity guarantees are made between different versions
#define OLA_API_VERSION "2.1.1"

/**
 * @brief Get the current version of the OLA Api
 * @return Pointer to a string representation of the API version
 */
const char *ola_get_api_version(void);

/**
 * @brief Get the current version of the OLA Implementation
 * @return Pointer to a string representation of the API implementation
 */
const char *ola_get_implementation_version(void);

/**
 * @brief Initialize OLA implementation. Need to include xxx_ola_adapter.h to interface to proprietary_data's type
 * @return OLA error
 */
tOLAError ola_initialize_implementation(const uint8_t *tlv, uint16_t tlvLength);

/**
 * @brief Set a trace function
 */
void ola_set_trace_function(logf_function fct);

#ifdef __cplusplus
}
#endif

#endif

ola_emv.h