Transit Module 21: Mobile Fare Ticketing/Payment

HTML of the PowerPoint Presentation

(Note: This document has been converted from a PowerPoint presentation to 508-compliant HTML. The formatting has been adjusted for 508 compliance, but all the original text content is included, plus additional text descriptions for the images, photos and/or diagrams have been provided below.)

Slide 1:

This slide contains a graphic with the word “Welcome” in large letters. ITS Training Standards “WELCOME” slide, with reference to the U.S. Department of Transportation Office of Assistant Secretary for Research and Technology

 

Slide 2:

This slide contains a graphic with the word “Welcome” in large letters, photo of Kenneth Leonard, Director ITS Joint Program Office - Ken.Leonard@dot.gov - and on the bottom is a screeshot of the ITS JPO website - www.pcb.its.dot.gov

 

Slide 3:

Module 21 Mobile Fare Ticketing/Payment

Title slide: This slide contains a graphic of three smart phone app screens. The first in the series is of the RTD (Regional Transit District of Denver). It is a branded RTD page that shows a graphic of the RTD bus with several user options including “buy tickets”, “ticket wallet”, “account”, “trip planner” and “next ride”. The second screen is of an UBER app which shows a map of Denver and users options including “UberX $34.28”, “Comfort $42.84”, and “Transit $10.50-10.50, See Routes”. The third screen is of the Transit App which shows a map with multicolored placeholders for transit stops. The app includes a search function with a field “where to”. It also includes quick selections and estimated time to arrive at current stop for “D Mineral”, “F Ridgegate”, “5L Billings via E Colfax Ave”. At the bottom of the app, the user can select the RTD branded selection to “Buy ticket”.

Graphic courtesy of Regional Transit District - Denver

 

Slide 4:

Instructor

This slide, entitled “Instructor” has a photo of the instructor, Paula (Polly) Okunieff, on the left hand side.

Paula (Polly) Okunieff

Solution Architect

GO Systems and Solutions LLC

 

Slide 5:

Learning Objectives

 

Slide 6:

Learning Objective 1

 

Slide 7:

Mobile Fare Ticketing / Payment

System Architecture

A set of all components of an Electronic Fare Payment System (EFPS) and the methods used to send information between those components.

Author's relevant description: This slide has four boxes with dual directional lines between them, and two boxes on top and below the last box in the sequence. The four sequential boxes include “Fare Media”, “Reader”, “Local Device [Optional]”, and “Central Computer”. The box above central computer is entitled “Regional Clearinghouse [Optional]” and below is entitled “Payment Processor [Optional]”. Examples of Fare media are located under the fare media box with “Mobile Devices” encircled. Examples of Local Devices are located under the aforementioned box. Examples of Payment Processors are located under that box. A callout form is associated with the Reader which states that “A reader may be optional in a Mobile Fare system”. A callout form is associated with a local device which states that “Mobile app provides Point of Sales (POS) functions.

Source: PCB Transit Module 10

 

Slide 8:

Mobile Fare Ticketing / Payment

Primary Purpose of the Mobile Fare Payment App

 

Slide 9:

Mobile Fare Ticketing / Payment

Mobile Payment Systems Operator

Roles and Responsibilities

Source: PCB Transit Module 12

 

Slide 10:

Mobile Fare Ticketing / Payment

Growth of Mobile Devices and Mobile Fare Payment Apps

Author's relevant description: This slide shows a graph from the Pew Research Mobile Facts Sheet (2020). The graph title displays an icon of a man and woman with a label that states: “Who owns cellphones and smartphones”. The graphic includes notes such as a label that states “% of U.S. adults who own the following devices” primarily Smartphones. The line graph shows that smartphone ownership from 2012 to Feb 7, 2019 grew 81%. The “Source: Surveys conducted 2002:2019” and the study was conducted by the “PEW RESEARCH CENTER”.

Simple icon of man and woman standing next to each other.

Who owns cellphones and smartphones

Source: Pew Research- Mobile Fact Sheet (2020)

Background information icon indicates general knowledge that is available elsewhere and is outside the module being presented.

 

Slide 11:

Mobile Fare Ticketing / Payment Features Current Mobile Fare Payment App Characteristics and Features from Transit Cooperative Research Program (TCRP) Synthesis 148

App characteristics:

App features/functions

The slide includes a graphic of the front cover of the Transit Cooperative Research Program (TCRP) Synthesis 148 Business Models for Mobile Fare Apps. The cover display includes the following markings: “Transit Cooperative Research Program, TCRP Synthesis 148 Business Models for Mobile Fare App, A Synthesis of Transit Practice, Candace Brakewood, University of Tennessee, Knoxville, Knoxville, TN”

 

Slide 12:

Mobile Fare Ticketing / Payment Features

Mobile Fare Payment App Characteristics

The slide includes 5 green colored icons of a bus, person on wheelchair, light rail vehicle, ferry, and heavy rail (subway) vehicle on tracks.

 

Slide 13:

Mobile Fare Ticketing / Payment Features

Mobile Fare Payment App Characteristics, cont.

