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:
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
- Review Electronic Fare Payment (Module 10) and Advanced Electronic Fare Payment (Module 12) concepts
- Define concept of mobile payment
- Describe electronic fare payment business models
- Review Case Studies on emerging trends in implementing fare payment apps
- Understand challenges related to mobile technologies
Slide 6:
Learning Objective 1
- Review Electronic Fare Payment Systems (EFPS) concepts from Modules 10 & 12
- Identify mobile fare within the context of EFPS
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
- Point of Sale
- Sell payment products
- Store payment products (ticket, period pass, stored value)
- Proof of Payment
- Activate fare products
- Validate access rights for conductor, inspector, operator, or gate/validator device
Slide 9:
Mobile Fare Ticketing / Payment
Mobile Payment Systems Operator
Roles and Responsibilities
- Develops and operates a mobile payment system
- Recruits issuers and enables integration with their system
- Offers a mobile app and/or mobile wallet to cardholders that enables use of the mobile payment system
- Facilitates virtual card account setup by cardholders
- Performs front end cardholder identification (e.g., biometrics)
- Provides front end card data security (e.g., tokenization)
- Examples
- Apple Pay
- Google Pay
- Various banks with virtual cards
- Examples
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:
- Mobile platforms and devices
- System Status
- Transit Modes using mobile apps
- Fare Products offered
- Regional Integration
- Accessibility features
App features/functions
- Activation
- Validation approach
- Customer facing features
Slide 12:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Characteristics
- Mobile platforms/devices
- 100% responded with Android and iPhone/iOS
- System status
- 77% (48) responded that the mobile fare app is a permanent deployment
- Significant number of agencies launched fare app in 2017 (31%)
- Transit modes accepting mobile payment
- Bus 84%
- Demand responsive 29%
- Commuter / light rail 24%
- Ferry 11%
- Heavy rail (subway) 2%
Slide 13:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Characteristics, cont.
- Fare Products Offered
- Regular single (95%) /multiple ride (69%)
- Period passes (82%)
- Reduced fare (90%)
- Regional Integration: do other agencies app use same app for payment
- No integration (56%)
- Yes (37%)
- Trend is increasing to integrate payment into a regional app
- Accessibility Features
- Large fonts, high contrast, features for people with visual disabilities and audio assist for people with hearing disabilities
- Limited use of "wearables" (e.g., glasses or watches)*
Source: King County Metro
Slide 14:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Features
- Activation
- "The process of making a mobile fare product valid for a given period of time"
- May be activated on-line or off-line 50%
- Must be on-line to activate 29%
- Primary Validation Method
- Visual validation 87%
- May also include Near Field Communication (NFC) (7%) or Quick Response (QR) / bar code (32%)
- QR code 6%
- At the time 0% used Bluetooth or NFC
- Visual validation 87%
QR code displayed in mobile ticket Source: Regional Transportation District (Denver)
Slide 15:
Mobile Fare Ticketing / Payment Features
Mobile Fare Payment App Features, cont.
- Customer Facing Features
- Real time transit information (29%)
- Transit schedules (34%)
- Trip planning (34%)
- Reporting (12%)
- Integration with MaaS specifically ridehailing / bikesharing (8%)
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
- Widely adopted standard for short range communications between cards and readers
- Applies to physical and virtual cards
- Incorporated in all the leading contactless bankcard specifications
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)
- Better known as near field communications (NFC)
- Defines methods to enable short-range mobile phones and readers
- Uses ISO/IEC 14443 communications protocols
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
- Requirements apply to contactless/virtual bankcards, equipment and transactions
- Unique specification for each network
- Card network programs
- Visa payWave
- Mastercard PayPass
- American Express ExpressPay
- Discover ZIP
- GooglePay
- ApplePay
- May change with little advance notice
Source: Adapted from Transit Module 12
Slide 20:
Relevant Standards and Practices
Card Network Operating Rules
- Defines rules for acceptance of cards and mobile payment linked to cards
- Unique rules for each network
- Updated semi-annually
- Not true specification per se
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
- Vendor
- Social Media
- Agency
- App Store
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
- Define concept of mobile payment
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".
- Bank cards such as PNC
- Ventra Apple wallet
- OMNY Google wallet
Payment apps - mobile app that provides sales, customer services and account management support to customers.
- CapMetro App (Capital Metro, Austin)
- TouchPass Mobile App (Victor Valley Transit Authority)
Peer-to-peer payment apps - mobile app that enables the electronic transfer of money between two bank accounts.
- Examples of apps: Venmo, Paypal.Me, clearXchange
Cryptocurrency Apps and Wallets - mobile apps to manage and pay for services using cryptocurrency
- Examples of apps: Coinbase, Blockchain
Slide 26:
Fare Payment Proof of Purchase
Fare Proof of Purchase Methods
- Visual Verifiable Validation (V3) or "Flash" pass
- QR Code
- NFC (virtual card)
- Transit Wallet
- Open Payment
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.
- Uses ISO/IEC 18004:2015 Information - Automatic identification and data capture techniques - QR Code barcode symbology specification
- Requires QR Code Generator
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)
- Secure Element is a hardware storage device to secure PII.
- Embedded storage (internal)
- SIM / UICC Card (external)
- SD Card (external)
- Host-based Card Emulation (HCE) is commonly used in place of a hardware-based secure element to secure the PII by using a unique alias or token to communicate with information stored in a cloud.
- Tokenization is the process used to generate a token for the information, storing the token in an HCE, and storing the PII in a more secure environment.
- NFC controller in mobile device directly routes data (transactions) from secure element to and from NFC card reader
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
- SDK
- API
- Walled garden
- Deep link
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
- Describe electronic fare payment business models
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
- Describes interaction between actors irrespective of
- business model,
- fare payment method, or
- validation method
- Categories cover functionality associated with payment system
- Define set of rules
- Certification
- Interaction with external objects (media, applications, ID services, payment/financial services)
- Registration
- Managing ID services
- Management of customer accounts
- Management of customer media
- Management of applications
- Security management
- Customer service management
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:
- detection and verification of application;
- detection, selection and verification of product;
- verification of application and product according to security policies;
Label B highlights the following text:
- processing of product data;
- communication between customer medium and Back Office;
- computation of product rules;
- collection of the product usage and inspection data;
and:
Inspection consists of
- simple detection,
- detection and verification, or
- detection, verification and further processing.
Label C highlights the following text:
- distribution of product usage and inspection data to the Product Owner through the Collection and Forwarding.
)
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
- A stand-alone application that can be installed on a workstation
- A first aid kit for your computer
- A set of interfaces that can be used to exchange information between two applications.
- A software library for building applications, interfaces, and user interfaces.
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
- Emerging trends in implementing fare payment apps
Slide 55:
Slide 56:
Regional Transportation District -Denver
RTD App Model
- Uses Software as a System (SaaS) Mobile Ticketing Platform (Masabi)
- Other Functionality - deep link to RTD Trip Planner and Next Ride apps
- Business Model: white label
- Modes
- Regular bus,
- FlexRide,
- SkyRide, and
- Train services
- Validation Method:
- QR Code
- Potential for 40% in Ticket Vending Machines (approx. $4.5M savings in TVM replacement costs as customers shift to mobile fare app)
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
- Happened organically through existing contractual relationship with app provider
- Took advantage of the APIs developed by vendor's SaaS Mobile Ticketing platform to integrate ridehailing service (Uber)
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
- GoPass supports multiple Agencies across DFW region
- In operation since 2013, frequent feature additions
- Currently scaling to different regional partners
- White-label platform version also available
Multi-Modal Trip Planning
- Seamless end-to-end directions for Point A-B-C
- Real-time vehicle status updates
- Map interface displaying DART vehicles in motion
- Additional options for TNCs & Micro-Mobility (Uber, Bird)
Digital Payments & Cash to Mobile
- Cash-to-Mobile supporting unbanked riders (7-Eleven, Tom Thumb, Ace Cash & More)
- Google Pay, Apple Pay, All Major Credit Cards
- Digital Wallet solution for loading and storing value
Rider and Operator Safety & Security
- DART See Something Say Something integration alerts authorities to incidents and protect rider safety
- Rider Alerts from Agency presented to flag issues to riders
Additional Rider Support
- Support to service riders in transit deserts through on-demand services
- Integrated Concessions for eligible riders (Low income programs, minors, seniors)
- Support for riders with additional needs (wheelchair, service animal)
Regional Events and Wayfinding
- Presents and sell tickets to key regional events such as State Fair and NCAA events
- Local events promotion and listing through App
Fully Integrated Microtransit
- GoPass includes full integration of GoLink™
- VIA Microtransit integration is planned for Q3 2020
- App intelligently offers Microtransit options for trips with origin or destination within defined zones, linking to transit hubs
)
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
- The RTD mobile fare app is implemented as a SaaS
- RTD manages the interface with Uber
- RTD uses visual verifiable validation of mobile fare products
- All fare products offered on RTD's mobile fare app are also offered on the Uber app
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
- Understand challenges related to mobile technologies
Slide 68:
Understanding Challenges
Challenges to Implementation
- Validation and "Proof of Payment"
- Mobile Handset Performance
- Security and Personal Information
- Equity
Slide 69:
Understanding Challenges
Validation and "proof of payment"
Visual Verifiable Validation
- Does not collect ridership information
- May require on-line access and validate ticket to prevent fraud
QR Code
- As V3, does not collect ridership information
- When scanned, requires back office or active list update in real time
- Requires QR reader or inspection tool
NFC (Virtual Card, Open Payment)
- When read, requires payment gateway or active list authentication in real time (current card read/write is less than 300ms)
- Requires NFC reader or inspection tool
Slide 70:
Understanding Challenges
Mobile Handset Performance
Handsets (and wearables) don't work the same
- Antenna position
- Antenna size and quality
- Effect of nearby interference
- Power levels
- On all the time vs. only when activated (Android vs. older IOS)
Impacts
- Reading position
- What is the optimal position and angle relative to reader
- Signal strength
- Secure element handoff to NFC communications controller
- Tap speed - handshake and transfer data
- Tap distance from reader
Slide 71:
Understanding Challenges
Security and Personally Identifiable Information
Privacy Laws and Policies
- European Union's General Data Protection Regulation (GDPR)
- California Consumer Privacy Act (CCPA)
- Health Insurance Portable and Accountability Act (HIPAA)
(Extended Text Description: Graphic of Identity Management system is composed of several geometric figures:
- Legends for PII (enclosed frame) with three labels Identifier (blue), attribute (green), and External registry (yellow)
- Entity, Traveler (person) (blue circle with person icon)
- 1 to 1 relationship (green double sided arrow) pointing between Entity and Identify Provider
- Identify Provider (circle enclosing several labels of varying colors) showing Personal Identifiable Information
- ID person (blue)
- Name, Age, Address (grouped, labels are in green)
- Authentication Credentials (green)
- Etc (green)
- Driver's License (yellow)
- Payment data (yellow)
- External ID services (yellow box) with arrow pointing to Entity and another arrow pointing to Identity Provider
- 1 to N (green double sided arrow) pointing between Identity Provider and multiple Personalized Account / Media
-
Multiple sets of Personalized Account / Media (grouped objects). Each object is labeled as Identity ID[1] and includes the following objects
- Entity – cell phone icon
- Two grouped objects –
- ID account (or media) (blue)
- Credentials (green)
- Anonymous Media (similar to Personalized Account / Media, but without any connections)
)
Adapted from IFMS, Appendix C Identity Management
Slide 72:
Understanding Challenges
Equity
- Unbanked or underbanked
- Limited English Language
- Access to smart phone or cellular communications
- Limitations using smart phone
- Due to training or disability
Courtesy of Bonnie Epstein (PSTA)
Slide 73:
Slide 74:
Question
What media type presents a challenge to collect ridership information?
Answer Choices
- NFC
- Flash pass
- QR code
- Open Payment
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
- Mobile fare payment standards use many of the same standards as card and account-based systems
- New payment technologies and standards are emerging that support mobile fare payment
- Although fare payment business models differ, open APIs and SDKs enable integration with multiple agencies, mobility services and providers
- Mobile payment methods that may be used for fare and ticketing are becoming more prevalent even as new challenges arise.
- In deploying mobile fare apps, the important lesson is to adopt technologies that meet your business goals and data needs.
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!