Business Models for Mobile Fare Apps (2020)

Below is the uncorrected machine-read text of this chapter, intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text of each book. Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.

1 A rapidly evolving area in the public transit industry is fare payment systems. One increasingly common component of new fare payment systems is a passenger-facing mobile fare payment application (or app). A mobile fare payment app refers to a software application on a smartphone or other portable electronic device such as a tablet that allows transit riders to pay for and access public transit services. These software applications are typically downloaded onto the user’s device from Google Play for Android devices or the Apple App Store for iOS (Apple’s mobile operating system) devices. Over the last decade, the number of transit agencies in the United States and Canada offering mobile fare payment apps to riders has rapidly grown, and many agencies are employing different business models with varying costs. In light of this, the objective of this study was to synthesize different business models for mobile fare payment apps used by American and Canadian transit agencies. The scope of this study included various aspects of the business arrangements accompanying mobile fare payment apps, such as the role of vendors in developing and maintaining apps, the upfront and ongoing costs, the procurement process, and integration both within a transit system’s fare payment system and with other transit operators. To meet the objectives, a three-part methodology was used. First, a review of prior literature pertaining to mobile fare payment apps was conducted. Second, an e-mail survey of transit agencies and operators that have mobile fare payment apps in the United States and Canada was conducted. The survey included more than 60 questions on various business and technology-related topics, and a total of 62 responses were received and analyzed. Third, detailed case examples were collected via telephone interviews with representatives from six transit agencies. The agencies selected for the case examples have different approaches to mobile fare payment apps, and their approaches were compared and categorized to identify different business models. Key findings from the survey, case examples, and different business models are described in the following paragraphs. Noteworthy results from the survey of transit agencies were as follows: • The first mobile fare payment app was deployed in the United States in 2011. Most agencies have made their mobile fare payment app available to the public within the last 5 years, suggesting that this is a new and rapidly growing trend in the transit industry. • The primary reasons that agencies deploy mobile fare payment apps include improving the customer experience, reducing cash handling, and decreasing the cost of fare collection. • The platforms used for mobile fare payments are Android and iOS; all transit agencies that responded to the survey have mobile fare payment apps on both platforms. • Adoption of mobile fare payment apps varies by transit mode. Many agencies that provide bus, light rail, commuter rail, or ferry service have mobile fare payment apps. However, S U M M A R Y Business Models for Mobile Fare Apps

2 Business Models for Mobile Fare Apps there are few examples of heavy rail services that offer mobile fare payment apps; this is likely due to the validation process, which is typically done via fare gates on heavy rail systems. • The primary method for validating fare products purchased through mobile fare pay- ment apps is visual validation by a conductor, inspector, or driver. Additional methods of validation may be done using Quick Response (QR) Codes or barcodes. There is limited use of Bluetooth or near field communication (NFC) technology for fare validation at this time. • Transit agencies hire outside vendors to develop and maintain apps; in-house transit agency staff is usually not responsible for software development. A handful of companies (5 or 6) have most of the mobile fare payment app development market in the United States and Canada. • Many agencies (58%) deploy mobile fare payment apps in business arrangements that do not have any upfront costs; instead, these agencies typically pay their vendor based on a percentage of sales. • Some transit agencies procured mobile fare payment apps from vendors with preexisting apps that could be quickly and easily configured, such as to provide specific fare types. Others have procured apps that require additional configuration, particularly to include agency branding. A smaller number of agencies procured apps that required significant customization and software development. • In terms of roles, most vendors have the primary responsibility for app development, payment processing, hosting the mobile fare payment app, and payment card industry (PCI) compliance. Many transit agencies take the lead on customer service and marketing to riders. Important findings from the case examples are summarized as follows. 1. Big Blue Bus in Santa Monica, California: This agency contracts a vendor to provide a mobile fare payment app that is used in dozens of other American cities and pays the vendor as a percentage of fare sales. Although the customer experience has been positive, payment via the mobile app makes up only a small percentage of all fare revenues, likely because of a lack of regional integration. 2. Regional Transportation District in Denver, Colorado: This agency contracts a vendor to provide a white label app that has been rebranded. The vendor was paid a small upfront fee and continues to be paid on an ongoing basis as a percentage of fare sales. The mobile fare payment app is stand-alone in that it has not integrated into this agency’s preexisting fare payment system; however, mobile fare payments are integrated into other smartphone apps such as Uber. 3. Capital Metropolitan Transportation Authority in Austin, Texas: As an early adopter of mobile fare payment apps, this agency initially contracted a vendor for an app that required significant customization; however, the agency is currently transitioning to a white label app provided by the same vendor. A noteworthy feature is that readers have been installed on some transit vehicles enabling riders to scan a barcode in the mobile fare payment app for validation. Another vendor was needed to support the validation hardware, which had additional costs. 4. Dallas Area Rapid Transit in Dallas, Texas: This agency initially had a customized app; however, the transit agency has transitioned to a white label version of the app from the same vendor. The app is part of an account-based system that functions separately from the agency’s tap card account-based fare payment system. Two noteworthy features of the mobile fare payment app are (1) fare capping and (2) the ability to load cash into mobile fare payment app accounts at a network of local retailers.