The slide includes three smartphone screens that show the process of activating a mobile ticket. Sequentially above each screen in order are the labels “initial activation, activation, on tap”. The first screen shows three boxes with different colors with the following markings “Metro [in yellow], 1 Adult ($2.75) [in blue], 06/12/2018 Expiration Date & Time [in two toned brown]” with a QR code on the bottom right hand corner. The second screen shows the same information but the last box is now colored yellow. The final screen includes the same information but the boxes are colored as follows: yellow “Metro”, light blue “1 Adult ($2.75)”, two toned brown “06/12/2018 Expiration Date & Time”. In addition, a label is included “*Including Metro Community Shuttles, Community Vans, Community Ride, Trailhead Direct, Via to Transit, Ride2 and Access service”. Source is from King County Metro

Source: King County Metro

 

Slide 14:

Mobile Fare Ticketing / Payment Features

Mobile Fare Payment App Features

QR code displayed in mobile ticket for the Regional Transportation District (Denver). The mobile app screen shows ticket details – a label that reads “local 3-hour pass discount”, a QR code, the time of activation 4:19:01PM 04/22/2019, and the description of the pass “Local, 3-Hour Pass, 1-3 zones, and valid in airport fare zone, expires June 11, 2019 1:50 AM” and the logo “LD discount”

QR code displayed in mobile ticket Source: Regional Transportation District (Denver)

 

Slide 15:

Mobile Fare Ticketing / Payment Features

Mobile Fare Payment App Features, cont.

Two mobile app screens from the CapMetro Mobile Traveler and Payment App. The first screen has a caption ‘Use the CapMetro App to purchase and use tickets on your phone” with a screen shot of “Tickets” and two tabs – “Active” and “Available”. The Available selection is shown on the screen with three options – “1 Month Pass Access Monthly Pass”, “7 Day Pass Commuter 7-Day Pass”, and 1 Ride Local Single Ride”. The second screen has a caption “No Cash? Buy tickets directly on your phone!” The screen header reads “Store” with a cart on the same line. Under the header is a caption that reads “Local, 4 products available”. The four products listed under it include: “1 Ride Local single ride $1.25” with two buttons “Add to Card” or “Buy Now” - “1 day pass Local day pass $2.50” with two buttons “Add to Card” or “Buy Now” - “7 day pass Local 7-day pass $11.25” with two buttons “Add to Card” or “Buy Now” - “31 day pass Local 31-day pass $41.25” with two buttons “Add to Card” or “Buy Now”

Source: CapMetro Mobile Traveler and Payment App

 

Slide 16:

Key Mobile Fare Ticketing / Payment Roles & Responsibilities

Mobile Fare Payment App System Roles and Responsibilities

Please see extended text description below.

(Extended Text Description: This slide contains a table entitled Table 2: Roles and Responsibilities with the following data:

Primary Responsibility For Vendor Agency Other N/A Count(n)
Payment processing 85% 7% 8% 0% 61
Hosting the app 98% 2% 0% 0% 61
Customer service for riders 43% 56% 2% 0% 61
Marketing the app to riders 7% 93% 0% 0% 61
PCI Compliance 85% 7% 3% 5% 60

Additionally, there are areas that are encircled: the Vendor contribution for the five primary responsibilities, and the second circle highlights the agency responsibilities for customer service and marketing the app to riders (56%, 93% respectively).)

Source: TCRP Synthesis 148, Table 2.

 

Slide 17:

Relevant Standards

International Standards Organization (ISO)/ International Electrotechnical Commission (IEC) 14443

Contactless integrated circuit cards - Proximity cards

Source: Module 10 and 12

Definition of Virtual Card - "an electronic replica of a physical card and it usually contains a randomly generated credit card number [token] that change every time your credit card is used for a purchase."

 

Slide 18:

Relevant Standards

ISO/IEC 18092 and ISO/IEC 21481

Information technology, telecommunications and information exchange between systems, Near Field Communications, Interface and Protocol (NFCIP-1) and (NFCIP-2)

Source: Module 10 and 12

In May 2020, the NFC Forum approved 4 specifications that provide faster and more robust data exchange methods than the older versions. Spec called Tag NFC Data Exchange Format Protocol (TNEP).

 

Slide 19:

Relevant Standards and Practices

Specifications

Card Network Specifications apply to Mobile Virtual Cards

Source: Adapted from Transit Module 12

 

Slide 20:

Relevant Standards and Practices

Card Network Operating Rules

Source: Adapted from Transit Module 12

 

Slide 21:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

 

Slide 22:

Question

Who does the primary marketing of an agency's fare app to riders?

Answer Choices

  1. Vendor
  2. Social Media
  3. Agency
  4. App Store

 

Slide 23:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Vendor
Incorrect. Only 7% of vendors promote an agency's fare app.

A small graphical red and yellow X representing incorrect.b) Social Media
Incorrect. Although social media might help promote the app, the primary marketing is performed by the agency.

A small graphical green and yellow check mark representing correct.c) Agency
Correct! Respondents of TCRP Synthesis 148 responded that the agency markets the app to riders.

A small graphical red and yellow X representing incorrect.d) App Store
Incorrect. Although an app store might help suggest an app, the primary marketing is performed by the agency.

 

Slide 24:

Learning Objective 2

 

Slide 25:

Payment Methods

Mobile Payment Methods

Virtual Wallets - store virtual cards that emulate contactless bankcards (support ISO 14443 and NFC) stored in a mobile operating system "wallet".

