This article is intended for executives and product managers of two-sided marketplaces such as Amazon, PayPal, Lyft, Uber, Payz, Neteller, and others. It describes the Universal Ticket Agent (UniTiAg) business concept, which provides an opportunity for two-sided marketplaces to include public transit operators as merchants.
By allocating funds to an Open-to-Ride Balance (OTRB), customers of the two-sided marketplace (a shopper, a wallet holder, or a taxi rider) can access the services of any participating Transit Agency (TA) by simply tapping their contactless card at the TA’s validators.
This article explains how UniTiAg works and outlines the benefits for two-sided marketplaces, including extending the marketplace’s customer base and collecting service fees. It is worth noting that worldwide public transit’s annual fare revenue is estimated at $300 billion. However, the cost of fare collection, across all ticketing methods, starts at 7% of fare revenue, often exceeding this baseline.
Many Transit Agencies worldwide are currently piloting open-loop account-based ticketing (ABT) systems. The aim is to reduce cash management costs and provide frictionless access to their services. However, these systems often encounter challenges with low adoption rates and high implementation and operational costs.
As discussed in our previous articles, implementing open-loop ABT can be quite expensive.
- TAs must procure costly open-loop hardware and software components, and merchant services, while also securing someone to integrate them.
- TAs must also manage to organise and operate card-present merchant business processes, which are governed by complex payment scheme rules for transit transactions aggregation and risk management. These rules often require TAs to redesign their traditional ticketing policies and business processes.
- Additionally, TAs are subject to Payment Card Industry Data Security Standard (PCI DSS) regulations.
While large TAs like Transport for London can afford these investments and operational expenses, mid-size and small TAs often cannot. A more comprehensive analysis of this issue can be found here.
In our previous articles, we introduced Informed Validation method and described its advantages. This method moves fare collection from the card-present domain to the card-not-present domain, where contactless card taps are used to register rides rather than process payment transactions. This removes the burden of the card-present acquiring from TAs.
Being transaction aggregation friendly, the Informed Validation method is also debit and prepaid card friendly. This enables savings on interchange fees, which can otherwise discourage small transit operators from adopting open-loop systems.
However, the Informed Validation method requires riders to pre-pay for their travel in advance with each transit agency they use. This may cause friction and discourage sporadic patrons and tourists from utilising public transit.
In this article, we introduce UniTiAg, a cloud service that removes the friction caused by the Informed Validation method. UniTiAg provides customers of two-sided marketplaces (shoppers, wallet holders, etc.) with an Open-To-Ride Balance (OTRB) shared among all participating Transit Agencies.
Customers, who are also transit riders, only need to create their OTRB once. After that, they can simply tap their cards at any participating TA. UniTiAg takes care of seamlessly sharing the OTRB between all participating Transit Agencies.
The TA takes care of providing rides, calculating fares, and registering card taps as proof of service using the Informed Validation method at their validators. This approach significantly reduces or eliminates the TA’s exposure to PCI DSS-regulated data. On the other hand, UniTiAg takes care of card acquiring, in an efficient card-not-present, e-commerce manner. They charge riders and reconcile transactions with their TAs.
To illustrate the UniTiAg user experience, consider the following example:
When you order food from Uber Eats or make a purchase on Amazon using their app, you receive a prompt like this one:
“As a valued customer, you have the right to tap your contactless credit card at any participating transit agency (see the list of transit agencies). These agencies will allow you to ride up to the default Open-To-Ride balance of $20. We will apply the actual fare costs to your account at the end of the day. You can increase your Open-To-Ride balance and set up auto-replenishment here.”
This proposition works well for credit cardholders known to the marketplace. For debit cardholders, the proposition could be:
“Dear customer, you can set aside a small amount of money for rides at any participating transit agency (see the list of transit agencies). You can purchase your Open-To-Ride balance and setup auto-replenishment here.”
4. UniTiAg Architecture
Let’s take a closer look at the business architecture of UniTiAg.
UniTiAg is a two-sided marketplace. It reconciles the participating Transit Agencies for fares charged up to the Open-To-Ride Balances.
UniTiAg communicates with the payment schemes to provide OTRB top-up and refund services for riders via card-not-present transactions.
The Open-to-Ride Balance is a balance for ticketing purposes, associated with a given contactless card.
View this presentation video that outlines the UniTiAg business architecture and the life cycle of the Open-to-Ride balance.
The OTRB is shared among the participating TAs. UniTiAg synchronises the OTRB list with the TAs in near real-time. When some of the funds on the OTRB is spent in one TA, the OTRB decreases for all other TAs by the time the rider reaches any validator within these TAs.
The OTRB can be pre-authorised, prepaid, postpaid, or a combination of thereof, depending on the UniTiAg customer’s creditworthiness, the types of payment cards associated with the OTRB, and UniTiAg risk management policies.
A Transit Agency is a transit operator or an agency of multiple transit operators and acts as a merchant from UniTiAg’s standpoint. Each TA has the responsibility to:
- implement its access (validation) policies and determines fares
- collect proofs of service through contactless card tap data
- maintain unique relations with the riders in terms of fare policies and services
- optionally, manage a unique ABT system with rider profiles that include ride history, discounts, and concession parameters;
- implement an application program interface (API) called UniTiAg API for OTRB lists synchronisation, fare charge and refunds reporting, and fare reconciliation
The TA is not required to implement any type of acquiring for fare collection purposes. The TA does not need to be PCI DSS compliant unless it decides to keep some sensitive cardholder information (for example, to implement their concession policies).
UniTiAg maintains a large OTRB list but only synchronizes with TAs the OTRBs actively used there.
Validators belong to their respective TAs and are managed by them through the TAs proprietary APIs. In the context of UniTiAg architecture, we can distinguish two types of validators:
- Wireless Validators which are usually installed on transit vehicles or hand-held devices used to validate trips and collect fares. Such validators require a copy of OTRB list that their TA provides them with and synchronises periodically.
- Wired Validators, usually installed on railway or subway stations, and in any sites where there is a reliable and fast internet connection. These validators can always access the OTRB data directly from their TA, eliminating the need to have their own copies of OTRB lists. They can also get validation decisions swiftly from their TA.
5. Business Artifacts
Business requirements describing the business architecture, business processes, use cases, service-level agreements, and UniTiAg API, as well as the UniTiAg demo version, and feasibility studies, are available upon request.
A brief understanding of the Informed Validation workflow can be reviewed here.
To understand its technical details and specific technology further, feel free to explore the UniTiAg platform on their website.
6. Go To Market
We have noted above that the UniTiAg solution bears similarities to existing two-sided marketplace solutions like Uber, Lyft, Amazon etc. Taking this is a step further, mass transit fare payment can be considered as simply another two-sided marketplace use case facilitating purchase and value exchange between buyers (commuters) and sellers (transit operators).
From this viewpoint, the obvious question is “can existing global two-sided marketplaces play a role in providing UniTiAg?” We think the answer is yes.
Existing operators have the global infrastructure that allows them to onboard transit operators as card-accepting merchants. They can also acquire and settle card transactions from commuters settling them efficiently. Further, with minimal development, they can enable commuters to manage their OTRB. By integrating the UniTiAg solution into existing two-sided marketplace apps, it becomes ubiquitous and user-friendly for consumers. Moreover, it serves as a source of new customers and enhances the processing volume for two-sided marketplaces.
If existing two-sided marketplaces were to embrace the transit opportunity, there are potential benefits for all stakeholders.
- Two-sided marketplaces can apply existing business models and generate additional profits, even where interchange fees are high. Incremental business could come from existing users and new users attracted by the UniTiAg functionality.
- Commuters have the convenience of getting immediate and frictionless access to transit services using their existing contactless debit or credit card as a token, and potentially across multiple (even many) currently disparate transit operators.
- Transit operators enjoy the convenience of fare collection without the financial and operational burden of card acquiring and without changing their legacy fare policies.
- The two-sided marketplace has the potential to offer bundled travel options that are currently unavailable. This includes discounted travel for events and more.
- Small and mid-size transit operators implementing Open-Loop ticketing systems are disproportionally impacted by implementation and operation costs comprising merchant services fees, risk and dispute management, point-of-sale management, as well as procurement of integration services and system components necessary to implement acquiring-related business processes and services.
- The Informed Validation method, based on prepaid balance, significantly reduces these costs but creates friction for riders. UniTiAg (Universal Ticket Agent), a shared service, eliminates this friction by allowing riders to use any participating transit agency without the need to create an account with this agency, purchase Open-to-Ride Balance before the ride, and get a refund after parting with the agency.
- UniTiAg can be created from scratch. However, similar services, such as two-sided marketplaces are in a better position to implement it.
- UniTiAg service shields the participating transit agencies from the acquiring risks and complexities while allowing them the freedom to maintain their proprietary validation policies, structure fares, and apply caps, discounts, and concessions.
Authors: David Lunt, Technical Director, Melbourne, Eugene Lishak, Associate, Toronto, & Terry McMullen, Consultant for Loyalty, Sydney, Payments Consulting Network
David and Eugene have worked on ticketing systems since 2011 and 2008, respectively. They both bring a wealth of knowledge to the Payments Consulting Network on this topic.
With his background spanning 38 years in financial services and merchant loyalty, Terry not only contributes invaluable insights to transit ticketing and payments but also adds his extensive expertise in loyalty solutions to the mix.
This is part of a series of transit articles.
If you found this article helpful and would like to read similar articles, please subscribe to our newsletter.
To get notified of our latest posts, follow the Payments Consulting Network company LinkedIn page and click on the bell icon at the top right section of our company profile.