Interoperability & compliance of Keyple-based ticketing terminal solutions

In order to guarantee interoperability between smart cards and terminals, the ‘Calypso Networks Association’ (CNA) encourages ticketing operators to follow various specifications and certification processes.

Contactless reader communication protocol

For compliance with the contactless reader communication protocol, CNA supports the certification programme standardised by the ‘Smart Ticketing Alliance’ (STA) for ‘Public Transport Readers’ (PT Readers). Several test laboratories are approved for ‘Proximity Coupling Device’ (PCD) certification under the supervision of the ‘Certification Body’ Paycert.

Separation and functional logic of the various software layers

To guarantee the functional capability of the ticketing terminals, CNA has proposed a software architecture with a distribution of responsibilities per layer, and has defined dedicated functional requirements for each software layer.

Reader software layer

For terminals integrating contactless and/or contact readers, the Keyple’s ‘Core’ libraries have been designed to meet the terminal requirements for the reader layer.

• In order to declare that a configuration of Keyple Core libraries and a smart card reader plugin are indeed compliant with the terminal requirements for the reader layer, the main condition is that the plugin used to interface the reader has been implemented according to the Keyple plugin development guide.

The Keyple project hosts plugins for interfacing reader solutions based on standardized APIs: PC/SC and Android NFC. Pending the future certification programme for reader layer libraries, CNA plans to publish the self-declarations of conformity of the Keyple Core libraries for reader solutions interfaced with these plugins.

Applicability and supported rules

For a smart card reader solution integrated with the “Keyple Core” software libraries, the applicability of the “reader layer” requirements depends primarily on the characteristics of the reader solution.

However, the Keyple Core libraries have a limitation regarding applicability: they do not support “Channels.”

• In fact, the keyple-service-lib component (in versions < 4) does not support multiple logical channels: with this version of Keyple Core, it is not possible to manage transactions across different logical channels on the same reader.
• Therefore, the Channels applicability must necessarily be set to false in the declaration of conformity.

For readers with Contactless applicability, compliance with requirement RL-CL-RFSTA.2, which mandates that the readers’ RF communication be certified by the STA (Smart Ticketing Alliance) or the NFC Forum, is the responsibility of the reader manufacturer.

Regarding the Polling, RF Shut-off, and Protocol application modes:

• Support for the associated requirements falls outside the scope of Keyple; it depends on the low-level driver specific to the reader solution.
• In 2026, verification of compliance with these requirements was transferred to the STA’s RF certification process.
• NFC Forum readers do not allow for configuring RF protocol polling. The RF field is not turned off by applications but rather by the device’s power-saving mode.

However, since keyple-service-lib 2.0.0, Keyple Core is capable of properly supporting all other applicable “reader layer” requirements for any integrated reader solution through a “reader plugin” that complies with the Keyple plugin development guide

• For example, the detection applicability requires that the plugin implement the ObservableReaderSpi SPI. All requirements related to the detection applicability are supported.
• The presence applicability is always supported for a reader solution integrated with Keyple that also supports the “detection” applicability. The methodology used to manage card presence depends on the SPIs ( CardPresenceMonitorBlockingSpi, CardRemovalWaiterNonBlockingSpi, CardRemovalWaiterAsynchronousSpi, CardRemovalWaiterBlockingSpi ) implemented by the reader plugin.

Depending on the conditions of applicability, and provided that a compliant reader plugin is available, the Keyple Core software layer ensures that all of these requirements are properly supported by the reader layer: RL-CT-T0T1.2, RL-PON-IDENTIFY.2, RL-PON-FILTER.2, RL-DET-INSNOTIF.1, RL-DET-REMCTRL.1, RL-DET-REMNOTIF.1, RL-DET-REMCFG.1, RL-CMD-USED.1, RL-CMD-SHORT.2, RL-CMD-EXTENDED.2, RL-CMD-GROUP.2, RL-CMD-STOP.2, RL-CLA-ACCEPTED.2, RL-SW-ANALYSIS.2, RL-SW-61XX.1, RL-SW-6CXX.1, RL-SW-CASE4.2, RL-PERF-TIME.1, RL-SEL-USAGE.2, RL-SEL-CLA.1, RL-SEL-P2LC.2, RL-SEL-DFNAME.1

Properties of PC/SC and NFC reader solutions

“Keyple Java Service 2026.10.14 set” definitions for PC/SC & Android NFC plugins

“Keyple C++ Service 2026.09.22 set” definition for PC/SC plugin

Calypso software layer

The Keyple’s ‘Calypso’ libraries have also been implemented to meet the terminal requirements for the Calypso layer, regardless of the reader solutions used. To guarantee « complete » compliance with the requirements of the Calypso layer: the reader software layer used as a basis (Keyple’s ‘Core’ libraries + reader plugins) must comply with the terminal requirements for the reader layer.

Pending the future certification programme for Calypso layer libraries, CNA has published the self-declarations of conformity of the Keyple Calypso libraries (independently of interfaced reader solutions, but on the basis of a compliant reader software layer):

• Keyple Java Calypso Prime PKI 2026.10.14 set
• Keyple C++ Calypso Prime Extended 2026.09.22 set

Terminal requirements support declarations

All terminal requirements defined for the Calypso software layer that are necessary to ensure proper interoperability with Calypso card and SAM solutions are fully handled by the Keyple Calypso extension libraries. Only a few requirements are, exceptionally, partially supported; here are the explanations.

The CL-SEL-SNHEADER.2 requirement, which is used to support the Calypso HCE feature, is not supported. The middleware does not provide a way to automate the validation of HCE tokens. This lack has a limited impact: the project provides a development guide for managing HCE token validity.

Regarding the CL-PERF-HFLOW.1 requirement, the Keyple Calypso libraries have been designed to optimize card & SAM command exchanges with the best possible performance, depending on the terminal architecture:

• for an embedded architecture (saving latencies of between 1 and 10 milliseconds on transmissions with local readers),
• for a distributed architecture (saving latencies of between 10 and 100 milliseconds on network exchanges with remote readers).

Support for requirements specific to the Prime PKI feature (CL-PKI-ALGO.1, CL-PKI-VERIF.2, CL-PKI-PUBKEY.1, CL-PKI-RQMODE.1) is only included in versions where this feature is available (Keyple Card Calypso Crypto PKI Library 0.2+).

CL-SV-RECOVERY.1 is not supported: this requirement appears to be unnecessary. If a Stored Value transaction presents a risk of card communication interruption that needs to be handled: in this case, the SV transaction can be performed within a secure Calypso session that is closed with a “not ratified” state. In the event of a card communication interruption at the end of the transaction, the transaction recovery can then be easily managed based on the card’s ratification status.

“Keyple Java Calypso Prime PKI 2026.10.14 set” definition

“Keyple C++ Calypso Prime Extended 2026.09.22 set” definition

Ticketing software layer

For a ticketing terminal solution built on the Keyple framework, the responsibility for complying with the requirements for the ticketing software layer lies exclusively with the developers of the terminal application using the ‘public’ Reader & Calypso terminal APIs.