Payment apps - mobile app that provides sales, customer services and account management support to customers.

Peer-to-peer payment apps - mobile app that enables the electronic transfer of money between two bank accounts.

Cryptocurrency Apps and Wallets - mobile apps to manage and pay for services using cryptocurrency

 

Slide 26:

Fare Payment Proof of Purchase

Fare Proof of Purchase Methods

The figure shows a reader / validator device and a hand holding a mobile phone with the Capitol Metro QR product under the device.

CapMetro QR product with V3

(source: Bytemark)

 

Slide 27:

Fare Payment Proof of Purchase

Fare Proof of Purchase Method - Visual Validation

Visual validation, also called Flash Pass, is an animated ticket shown to the operator

Author's relevant description: The figure is a flow diagram between Transit agency, Central Computer, Reader, and a mobile app. The mobile app screen shows a V3 screen of a Big Blue Bus traveling under the Sport Fishing arch in Santa Monica. The three blue boxes show the data flow between the Transit Agency and the Central Computer (operated by the the mobile fare app vendor); between the Central Computer and the mobile phone (with the functions sales, account info, product transactions and upon activation, sends updated animation). The Reader (representing the transit operator or driver) has no data flow connection between any other box.

Source: Big Blue Bus website Bigbluebus.com

 

Slide 28:

Fare Payment Proof of Purchase

Fare Proof of Purchase Method - QR Code

QR (Quick Response) is a two-dimensional barcode.

Author's relevant description: The figure is a flow diagram that shows boxes for a Transit agency, Central Computer, Fare Validation Device, QR code Reader, and a mobile app. The mobile app shows three screens for each step in the process -- “Select ticket”, “activate” and “present QR to reader”. The mobile device points to the QR Code Reader. A double arrow points between the QR Code Reader and the Fare Validation Device. A double arrow points between the Fare Validation Device and the Central Computer (operated by the Mobile Fare App Vendor). A double arrow points between the Central Computer and Transit Agency. A double arrow points between the Transit Agency and Fare Validation Device with the label “Product transactions” and “Valid/Invalid code lists”. And finally, a double arrow points between the Central Computer and mobile app with the label “Sales”, “Account Info”, and “Product transactions and unique QR code generation”.

 

Slide 29:

Fare Payment Proof of Purchase

Fare Proof of Purchase Method - Mobile Open Payment

Author's relevant description: The figure is a flow diagram that shows boxes for a Regional Clearinghouse, EFPS Central Computer, Payment Processor, Validator, NFC Reader, and a mobile app. The mobile app shows a virtual credit card stored in Google Pay. A double arrow is shown between the mobile device and the NFC Reader. The NFC reader has three boxes under which includes the icon for a NFC device (four curved lines and a hand holding a card), an icon for the Google Pay, and another for a virtual wallet. A double arrow points between the NFC Reader and the Validator. A double arrow points between the Validator and the EFPS Central Computer with check bullets that displays “product transactions and valid/invalid lists”. A double arrow that points between the EPFS Central Computer and Regional Clearinghouse. A double arrow that points between the EPFS Central Computer and Payment Processor.

 

Slide 30:

Fare Payment Proof of Purchase

Fare Proof of Purchase Method - Transit Wallet

Example: Ventra virtual card

Author's relevant description: The figure is a flow diagram boxes for the Ventra Regional Clearinghouse, Ventra Central Computer, Payment Processor, Validator, NFC Reader, and a mobile app. The mobile app shows a virtual Ventra card stored in Google Pay. A double arrow is shown between the mobile device and the NFC Reader. The NFC reader has three boxes under which includes the icon for a NFC device (four curved lines and a hand holding a card), an icon for the Google Pay, and another for a virtual wallet. A double arrow points between the NFC Reader and the Validator. A double arrow points between the Validator and the Ventra Central Computer with check bullets that displays “product transactions and valid/invalid lists”. A double arrow that points between the Ventra Central Computer and Ventra Regional Clearinghouse. A double arrow that points between the EPFS Central Computer and Payment Processor.

Source: Ventrachicago.com

 

Slide 31:

Mobile App Technology Terminology

Mobile App Development Characteristics

Walled Garden - closed ecosystem in which all operations are controlled by the ecosystem operator.

Deep Link - relationship between multiple applications in which one app redirects users to another app.

Application Programming Interface (API) - set of communication protocols for exchanging information between one or more applications. Payment application owners sometimes provide open APIs.

Software Development Kit (SDK) - set of libraries, documentation or tools which may also include APIs that can be tailored by an app. Payment application owners sometimes provide an SDK.

Source: TCRP Synthesis 148

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 32:

Mobile App Technology Terminology

Secure Element

Mobile providers use a secure element to protect personally identifiable information (PII)

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 33:

Mobile App Physical Architecture

Conceptual View of Mobile App Physical Architecture

The NFC Controller channels the token directly to NFC Reader

The figure shows the internal components of a mobile phone in a blue box interacting using a lighting bolt with a cellular network tower, and interacting with a NFC Fare Reader / Validator. The mobile phone components boxes are embedded in a box entitled “Operating System (OS)”. The components in light blue include “OS SDK and Libraries”, “Cell / Wi-Fi / Bluetooth”, “Secure Element (HCE)” with a lock, and “NFC Controller”. A lighter blue box has a label “Mobile fare app”. A dotted line divides the OS SDK, Mobile Fare app and Cell / Wi-Fi / Bluetooth boxes from the Secure Element and NFC Controller boxes. The cellular network points to the area above the line and the NFC log and Fare Reader / Validator is aligned with the boxes below the line.

 

