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.

30 This chapter presents the results of the six case examples. Information for the six case examples was gathered from phone interviews conducted with staff at each transit agency. These were semistructured interviews, and the list of questions used to guide the dis cussion can be found in Appendix C. The results of each case example include a description of the agency’s mobile fare payment app, an explanation of the launch time frame and procurement process, and a discussion of vendor roles and responsibilities. Additionally, integration with the agency’s existing fare payment system, regional integration, and integration with other apps are discussed. Finally, a summary and lessons learned are presented for each case. Big Blue Bus The first case example is the City of Santa Monica’s Big Blue Bus, which is a subregional transit property that serves the west side of Los Angeles County in California. The agency provides local bus service, bus rapid transit, and demand-responsive transportation services in Santa Monica and some neighborhoods of Los Angeles. The 2017 National Transit Database (NTD) agency profile and the logo for Big Blue Bus are shown in Figure 19. App Description The mobile fare payment app used by Big Blue Bus is provided by the company Token Transit, and the app has the same name as the vendor. This app is used by many small-sized and medium-sized transit agencies nationwide. After downloading the app, users select the agency where they will purchase tickets (see Figure 20). Users can go to the settings tab of the app at any time to change agencies, such as if they are traveling to another region that also provides passes in the Token Transit app. Because of its multiregional nature, it will be referred to as a shared app. The Token Transit app is available on both the Android and iOS platforms. The Token Transit app includes all fare types offered by Big Blue Bus, such as single ride tickets, period passes, and reduced fares. However, the app does not provide transfers to other services in the Los Angeles region, which will be discussed in more detail later. The app can be used on all bus services provided by Big Blue Bus. To use the app, riders select a pass to purchase and charge their credit or debit card (as shown in the left screen of Figure 21). When users are ready to ride Big Blue Bus, they can select a pass to use (as shown in the middle screen of Figure 21) and then activate a pass to show the driver when boarding the bus (shown on the right screen of Figure 21). To activate a mobile ticket, the rider’s phone must be online (e.g., have an active cellular network or Wi-Fi connection). C H A P T E R 4 Case Examples

