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.

55 Models and Emerging Trends This chapter synthesizes the findings from the survey and case examples to present different business models and technical approaches to mobile fare payment apps. The chapter is divided into three sections. The first section summarizes the different business models for implementing mobile fare payment apps and compares them along different dimensions. The second section discusses another emerging trend related to mobile fare payment apps, and the last section provides a summary of this chapter. Models for Mobile Fare Payment Apps The business models are divided into five overarching approaches. For each model, different dimensions are discussed. They include (1) a case example from the previous chapter using this approach, (2) the typical size of the transit agency selecting this approach, (3) the level of configuration or customization of the app, (4) time to deployment, (5) the typical costs, (6) the method of validation, and (7) the level of integration with the preexisting fare payment system. Table 4 compares the mobile fare payment app business models. Model 1: Shared App The first model can be described as a shared app. In this model, the same app is used by many transit agencies in different regions that contract the same vendor to provide the app; the app name remains the same across all regions. After downloading the app, users select the agency where they will purchase fare products. Because of its multiregional, shared nature, this model is referred to as a shared app. The case example from Chapter 4 that best fits this model is the City of Santa Monica’s Big Blue Bus. This agency contracts with the company Token Transit to provide a shared app. Based on the survey results from Chapter 3, it appears that this model caters to smaller and medium- sized transit agencies with lower levels of ridership and smaller numbers of agency staff. In this model, the vendor adds new transit agencies by configuring a few settings in an exist- ing mobile fare payment app, such as the agency’s specific fare types and some agency branding, such as the agency’s logo and a few images of local landmarks. No customization is required. Because only configuration (not customization) is required to deploy a shared app, the time frame for a transit agency to launch a share mobile fare payment app can be as short as a few days. However, because of training and marketing considerations, the time frame is likely to be at least a few weeks. In terms of costs, upfront costs are low or minimal to acquire a shared app. The vendor is instead paid on an ongoing basis, typically as a percentage of sales based on fare value. C H A P T E R 5

56 Business Models for Mobile Fare Apps For validation, this model relies heavily on transit agency staff to perform validation by visual inspection. Bus drivers can do this as passengers board the transit vehicle, conductors can do this on board trains, or roving inspectors can do this in proof-of-payment systems. A shared app functions as stand-alone fare payment system and is typically not integrated with a preexisting fare collection system at each transit property. Similarly, this type of app is not integrated with preexisting regional fare payment systems and, therefore, transfer policies are typically not accommodated. However, the shared app model provides the same app to dozens of transit agencies, and therefore, interoperability is available to a certain extent across regions. Model 2: White Label App This second model can be described as white label because this term is commonly used to refer to a product made by one company that is rebranded to appear as if it were made by another company or organi- zation. In this case, the vendor provides a mobile fare payment app that can be rebranded in numerous ways—including the app name— to appear as if the transit agency developed the app. The case example from Chapter 4 that best fits this model is Denver’s RTD; this agency contracts with the company Masabi for a white label app. A white label app can be configured in numerous ways, including the name of the app and agency branding throughout the app. Specific fare types are configured, and other transit-related White Label: A product made by a company that is rebranded to appear as if it were made by another company (or transit agency). Model/ Characteristic Model 1: Shared App Model 2: White Label App Model 3: White Label App With Validation Hardware Model 4: Open Payment App Model 5: SDK Only Case Example Big Blue Bus RTD CapMetro CTA St. Catharines Level of App Configuration or Customization Configuration typically only for fare types and some agency branding; no customization Configuration for fare types and additional agency branding; typically no customization Configuration for fare types and additional agency branding; customization for hardware Some customization Does not apply Costs (Upfront and Ongoing) Typically no upfront costs; ongoing costs usually paid as a percentage of sales Typically limited upfront costs; ongoing costs usually paid as a percentage of sales Higher upfront costs; ongoing costs may be paid in numerous ways (e.g., periodic fixed fees) Higher upfront and ongoing costs Limited upfront costs; ongoing costs paid as a periodic fixed fee or possibly as percentage of sales Validation Process and Technology Primarily visual validation Primarily visual validation; QR Codes/barcodes as secondary method using inspector app or handheld devices Visual validation and QR Codes/barcodes integrated with validation hardware on vehicles Multiple methods, including NFC tapped at validators Primarily visual validation Integration with Preexisting Fare Payment System None None Some backend and/or hardware integration Full integration with account- based, open payment system None Table 4. Comparison of mobile fare payment app business models.