Summary 3 5. Chicago Transit Authority in Chicago, Illinois: This agency has an open payment, account-based fare payment system (accepts payment media such as bankcards), which includes a mobile fare payment app. The app is primarily for account management; however, a pending update will enable transit payments using a virtual transit card in Apple Wallet. The transit agency paid large upfront costs for the initial account-based, open payment system, and the app was added later via an amendment to the original contract. Notably, this app is part of an integrated system shared by two other regional transit agencies (the commuter railroad and the suburban bus system). The app, however, functions differently on the nearby commuter railroad. 6. St. Catharines Transit Commission in Ontario, Canada: This agency used the approach in which a mobile fare payment app vendor’s software development kit (SDK) was integrated into a widely used real-time information app. The transit agency paid small upfront costs and nominal monthly maintenance fees to the mobile fare payment SDK vendor; the main mechanism for payment is via a percentage of fare sales. Validation is done visually by drivers, and there is no integration with the agency’s preexisting fare payment system. Based on the results of the survey and case examples, five different business models were identified. These are briefly summarized as follows. 1. Shared App: In a shared app model, multiple transit agencies in different regions use the same mobile fare payment app provided by a single vendor. This model is quick to implement and low in cost; a shared app can be configured in a few days to add specific fare types and some limited agency branding. However, this model typically does not include integration with preexisting fare payment systems, and validation of fares is typically done only by visual inspection. The case example for this model is the City of Santa Monica’s Big Blue Bus. 2. White Label App: This model is referred to as “white label” because the app is developed by a vendor but rebranded to look as if it were made by the transit agency. A white label app is relatively quick to deploy, comparatively low cost, and allows for configuration including specific fare types and some agency branding. When offered as a stand-alone system, white label apps are usually not integrated with preexisting fare payment systems, and they typically rely only on visual inspection for fare validation. Denver’s Regional Transportation District is the case example of this model. 3. White Label App with Validation Hardware: This model is similar to the previous one, except it also includes hardware for validation, such as readers installed on transit vehicles. An additional vendor is typically part of the contractual process to facilitate hardware installation and integration. The costs are usually higher, and the deployment time may be longer. The case example for this model is Austin’s Capital Metropolitan Transportation Authority. 4. Open Payment App: This model applies to fare payment systems that are both standards- based (commonly called open payment) and account-based. Riders download the transit agency’s mobile fare payment app, which can be used to manage transit accounts by reloading value or purchasing passes. Transit accounts can be loaded into mobile wallets (e.g., Apple Pay or Google Pay) using virtual cards. Fare products can be validated in different ways, such as tapping NFC on the user’s phone at readers. Because this is still an emerging model and is usually part of a fully integrated system, costs are currently high; however, this could change in the future if other agencies adopt this model. The Chicago Transit Authority is the case example. 5. SDK Only: The last model is an “SDK only” approach in which only an SDK is procured from a mobile fare payment app vendor. Then, the SDK can be integrated into other smartphone apps, such as real-time information or ridesourcing apps. This model

4 Business Models for Mobile Fare Apps appears to have relatively low costs (both upfront and ongoing). Validation is done visually by drivers, and there is typically limited integration with the transit agency’s preexisting fare payment system. St. Catharines Transit Commission is the case example of this model. Another trend pertaining to mobile fare payment apps that was also identified is increased integration with other smartphone apps, such as real-time transit information or ridesourcing services. This is typically done using one of the following three methods: (1) deep links between applications, in which one app redirects users to another app, (2) application programming interfaces (APIs), which are sets of communication protocols for building software applications, or (3) SDKs, which include APIs as well as additional libraries, documentation, or tools. This study reports the state of mobile fare payment app business models within the United States and Canada, which is a rapidly developing area. Because of the significant changes that have happened in the last 5 years, it is anticipated that these models will con- tinue to evolve in both the short term and long term. Perhaps the most important lesson learned is for transit agencies to consider nimble approaches to mobile fare payment apps that enable them to adapt to future changes.