<< Go back to Part 1: Introduction to Contactless Payments (cEMV) in transit
Overview of the system
A modern contactless fare collection system has four major components:
- Acceptance devices, or validators (hardware) (front office)
- Fare engine (back office)
- Payment gateway (PSP or gateway) (middle office)
- Payment acquiring (banking)
Additional components, such as data analytics and customer apps, can be added to the above to further enhance the system.
The diagram below shows an abstract of a contactless fare collection architecture.
- Acceptance Devices (Front Office): These are the point-of-sale terminals or devices used to accept and process payments from passengers. There is a wide range of hardware options for varying use cases, including validators on gates, driver consoles (Electronic Ticket Machines, ETMs), and simple low-cost pole-mounted validators. Transit hardware must be designed to be durable and reliable, able to withstand heavy usage and extreme weather conditions, and have the appropriate certifications to accept contactless EMV transactions. (Part 4 of this series will be dedicated to Hardware considerations)
- Fare Engine (Back-office): The fare engine manages fare rules and applies these rules to passenger travel. This is the heart of the transit ticketing system and, depending on the complexity of the fare rules and their interoperability with numerous modes of travel, it can be the most complex and expensive component of the solution. Simplification of complex legacy fare rules is perhaps the most effective way for a transit agency to reduce the overall cost of fare collection, including the cost of hardware.
There are broadly three types of fare systems: Automated Fare Collection (AFC); Account Based Ticketing (ABT); and Mobility as a Service (MaaS). (Part 3 of this series delves deeper into these alternative systems) - Payment Gateway or Payment Service Provider (PSP)(Middle Office): In a contactless ticketing system, once a fare is calculated, the system must connect to the payment card networks to authorise and settle the payment. This is done by a Payment Gateway or Payment Service Provider. A PSP is a third-party service provider that facilitates the secure flow of payment information between the passenger and the transit agency’s banking institution. PSPs must be PCI Level 1 certified, and handles payment security compliance burdens for transit operators through the use of encryption technologies, tokenisation, and key exchange protocols with other parts of the system.
Third party PSPs are sometimes referred to as the ‘middle office’ and act as a connective layer between the Front Office (Hardware) and Back Office (Fare Calculation) enabling a more flexible and modular fare system. With its exclusive focus on the transit sector, Littlepay stands as the global leader in payment processing for transit. (Part 5 of this series focuses on PSP and Gateway capabilities) - Payment Acquiring (Banking): This is a licensed and regulated financial institution, acting on behalf of the Merchant to process transactions and handle customer funds. The Acquiring Bank is connected to the payment card networks and manages the risk associated with processing payments to ensure all transactions are secure and compliant with regulations.
Models of Open-loop Systems
While all open-loop fare collection systems will have the four key components, how these fit together can vary markedly. There are 3 models which can be adopted:
1. Build to Own
These are systems built from the ground up to meet the specified requirements of a transit agency. The components are bespoke, built to requirements, and tightly coupled as there’s no need to be interoperable.
This was the conventional approach to ticketing systems in the pre public cloud era, when system integrators charged eye-watering sums to develop large, complex, on-premise systems, and then charged even more to operate and maintain these systems for the transit agency.
During the development phase, these are complex waterfall projects, that carry high risk. Hardware and Software, including Ticketing, fare management, payment processing, customer management are all developed in a monolithic system that is inflexible, expensive to manage and even more expensive to upgrade. This approach locks in a single vendor, who then holds the transit agency hostage to the vendors timetable, and every more exorbitantly priced change requests.
A classic example of Build to Own systems was Melbourne’s disastrous Myki system. A two year project that took 9 years to complete and was more than $500m over budget.
Large system integrators, specialise in these kinds of bespoke implementations. These include Accenture (Toronto), Cubic (London, Sydney) and Thales (Netherlands).
As we’ve seen time and time again, these kinds of deployments inevitably end up way over budget, years late to delivery, and dysfunctional through the life of the contract. There are many case studies that should serve as a warning to agencies. However, sadly, this still seems to be the approach being adopted by many agencies such SEPTA, Melbourne (for the 2nd time) and MARTA.
2. Off the Shelf (OTS) systems
The advent and popularisation of the public cloud by AWS kicked off the enterprise SaaS revolution in the 2010’s. This significantly lowered the cost of software development and deployment, and allowed new smaller and more agile players to enter the enterprise software space and disrupt incumbent players by rapidly shortening the product development life-cycle and accelerating obsolescence.
The transition to OTS systems has been slower in fare collection than most other verticals. The interconnectedness of fare collection systems with many other external systems (accounting, financial, business intelligence etc.) has made decoupling and replacement difficult and expensive.
Some traditional ‘Build to Own’ system integrators have begun to ‘productise’ their legacy software, and moved into the cloud. This often involves front-end lipstick on legacy porcine back-end systems. For this reason some of these systems still remain relatively expensive to buy and operate, and can remain out of reach for smaller transit agencies and operators.
These newer kids on the block have the advantage of developing platforms that are native to the cloud and designed as configurable products. However, whilst configurable and more flexible (within limits), they remain proprietary with tightly-coupled components that work end-to-end. That is, you usually can’t swap out components or integrate third party software from best-of-breed vendors. And with the increasingly rapid pace of technological change, and the increasing complexity of public transport networks, ‘configurability’ is still a poorer substitute for interoperable modular systems.
3. Modular Systems
Modular systems are the latest generation of platforms that are cloud-native and leverage the latest software architecture and application interfaces (APIs) to build a system from best-of-breed components that integrate.
Littlepay was a pioneer in bringing modularity to fare collection in public transit by publishing APIs that device vendors and fare collection systems vendors could use to integrate with the payment platform. These APIs are standard interfaces that allow independent components from various vendors to communicate, resulting in much lower cost and friction. This is analogous to an operating system on a computer that allows other software and hardware components, such as printers and monitors, to be interoperable.
The advantages of this approach are driving more OTS vendors to open their systems and integrate with Littlepay. Today we have over 20 validators certified and five back-office fare collection systems integrated with Littlepay.
Founded in 2016 to address the growing demand for a more affordable EMV solution by the transit industry, Littlepay has built a dedicated, modular transit payments service. The platform handles the entire end-to-end cEMV payment requirements for the transit operator, removing the need to build systems, deploy software or worry about PCI compliance.
Its modular, API-based payments platform plugs-and-plays with pre-integrated, ‘Littlepay Ready’ validators, back offices, payment gateways and acquiring banks - giving transit agencies a fast, flexible route to contactless payment acceptance. Agencies can simply configure their preferred transit rules while benefiting from ongoing product developments.
In the United States, Littlepay has deployed its solution in multiple locations, integrating with relevant partners according to the needs of the agencies, collaborating therefore with Kuba in Santa Barbara and with SC Soft in Sacramento.
When putting together a transit infrastructure, the operator can pick the level of involvement desired from the PSP, from a "lightweight' deployment with flat fares and minimal back office integration such as Cannes to a "fully integrated" deployment with Littlepay calculating fares, caps and integrating EMV into its own ABT portals such as Leicester’s multi-operator deployment.
A modular system requires a modular approach to procurement. Transit agencies have often been trapped by consultant-designed procurement processes that favour vertically integrated vendors to the disadvantage of specialist best-of-breed component vendors. We cover this in section six on procurement.