Slide 34:

Fare Payment Role Based Architecture

ISO/Draft International Standard 24014-1 Public transport Interoperable fare management system (IFMS) Part 1: Architecture (version 3)

The figure is the IFMS architecture. The diagram shows three main areas: External Systems Manager (blue), Interoperable fare managers (IFM) (orange/brown), and Identification manager (green). The External System Managers includes four boxes that describe different roles associated with the managers including “Media provider”, “media retailer”, Identity provider” and “payment provider”. The IFM includes boxes for “product owner”, “application owner”, “application retailer”, “product retailer”, “account provider”, “customer service”, “customer”, “passenger”, and “service operator”. It also includes a cloud labeled “collection and forwarding”. The Identification Manager including two boxes “security manager” and “registrar”. A double arrow connects the Identification Manager and IFM. The collection and forwarding cloud connects to the following boxes: application owner, product owner, media provider, media retailer, application retailer, product retailer, customer service, service operator, identity providers (via dotted line). The Customer is connected to the account provider and customer service (via dotted lines), application and product retailers, and payment provider. The passenger is connected to the service operator. The identify provider connects to the account provider, customer and collection and forwarding (via dotted line).

 

Slide 35:

Fare Payment Role Based Architecture

Open Payment (PAYG) with a Transit Wallet

The diagram shows an instance of the IFMS architecture for open payment using a transit wallet. The diagram is divided into two parts, internal and external to the IFMS. Each part includes boxes that are notated as basic IFMS roles, additional roles or composite IFMS roles. The External to IFMS include two boxes: Merchant Acquirer (additional role), Bank Card Issuer (additional role). The Internal to the IFMS includes payment provider (an IFMS 24014-1 roles with an embedded box that says PAYG Balance Holder which is additional roles), PAYG Product Owner (basic IFMS role), Transport Service Operator (basic IFMS role), PAYG Top-Up Fulfiller (additional roles), PAYG Top-Up Retailer (basic IFMS role), Passenger (basic IFMS role). The following pairs are connected: Merchant acquirer and bank card issuer, Merchant Acquirer and Payg top-up retailer. Bank card issuer and passenger. Payment provider and payg product owner, payment provider and payg top-up retailer. Passenger and transport operator. Transit operator and payg product owner. Payg top-up retailer and payg top-up fulfiller. The following boxes include callouts that show how the model relates to the Ventra system – Merchant Acquirer is called out as “Money Network” MetaBank, Bank card issuer is called out as MasterCard, Payg products owner is is called out as as Ventra, Transport service operator is called out as CTS, PACE or METRA, Payg top-up retailer is called out as Jewel.

Source: IFMS-1 v3, Appendix B

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 36:

Fare Payment Role Based Architecture

Open Payment with a Virtual Bankcard

The diagram shows an instance of the IFMS architecture for open payment using a virtual bankcard. The diagram is divided into two parts, internal and external to the IFMS. Each part includes boxes that are notated as basic IFMS roles, additional roles or composite IFMS roles. The External to IFMS include one box: Payment Provider (composite IFMS roles) with two embedded boxes -- Merchant Acquirer (additional role), Bank Card Issuer (additional role). The Internal to the IFMS includes payment PAYG Product Owner (basic IFMS role), Transport Service Operator (basic IFMS role), and Passenger (basic IFMS role). The following pairs are connected: Merchant acquirer and bank card issuer, Merchant Acquirer and Payg product owner. Bank card issuer and passenger. Passenger and transport service operator. Transit operator and payg product owner.

Source: IFMS-1 v3, Appendix B

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 37:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

 

Slide 38:

Question

What payment access method is most proprietary? Answer Choices

  1. SDK
  2. API
  3. Walled garden
  4. Deep link

 

Slide 39:

Review of Answers

A small graphical red and yellow X representing incorrect.a) SDK
Incorrect. SDK is typically a toolkit for incorporating open functions into and information exchanges with another application.

A small graphical red and yellow X representing incorrect.b) API
Incorrect. APIs are open specifications for exchanging information between two applications.

A small graphical green and yellow check mark representing correct.c) Walled Garden
Correct! Walled garden refers to applications that are closed with the intention of securing and restricting access.

A small graphical red and yellow X representing incorrect.d) Deep Link
Incorrect. Deep link is a uniform reference link (URL) that accesses another application. This selection is also restricted and proprietary but not as restricted as the Walled Garden.

 

Slide 40:

Learning Objective 3

 

Slide 41:

Mobile Fare App Business Models

5 Business Models

Described by TCRP Synthesis 148

SmartArt of five orange shaded list boxes. The first includes a centralized graphic with five spokes, the second list graphic is of a label, the third list graphic is of a validator, the fourth list graphic is of a bank card icon, the last list graphic is of a hammer.

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 42:

Mobile Fare App Business Models

Shared App

✓ Multiple agencies on same mobile app

✓ Agencies share common platform

✓ No hardware needed

✓ Validation methods

□ Visual verification

✓ No integration with fare system

