Chapter Three: 
Fare Systems in Contactless 

Go back to Part 2: Architecture of an Open Loop Transit System

Overview

In the age of Uber, every passenger expects price transparency and payment simplicity. Yet public transit fares in many cities remain complex, opaque and difficult to understand.

Fare calculation is arguably the central component of a transit ticketing system. The purchase of a transit ticket and fare represents the product choice of a traveller, and so of strategic importance to any transit agency seeking to engage with its ridership. The ability to create, adjust, bundle and cap fares offers an effective method for transit agencies to respond to different customer segments and changing circumstances. We’ve recently seen this used to great effect in the UK, where a government initiated £2 fare cap to help citizens with cost of living pressures has driven a surge in ridership.

In this section we provide a high-level overview of different fare collection systems, the fare types they manage, and how these fare types are handled in a contactless payments environment.

Fare Systems

One thing is clear - the more complex the fare rules, the more expensive the overall system that is required to manage them. Due to the complexity of many legacy ticket products, the back-end software that manages fare rules is often the most expensive component to procure, the most complex to implement, and the most risky from an information security perspective.   

Fare systems fall into 4 broad categories:

i) Automated Fare Collection (AFC)

AFC systems replaced traditional manual fare collection methods such as cash and paper tickets with electronic payment methods such as closed-loop smartcards and QR codes.

A closed-loop system is typically a card-centric, pre-paid system with the following attributes:

• Fare media: primarily based on smartcards that store value or ticket data on the card. These cards operate on a range of standards which differ by region and supplier. Some common smartcard standards include Mifare, Calypso, ITSO and Felica. Passengers can pre-load these cards with a pre-purchased ticket or value added through top up payment. 
• Validation devices: ticket readers located at entry gates, on platforms or onboard vehicles that interact with the fare media to deduct the appropriate amount or validate the relevant ticket on the card.  
• Back-Office: infrastructure that performs fare calculation, card lifecycle management, customer support, card balances, data management and analytics. Some AFC systems are cloud based. 

AFC systems can be upgraded to support open-loop and accept bank cards. This requires the validation devices to be compatible and certified for open loop, and be integrated with a system able to securely manage the open-loop payment flows e.g. by integrating with a PSP such as Littlepay.

ii) Account Based Ticketing (ABT)

ABT is a customer-centric system that moves more of the processing and fare calculation into the back-office. ABT solutions usually support multiple types of token such as closed loop smartcards, open loop bank cards and QR codes.  

Passengers can then travel using a valid token to tap in and out of public transport services. Their taps are stored centrally in the ABT system where the appropriate fare can be calculated and charged according to the rules set by the transit agency.

Many ABT solutions require passengers to register an account in order to travel. During registration, passengers can select their token of choice and then link various and multiple payment methods to the account for post-payment, top ups and subscriptions. This type of solution allows an interaction between closed and open loop cards. For example, a child’s concessionary smart-card that is topped-up by a parent’s open loop card. 

Fares are typically calculated at the end of day or specified period. The system can therefore apply more granular and personalised fare rules to the passenger’s travel history over that time period rather than for each single trip- for example, application of capping rules across multiple modes of transport and service providers. 

However, the benefits of these additional capabilities come with the added friction of passengers having to register their information onto the ABT system.

Most ABT systems on the market are modifications of legacy AFC systems. They remain complex, expensive and add significant data risks for transit operators. Given the amount of sensitive personal data these systems accumulate, such systems can be a target for cybercriminals as seen in recent examples.

iii) Mobility as a Service (MaaS)

MaaS encompasses the idea of moving towards a more interconnected transportation system. This involves integrating various modes of transportation, such as buses, trains, taxis, ride-sharing services, bicycles, and even scooters, into a single platform or service. 

MaaS platforms enable users to plan, book, and pay for their entire journey using a single application or service provider. They provide real-time information about available modes of transportation, fares, and routes, allowing users to choose the most efficient and cost-effective option for their specific needs.

