Fare Payment
On this page:
Introduction
Anyone who has travelled to a new city has both marvelled at how easy it is to get transit directions in apps like Transit, Google Maps, or Apple Maps thanks to the power of GTFS, but also been frustrated by how hard it can be to actually pay the fare because they don’t have exact change, or need to figure out which card to buy at a ticket vending machine.
App-based transit fare payment options have gained momentum recently, propelled in part by the COVID-19 pandemic and a desire to accelerate the shift to contactless payments. There are an increasing number of transit agencies and mobile ticketing providers that have enabled a wide variety of apps and mobility services to seamlessly integrate mobile transit payments. These advancements are an early step that indicate the potential for an open standard that transit agencies and fare payment partners could adopt to accept app-based payments.
Despite these successful examples, most traditional fare collection vendors still don’t offer APIs for integration into mobility apps. In the few places where these vendors do offer mobile payments, they are available only in a proprietary app riders must download separately. Even vendors whose systems promote “open loop” payments using contactless credit or debit cards often restrict users by making account information and other important functionality only available in their proprietary app. These approaches prevent riders from paying fares in the way that’s easiest for them.
Ultimately, these approaches lock the agency to the fare payment vendor and reduce opportunities for innovation that improve the rider experience. Keeping mobile payments under lock and key means that transit agencies aren’t able to bring fares to riders in popular user-focused apps, like Google Maps and Transit.
Having mobile ticketing available through APIs creates a mobility ecosystem where apps and vendors compete to build the best experience for riders. In the long run, these APIs can become public and standardized to ensure transit agencies benefit from interoperability between all apps and vendors. This would extend the benefits of GTFS, which revolutionized access to transit information, into the fare payment realm and allow transit agencies to build a complete trip experience for riders in whichever app they choose.
Fare payment shouldn’t be a hurdle for customers. With a focus on APIs and the customer experience rather than checking “having an app” off an RFP laundry list, transit agencies can welcome innovation and provide space for the experimentation necessary to deliver the best possible fare payment experience now and in the future.
Guidance for public agencies
- Because open data standards don’t yet exist for mobile ticketing, ask vendors to provide their mobile payment APIs, and share them for evaluation by apps that have integrated similar services in the past. Transit is not the only company in this category, but you can use our requirements to get started.
- When evaluating a mobile ticketing provider, find out where they can sell their tickets besides their own app. If your agency is putting out a Request for Proposals, score providers on their proven ability to work with third parties, not just their willingness to do it.
- Are you dealing with the market through your ticketing vendor, or do you have independent relationships? Relying on a single vendor poses risks. If your only relationship is with your ticketing provider, you might not get the innovation you’re looking for in the long run. Consider contracting strategies that allow you to work directly with a range of market participants in addition to your ticketing vendor.
- Business models matter. Commissions, enablement fees, monthly fees. There are seemingly as many ways to pay for fare payment as there are ways to pay your fare. Consider the incentives you’re offering through your remuneration scheme: commissions incentivize ongoing development, recurring payments can help spread the risk, and upfront capital investments may reduce innovation over the long haul.
RFP and contract examples
This page will be regularly updated with new RFP and contract examples.
Transit Authority of River City (Louisville, KY), 2021: Released an RFP for Next Generation Mobile Ticketing Application graded mobile ticketing vendors on their “ability for third party applications such as Google Maps, Apple Maps, Transit App,Citymapper, TNCs to offer TARCmobile tickets in their app via an API or SDK” (see page 12 of RFP)
Metro Transit (St. Louis), 2021: An RFP for Electronic Fare Collection Systems asked vendors to “describe how their SDK/API can be used to integrate with 3rd Party MaaS applications” (see page 28 of RFP)
Metro Transit (Twin Cities, MN), 2020: An 2020 RFP for a Metro Transit Mobile App required that any vendor’s “mobile ticketing solution must offer the ability to sell tickets in non-Metro Transit apps, including but not limited to Google, Transit App, etc. via ticketing API.”
Greater Dayton RTA (Dayton, OH), 2018: The Greater Dayton Regional Transit Authority structured its entire mobile ticketing RFP as a request for fare payment within a chosen MaaS app, highlighting Key goals for the new FPS including “providing an open and nonproprietary architecture.”
Roaring Fork Transportation Authority (Aspen, CO), 2020: RFTA highlighted their desire for ticketing integration into Transit App by name. “RFTA seeks options to integrate the APP with Transit App which already is used for passenger information, trip planning, real-time predictions and service bulletins and WE-CYCLE bicycle reservations” (see page 15 of RFP)
Alameda County Transit (East Bay, CA), 2019: AC Transit put out an RFP for a Mobile Ticketing Application. The scope of work included “Ability for third party applications such as Google Maps, Apple Maps, TransitApp, Citymapper, TNCs to offer AC Transit mobile tickets in their app via an APIor SDK” (see page 10 of RFP)
Central Ohio Transit Authority (Columbus, OH), 2020: COTA put out an RFP for a fare collection system, the Central Ohio Transit Authority asked vendors to “describe any planned or existing integrations you have with other transportation options including integrations with trip planners, Transportation Network Companies (TNCs) such as Lyft and Uber, and bike sharing companies.”