✓ Turnkey / service subscription

The diagram shows an instance of the IFMS architecture for a shared app business model. Two external system managers boxes with merchant acquirer and bank card issuer in each. Four blue boxes representing Shared App Vendor for the following IFM roles (1) Payment Provider (with an embedded white box with a tickets label), (2) Application Owner, (3) Top-Up Retailer/Fulfillment (POS), (4) Account provider. One green box representing Apple/Google store for the Application Retailer role. One orange box representing the customer smartphone for Passenger role. Two series of brown boxes representing one or more transit agencies for (1) product owner and (2) Transport Service Provider roles. The linkages are as follows: the Merchant acquirer is connected to the Bank Card issuer and the Top-up retailer/Fulfillment (POS). The Bank Card Issuer is also connected to the Account Provider. The Account Provider is connected to the Passenger. The Passenger is connected to the Transport Service Operator. The Transport Service Operator is connected to the Product Owner. The Product Owner is connected to the Application Retailer and the Payment Provider. The Payment Provider is connected to the Application Owner, and the Application Owner loads the application to the Application Retailer.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 43:

Mobile Fare App Business Models

White Label App

✓ Single agency mobile app

✓ No hardware needed

✓ Validation Methods

□ Visual verifiable

□ QR code method

✓ Limited integration with fare system

✓ Turnkey / service subscription

The diagram shows an instance of the IFMS architecture for a white label app business model. Four blue boxes representing White Label App Vendor for the following IFM roles (1) Payment Provider (with an embedded white box with a tickets label), (2) Application Owner, (3) Top-Up Retailer/Fulfillment (POS), (4) Account provider. One green box representing Apple/Google store for the Application Retailer role. One orange box representing the customer smartphone for Passenger role. Two brown boxes representing the transit agency for (1) product owner and (2) Transport Service Provider roles. The linkages are as follows: The Account Provider is connected to the Passenger and Top-up Retailer/Fulfillment (POS). The Top-up Retailer/Fulfillment (POS) is also connected to the Product Owner and Payment Provider. The Passenger is connected to the Transport Service Operator and Top-up Retailer/Fulfillment (POS). The Transport Service Operator is connected to the Product Owner. The Payment Provider is connected to the Application Owner. The Application Owner loads the application to the Application Retailer which is downloaded to the Passenger smartphone.

Note: removed External Systems from this diagram

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 44:

Mobile Fare App Business Models

White Label App with Hardware

✓ Single/regional agency mobile app

✓ Hardware reader / validation

✓ Validation Methods

□ QR code method

□ NFC - Transit Wallet

✓ Limited integration with fare system

✓ Turnkey / service subscription

The diagram shows an instance of the IFMS architecture for a white label app with Hardware business model. Four blue boxes representing White Label App Vendor for the following IFM roles (1) Payment Provider (with an embedded white box with a tickets label), (2) Application Owner, (3) Top-Up Retailer/Fulfillment (POS), (4) Account provider, and blue cloud for the Collection and Forwarding function. One green box representing Apple/Google store for the Application Retailer role. One orange box representing the customer smartphone for Passenger role. Two brown boxes representing the transit agency for (1) product owner and (2) Transport Service Provider roles. The linkages are as follows: The Account Provider is connected to the Passenger and Top-up Retailer/Fulfillment (POS). The Top-up Retailer/Fulfillment (POS) is also connected to the Passenger and Payment Provider. The Passenger is connected to the Transport Service Operator and the Collection & Forwarding cloud. The Transport Service Operator is connected to the Product Owner. The Product Owner is connected to the Payment Provider. The Payment Provider is connected to the Application Owner. The Application Owner loads the application to the Application Retailer which is downloaded to the Passenger smartphone.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 45:

Mobile Fare App Business Models

Open Payment using Bankcard

✓ Transit's role is as a merchant

✓ Hardware validation using NFC

✓ Requires external identity and financial authentication of payment

The diagram shows an instance of the IFMS architecture for an open payment using bankcard business model. Two external system managers boxes with merchant acquirer and bank card issuer in each. One blue box representing Virtual Wallet for the Identify Provider. One green box representing Apple/Google store for the Application Retailer role. Two orange boxes representing the customer smartphone for Passenger and Product Owner roles. One brown box and cloud representing the transit agency and its validator/POS EFPS for (1) Transport Service Provider and Collection and Forwarding, respectively. The linkages are as follows: the Merchant acquirer is connected to the Bank Card issuer and the Collection and Forwarding cloud. The Bank Card Issuer is also connected to the Application Retailer. The Account Retailer is connected to the Product Owner. The Product Owner is connected to the Passenger; the passenger is connected to the Transport Service Operator. The Transport Service Operator is connected to the Collection and Forwarding functions.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 46:

Mobile Fare App Business Models

Open Payment using Transit Wallet