MaaS was the hot new thing for a few years, and has gradually waned in popularity as the available platforms proved to be expensive and complex with the added challenge of requiring the commercial and technical cooperation of many disparate entities. That is why there are no real MaaS success stories of significant scale in the world today. Whilst there is value in the overall vision, stakeholders are reconsidering the path to deliver value to the passenger. Building on existing commercial models and passenger behaviour is more likely to encourage interconnectivity and adoption.

iv) Littlepay - API infrastructure for open payments

The huge capital and operating expenses required to implement AFC, ABT and MaaS systems has meant they could only be afforded by transit agencies of the larger cities. At Littlepay, we set out to develop a scalable and more affordable solution for agencies and operators of all sizes, so they could easily accept open loop payments. Today, Littlepay offers cost effective open payment solutions to bus operators with as few as 5 vehicles and as many as 5000. 

We achieve this by using an open, modular, cloud based infrastructure that can either integrate to existing ticketing solutions or work on a standalone basis. The foundation of the Littlepay platform are Application Programming Interfaces (APIs) that enable different components of the solution to interact and share data with each other; collaboration is at the heart of our design. This is the connectivity layer of the system. These APIs serve different functions:

i) Device APIs: used by validator vendors to integrate to Littlepay’s payment gateway, and accept open payments. This approach allows the transit agency to separate decisions regarding validator selection from other components, creating modularity and reducing vendor lock-in. Once integrated and certified, the devices can be rapidly installed for a simple open loop implementation. We now have a wide selection of validators certified with Littlepay.

ii) Back-office API’s: allow various AFC and ABT systems to integrate to Littlepay’s payment platform. In this modular configuration, Littlepay handles encryption and tokenisation of the payments to reduce the exposure of the AFC/ABT system to sensitive payment data. The AFC/ABT back-office can then calculate fares based on anonymised data, and then requests Littlepay to process the payment. These APIs enable larger transit agencies to upgrade legacy AFC/ABT ticketing systems with open payments. 

While some AFC and ABT systems offer built-in payment solutions, given the complexity and security implications, there are many advantages to partnering with a specialised PSP that is capable of managing the compliance and security risks at scale. 

Some smaller transit agencies or operators don’t have the need for complex fare calculations. In this case Littlepay offers a stand-alone light-weight back-office that can handle simple fare structures (based on route, zone, time, or fixed point to point), and fare adjustment (daily, weekly capping). A number of larger cities have used this light-weight solution to expedite the delivery of open payments while they implement and transition to their newly procured AFC/ABT system over several years

iii) Checkout APIs/SDKs: this is an e-commerce payment gateway for purchases through mobile or web channels. This allows Littlepay to offer transit agencies a single platform across all purchasing channels. In turn, this provides a single view of customer purchases on a secure and anonymous basis, without the need for account registrations. 

iv) Omnichannel experience: Littlepay Checkout and Littlepay Contactless offer a unified passenger experience creating a common token for bank cards and mobile wallets used across both payment channels. A common token enables agencies to unlock passenger value in a variety of innovative ways including:

• Buy Now Tap Later: passengers can link the ticket purchased to their payment card or mobile wallet so that it can be used to travel. They just turn up, tap and ride.
• Ridership engagement: passenger’s can opt-in to have their physical Pay As You Go taps made using their payment card linked to their mobile app. This allows the agency to interact with the rider in real-time with focussed, added value information, notifications and services e.g. notifying a passenger via the app that they have reached a fare cap and travel for the rest of the week is free.
• Concession and discounted travel eligibility: using a similar feature to that used in Buy Now Tap Later, the passenger can choose to verify their eligibility for discounted travel via the mobile app or website and link their payment card or mobile wallet to the discount. When the passenger purchases tickets or travels on transport via Pay As You Go, they will automatically receive their discount before being charged. 

v) Multi-Operator Adjustment (Interoperability): Littlepay’s “Multi-Operator” capability enables interoperability across independently run back-offices. This functionality is currently being used in the UK, whereby independent operators are offering passengers a ‘City Zone’ product. Littlepay detects that the customer has travelled across 2 or more systems, and can then cap the fare and set the rules by which the revenue can be apportioned to the operators. This is a way to offer simple and low-cost multi-modal travel products (e.g. MaaS), without the need for complex new systems.

