Chapter Four: 
Hardware - Point of Sale Validators

<< Go back to Part 3: Fare Systems in Contactless

Overview

The range of card validators available for public transit ticketing systems is varied and complex. This complexity increases further when the acceptance of contactless bank cards is added to the requirements.  

We’ve seen numerous instances of poor decisions in validator selection leading to complications and delays in implementing contactless ticketing systems. In this part of our series, we provide a high-level overview of some of the considerations to be aware of when procuring and implementing a validator for cEMV open payments. 

Understanding your requirements

The most suitable validator for a given implementation will depend on a number of requirements and considerations:

Is the fare selected before purchase? If so, there are 3 general scenarios:

1. Driver Intervention: The passenger requests a specific fare from a vehicle driver (or conductor) before tapping their card to complete a purchase.
2. Passenger Intervention: The passenger interacts with the validator to select a ticket (e.g. select a zone, or family ticket) before tapping their card. The validator interface (screen, buttons) will handle this interaction. This type of device often has the most complex User Interface requirements due to support for the different payment and ticketing options, multi-language, accessibility legislation etc.
3. No intervention: The passenger simply taps their card, (tap-on) for a Known or Fixed fare. 

Is the fare calculated post travel? 

For the Tap-On/Tap-Off (no intervention) scenario, the fare is calculated by the system after the journey is completed. Typically this involves subsequent processing by an automated fare collection system, which assigns the fare to one or more taps.

In the two no-intervention scenarios, aggregation of the individual fares may occur at the back office and capping or other discounts may be applied before the passenger is charged for their journey(s).

Each of these scenarios implies a different set of capabilities for the validators which need to be considered.

What payment types are accepted? A transit system may need to accept cash payments, closed-loop smart-cards, QR-codes and contactless bank-card payments concurrently. This can result in separate legacy and upgraded hardware being used side-by-side for different types of cash and digital transactions

How is the purchase verified? Is a receipt required? Different approaches to verifying ticket purchases will have implications for the features of validators to be used. 

Modern, paperless implementations of contactless are sometimes complemented with separate handheld ‘inspection’ devices, which can be viewed as another type of validator. The ticket inspector will request the passengers to tap their bank card on the inspection device, which will confirm whether a ticket has been purchased or if they have indeed Tapped-On as they boarded the vehicle or entered the transit system (e.g. metro). If not, a fine or penalty notice can be issued, and in some cases, the inspection device can also process a payment for a ticket or the fine.

Despite the negative impact on boarding times, physical receipts are still a requirement in some regions significantly increasing the cost of validators which then need a thermal printer or similar capability. 

Where is the validator to be installed / Form factor? 

Transit validators can be on gates at train stations, in a bus cockpit, on a pole mount, or outdoors on a platform or pier. Conditions in various geographic regions can have implications for the suitability of validators. They may need to be certified for electrical compliance, tolerance to extreme environments such as sub-zero temperatures or exposure to dust, sand or water.  In all cases, they will need to be hardened to withstand vandalism and heavy usage. This is why transit validators can be significantly more expensive than a retail POS device.

What are the basic validator types

Electronic Ticket Machines (ETMs): 

ETMs are usually found on buses and are generally “attended” by the driver. It is a larger unit that can allow the driver to manage routes, and select the appropriate fare before the passenger makes a contactless purchase on the card reader. 

This flexibility allows bus drivers to switch from simple PAYG tap transactions, to a KFT transaction with potentially multiple passengers (e.g. family) paid for with one tap. However this can come at a cost of slower boarding times. 

ETM’s can also manage some parts of the fare calculation for more complex fare structures as they are integrated into route management software that can identify each stop and send the right fare to the card reader. 

Ticketer’s Standard ETM was the first ETM to integrate with Littlepay and now serves a significant portion of the UK bus market.

Individual / Pole Mounted Validators:

Pole mounted validators include brackets for mounting and more complex electrical wiring to fit on various vehicle configurations. They can be used as primary validators which are fully certified as independent acceptance devices. Alternatively, they can be a secondary device (child to the primary parent device or ETM), often used for tap-off only, and connect through to the primary validator or ETM.