The diagram shows an instance of the IFMS architecture for an open payment using transit wallet business model. Two external system managers boxes with merchant acquirer and bank card issuer in each. One blue box representing Virtual Wallet for the Identify Provider. One green box representing Apple/Google store for the Application Retailer role. Two tan boxes representing the app vendor for the Application Owner and retailers for the Top-up Retailers/Fulfillers (POS). One orange box representing the customer smartphone for Passenger. Three brown boxes and cloud representing the transit agency and its validator/POS EFPS for (1) Transport Service Operator, Product Owner, Payment/Account Provider (EFPS) with embedded box with a Balance Holder label and Collection and Forwarding for the validator. The linkages are as follows: The Merchant acquirer is connected to the Bank Card issuer and the Collection and Forwarding cloud. The Bank Card Issuer is also connected to the Application Retailer. The Application Retailer is connected to the Application Owner and the Passenger. The Passenger is connected to the Identity Provider and the Transport Service Operator, the Payment/Account Provider and the Top-Up Retailer/Fulfiller (POS). The Payment/Account Provider is connected to the Product Owner and Top-Up Retailer/Fulfiller (POS). The Transport Service Operator is connected to the Collection and Forwarding functions.

✓ Multimodal mobility and event product integration

✓ Hardware validation using NFC

✓ Requires external identity and financial authentication of payment

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 47:

Mobile Fare App Business Models

Software Development Kit

✓ Multimodal mobility and event product integration

✓ Hardware validation using either QR or NFC

✓ Centralized payment model

The diagram shows an instance of the IFMS architecture for an SDK business model. Legend – Blue box or cloud represents the EFPS. Dark brown box represents a mobility service provider. Brown box represents a Transit Operator. Tan box represents an App vendor. Green box represents an app store (Google or Apple). Orange box represents a customer (mobile app). Account Provider (blue box) with embedded box labeled Ticket Balance) is EFPS. Account Owner (blue box) is EFPS SDK. Product Owner (orange box) is Customer Mobile App. Transport Service Provider (series of brown boxes) is Transit Agency. Passenger (orange box) is Customer. Collection and Forwarding (blue cloud) is Validator/POS EFPS. Application Retailer (green box) is App Stores – Apple/Google. Account Provider (dark brown box) includes an embedded box labeled Balance Holder is Mobile Service Provider. Transport Service Operator (series of dark brown boxes) is Mobile Service Provider. Application Owner (series of tan, blue and dark brown boxes) represents one or more app vendors, EFPS or mobility service providers. Top-Up Retailer/Fulfillment (POS) (series of tan, blue and dark brown boxes) represents one or more app vendors, EFPS or mobility service providers. The linkages are as follows: The Account Provider (EFPS) is connected to the Application Owner and Product Owner. The Account Providers (EFPS and Mobility Service Providers) are connected to Top-up Retailer/Fulfillment (POS). The Account Provider (Mobility Service Provider) is connected to the Collection and Forwarding. The Passenger is connected to the Transport Service Operator and the Collection and Forwarding cloud. The Transport Service Operator is connected to the Product Owner and Transport Service Operator (Transit Agency). The Application Owner loads the application to the Application Retailer which is downloaded to the Product Owner smartphone.

Example icon. Can be real-world (case study), hypothetical, a sample of a table, etc.

 

Slide 48:

IFMS Concept Model and Use Case Descriptions

IFMS Use Case Categories

use case

"description of a process by defining a sequence of actions performed by one or more actors and by the system itself"

[Source IFMS, Section 2.36]

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 49:

Fare App Actors and Use Cases

Please see extended text description below.

(Extended Text Description: On the left side of the slide is a flow chart (from top to bottom). Brown box with Product Owner, Transit Agency to the Orange box with Passenger, Customer fare "QR code" in mobile app connected (tagged with label A) to the Brown box with Transport Service Operator, Transit Agency connected (tagged with label B) to the Blue cloud with Collection & Forwarding. The Collection & Forwarding cloud is connected (tagged with label C) to the Product Owner.

To the right is the following table:

Use case name Use and inspection of products
Outline The Service Operator checks and collects the data of a Customer Medium using the public transport service.
Triggered by Service Operator
Actor(s) Customer
Service Operator
Collection and Forwarding
Product Owner
Use case description

A Customer who uses a product on public transport. The use case consists of several processes performed by the Service Operator:

  • detection and verification of application;
  • detection, selection and verification of product;
  • verification of application and product according to security policies;
  • processing of product data;
  • communication between customer medium and Back Office;
  • computation of product rules;
  • collection of the product usage and inspection data;
  • distribution of product usage and inspection data to the Product Owner through the Collection and Forwarding.

Inspection consists of

  • simple detection,
  • detection and verification, or
  • detection, verification and further processing.

The table includes sections that are highlighted. Label A highlights the following text:

Service Operator:

Label B highlights the following text:

and:

Inspection consists of

Label C highlights the following text:

)

Example using a white label with hardware model

 

Slide 50:

Fare App Actors and Use Cases

Similar to the previous slide with a change in the flow diagram roles: On the left side of the slide is a flow chart (from top to bottom). Orange box with Product Owner, Virtual Card to the Orange box with Passenger, Customer smart wallet device connected (tagged with label A) to the Brown box with Transport Service Operator, Transit Agency connected (tagged with label B) to the Blue cloud with Collection & Forwarding. The Collection & Forwarding cloud is connected (tagged with label C) to the Product Owner. Labels text is the same as slide #49.

Same use case but using an open payment with bank card model

 

Slide 51:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

 

Slide 52:

Question

What is a Software Development Kit? Answer Choices

  1. A stand-alone application that can be installed on a workstation
  2. A first aid kit for your computer
  3. A set of interfaces that can be used to exchange information between two applications.
  4. A software library for building applications, interfaces, and user interfaces.

 

