The National Academies Press

Currently Skimming:

Pages 30-54

The Chapter Skim interface presents what we've algorithmically identified as the most significant single chunk of text within every page in the chapter.
Select key terms on the right to highlight them within pages of the chapter.

From page 30... ... 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. Read the entire page →
From page 31... ... 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. Read the entire page →
From page 32... ... 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. Read the entire page →
From page 33... ... 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. Read the entire page →
From page 34... ... 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. Read the entire page →
From page 35... ... 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) Read the entire page →
From page 36... ... 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. Read the entire page →
From page 37... ... 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. Read the entire page →
From page 38... ... 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. Read the entire page →
From page 39... ... 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) Read the entire page →
From page 40... ... 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) Read the entire page →
From page 41... ... Case Examples 41 Integration with Existing Fare Payment System The existing fare system comprises multiple, separate components. This includes Genfare fareboxes on buses for payment with magnetic strip tickets, stand-alone validators (see Figure 32) Read the entire page →
From page 42... ... 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. Read the entire page →
From page 43... ... 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. Read the entire page →
From page 44... ... 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. Read the entire page →
From page 45... ... 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 transportation (see left side of Figure 36) Read the entire page →
From page 46... ... 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. Read the entire page →
From page 47... ... 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. Read the entire page →
From page 48... ... 48 Business Models for Mobile Fare Apps The vendors (Cubic and moovel) have various roles and responsibilities. Read the entire page →
From page 49... ... 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. Read the entire page →
From page 50... ... 50 Business Models for Mobile Fare Apps App Description St. Catharines Transit Commission has a unique arrangement for its mobile fare payment app. Read the entire page →
From page 51... ... 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. Read the entire page →
From page 52... ... 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. Read the entire page →
From page 53... ... 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. Read the entire page →
From page 54... ... 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. Read the entire page →

From page 30...

... 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.