Gate Validators:

A gate validator has the added signalling capability to trigger the opening and closing of a physical barrier or gate, granting or denying passenger access to the transit system. These validators are most commonly used in train and metro stations across the world. While they have a different form factor, from a ticketing perspective, they can be viewed in the same way as an individual pole-mounted validator.

Handhelds:

Most Handheld validators in transit are modified versions of retail mobile point of sale devices. Sometimes referred to as ‘queue-busters’ these devices are used to accept retail or KFT transactions, by a representative who sells tickets to passengers before boarding. They are often used for Demand-Responsive Transport solutions. The devices usually come with a printer to provide paper receipt and/or can print a barcode for subsequent ticket validation.

Components of a contactless validator

A transit validator that can process open payments has several components. This is a high-level overview of some of the more important components you should be aware of:

cEMV Card Reader:  

This is the sophisticated component that sits within any validator and interacts with open-payment cards. The reader must be certified by EMV Co. to comply with the required standards of card acceptance and security (see below on certifications)

Two important sub-components within the reader are:

• The Radio Frequency module that allows for wireless communication with contactless payment cards or mobile devices. It enables the exchange of data and commands between the reader and the card.
• The ‘Secure Reader’ which is a tamper-resistant hardware component that securely stores cryptographic keys and performs secure transactions. It ensures the confidentiality and integrity of sensitive data during the transaction process.

Card readers are manufactured by a number of OEM vendors including: Pax, Gemini 2000, Emsyscon, Ingenico and Feig to name but a few. 

Security Access Module (SAM slot): 

A SAM slot in a cEMV Card Reader refers to a physical slot or compartment designed to accommodate a SAM card. A SAM card is a small, removable device (like a SIM card) that may contain cryptographic keys and algorithms used for secure communication and transaction processing in a Point of Sale (POS) system or may simply provide additional services not available directly by that reader.

By using a SAM card in the dedicated slot, the POS reader has an alternative way to establish a secure channel of communication with the payment network, perform card authentication, and protect sensitive data during the transaction process if that is not already available with the Card Reader’s inherent functionality. Thus the SAM is another way to help prevent fraud and unauthorised access to critical information, ensuring the integrity and trustworthiness of the transactions.

Transit validators can have multiple SAM Slots to manage different closed-loop and open-loop transaction protocols. For example, the validators commonly used in the UK have SAM cards for MIFARE DESFire closed-loop cards and ITSO cards. It is not mandatory to have or use SAM slots but is one common way to extend validator functionality.

Kernel:

A kernel refers to the software component that operates at the core of the payment processing functionality. The kernel handles tasks such as reading the payment card data, encrypting sensitive information and performing authentication. It ensures that the transaction is executed securely and in compliance with industry standards and regulations, such as the Payment Card Industry Data Security Standard (PCI DSS). Each card scheme, such as Visa, Mastercard, Amex have their own required ‘card Kernels’ which are updated and versioned. Older Kernels may not be able to accept newer issued cards. 

Payment Application:

This is the software application that interacts with the Card Reader, and executes the business logic and protocols to, for example, initiating the authorisation process. It is also responsible for the user interface - such as sound, lights, receipt generation etc. Processing of Deny Lists often happens in this domain while using the cryptographic services of the EMV Reader to verify the authenticity and integrity of deny list updates.

Littlepay provides EMV reader device vendors the API’s and encryption keys required to integrate their payment application to various financial institutions (acquirers). 

Certifications and Security

Validators must comply with 3 levels of certification before they can be put into use for open payments.  As described by EMV Co:

EMV Level 1: Level 1 certification is a ‘hardware’ test to ensure the terminal chip reader for compliance with the mechanical and electrical protocols in the EMV Chip Specifications, which covers the transfer of data between the terminal and the card, smartphone, watch, or other device for making card-based payments. This includes tests to confirm how close the card/device and the reader need to be for information to flow so card users enjoy a consistent and reliable experience with the device.

EMV Level 2: EMV contactless level 2 is a ‘software’ functional test. This certification evaluates the ‘EMV Level 2 kernel’, which is the software inside the terminal (known as firmware) that performs EMV processing, for compliance with the EMV Chip Specifications. These tests confirm that the software supports the EMV payment application functions. Each of the payment networks (Visa, Mastercard, Amex, etc)  have their own specific tests for this certification.