Models and Emerging Trends 57 features such as schedules or trip planning are potentially accessible, possibly through web links. Usually no customization is required if this is a stand-alone system. If there is no customization, the time frame to deploy a white label mobile fare payment app can be relatively short. This is likely to take a few weeks to a few months, depending on the specific features of the mobile fare payment app system. There may be some upfront costs; how- ever, these are likely relatively small. Most of the costs are paid on an ongoing basis and are most likely to be paid as a percentage of sales or a flat fee per transaction. This model relies heavily on visual validation done by drivers, conductors, or inspectors. However, there may also be a secondary mechanism for fare validation. For example, QR Codes or barcodes may be available in the mobile fare payment app; these are then validated by transit agency staff using another smartphone with an inspection app or using other handheld devices. This model is typically not integrated with the transit agency’s preexisting fare payment system and, therefore, operates as a stand-alone system. Model 3: White Label App with Validation Hardware Similar to the previous one, this model is based on a white label mobile fare payment app. However, the key difference is some form of hardware to enable different forms of validation. The case example from Chapter 4 that best fits this model is Austin’s CapMetro; this agency contracts with the company Bytemark and is transitioning to its white label mobile fare payment app. This arrangement includes an additional vendor to provide hardware, which is installed on some transit vehicles. Based on the survey results from Chapter 3, this model is typically used by larger transit agencies with higher levels of ridership. This model typically requires at least some customization of different elements of the system (particularly hardware). Therefore, the time frame to deployment is likely to be longer. Similarly, there are likely to be upfront costs associated with hardware and potentially higher ongoing costs. Validation can be done in multiple ways. Visual validation is available for transit routes without hardware. On transit routes with hardware, validation is usually done by scanning a QR Code or barcode on a reader installed in transit vehicles or at fare gates. This system is unlikely to be integrated with the agency’s preexisting fare payment system; however, integration is possible. Unlike the previous two models, based on the survey results there appears to be less consistency between transit agencies employing this approach. Model 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 then be loaded into mobile wallets (e.g., Apple Pay, Google Pay) using virtual cards. The case example from Chapter 4 that fits this model is Chicago’s CTA; this agency contracts with the vendor Cubic to provide an open payment, account-based fare payment system. Based on the survey results from Chapter 3, this model is only being used by a small number of transit agencies with relatively high levels of ridership. This model is still emerging, and therefore, at this time, customization may be needed to deploy an open payment app. Similarly, deployment Mobile Wallet: An application that stores payment card information on a mobile device and can be used to make purchases. Examples include Apple Pay, Google Pay, and Samsung Pay.

58 Business Models for Mobile Fare Apps times are likely to be longer and costs may be higher. However, if this model is adopted by more transit agencies in the future, it is likely that levels of customization, deployment time frames, and costs will decrease. Fare products can be validated in different ways, such as tapping NFC on the user’s smartphone at readers. Because this app is by definition part of an account-based open payment system, it should be fully integrated into the transit agency’s broader fare payment system. Model 5: SDK Only The last model can be categorized as SDK only, in which the transit agency hires a mobile fare payment app vendor to provide an SDK. An SDK is a set of tools, libraries, documentation, code samples, or guides that allow developers to create applications; typically, SDKs contain one or more APIs. Then, the mobile fare payment SDK can be integrated into other smartphone apps, such as those for real-time information or ridesourcing. The case example from Chapter 4 that best fits this model is St. Catharines Transit Commission; this agency has partnered with the companies Transit and Masabi for a real-time information app and a fare payment SDK, respectively. It should be noted that no other transit agencies that responded to the survey presented in Chapter 3 were using this model; however, this appears to be an emerging approach that could be used by small, medium, or large transit agencies. Because this model focuses on an SDK only, the level of customization for incorporating that SDK into another app was not investigated in detail. However, as SDKs become increasingly common, it is likely that this approach will require less customization. Similarly, it is likely that deployment times will be shorter once this approach becomes more common. There may be some upfront costs; however, these are likely to be relatively small. Most of the costs are paid on an ongoing basis, which could be through a fixed recurring fee (like St. Catharines Transit Commission) or potentially as either a percentage of sales or a flat fee per transaction in the future. This model currently relies on visual validation by drivers, conductors, or inspectors. Last, this approach is typically not integrated with the transit agency’s preexisting fare payment system. Comparison and Discussion of Models This section presents a brief comparison of the five models for deploying mobile fare payment apps in Table 4. The models are compared for the following characteristics: (1) case example with each model, (2) level of customization of the app, (3) costs, (4) validation process and technology, and (5) integration with an agency’s existing fare payment system. It is important to note that these characteristics have been generalized and may vary from case to case. Moreover, given the rapidly changing nature of mobile fare payment apps, they are likely to change in the future as the market continues to evolve. Last, it should be noted that there are other possible models that were not discussed in detail here. One potential model not discussed in this chapter is a fully customized app. In this addi- tional potential model, a mobile fare payment app could be designed and built to meet specific requirements defined by a transit agency, and any level of customization would possible. However, custom apps are likely to have longer deployment time frames and higher upfront and ongoing costs. Because they are custom built, these apps could utilize any form of validation

