(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:
Slide 2:
Slide 3:
Module 21 Mobile Fare Ticketing/Payment
Graphic courtesy of Regional Transit District - Denver
Slide 4:
Instructor
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.
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
Who owns cellphones and smartphones
Source: Pew Research- Mobile Fact Sheet (2020)
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
Slide 12:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Characteristics
Slide 13:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Characteristics, cont.
Source: King County Metro
Slide 14:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Features
QR code displayed in mobile ticket Source: Regional Transportation District (Denver)
Slide 15:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Features, cont.
Source: CapMetro Mobile Traveler and Payment App
Slide 16:
Key Mobile Fare Ticketing / Payment Roles & Responsibilities
Mobile Fare Payment App System Roles and Responsibilities
(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:
Slide 22:
Question
Who does the primary marketing of an agency's fare app to riders?
Answer Choices
Slide 23:
Review of Answers
a) Vendor
Incorrect. Only 7% of vendors promote an agency's fare app.
b) Social Media
Incorrect. Although social media might help promote the app, the primary marketing is performed by the agency.
c) Agency
Correct! Respondents of TCRP Synthesis 148 responded that the agency markets the app to riders.
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
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
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.
Slide 29:
Fare Payment Proof of Purchase
Fare Proof of Purchase Method - Mobile Open Payment
Slide 30:
Fare Payment Proof of Purchase
Fare Proof of Purchase Method - Transit Wallet
Example: Ventra virtual card
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
Slide 32:
Mobile App Technology Terminology
Secure Element
Mobile providers use a secure element to protect personally identifiable information (PII)
Slide 33:
Mobile App Physical Architecture
Conceptual View of Mobile App Physical Architecture
The NFC Controller channels the token directly to NFC Reader
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)
Slide 35:
Fare Payment Role Based Architecture
Open Payment (PAYG) with a Transit Wallet
Source: IFMS-1 v3, Appendix B
Slide 36:
Fare Payment Role Based Architecture
Open Payment with a Virtual Bankcard
Source: IFMS-1 v3, Appendix B
Slide 37:
Slide 38:
Question
What payment access method is most proprietary? Answer Choices
Slide 39:
Review of Answers
a) SDK
Incorrect. SDK is typically a toolkit for incorporating open functions into and information exchanges with another application.
b) API
Incorrect. APIs are open specifications for exchanging information between two applications.
c) Walled Garden
Correct! Walled garden refers to applications that are closed with the intention of securing and restricting access.
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
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
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
Note: removed External Systems from this diagram
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
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
Slide 46:
Mobile Fare App Business Models
Open Payment using Transit Wallet
✓ Multimodal mobility and event product integration
✓ Hardware validation using NFC
✓ Requires external identity and financial authentication of payment
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
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]
Slide 49:
Fare App Actors and Use Cases
(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:
Inspection consists of
|
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
Same use case but using an open payment with bank card model
Slide 51:
Slide 52:
Question
What is a Software Development Kit? Answer Choices
Slide 53:
Review of Answers
a) Stand-alone application
Incorrect. A stand-alone application is already built.
b) First aid kit for your computer
Incorrect. These are diagnostic tools.
c) Set of Interfaces
Incorrect. These are APIs. APIs are a subset of an SDK library.
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:
Slide 56:
Regional Transportation District -Denver
RTD App Model
Slide 57:
Regional Transportation District -Denver
RTD App Implementation
Courtesy of Tonya Anderson RTD, presented at Payments Conference 2020
Slide 58:
Regional Transportation District -Denver
Mobile Integration with Uber & Next Ride Apps
Slide 59:
Regional Transportation District -Denver
RTD App and Uber Integration
Courtesy of Tonya Anderson RTD, presented at Payments Conference 2020
Slide 60:
Smart Columbus
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
Source: Smart Columbus
Slide 61:
Smart Columbus
CPS Enables the Mobility Marketplace
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
Courtesy of Dallas Area Rapid Transit
Slide 63:
Dallas Area Rapid Transit
Robust Trip Planning, Ticketing & Payment platform
(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
Slide 64:
Slide 65:
Question
Which of the following is an incorrect statement related to the RTD Mobile App?
Answer Choices
Slide 66:
Review of Answers
a) The RTD mobile fare app is implemented as a SaaS
Incorrect. This is a correct statement.
b) RTD manages the interface with Uber
Correct! Masabi (not RTD) manages the interfaces, settlement and other technical matters associated with integration with Uber.
c) RTD uses visual verifiable validation of mobile fare products
Incorrect. This is a correct statement.
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
(Extended Text Description: Graphic of Identity Management system is composed of several geometric figures:
Adapted from IFMS, Appendix C Identity Management
Slide 72:
Understanding Challenges
Equity
Courtesy of Bonnie Epstein (PSTA)
Slide 73:
Slide 74:
Question
What media type presents a challenge to collect ridership information?
Answer Choices
Slide 75:
Review of Answers
a) NFC
Incorrect. NFC is validated by a card reader which records time and location.
b) Flash pass
Correct! A flash pass typically is not validated by a card reader which stores and records time and location.
c) QR Code
Incorrect. QR code is validated by a card reader which records time and location.
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
MODULE 10:
Electronic Fare Payment System
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!