Slide 53:

Review of Answers

A small graphical red and yellow X representing incorrect.a) Stand-alone application
Incorrect. A stand-alone application is already built.

A small graphical red and yellow X representing incorrect.b) First aid kit for your computer
Incorrect. These are diagnostic tools.

A small graphical red and yellow X representing incorrect.c) Set of Interfaces
Incorrect. These are APIs. APIs are a subset of an SDK library.

A small graphical green and yellow check mark representing correct.d) Software library
Correct! An SDK provides interfaces and tools (including compiler, installation tools, and functions) to build software typically on a specific platform (like a mobile device running a specific operating system).

 

Slide 54:

Learning Objective 4

 

Slide 55:

This slide contains a graphic with the word "Case Study" in large letters. A placeholder graphic of a traffic control center indicating that a real-world case study follows.

 

Slide 56:

Regional Transportation District -Denver

RTD App Model

Author's relevant description: For example only: RTD Rail and Flatiron Flyer Map

 

Slide 57:

Regional Transportation District -Denver

RTD App Implementation

Author's relevant description: A graph of the RTD Denver Passenger Fare Sales – 2019. The graph shows the trends categories for fare value (in millions) by month from Nov 17 to Dec 19 for the following categories: Mobile ticketing (red), Farebox (blue), TVM (yellow), Employee Pass Program (dark green), Paper Ticket Books (light green), Smart Card Stored Value (brown) and all other fares (light brown). An arrow labeled “Mobile Ticketing” points to the red line which shows a steady rise from 0.00 value to 2.00 over the time period. All other fare sales remain relatively the same over the period.

Courtesy of Tonya Anderson RTD, presented at Payments Conference 2020

 

Slide 58:

Regional Transportation District -Denver

Mobile Integration with Uber & Next Ride Apps

Author's relevant description same as title slide 3: This slide contains a graphic of three smart phone app screens. The first in the series is of the RTD (Regional Transit District of Denver). It is a branded RTD page that shows a graphic of the RTD bus with several user options including “buy tickets”, “ticket wallet”, “account”, “trip planner” and “next ride”. The second screen is of an UBER app which shows a map of Denver and users options including “UberX $34.28”, “Comfort $42.84”, and “Transit $10.50-10.50, See Routes”. The third screen is of the Transit App which shows a map with multicolored placeholders for transit stops. The app includes a search function with a field “where to”. It also includes quick selections and estimated time to arrive at current stop for “D Mineral”, “F Ridgegate”, “5L Billings via E Colfax Ave”. At the bottom of the app, the user can select the RTD branded selection to “Buy ticket”.

 

Slide 59:

Regional Transportation District -Denver

RTD App and Uber Integration

Author's relevant description: The figures (from left to right) show two smart phone screens, the first is an Uber app screen and the second is the RTD QR Code screen. A graphic is presented next to the two smart phone screens that show the RTD Denver Ticket Sales in the Uber App from May 2019 to December 2019. 44,000 tickets sold; 16.5% month-over-month growth. A label pointing to the trend line in July says 100% launched.

Courtesy of Tonya Anderson RTD, presented at Payments Conference 2020

 

Slide 60:

Smart Columbus

A SmartColumbus logo is show on the top left-hand corner.

Common Payment System (CPS)

✓ Single-account, single-payment integrated mobility platform including reservations and payment

✓ Public sector will manage relationship with rider for trip planning and ticket purchasing across public and private transportation

✓ Payment component of open-source "Smart Columbus" trip-planning platform

A graphic shows four overlapping circles: Travelers using MMTPA (yellow), Account-based CPS (red), Mobility Providers (blue), Operating System (in center, black). The Mobility Provider circle includes 7 smaller light blue circles surrounding it from top counterclockwise to bottom: TNCs, COTA, Carshare, Bikeshare, Taxi/Limo, Paratransit, Car/Vanpool.

Source: Smart Columbus

 

Slide 61:

Smart Columbus

A SmartColumbus logo is show on the top left-hand corner.

CPS Enables the Mobility Marketplace

A photograph of a man holding a smartphone communicating to a bicycle pushed by a woman. The communication is depicted with a line that include the following labels (starting from the man to the bike) Multimodal trip confirmed, payment received, bicycle pick-up 30 feet. The picture is entitled “Multimodal Trip Planning Assistance/Common Payment System”

Source: Smart Columbus

CPS APIs integrate with registering cash boxes on bus, taxi, limo, carpool, Via, bikeshare and carshare services, among others.

 

Slide 62:

Dallas Area Rapid Transit

Top left corner is the logo for GOPass

A timeline with the following labels from left to right: 2013 GoPass 1.0 Ticketing Trip planning Special events and offers Regional app, 2014 Admission Tickets State Fair of Texas Zoo CFC NCAA, 2015 Deep Linking Uber Lyft Zipcar, 2016 Introduced Corporate and University Pass, 2017 FTA Grant Recipient, 2018 GoPass 2.0 Real-time Cash-to-mobile Fare capping Apple Pay GoPass Wallet, 2019 GoPass 3.0 Multimodal Microtransit UberPool Bird Rideshare choices.

Courtesy of Dallas Area Rapid Transit

 