Models and Emerging Trends 59 (visual, QR Codes or barcodes, NFC, or Bluetooth). Similarly, they could have varying levels of integration with the transit agency’s preexisting fare payment system. This model seems to be less frequently used in the transit industry; few transit agencies that completed the survey summarized in Chapter 3 and case examples in Chapter 4 had customized apps. Therefore, this model is not presented in detail. Emerging Trend There is another noteworthy trend that is occurring with mobile fare payment apps. Over the past decade, transit agencies have increasingly provided riders with web-based or smartphone applications for trip planning, real-time vehicle location information, transit service alerts, or other similar tools. However, this is often done by creating separate apps, each with different functionality. Transit agencies are now begin- ning to integrate fare payments into these commonly used tools. In a step toward mobility as a service (MaaS), transit fare payments are also being integrated into other app-based transportation services, such as ridesourcing services. This section presents three different approaches to integrating mobile fare payments into other apps, beginning with the least complex. Deep Link A simple and commonly used form of integration between smartphone apps is known as a deep link. A deep link allows app users to navigate from one smartphone application to another. Because smartphone apps do not use URLs like websites do, another method is needed to link between specific locations in smartphone apps. Deep links are similar and typically use a uniform resource identifier (URI) to find a specific location in another app. An example is shown in Figure 46. This figure shows the multicity transit information app called OneBusAway, which has a deep link for mobile fare payments. If a user clicks on the “Pay my fare” icon (highlighted in red), he or she will be directed to a mobile fare payment app. In the case of the Seattle instance of OneBusAway, the deep link sends the user to Bytemark’s mobile fare payment app called Transit GO Ticket. If the user has this app installed on his or her phone, it will automatically open. If not, the user will be directed to an app store such as Google Play to download it (as shown in Figure 46). Application Programming Interface The next approach uses an API to integrate fare payments into other apps. APIs are sets of communication protocols that can be used to build software tools and enable applications to “talk” with one another. An example of a mobile fare payments API was discussed in Chapter 4 in the case of Big Blue Bus. The City of Santa Monica’s Big Blue Bus has an ongoing contract with its app developer Token Transit to create an API, which will soon be integrated in the widely used transit information app simply known as Transit for use in Santa Monica. Mobility as a Service: Mobility consumed as a service instead of using personally owned modes. It may be provided by public or private operators, ideally through a unified gateway to order, manage, and pay for trips. Deep Link: A method to help users navi- gate between apps. A uniform resource identifier is often used to link to a spe- cific location outside an app. Application Programming Interface: A set of protocols or tools for building software applications.

60 Business Models for Mobile Fare Apps Software Development Kit The third option that is being used in the transit industry to integrate mobile fare payments into other apps is known as an SDK. This approach builds on the previous one because it usually includes one or more APIs. SDKs may also include other tools, libraries, code samples, or documentation to help developers create and integrate apps. An example of a mobile fare payment SDK was discussed in Chap- ter 4 for the Denver RTD. The transit agency’s app developer Masabi has an SDK that was used to integrate transit fare payments into the Uber app. This means that Uber users in the Denver metro- politan region can purchase their RTD tickets directly in Uber’s smartphone app. Mobile fare payment SDKs were also discussed in detail in Chapter 4 for the case example of St. Catharines Transit Commission. Last, it is worth noting that SDKs are also being used in the state of Ohio by a consortium of seven transit agencies known as NEORide. Overarching Business Models This section provides a brief summary of the models presented in this chapter. Five over- arching business models for mobile fare payment apps were identified, and these can be summarized in the following manner: 1. Shared App: In the 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. 2. White Label App: This model is referred to as a white label app because the app is developed by a vendor but rebranded to look as if it were made by the transit agency. A white label is rela- tively quick to deploy, comparatively low cost, and allows for configuration including specific Figure 46. OneBusAway deep link to a mobile fare payment app. Red lines added for emphasis. Software Development Kit: A set of tools, libraries, documentation, code samples, or guides that allow developers to create applications. Typically, SDKs contain one or more APIs.

Models and Emerging Trends 61 fare types and agency branding. When offered as a stand-alone system, white labels apps are usually not integrated with preexisting fare payment systems and typically rely only on visual inspection for fare validation. 3. White Label App with Validation Hardware: This model is similar to the previous one, except it also includes validation hardware, 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. 4. Open Payment App: This model applies to fare payment systems that are both standards- based 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, 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 CTA is the case example for this model. 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 appears to have relatively low costs (both upfront and ongoing). Validation is done visually by drivers, and there is typically no integration with the transit agency’s preexisting fare payment system. Another noteworthy trend pertaining to mobile fare payment apps 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) APIs, which are a set of communication pro- tocols for building software applications; or (3) SDKs, which include APIs as well as additional libraries, documentation, or tools.