Case Examples 31 At the time of this writing, the only mechanism for fare validation used by Big Blue Bus was visual validation. The ticket screen has numerous security features, including dynamic animations, a clock, and a color that changes each day to protect against fraudulent tickets via screenshots. Timeline and Procurement Big Blue Bus initially considered a mobile fare payment app in 2016. After preliminary dis- cussions with the company Token Transit, the agency decided to launch a pilot program in 2017. It was the fourth transit agency in the United States to launch with the Token Transit app, and, therefore, the agency thought a pilot program was a good approach to gauge the customer experience. After formalizing the pilot agreement with Token Transit, it only took about 4 weeks to launch. During that time, Token Transit configured the app to include Big Blue Bus images (such as those shown on the right side of Figure 21; Big Blue Bus, 2017) and the local fare types. Training was also conducted, and marketing to passengers was done. This deploy- ment timeline can be considered fast. The pilot program lasted for 12 months, and, over this period, sales via the mobile fare payment app steadily increased to about 2% of Big Blue Bus ridership (and a similar figure in terms of revenue). While this percentage may seem small, the agency viewed it positively because the mobile fare payment app was not integrated with the regional fare payment system Annual Passenger Miles: 50,860,741 Annual Revenue Miles: 5,032,641 Annual Unlinked Trips: 13,356,740 Vehicles Operated in Maximum Service: 168 Source: NTD, 2017 Figure 19. Big Blue Bus logo and NTD agency profile. Figure 20. Token Transit Choose Your Agency screen. Figure 21. Screenshots of the Token Transit app used by Big Blue Bus (Source: https://www.bigbluebus.com/Newsroom/News/BBB-Accepts- Mobile-Tickets.aspx).

32 Business Models for Mobile Fare Apps and because Token Transit users reported a positive experience, appreciating the ability to not have to carry cash and to purchase passes anywhere. Based on seasonal and weekend surges in sales and usage, the pass was also popular with tourists visiting Santa Monica. In 2018, Big Blue Bus went through a formal procurement process for a mobile fare payment app. The agency received approximately a dozen responses, which included a wide range of technical features with a large degree of variation in costs. After considering all of the proposals, the agency decided to continue with Token Transit and now has a 3-year-long contract in place. Vendor Roles and Responsibilities Token Transit’s model as a vendor can be considered a shared solution. The app name remains Token Transit, and it is usable in many regions. The app that the vendor provides is largely off-the-shelf and is not customized software. The method for paying the vendor in this case is based on a sub- scription service for “software as a service.” There were no upfront costs for Big Blue Bus; rather, the app development costs are shared over all of the vendor’s customers. Big Blue Bus pays a percentage of its fare sales via the mobile payment app. This percentage (10%) is deducted by the vendor and also covers payment processing fees. The vendor transmits the balance (90%) to the transit agency nearly every business day. The vendor has various roles and responsibilities. The vendor hosts the app and does pay- ment processing. The app vendor also provides Big Blue Bus with a dashboard that can be used for analytics, including monitoring sales and ridership in real time. Customer service is shared between the vendor (particularly for app-related issues) and Big Blue Bus. Marketing to riders is done by the transit agency, which has in-house staff for this purpose. Big Blue Bus recently considered a new feature offered by its vendor that uses Bluetooth beacons for validation; however, given the relatively small percentage of mobile fare payment app users, the agency decided that the benefits did not outweigh the costs. At the time of writing, the only method of validation continued to be visual inspection. Integration with Existing Fare Payment System Big Blue Bus’s mobile fare payment app is not integrated with the rest of its fare collection system. Rather, it is a stand-alone system that is viewed by the agency as an added convenience for its customers. Integration with Regional Fare Payment Systems Perhaps one of the biggest challenges with Big Blue Bus’s current mobile fare payment app is the lack of integration with the regional fare payment system in Los Angeles. Big Blue Bus is a partner in Los Angeles Metro’s Transit Access Pass (TAP) Card system, which is a regional smart card system that allows customers to transfer between transit services throughout the region. This system will likely include a regional mobile fare product in the future. However, this could take a number of years to implement and, at the time of writing, it was unclear what the mobile solution would be. In the meantime, Big Blue Bus launched its own mobile fare payment app as a short-term solution. The agency recognized that until there were integrated regional transfers, it would be likely that the mobile fare payment app would only capture a small percentage of Big Blue Bus’s ridership. Software as a service is a distribution model in which software is accessed online and provided via a subscription, as opposed to bought and installed on individual devices.

Case Examples 33 Integration with Other Apps Big Blue Bus has a noteworthy update to their contract with their app vendor that was in progress at the time of writing. The update was for an API for fare payments. Additionally, Token Transit had a subcontract in place with a company simply known as “Transit,” which provided a widely used real-time transit information app. The agreement between the two companies included integration of the new Token Transit API within the Transit app, enabling Big Blue Bus fare payments directly in the Transit app. Once this feature launched, which was planned for late 2019, Big Blue Bus would pay a monthly licensing fee on top of its existing agreement with its mobile fare app vendor. Example screenshots are shown in Figure 22. Summary and Lessons Learned A brief summary of this case example and a discussion of the lessons learned are as follows: • The mobile fare payment app in this case example was purchased off the shelf without customization. When the transit agency contracted the app vendor, the vendor configured a small number of settings, and the app was deployed within a few weeks. • This case example focuses on a software-as-a-service model, which is relatively new in the transit industry. The transit agency did not pay any upfront costs for app development; instead, the agency pays the vendor a percentage of fare sales on an ongoing basis. • The transit agency initially launched its mobile fare payment app as a 1-year pilot program. Since this agency was an early customer of its vendor, this gave it an opportunity to test the app and assess rider acceptance before entering into a longer-term contractual arrangement. • There is no integration with the regional fare payment system in Los Angeles or the transit agency’s preexisting fare payment system. Instead, this fare payment app is a stand-alone system. This lack of integration—particularly the lack of integrated transfers between regional transit operators—likely contributed to relatively small adoption numbers (approxi- mately 2% of ridership). • Although the mobile fare payment app is not integrated with other operators in the region, this shared app includes numerous other transit agencies. Therefore, if this agency’s riders travel to other regions in the Token Transit app, they are able to use the same app. Figure 22. Example screenshots of Token Transit integration with Transit for Big Blue Bus.

34 Business Models for Mobile Fare Apps Regional Transportation District The second case example is the RTD, which serves the Denver metropolitan area in Colorado. The agency provides bus, light rail, commuter rail, and demand-responsive transportation services. The 2017 NTD agency profile and the logo for RTD are shown in Figure 23. App Description RTD’s mobile fare payment app is known as RTD Mobile Tickets, and it is provided under contract with the app vendor Masabi. It was configured from Masabi’s white label mobile app that is part of the “Justride” platform to have RTD branding throughout the app, as shown in the left and center screens of Figure 24. It was configured for specific fare products and includes most of RTD’s fare policy, such as single-ride tickets, period passes, and reduced fares (see the right screen of Figure 24). In August 2019, an additional low-income fare was incorporated into the app. The app can be used on RTD’s bus, light rail, and commuter rail services. The RTD Mobile Tickets app is available on both the Android and iOS platforms. This mobile fare payment app functions similarly to the one discussed in the previous example. After down- loading the RTD Mobile Tickets app, riders can select a pass to purchase and then use a credit card, debit card, or Apple Pay to purchase their pass. When users are ready to ride RTD transit services, they need to activate their tickets. Activating a ticket can be done with the user’s smart- phone either online or offline. Annual Passenger Miles: 607,643,381 Annual Revenue Miles: 98,077,504 Annual Unlinked Trips: 329,070 Vehicles Operated in Maximum Service: 1,480 Source: NTD, 2017 Figure 23. RTD logo and NTD agency profile. Figure 24. Screenshots of RTD’s mobile fare payment app.

Case Examples 35 The RTD Mobile Tickets app also provides users with other transit-related tools using web links built into the app. A uniform resource locator (URL), colloquially called a web address, is used to direct the user from the mobile fare payment app to the RTD’s mobile trip planner (shown in Figure 25) and “next ride,” real-time information web-based tool (not shown). These tools open in the web browser on the user’s smartphone; they do not open a native smartphone application. The primary mechanism for validation is visual inspection by RTD staff. This app also has a secondary mechanism for validation, which is a QR Code that can be validated by fare inspection staff. RTD fare inspectors have an inspection app that functions on iOS devices. Timeline and Procurement The vision to provide a mobile fare payment app initially came from senior management at RTD, who wanted to increase convenience for passengers. At the time (2016), a mobile fare payment app was not part of the agency’s electronic fare collection road map, which focused primarily on the agency’s smart card system. RTD went through an internal process in which many stakeholders were engaged to discuss the possibility of a mobile fare payment app; this concluded in 2017, and the RTD began to move forward with a procurement process. During the procurement process, RTD staff recognized that they would likely move away from procuring a custom system; instead, they were interested in an off-the-shelf system or software as a service. The motivation for this was to share the costs with other transit agencies that could be using the same mobile fare payment app platform. Agency staff also recognized that the system they procured would be based on some sort of revenue-sharing payment model, since there were not significant funds available to cover upfront costs. After putting out an RFP for a mobile fare payment app, RTD received approximately a half dozen responses. It selected the vendor Masabi and awarded this mobile fare payment app vendor a 5-year contract. A notice to proceed was issued in 2017, and it took approximately 6 months to prepare for the launch of the mobile fare payment app. During this time, RTD staff were trained for inspection and customer service, and the vendor configured its white label app for RTD. The vendor provided the agency with a configuration worksheet, which meant that only certain items could be changed within the app, such as the purchase flow, agency branding, disclaimers, and fare product names. Approximately 6 months later, in November 2017, the mobile fare payment app went live in a “soft” (or “silent”) launch. This meant that RTD did not do a major marketing campaign upfront; only after a few months that showed steady adoption did RTD conduct a marketing campaign. Another component of the RTD’s roll-out strategy was gradually increasing the number of fare products and features available in the mobile fare payment app. The initial 2017 mobile fare payment app only included one fare product: the day pass. RTD needed to make some adjustments to the fare policy so that the single ride products could more easily translate to the mobile platform. After a fare policy update, numerous other fare products were made available in the mobile app, including the single ride (3-hour) ticket and a monthly pass. The agency also gradually launched new features, such as the ability to purchase a ticket in the app using Apple Pay. The agency worked with its vendor to launch an SDK for transit fare payments (discussed more later) that was integrated into Uber’s app. Vendor Roles and Responsibilities The app vendor’s model is based on a white label mobile fare payment app that is used by many other transit agencies in the United States and Europe. White label is a term used to refer Figure 25. RTD’s trip planner.

36 Business Models for Mobile Fare Apps to a product made by one company that is rebranded to appear as if it were made by another company or organization. In this case, the vendor provides a mobile fare payment app that can be rebranded—including the name of the app—to appear as if the transit agency developed the app. In terms of costs, the vendor was paid a relatively small amount for upfront costs (less than $50,000). The primary mechanism for payment is an ongoing percentage of the fare value for each pass sold through the app. The vendor receives a 2.25% commission for every pass sold through its platform. RTD covers some additional ongoing fees, such as credit card fees. This model can be considered software as a service, similar to the previous case example. The app vendor has various roles and responsibilities. The vendor hosts the mobile fare payment app, facilitates payment processing, and is responsible for PCI compliance. The vendor also provides RTD with an inspector app for fare validation, as mentioned in the previous section. As part of its platform, the vendor provides the transit agency with a hub that is used in the back office for customer service, analytics, reporting, and other features (see Figure 26). RTD staff primarily carry out customer service to riders; RTD also does marketing to its customers. Integration with Existing Fare Payment System This mobile fare payment app is not integrated with the rest of the agency’s fare payment system; it is a stand-alone system. Integration with Regional Fare Payment Systems At the time of writing, RTD’s mobile fare payment app was not integrated with other regional fare payment systems. However, there was an effort underway to facilitate integration with a nearby intercity bus service known as the Bustang service that is managed by the Colorado Department of Transportation. The Bustang service has a mobile fare payment app (see Figure 27) procured from the same app vendor used by RTD (Masabi). As can be seen in the two right screens of Figure 27, the Bustang service ticket purchase flow is different from RTD’s app because it has Figure 26. RTD hub including customer services, reports, and analytics.

Case Examples 37 a distance-based fare policy, whereas the RTD has a hybrid fare policy with some flat fares and some distanced-based fares. An ongoing project is planned to enable Bustang riders to also purchase RTD tickets within the Bustang app, since there is a segment of Bustang ridership that often transfers onto RTD service. However, since the RTD app is based on a flat fare and there is a more limited segment of RTD’s riders who use the Bustang service, this is not planned for RTD’s app. Integration with Other Apps One of the unique features of this case example is that RTD tickets could be purchased in other smartphone apps beyond the RTD’s own mobile fare payment app. This was made possible through an SDK that was made available by the RTD’s mobile fare payment app vendor (Masabi). In January 2019, RTD announced that it would partner with its mobile fare payment app vendor and the ridesourcing company Uber to integrate transit trip planning and transit fare payments into Uber’s app, which is shown in Figure 28. The agency did not pay additional fees for this feature, which was launched in May 2019 and was being phased in gradually for Uber app users in the Denver region. Shortly after the Uber integration launched, Masabi’s SDK was also integrated into the smartphone app known as Transit, and it may be used to enable fare payments within other smartphone apps in the future. Summary and Lessons Learned A brief summary of this case example and a discussion of the lessons learned follow: • The mobile fare payment app in this case example can be considered a white label app. When the transit agency contracted the app vendor, numerous settings were configured by the vendor, and the app was deployed within about 6 months. • This case example focuses on a software-as-a-service model, which is relatively new in the transit industry. The transit agency paid a relatively small amount of upfront costs, but the primary mechanism for payment to the vendor is a percentage of fare sales paid on an ongoing basis. • The transit agency initially did a soft launch of its mobile fare payment app without a large marketing campaign; this gave RTD time to update its fare policy. RTD has gradually integrated more of its fare products into the app and added new features over time. Figure 27. Screenshot of the Bustang mobile fare payment app.

38 Business Models for Mobile Fare Apps • There is no integration with the transit agency’s preexisting fare payment system in this example. Instead, this mobile fare payment app is a stand-alone system. • Another transit operator in the Denver region, the Bustang Intercity Bus Service, has a mobile fare payment app with the same vendor; however, the two mobile fare payment apps were not integrated at the time of writing. There were plans to allow Bustang passengers to pur- chase RTD tickets in Bustang’s instance of the mobile fare payment app. • One unique feature of this case example is the use of an SDK to enable mobile fare payments within other apps, such as the ridesourcing service Uber. Capital Metropolitan Transportation Authority The third case example is the Capital Metropolitan Transportation Authority (CapMetro), which serves the Austin metropolitan area in Texas. The agency provides local bus service, express bus service known as MetroRapid, commuter rail, and demand-response transpor- tation services. The 2017 NTD agency profile and the logo for CapMetro are shown in Figure 29. App Description The mobile fare payment app in this case example is called the CapMetro app, and it is provided by the vendor Bytemark. When the app was initially created, it was highly cus- tomized for the transit agency. The app includes fare payment functionality, a trip planner, schedules, maps, and real-time bus information (see left side of Figure 30). The CapMetro app Figure 28. Mobile fare payments in the Uber app in Denver. Annual Passenger Miles: 158,801,665 Annual Revenue Miles: 24,519,732 Annual Unlinked Trips: 29,779,395 Vehicles Operated in Maximum Service: 751 Source: NTD, 2017 Figure 29. CapMetro logo and NTD agency profile.

Case Examples 39 can be used to purchase tickets for local bus service, express bus service, commuter rail, demand- response services, and multimodal services (see middle of Figure 30), and most fare products are available through the app, including period passes, multiple ride fares, and reduced fares (see right side of Figure 30). The CapMetro app is available on both the Android and iOS platforms. The primary mechanism for validation of tickets purchased through the CapMetro app is visual inspec- tion by the transit vehicle operators (see top of Figure 31). There are two additional mecha- nisms for validation. The first is QR Codes that can be scanned by fare inspectors using a handheld device, which is primarily done on the commuter rail service (see middle of Figure 31). Figure 30. Screenshots of CapMetro app. Figure 31. Different methods of validation at CapMetro.

40 Business Models for Mobile Fare Apps The second is by scanning QR Codes at onboard electronic validators; these devices are installed on the rapid bus service known as MetroRapid (see bottom of Figure 31). At the time of writing, CapMetro was in the process of installing validators across the rest of its fleet. Timeline and Procurement CapMetro was an early adopter of mobile fare payment apps. In 2012, the transit agency decided to conduct a pilot program for a mobile fare payment app, which was made available for the Formula One Racing event that occurred in Austin in the fall of 2012. This small-scale pilot yielded positive feedback from users, which led the transit agency to pursue a mobile fare payment app in a formal procurement process. Shortly thereafter, CapMetro issued an RFP including a mobile fare payment app with integrated trip-related tools, such as trip planning, as well as other related systems, including a back-office system and handheld devices for validating tickets. In May 2013, the transit agency selected Bytemark as their primary vendor. Bytemark included the company INIT as a subcontractor to provide ticket validators for MetroRapid (express bus) vehicles. In total, the contract was for a 6-year period and summed up to approximately $1.75 million, including both upfront costs and recurring annual fees. After awarding the contract, the transit agency worked closely with its vendors during the development process, and the app was largely custom-built for CapMetro, since there were few existing mobile fare payment apps at the time. In January 2014, the CapMetro app was launched systemwide. In 2019, CapMetro was in the process of migrating to a new version of the app, which was based on Bytemark’s white label app. Vendor Roles and Responsibilities The prime vendor, Bytemark, initially provided a highly customized app to CapMetro. How- ever, this was largely because there were few preexisting mobile fare payment apps at the time. At the time of this writing, CapMetro was in the process of transitioning to the same vendor’s white label app. The white label app will continue to be branded for CapMetro, include their specific fare products, and have all other preexisting features integrated within the app. The initial procurement in 2013 was for $1.75 million, which included recurring annual fees over the 6-year contract life. These costs included custom app development and ongoing maintenance. In addition, the transit agency pays ongoing licensing fees and a flat fee for each transaction conducted using the mobile fare payment app. Since the 6-year contract was expir- ing, the transit agency was renegotiating with their vendors. The primary app vendor has various roles and responsibilities. The vendor hosts the mobile fare payment app, facilitates payment processing, and is responsible for PCI compliance. The vendor and its subcontractor (INIT) also provide the transit agency with validators installed on rapid bus routes to scan tickets, as well as handheld devices to scan QR Codes in the app for ticket inspection. As part of their platform, the app vendor provides the transit agency with a back-office system. The back-office system has typical reporting and analytics features; it can also be used for bulk purchases for large customers (e.g., employer programs). The app vendor also performs app-related customer service. Transit agency staff have the primary responsibility for marketing to customers. Two other vendors also contribute to the mobile fare payment app system. The company HaCon provides the engine for the trip planning feature in the mobile fare payment app, and the company Swiftly is responsible for providing an API with real-time transit vehicle location information.

Case Examples 41 Integration with Existing Fare Payment System The existing fare system comprises multiple, separate components. This includes Gen- fare fareboxes on buses for payment with magnetic strip tickets, stand-alone validators (see Figure 32) for the mobile fare payment app on buses (rapid service only), and fare vending machines for the rail service. The components of the fare system function separately and have different back-office systems; however, the transit agency was in the process of developing a long-term strategy to better inte- grate systems in the future. Integration with Regional Fare Payment Systems The mobile fare payment app in this case example is only used on the CapMetro transit system. The app is not integrated with any other transit operators in Texas. Integration with Other Apps CapMetro’s vendor, Bytemark, provides an API for fare payments to trusted partners. At the time of writing, efforts were underway to integrate the fare payment API into the app called Transit and Via Transportation. It should also be noted that APIs are integrated into the CapMetro app for trip planning (from HaCon) and real-time information (from Swiftly). Summary and Lessons Learned A brief summary of this case example and some lessons learned follow: • The mobile fare payment app in this case example was initially created as a custom app for the transit agency; however, the transit agency was an early adopter of mobile fare payment apps. At the time of writing, the agency was transitioning to a white label app that is avail- able from the same app vendor. Figure 32. Validators on MetroRapid, 2017.

42 Business Models for Mobile Fare Apps • The app vendor has a subcontract with another company to provide hardware used for validation on vehicles. At the time of writing, this system had limited integration with the rest of the agency’s fare payment system. • One unique feature in this case example is that two additional vendors provided APIs that were integrated into the mobile fare payment app. These APIs are used to provide (1) trip planning and (2) real-time vehicle location information. Dallas Area Rapid Transit The next case example is Dallas Area Rapid Transit (DART), which serves the Dallas metro- politan area in Texas. The agency provides bus, light rail, streetcar, commuter rail, and demand- responsive transportation services. The 2017 NTD agency profile and the logo for DART are shown in Figure 33. App Description DART’s mobile fare payment app is called GoPass, and it is provided under contract by the app developer Unwire. The app includes fare payment functionality, a trip planner, and system maps (see Figure 34). GoPass can be used to purchase tickets for bus service, light rail, streetcar, commuter rail, and demand-responsive transportation services. Most fare products are available through the GoPass app, including single ride tickets that are good for 2 hours (see right screenshot in Figure 34), period passes, and reduced fares. DART recently began offering daily and monthly fare capping through GoPass; this means that an app user will never spend more than the total cost of a day pass in a single day or the total cost of a monthly pass in a calendar month. University and corporate pass products are also offered through the mobile fare payment app. GoPass is available on both the Android and iOS platforms. This mobile fare payment app functions similar to the ones discussed in the previous examples. After downloading the GoPass app, riders can select “Buy Tickets” and then use a credit card, debit card, Apple Pay, or Google Pay to purchase their pass. Additionally, users can load value into their transit account using cash at a network of local retailers; this is provided in partnership with the company PayNearMe to facilitate app usage by customers who cannot or do not want to use a credit card or debit card (see Figure 35). When users are ready to ride DART transit services, they need to activate their tickets. Activating a ticket can be done either online or offline. The primary mechanism for validation is visual inspection by transit agency staff. Timeline and Procurement In 2012, due to high entry costs for smart card systems, DART decided to pursue a mobile fare payment app and released an RFP. Annual Passenger Miles: 432,887,920 Annual Revenue Miles: 50,310,657 Annual Unlinked Trips: 65,583,009 Vehicles Operated in Maximum Service: 1,061 Source: NTD, 2017 Figure 33. DART logo and NTD agency profile. Fare Capping: The transit agency caps the maximum amount a rider can pay in a given period. For daily capping, riders never pay more than the total cost of a day pass.

Case Examples 43 The agency received four responses to the RFP. After considering the responses from various potential vendors, the transit agency selected the European company Unwire to be its mobile fare payment app developer. One of the primary reasons for this selection was that Unwire had a payment solution that was already in revenue service elsewhere. The transit agency and vendor moved forward with app development, and the first version of the GoPass app was deployed systemwide in September 2013. In 2016, DART moved forward with deploying a new version of the GoPass app that would be based on Unwire’s white label product. In May 2018, DART and its mobile fare payment app vendor launched GoPass 2.0. This version of the app included the ability to load cash to the app through the PayNearMe retail network. Shortly thereafter, in August 2018, DART introduced fare capping through the app. More recently, GoPass version 3.0 was made available to the public in March 2019. Many of the latest enhancements in the GoPass app were funded through the FTA Mobility on Demand Sandbox Program, which is an FTA initiative to facilitate integrated, multimodal, personalized mobility systems. The latest version of the app includes a deep link to the Uber app and the ability to find nearby e-scooters directly in the GoPass app. These features will be discussed in more detail later. At the time of writing, the GoPass app was widely used by transit customers. DART estimated that roughly 27% of all fare revenue was collected through the GoPass app. Moreover, the transit agency has a “roadmap” to look toward the future and keep the app relevant. Vendor Roles and Responsibilities The app vendor in this case example initially provided DART with a customized app but then transitioned to the white label version of its app. The app vendor has various roles and respon- sibilities. The vendor hosts the mobile fare payment app and facilitates payment processing in collaboration with DART, which holds the primary agreement for processing. DART has the primary responsibility for marketing the app to riders and providing customer service for the app, such as refunds to riders. Figure 34. Screenshots of DART’s GoPass. Figure 35. PayNearMe retail reload network in GoPass.

44 Business Models for Mobile Fare Apps In terms of costs, DART paid initial upfront costs to the app vendor that were on the order of hundreds of thousands of dollars. Ongoing costs are paid in two ways. First, the mobile fare payment app vendor is paid a fixed annual fee that covers hosting the app, maintenance of the app, licensing, and security; this is approximately $430,000 each year. Additionally, the app vendor is paid a percentage of each fare sold through the app, which varies based on fare type; this is 1% of each regular fare and 0.25% of corporate or university passes. Beyond the mobile fare payment app provider, there are other vendors that have important roles. First, the app vendor has an arrangement with a company known as Spare for a platform to integrate booking for on-demand transportation services in the app; the costs of this are paid annually as an additional fixed fee. Second, DART has an arrangement with Google for their Trip Planner (developed by Google and purchased by DART) to use their real-time trip feed; this is paid via a fixed fee annually. DART also utilizes a Google product called Firebase for detailed analytics pertaining to the app. Integration with Existing Fare Payment System At the time of writing, the mobile fare payment app provided by Unwire functioned as an account-based system that was separate from the rest of the fare system. DART also has an account-based system for their tap card, known as the GoPass Tap Card, that is a proprietary system provided by the vendor Vix Technology. In other words, DART has two different account-based systems: one for its mobile solution and the other for its card-based system. The transit agency hopes to transition to a single, unified account-based system in the future. Integration with Regional Fare Payment Systems The GoPass app can be used to purchase tickets for two other regional transit agencies: Denton County Transportation Authority (DCTA) and Trinity Metro in Fort Worth. App users can buy regional fare products, including daily, monthly, or annual passes, for these agencies, as shown on the right side of Figure 36. DART has agreements in place with each of these two regional transit agencies, and DART has the primary contract with the fare payment app vendor. Figure 36. Other modes (left) and regional agencies (right) in GoPass.

Case Examples 45 Integration with Other Apps The mobile fare payment app vendor in this case example can provide the transit agency with an API or SDK for fare payments; however, at the time of writing, this option was not being used. DART’s GoPass app has some innovative features that link it to other modes of trans- portation (see left side of Figure 36). First, the GoPass app has a deep link to Uber’s app to facilitate booking a shared UberPool ride. GoPass also has a deep link with the BIRD scooter app; users can see if scooters are available within the GoPass app and are directed to BIRD’s app for booking. Last, DART’s mobile fare payment app vendor Unwire has fully integrated booking for on-demand transportation services known as GoLink; this is done using a platform provided by the vendor Spare. Summary and Lessons Learned A brief summary of this case example and a discussion of the lessons learned follow: • The mobile fare payment app in this case example was initially created as a custom app for the transit agency; however, the transit agency transitioned to a white label version of the app from the same vendor. • The primary mechanism of validation for the mobile fare payment app is visual inspection by transit agency staff. • The mobile fare payment app in this case example functions as an account-based system that is separate from the rest of the agency’s fare payment system. The agency has a separate, proprietary account-based system for its tap card. In other words, the transit agency cur- rently has two different account-based systems: one for its mobile solution and the other for its card-based system. • The transit agency offers fare capping through the mobile fare payment app. For example, the maximum amount a rider can pay in a given day is capped at the price of a daily pass. • Mobile fare payment app users can load value into their transit account using cash at a network of local retailers provided in partnership with a third-party vendor; this facilitates adoption of the app by transit customers who do not have or do not want to use a credit or debit card. • The mobile fare payment app vendor has integrated the ability to book on-demand transit trips through a platform provided by another vendor. Additionally, the mobile fare payment app contains deep links to ridesourcing services and shared scooters. Chicago Transit Authority The fifth case example is the CTA, which serves the Chicago metropolitan area in Illinois. The agency provides bus, heavy rail, and demand-responsive transportation services. The 2017 NTD agency profile and the logo for the CTA are shown in Figure 37. Annual Passenger Miles: 1,972,073,598 Annual Revenue Miles: 125,902,692 Annual Unlinked Trips: 479,435,218 Vehicles Operated in Maximum Service: 2,719 Source: NTD, 2017 Figure 37. CTA logo and NTD agency profile.

46 Business Models for Mobile Fare Apps App Description The mobile fare payment app in Chicago is known as the Ventra app, and it is part of the CTA’s account-based, open payment system known as Ventra. The Ventra system is provided under contract with the vendor Cubic Transportation Systems, Inc. (Cubic), and at the time of writing, the app was provided via a subcontract with the company moovel (recently branded as REACH NOW). The Ventra app is available on both the Android and iOS platforms. For CTA riders, the Ventra app is primarily used for account management, and riders can load value into their Ventra account using the app (see Figure 38). Although smartphones and contactless bankcards can be used to pay fares, the most commonly used fare media on the CTA systems are contactless plastic Ventra cards and limited use paper tickets. The Ventra app can be used to reload values or passes in Ventra accounts, but it is the physical Ventra card that is tapped on readers in buses or at fare gates in rail stations. At the time of writing, the Ventra app was one of numerous channels (e.g., vending machines, participating retailers, or online) that could be used to purchase passes or load value into a Ventra account. The Ventra app is also used by two other regional transit providers: the suburban bus service Pace and the commuter rail service Metra. On the Pace bus service, the app functions in a simi- lar manner as with CTA buses; in other words, the app can be used to load value to a Ventra account, and then a Ventra card can be tapped on a Ventra reader when boarding the bus. On Metra commuter rail service, the app functions in a different manner. Metra tickets and passes can be purchased directly through the Ventra app, and then the tickets can be activated after boarding the train. The ticket appears on the screen (see Figure 39) and can be shown to Metra conductors for visual inspection. This regional integration will be discussed in more detail later. As previously mentioned, passengers can also pay directly with their smartphones using Apple Pay, Google Pay, Samsung Pay, or Fitbit Pay, since the CTA has an open payment system. At the time of writing, these four mobile fare payment options could be used by simply tapping the NFC on a user’s smartphone on a Ventra reader; similarly, contactless bankcards can be tapped directly on a Ventra reader. Then, the pay-as-you-go fare is automatically deducted; Figure 38. Ventra app for CTA.

Case Examples 47 however, this set up does not interface with the Ventra app; upgrades are planned for the near future to change this. Timeline and Procurement The Ventra app was procured as an amendment to the larger, account-based Ventra fare payment system. The initial contract for the open payment system was awarded to the vendor Cubic for $454 million in 2011, and the Ventra system was launched to the public in 2013. The initial launch focused on the Ventra card and did not include a mobile fare payment app. In 2015, the contract was amended for the mobile fare payment app. Cubic selected the company moovel (formerly known as GlobeSherpa; recently branded as REACH NOW) as a subcontractor to develop the app. The moovel/Cubic app underwent substantial testing, including early use by over 700 beta testers, before it went live systemwide for CTA, Pace, and Metra in 2015. At the time of writing, a significant change was on the horizon for the Ventra app. A new version of the app was under development by Cubic. The new version of the Ventra app will be available for both Android and iOS platforms. The ability to pay fares using a “virtual Ventra card” from the user’s Apple Wallet (iOS only) will eliminate the need for a physical Ventra card (see Figure 40). Vendor Roles and Responsibilities The prime contractor for the Ventra system is Cubic Transportation Systems, Inc., and the subcontractor responsible for app development and maintenance is the company moovel. The app was created for the CTA to be compatible with the preexisting Ventra account-based system. The upfront costs for the Ventra app for the CTA, Pace, and Metra were approxi- mately $2.5 million. In terms of operating costs, each of the three agencies pays a monthly fee and additional agency-specific fees (e.g., Metra also pays a percentage of sales fees). Figure 39. Ventra app for Metra. Figure 40. Planned deployment of Ventra in Apple Wallet (Image source: https:// www.ventrachicago. com/coming-soon/).

48 Business Models for Mobile Fare Apps The vendors (Cubic and moovel) have various roles and responsibilities. The vendors host the mobile fare payment app, facilitate payment processing, ensure PCI compliance, and are responsible for payment-related customer service. The CTA’s primary role is marketing to customer; otherwise, most fare payment-related roles are outsourced to the contractors. Integration with Existing Fare Payment System The Ventra app is integrated with the CTA’s account-based open payment system. As was previously noted, the initial Ventra system was launched to the public in 2013, and this included new readers on buses, new vending machines in rail stations, a completely new back-office system, a new accounting system, and other components. The initial system enabled fare pay- ment using the contactless, reloadable plastic Ventra card, the limited use paper Ventra ticket, and payment directly with contactless credit or debit cards (see Figure 41). The Ventra app was added later to be integrated with this account-based system, and the planned future update of the iOS app will provide even tighter integration. One of the only components of the CTA’s fare collection system that is not integrated with the account-based Ventra system is the cash-only fareboxes on buses. The fareboxes are separate from the Ventra readers installed on vehicles. Integration with Regional Fare Payment Systems The initial Ventra system was procured by the CTA, but shortly thereafter, amendments to the contract with Cubic were made to include the suburban bus operator Pace and the commuter railroad Metra. As part of this, the Ventra app is used by all three operators (CTA, Pace, and Metra), although there are some noteworthy differences between the agencies. The suburban bus operator, Pace, uses the Ventra app in a similar manner to CTA on the bus side. In other words, the app can be used to load value to a Ventra account, and then a Ventra Figure 41. Forms of Ventra fare media.

Case Examples 49 card can then be tapped on a Ventra reader when boarding the bus. The same Ventra readers that are installed on CTA buses are also installed on Pace buses. Moreover, the Ventra system can be used to transfer between CTA and Pace, and the business rules are automatically calculated by the Ventra system. On Metra commuter rail service, the app functions in a different manner. Metra fare products can be purchased directly through the Ventra app, and then they must be activated just before boarding the train. A fare product then appears in the app and has dynamic images to reduce fraudulent usage. The primary method for validation is visual inspection by conductors. The Ventra app also contains a barcode on Metra tickets; at the time of writing, it was not clear if the barcode was in use for validation. Additionally, Metra has its own zone-based fare policy, which differs substantially from the fare policies of the CTA and Pace. However, Metra offers a “link up” pass that enables monthly pass purchasers to pay an extra fee and receive free transfers to the CTA and Pace during selected time periods (i.e., the weekday rush hours); this is available in the Ventra system. Last, reconciliation is done regularly between the three transit operators (CTA, Pace, and Metra). Revenue reports are received daily, and settlement between the three agencies occurs at the end of the month. Integration with Other Apps The Ventra app is not integrated with other apps. However, an effort is underway to expand the Ventra app to integrate functionality pertaining to Divvy, which is Chicago’s bikeshare system. This effort is funded through an FTA Mobility on Demand grant. Summary and Lessons Learned A brief summary of this case example and a discussion of the lessons learned follow: • The mobile fare payment app in this case example is part of an open payment, account-based system. Substantial customization of the app was done by the vendors to ensure compatibility with the transit agency’s preexisting account-based fare payment system. • The current version of the app is primarily used for account management. • A pending update will expand the functionality to enable transit payments in Apple Wallet for iOS users. • The transit agency paid a large upfront sum for the initial open payment, account-based fare payment system, and the app was not included in this original system. The app was added at a later date via an amendment to the original contract. • The transit agency and vendors did substantial beta testing prior to launching the initial version of the app. • This app is part of an integrated system shared by three transit agencies in the region (urban bus and rail, suburban bus, and commuter railroad); however, the app functions differently on the commuter railroad. Commuter railroad fare products can be purchased directly in the app, and then they are visually verified by conductors on trains. St. Catharines Transit Commission The last case example is St. Catharines Transit Commission, which serves the city of St. Catharines in Ontario, Canada. The agency provides local bus and demand-responsive trans- portation services. NTD data were not available for this Canadian transit agency; instead, statistics were requested directly from the transit agency, and a brief profile is shown in Figure 42.

50 Business Models for Mobile Fare Apps App Description St. Catharines Transit Commission has a unique arrangement for its mobile fare payment app. The transit agency contracts the company known as Transit, which provides a widely used real-time transit and shared mobility information app. Transit has a preexisting arrangement with the agency in which the vendor provides a branded version of the app to St. Catharines Transit Commission. Recently, the transit agency also contracted the mobile fare payment app vendor Masabi for its SDK so it could be integrated into the Transit app for fare payments in the St. Catharines’ region. Unlike the other case examples, there is not a separate app focused primarily on fare payment; rather, the payment functionality has been added to the real-time information app (see Figure 43). The app Transit is available on both the Android and iOS platforms. The Transit–Masabi integration has been configured to include most of St. Catharines’ fare products, including single rides, 10 rides, and monthly passes. At the time of writing, there were some fare products that had not yet been integrated into the app, such as a family pass and a semester pass for university students; however, the transit agency hopes to add these fare products into the Transit app in the future. A brief description of how the app works is as follows. When the user initially opens the Transit app, the user sees information for nearby transit service, as shown in Figure 43. If the user clicks “Buy Ticket,” he or she is then directed to a screen to select a fare product, which is shown in the left screenshot of Figure 44. Next, the user can create or sign into a Transit app account (center screenshot in Figure 44), and review the order and pay (not shown). When the user is ready to utilize the fare product and board the bus, he or she can activate the mobile fare product and show the screen to the driver for visual validation. Notably, the ticket screen looks similar to the physical tickets sold by St. Catharines Transit Commission (right screenshot in Figure 44). In summary, the fare payment functionality within the Transit app functions similarly to the apps discussed in the previous case examples. Timeline and Procurement Unlike the other case examples, St. Catharines’ deployment timeline (shown in Figure 45) focused on the provision of real-time information and then integrated fare payments later. In October 2014, St. Catharines Transit Commission launched automatic vehicle location (AVL) devices on its fleet of buses. The real-time bus tracking information from the AVL devices was then provided to the company Transit, and approximately 1 year later, in August 2015, the Transit app was launched to riders in St. Catharines. This was done via a contractual arrange- ment between St. Catharines Transit Commission and the company Transit to provide the commission’s own branded version of the Transit app for this region. Shortly before, St. Catharines Transit Commission began to explore various options to upgrade its fare payment system, which primarily relied on magnetic stripe tickets. The transit Annual Regular Service Passenger Trips: 5,980,441 Annual Revenue Vehicle Kilometers: 3,060,283 Estimated Peak Vehicles (Bus): 56 Source: St. Catharines Transit Commission Figure 42. St. Catharines Transit Commission logo and agency profile. Figure 43. Real-time information and Buy Ticket screen in Transit.

Case Examples 51 agency’s fareboxes were nearing the end of their useful lives, and the agency was looking for a modern alternative technology. The agency wanted to “leap frog” over smart cards and find a lightweight, low-risk technology option. These reasons led St. Catharines Transit Commission to focus on mobile fare payment apps and identify different ways to deploy such apps. One option was to integrate mobile fare payments directly into the Transit app, which would involve bringing in a mobile fare payment app vendor for the fare payment functionality. This approach would utilize an SDK for integration. In 2017, the transit agency decided to move forward with this option. A key reason for selecting this approach was that riders on the St. Catharines Transit Commission’s system were already using the Transit app, and customer acceptance and satisfaction was high. Moreover, customers would not need to download another app, which was viewed as an added convenience. In January 2018, St. Catharines Transit Commission signed a 1-year contract with a mobile fare payment app vendor, Masabi, for SDK. It should be noted that this contract did not Figure 44. Screenshots of ticket purchase flow for St. Catharines in Transit (Image source: Presentation at CUTA meeting by Tim Luey). October 2014– AVL Launch August 2015– Transit App January 2019– Mobile Ticketing Pilot April 2019–Launch of Mobile Ticketing Figure 45. Timeline for St. Catharines (Image source: Adapted from CUTA presentation by Tim Luey).

52 Business Models for Mobile Fare Apps include Masabi’s white label app, but instead, was only for the Justride SDK. Additionally, the 1-year contractual period would not start until the app was publicly deployed. The two vendors (Transit and Masabi) then spent about 1 year working on the integration. In October 2018, St. Catharines conducted a customer survey; this included identifying potential beta users interested in testing the new payment functionality in the Transit app. In January 2019, a pilot program was launched with approximately 50 testers who provided feedback to the transit agency that was used to make changes prior to the systemwide launch. The pilot program continued for approximately 3 months. In April 2019, the new version of the Transit app with the Masabi mobile fare payment SDK integration was officially launched to all customers in St. Catharines. As of June 2019, 9.1% of eligible ridership (e.g., excluding fare products such as university passes not currently available in the app) used the Transit app to purchase their fares. In the future, St. Catharines Transit Commission intends to evaluate different options for validation, particularly hardware technologies, since the current mobile fare payment system relies solely on visual validation by bus operators. Vendor Roles and Responsibilities In this case example, the primary contract for the mobile fare payment SDK is with the vendor Masabi. Masabi was paid a small upfront implementation fee (on the order of thousands of dollars). This vendor is also paid a nominal monthly maintenance fee, and the main mechanism for payment to the vendor is via a percentage of fare sales. The transit agency has a separate, ongoing contract with the real-time information app vendor (Transit) that was already in place when the contract with the mobile fare payment SDK vendor was set up. The two vendors (Masabi and Transit) have various roles and responsibilities. Masabi provides payment processing, ensures PCI compliance, and provides the transit agency with a backend portal that can be used for reporting, analytics, and customer service related to mobile fare payments. Marketing to riders is done by the app vendor Transit and transit agency staff. Staff at the transit agency primarily do customer service for fare payment-related issues such as providing refunds to users. Integration with Existing Fare Payment System The app in this case example is not integrated with the rest of the agency’s fare payment system. The app is a stand-alone system. Integration with Regional Fare Payment Systems At the time of writing, fare payments in the Transit app were only available for St. Catharines Transit Commission; no other transit operators in the Niagara region were integrated. However, integration may be considered in the future by other regional transit operators. Integration with Other Apps St. Catharines Transit Commission took an approach to mobile fare payments based on an SDK, which enables integration with other apps. At the time of writing, Masabi’s fare payment SDK was only integrated into the Transit app, and the transit agency did not have specific plans for integration with other smartphone apps. However, it is technically possible that the fare payment SDK could be integrated in other apps as desired in the future.

Case Examples 53 Summary and Lessons Learned A brief summary of this case example and a discussion of the lessons learned follow: • This case example focused on an SDK-only approach to mobile fare payments integrated into other apps; in this case, a mobile fare payment app vendor’s SDK was integrated into a widely used real-time information app. One of the primary reasons that the transit agency selected this approach was that its riders already used and liked this real-time information app; therefore, it was already in the hands of a large percentage of its customers. • The transit agency paid a small amount of upfront costs and nominal monthly maintenance fees to the mobile fare payment SDK vendor; however, the main mechanism for payment is via a percentage of fare sales. • The transit agency initially did a small-scale pilot program of the fare payment functionality in the real-time information app; beta testers provided feedback to the agency that was used to make improvements prior to the systemwide launch. • The transit agency offers most of its fare products in the app; the agency is working to expand the fare product options in the future until all fare products are available. • The primary mechanism for validation is visual inspection by drivers; other validation technologies may be considered in the future. • There is no integration with the transit agency’s preexisting fare payment system in this example. Instead, this is a stand-alone system. Summary and Comparison of Case Examples This section presents a summary of each case example as well as a comparison of the key characteristics of each example. The case examples can be 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 is 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 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; this required another vendor to support the hardware and had additional costs. 4. Dallas Area Rapid Transit in Dallas, Texas: This agency initially had a customized app; however, the transit agency 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 select retailers. 5. Chicago Transit Authority in Chicago, Illinois: This agency has an open payment, account- based system, which includes a mobile fare payment app. Currently, the app is used primarily

54 Business Models for Mobile Fare Apps for account management; however, a pending update will enable transit payments using a virtual card in Apple Wallet. The transit agency paid large upfront costs for the initial account-based fare 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; however, the app functions differently on the nearby commuter railroad. 6. St. Catharines Transit in Ontario, Canada: This agency took an SDK-only approach in which a mobile fare payment app vendor’s SDK was integrated into a widely used real-time information app. The transit agency paid a small amount of 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 bus drivers, and there is no integration with the transit agency’s preexisting fare payment system. Finally, the case examples were qualitatively compared, and the results are summarized in Table 3. Based on the characterization of each example presented in the table, overarching models and trends in mobile fare payment apps were identified. These are discussed in more detail in the next chapter. Table 3. Comparison of six case examples. Characteristics of Transit Agency Big Blue Bus RTD CapMetro DART CTA St. Catharines Location Santa Monica, California Denver, Colorado Austin, Texas Dallas, Texas Chicago, Illinois St. Catharines, Ontario, Canada Size of Transit System Small Medium Medium Medium Large Small Vendor Token Transit Masabi Bytemark Unwire moovel/Cubic Masabi(also Transit) Mobile Fare Payment App Costs Low Low Medium Medium High Low Validation Hardware None None Some None Many None Level of Integration with Fare Payment System None None None None Medium None Level of Integration with Regional Transit Systems None Limited None Medium High None Characterization of the Example Shared App White Label App Initially Custom App; Transitioned to White Label App with Validation Hardware Initially Custom App; Transitioned to White Label App Account-Based and Open Payment App SDK Only