vi)Bank Integrations: Littlepay integrates with a range of financial institutions around the world to authorise and settle payments and manage risk and fraud to maximise revenue collection.

The combination of Littlepay's APIs and transit functionality allows plug and play of components to create solutions that are fit for purpose, regardless of size or complexity.

Managing Complex Fares via Open Payments

Transit agencies need to consider catering to a wide range of fare types, including:

• Flat Fares (with or without capping)
• Time-based
• Zone-based
• Route-based
• Number of stops
• Fixed Point to Point (fixed validators e.g. railway platforms)
• Variable Point to Point (moving validators e.g. bus)

AFC and ABT ticketing systems handle these fare variations through a back-office that can aggregate and adjust trips. In a closed loop system, once a dollar value is added to the card, there is no longer a need to interact with payment rails and be subject to the regulations and rules of the payment card networks. Transit smart-cards are usually only single-purpose, so there are fewer implications for fraud, theft, and misuse.

In contrast, open payments were originally designed for simple individual retail transactions. In a retail contactless EMV transaction, you will find the following:

• Transaction value is known at the time of purchase
• The retail system sends the the transaction value to the point of sale device/validator which the customer taps
• Authorisation is then made for the specific value
• The device can get a real-time authorisation, which means it must be able to be ‘online’ and communicate with the payment network
• Transactions are individually processed, so there is no aggregation of transactions
• If the customer/passenger has no funds they will not be able to complete the transaction, and therefore there is no risk of having insufficient funds and no need for recovery of debt owed

To accommodate transit fares, which require more complex rules and adjustments, the card schemes developed specifications for two alternative transaction models:

i) Know Fare Transactions (KFT): KFT transactions are a modified version of the ‘Retail’ model for use in the transit context. These are single transactions with known values and usually no capping. The transactions are able to be authenticated ‘offline’ to allow for a vehicle such as a bus to lose connectivity, while risk is managed through deny lists and debt recovery.

Littlepay has further developed the KFT model so capping can be introduced on an incremental basis, applying discounts to flat fares. In this scenario, rather than aggregating transactions and capping at the end of day, the passenger is charged for each transaction with discounts applied as the cap is reached.

ii) Aggregated Pay as You Go Transactions (PAYG): PAYG allows for a complete set of variable fares to be adopted on contactless open payments, including tap-on / tap-off (TOTO). Passengers tap to travel throughout the day and the back-office calculates the best fare for that travel. There is no need for the passenger to pre-purchase a ticket. PAYG processing involves a 2-step authorisation process. 

After the initial tap, a ‘zero’ value (or small nominal value) is sent for authorisation. This allows the passenger to board their travel, but carries the risk that the passenger does not have adequate funds for the fare. At the end of a specified period (usually end of day), the back-office calculates the total fare for the passenger, factoring in any adjustments for multiple modes, zones, capping or other variables. This fare is then sent for ‘final’ authorisation, and settlement.

If the authorisation fails, the transit operator is protected by liability shift rules, in which the card-issuer will guarantee the ‘first-ride’ payment up to an amount. This protected amount varies by region. An authorisation failure will result in the payment being placed on a deny list. This list is maintained by Littlepay with updates communicated to all the validators in the network every few minutes. The validator checks a card that is tapped against the list and denies travel to the passenger. 

If the transaction is above the first-ride guarantee limit and not protected, Littlepay has automated debt-recovery processes that re-attempt completion of the transaction over the following weeks. Usually passengers will at some stage add funding to their cards, and most of the debt can be recovered. 

The combination of these risk processes are fundamental to minimise the revenue loss for a transit operator. Revenue loss resulting from failed transactions or insufficient funds is a direct cost to the transit operator.

As the first specialist payment service provider to the transit industry Littlepay has spent years refining risk management and automated debt recovery processes using machine learning to maximise revenue collection for operators.  

Go To Part 4:  Hardware - Point of Sale Validators >>