Slide 63:

Dallas Area Rapid Transit

Top left corner is the logo for GOPass

Robust Trip Planning, Ticketing & Payment platform

Please see extended text description below.

(Extended Text Description: The graphic shows a hand holding a smartphone with the screen of DCbus day pass visible. The functions of the app are described around the phone. They include the following:

Mature Multi-Agency Platform

Multi-Modal Trip Planning

Digital Payments & Cash to Mobile

Rider and Operator Safety & Security

Additional Rider Support

Regional Events and Wayfinding

Fully Integrated Microtransit

)

Courtesy of Dallas Area Rapid Transit

Supplement icon indicating items or information that are further explained/detailed in the Student Supplement.

 

Slide 64:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

 

Slide 65:

Question

Which of the following is an incorrect statement related to the RTD Mobile App?

Answer Choices

  1. The RTD mobile fare app is implemented as a SaaS
  2. RTD manages the interface with Uber
  3. RTD uses visual verifiable validation of mobile fare products
  4. All fare products offered on RTD's mobile fare app are also offered on the Uber app

 

Slide 66:

Review of Answers

A small graphical red and yellow X representing incorrect.a) The RTD mobile fare app is implemented as a SaaS
Incorrect. This is a correct statement.

A small graphical green and yellow check mark representing correct.b) RTD manages the interface with Uber
Correct! Masabi (not RTD) manages the interfaces, settlement and other technical matters associated with integration with Uber.

A small graphical red and yellow X representing incorrect.c) RTD uses visual verifiable validation of mobile fare products
Incorrect. This is a correct statement.

A small graphical red and yellow X representing incorrect.d) All fare products offered on RTD's mobile fare app are also offered on the Uber app
Incorrect. This is a correct statement.

 

Slide 67:

Learning Objective 5

 

Slide 68:

Understanding Challenges

Challenges to Implementation

 

Slide 69:

Understanding Challenges

Validation and "proof of payment"

Visual Verifiable Validation

QR Code

NFC (Virtual Card, Open Payment)

 

Slide 70:

Understanding Challenges

Mobile Handset Performance

Handsets (and wearables) don't work the same

Impacts

 

Slide 71:

Understanding Challenges

Security and Personally Identifiable Information

Privacy Laws and Policies

Please see extended text description below.

(Extended Text Description: Graphic of Identity Management system is composed of several geometric figures:

  1. Legends for PII (enclosed frame) with three labels Identifier (blue), attribute (green), and External registry (yellow)
  2. Entity, Traveler (person) (blue circle with person icon)
  3. 1 to 1 relationship (green double sided arrow) pointing between Entity and Identify Provider
  4. Identify Provider (circle enclosing several labels of varying colors) showing Personal Identifiable Information
    1. ID person (blue)
    2. Name, Age, Address (grouped, labels are in green)
    3. Authentication Credentials (green)
    4. Etc (green)
    5. Driver's License (yellow)
    6. Payment data (yellow)
  5. External ID services (yellow box) with arrow pointing to Entity and another arrow pointing to Identity Provider
  6. 1 to N (green double sided arrow) pointing between Identity Provider and multiple Personalized Account / Media
  7. Multiple sets of Personalized Account / Media (grouped objects). Each object is labeled as Identity ID[1] and includes the following objects
    1. Entity – cell phone icon
    2. Two grouped objects –
      1. ID account (or media) (blue)
      2. Credentials (green)
  8. Anonymous Media (similar to Personalized Account / Media, but without any connections)

)

Adapted from IFMS, Appendix C Identity Management

 

Slide 72:

Understanding Challenges

Equity

Author's relevant description: Mobile App for PSTA Direct Connect Program smart phone screen shot. Uber app screen show with the addition option of PSTA TD Late Shift, Billed to company. An arrow points to a red circle that envelops the PSTA option.

Courtesy of Bonnie Epstein (PSTA)

 

Slide 73:

Activity Placeholder: This slide has the word “Activity” in large letters at the top of the slide, with a graphic of a hand on a computer keyboard below it.

 

Slide 74:

Question

What media type presents a challenge to collect ridership information?

Answer Choices

  1. NFC
  2. Flash pass
  3. QR code
  4. Open Payment

 

Slide 75:

Review of Answers

A small graphical red and yellow X representing incorrect.a) NFC
Incorrect. NFC is validated by a card reader which records time and location.

A small graphical green and yellow check mark representing correct.b) Flash pass
Correct! A flash pass typically is not validated by a card reader which stores and records time and location.

A small graphical red and yellow X representing incorrect.c) QR Code
Incorrect. QR code is validated by a card reader which records time and location.

A small graphical red and yellow X representing incorrect.d) Open Payment
Incorrect. Payment transactions are validated by a card reader which records time and location.

 

Slide 76:

Module Summary

 

Slide 77:

We Have Now Completed the Fare Ticketing/ Payment Curriculum

A small graphical green and yellow check mark representing correct.MODULE 10:
Electronic Fare Payment System

A small graphical green and yellow check mark representing correct.Module 12:
Electronic Fare Payment/Advanced Payment Systems: Open Payments Acceptance

 

Slide 78:

Thank you for completing this module. Feedback

Please use the Feedback link below to provide us with your thoughts and comments about the value of the training.

Thank you!

↑ Return to top