Level 1 and 2 certifications are valid for at least 2 years - often up to 4 years. This certification framework was originally created for the retail environment, where low-cost devices could be easily replaced after a couple of years. In a transit implementation where devices are more expensive and harder to replace, the payment networks have allowed existing certifications to be ‘grandfathered’ and continue in the field after certifications have elapsed. However, certifications must be valid at the time of implementation.

For security evaluation, the Payment Card Industry (PCI) Security Standards Council sets the benchmarks. The relevant SRED (Secure Reading and Exchange of Data) certification is part of the PCI PIN Transaction Security (PTS) standard and this still applies even though EMV card readers as described in the previous section are contactless only and do not support PIN. The SRED rules apply to any Point Of Interaction (POI) which is any point where cardholder data is captured. The focus of these rules and certification is to ensure that there are adequate protections in place to ensure the device will not “leak” any keys used in protecting cardholder data, that only approved algorithms are used, that keys used by devices are unique, that updates and remote access are authenticated cryptographically and that sensitive data is held for no longer than is absolutely necessary. 

When purchasing a Validator, you should confirm the validity of the Level 1 and 2 certifications, and how long remains on these certificates. This will be the window of time to complete the Level 3 certification.

Level 3: L3 certification is an end-to-end test from device to Acquirer. This testing evaluates and confirms that an EMV-compliant payment acceptance terminal will work with merchant and bank systems to enable end-to-end transaction acceptance. The testing helps ensure that a new or upgraded terminal (hardware and/or software) meets the specific requirements and recommendations of the individual payment systems and the acquiring bank before it is brought to market. Level 3 for transit involves performing specific test cases for this environment.

Waivers:

During the various certifications, some tests may fail on older devices. For example, a failure on a Level 2 certification may indicate some older bank card chips are not accepted. It is possible to apply to the payment networks for a waiver to allow the device to be deployed despite certain minor failures. Payment networks are more lenient on allowing older devices to be deployed if there is a plan to upgrade these within a reasonable time frame.

Encryption: Protocols, Algorithms & Keys:

Central to the security of the interaction between the validator and the passenger's card; and also between the validator and the Payment Processor; is encryption. Protection of the sensitive cardholder data from point of capture to the point of payment authorisation (and at every intermediate step along the way) is essential. How this “trust” is established and assured is worthy of some comment. One way to break this down is to consider separately “confidentiality” and “integrity”.

Confidentiality is where the data is protected so that it is visible only to those who have the rights (and need) to view that data. This is the role of encryption, where the data is converted; via an algorithm and a key, into something that anyone who intercepts the data (and doesn’t have the relevant key) is unable to reverse into the original unprotected data or message. The choice of algorithm and the length of key used (sometimes referred to as the strength) are often specified by the relevant industry bodies. In the case of payment, this can be the payment card networks and/or PCI - both of which will be guided by national bodies such as National Institute of Standards and Technology (NIST) in the USA, National Cyber Security Centre (NCSC) in UK or Agence Nationale de la Sécurité des Systèmes d'Information (ANSSI) in France. 

It is absolutely essential that only approved algorithms with the appropriate keys are used - and this is one of the primary checks performed in the certification and security assessment processes. It is also essential that these algorithms and keys are used in an approved manner - as there are “weak” ways of performing these steps that render the security offered by these trusted protocols useless. That is why it is important to use partners with experience and provenance in this domain - with up to date certification that verifies best practices are instilled in the organisation at all levels. Attacks on systems never get worse - they only ever get more advanced, sophisticated and prevalent. 

Security is a process, not a product.

Integrity is where the recipient of any data can confirm that what was received is what was sent without having prior knowledge of that transmitted information. Rather than encryption, this is achieved through Message Authentication Codes (MAC) or Digital Signatures. Digital Signatures can be used to prove who generated the signature (authorship) using what is called asymmetric cryptography where there is a public and private key.  MACs are based on symmetric cryptography (where there is a shared secret key). A variation on the MAC is the HMAC - which uses a one-way HASH function rather than a symmetric encryption algorithm at its core. 

Littlepay uses a range of encryption technologies to ensure the confidentiality and integrity of your passenger payment information. 

If you have followed the discussion in this section so far, congratulations - and you would also be right to ask “How do I ensure I don’t have to become an expert in cryptography just to accept bank cards on my buses?” This is where having partners with the right certifications and accreditations come in. Those partners work collaboratively to take on the security responsibility. Through a modular solution with clearly defined APIs and responsibilities, a solution can be delivered swiftly without compromising the security. Let’s now look at the Certifications that enable this approach.

Littlepay test lab:

At Littlepay we have our own test facility and use industry approved equipment to support validator vendors with their Level 3 certifications. With over 20 devices certified on the Littlepay platform, transit agencies have a wide variety of pre-certified devices to choose from.

We’ve also worked with partners to develop technology that can upgrade some older closed-loop terminals to accept contactless EMV. That is, if a device can pass the Level 1 test, we can use the SAM slot on the device to upgrade the terminal’s kernel to become Level 2 compliant, and be ready for Level 3 certification.  

Get in touch to find out more.

Pitfalls in validator procurement

A transit validator vendor must be able to navigate the many complexities of open payment certifications, as well as understand the nuances of transit ticketing. A deficiency of experience in either domain is likely to lead to a frustrated transit agency, and many delays in implementation.

While it is important to ensure that all the certifications and EMV functionality is available, it is also important to ensure that the supporting transit specific functionality and services are also available. For example, does the validator provide location information in the format already used by your existing back office environment. Does it provide all the route, vehicle and driver information. If required, does it integrate with the existing Vehicle Location systems and on-board rider information system? Or does it provide integration with any existing driver consoles? Or can all the required information be provided to the agency independently of these other systems - making the installation and configuration much simpler?

When that is established, it is then important to consider how the validator and its associated Payment Services Provider must interact with any Automated Fare Collection (AFC) system or Account Based Ticketing (ABT) system. Will the validator be the source of specific information for that solution or is the fare structure simple enough that no additional fare engines are required?

Using standard APIs provided by a PSP like Littlepay can ensure the interfaces between validators and the back office are functional and interoperable between vendors.

So where can problems still emerge?

When comparing specifics of individual validators, considerations should include:

• Are all the required EMV payment schemes supported? For example: Visa, Mastercard, American Express, Discover
• Is the device already certified in a similar implementation? (validate all references!)
• For a new model, are all the relevant certifications in place?
• Are any of the certifications likely to expire before the launch?
• Are there any end-of-life notifications for any key components of the validator?
• Is there adequate support and training available?
• Are the localisation and accessibility options to be supported clear?
• Are there any geographic restrictions on the supply or use of the validator?
• Are warranties and support packages appropriate for the environment?
• Are they configurable to meet the needs of your network (consider vehicle rotation on bus routes vs. a validator that is built into a gate in a metro system).
• Do they have a decommissioning process to ensure they are securely “wiped” of any secrets that could be useful to “bad actors”

In addition, especially in the cases where a single validator must process not only open loop EMV payment cards, other critical requirements include:

• Performance of the device (particularly speed) in processing physical EMV cards vs. closed loop vs. QR code scanning.
• Performance of the device in processing digital EMV cards in mobile wallets.
• Clarity in User Experience on how EMV operates vs. closed loop card processing vs. QR code scanning.
• How revenue inspection will be performed for each type of media accepted in the scheme.

An experienced vendor in the transit space can help provide holistic insights and a roadmap on how to deploy a contactless EMV validator successfully - be that on a greenfield deployment, as an addition to an existing system of closed loop cards, or as part of an account based ticketing implementation. They will also have an appreciation of the nuances between the requirements of payment schemes in different geographic regions. If they are not aware of these considerations, it should be taken as a warning.

At Littlepay, we partner with the best validator vendors in the industry, who we’ve assessed, tested and certified.  Speak to us to find out more about the range of pre-certified devices that are ready to be implemented in your region.

Go to Part 5: The Role of the Payment Service Provider >>