Visa Urban Mobility

Implementation Guide

January 2024
Version 2.1
Visa Confidential

Visa Acceptance Solutions

Visa Urban Mobility Legal
Implementation Guide

Important Information on Confidentiality and Copyright

Notice: The Visa Confidential label signifies that the information in this document is proprietary and
CONFIDENTIAL to Visa. It is distributed to Visa participants for use exclusively in managing their
Visa programs. It must not be duplicated, published, distributed or disclosed, in whole or in part, to
merchants, cardholders or any other person without prior written permission from Visa.

The trademarks, logos, trade names and service marks, whether registered or unregistered
(collectively the “Trademarks”) are Trademarks owned by Visa. All other trademarks not attributed to
Visa are the property of their respective owners.

Note: This document is not part of the Visa Rules. In the event of any conflict between any
content in this document, any document referenced herein, any exhibit to this document, or any
communications concerning this document, and any content in the Visa Rules, the Visa Rules shall
govern and control.

Visa does not provide legal, regulatory, tax or financial advice. Each participant is fully responsible for
ensuring that its program operates in compliance with applicable legal and regulatory requirements
and is responsible for conducting independent legal and regulatory reviews through its legal
counsel.

THIS PUBLICATION COULD INCLUDE TECHNICAL INACCURACIES OR TYPOGRAPHICAL ERRORS.

CHANGES ARE PERIODICALLY ADDED TO THE INFORMATION HEREIN: THESE CHANGES WILL
BE INCORPORATED IN NEW EDITIONS OF THE PUBLICATION. VISA MAY MAKE IMPROVEMENTS
AND/OR CHANGES IN THE PRODUCT(S) AND/OR THE PROGRAM(S) DESCRIBED IN THIS
PUBLICATION AT ANY TIME.

If you have technical questions or questions regarding a Visa service or questions about this
document, please contact your Visa representative.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 2
Visa Urban Mobility Document history
Implementation Guide

Document history

Version Date Comment

1.0 August 2017 Initial Version.

1.1 June 2018 General updates.

Deferred Authorizations.
Authorization validity times.
Clarification of issuer requirements.
Clarification to CVL approach.
Dispute resolution updates.

1.2 October 2020 Document title change.

Clarifications and updates around debt recovery.
Inclusion of mobility adjacent additional payment options.
General updates and revisions.

2.0 May 2023 Inclusion of Tap to Phone for Deferred Authorizations.

Clarifications to shared liability and debt recovery.
Additional clarification of issuer best practice.
General updates and revisions.

2.1 Jan 2024 Additional clarification on Table 8.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 3
Visa Urban Mobility References
Implementation Guide

Referenced or related documents

System type Description Author Location

[VCPS] Visa Contactless Payment Visa Visa Online (VOL) or via

Specification acquirer for UM operators.

[VMCPS] Visa Mobile Contactless Visa Visa Online (VOL) or via

Payment Specification acquirer for UM operators.

[VUMTIG] Visa Urban Mobility Visa Visa Online (VOL) or via

Terminal Requirements acquirer for UM operators.
and Implementation Guide

[VCTKS] Visa Contactless Transit Visa Visa Online (VOL) or via

Kernel Specifications acquirer for UM operators.

[BOOK C-3] EMV® Contactless EMVCo www.emvco.com

Specifications for Payment
Systems Book C-3 Kernel 3
Specification

[PCI DSS] Payment Card Industry PCI www.pcisecuritystandards.org

Security Standards

[ISO27001] Information technology, ISO www.iso.org

Security techniques,
Information security
management systems,
Requirements

[MIT] Alignment of Authorization Visa Visa Online (VOL) or via

procedures for Merchant acquirer for UM operators.
Initiated Transactions

[VIPLG] Visa International Private Visa Visa Online (VOL) or via

Label Guidelines acquirer for UM operators.

[VIPPG] Visa International Prepaid Visa Visa Online (VOL) or via

Program Guidelines acquirer for UM operators.

[TTP] Visa Ready Tap to Phone Visa Visa Online (VOL) or via
Solution Requirements v1.9 acquirer for UM operators.
or later

* EMV® is a registered trademark in the U.S. and other countries and an unregistered trademark
elsewhere.
The EMV trademark is owned by EMVCo, LLC

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 4
Visa Urban Mobility Contents
Implementation Guide

Contents

1 About this document 10

1.1 Purpose 10
1.2 Audience 10
1.3 Scope 10
1.4 Document organization 11
1.5 Definitions 12
1.6 Document conventions 16
1.7 Requirement terminology 16
1.8 Visa requirements 16
1.9 For further information 16

2 Overview of Visa Urban Mobility frameworks 17

2.1 High-level comparison of MTT and KFT frameworks 18

3 Mobility & Transport Transaction framework 19

3.1 MTT Overview 19
3.2 Processing overview 20
3.3 Tap processing 21
3.3.1 Offline Data Authentication (ODA) 22
3.3.2 Expiry date check 22
3.3.3 Deny list check 23
3.3.4 New card check 23
3.3.5 Deferred Authorization 24
3.3.6 Urban Mobility operator proprietary processing 25
3.3.7 Urban Mobility operator revenue protection devices 25
3.4 Fare calculation and submission 25
3.4.1 Fare calculation 26
3.4.2 Authorization requirements 26
3.4.3 Deny list management 28
3.4.4 Clearing 29
3.5 Debt recovery 31
3.5.1 Data fields in debt recovery 31
3.5.2 Zero amount debt scenario 32
3.5.3 Merchant initiated 33
3.5.4 Card present tap initiated 35

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 5
Visa Urban Mobility Contents
Implementation Guide

Contents (Continued)

3.5.5 Card not present cardholder initiated 36

3.6 Transaction processing 36
3.6.1 Transaction Identifier 36
3.6.2 Transaction data fields 37
3.6.3 Dates in Authorization and Clearing 39
3.6.4 Transaction Authorization amount 40
3.6.5 Acquirer transaction processing 40
3.6.6 Issuer transaction processing 41
3.7 Exception handling 43
3.7.1 Late or lost data scenario 43
3.7.2 Refunds 44
3.7.3 Revenue protection charges 44

4 Known Fare Transaction framework 45

4.1 KFT overview 45
4.2 Tap processing 45
4.2.1 Handling of Deferred Authorizations 46
4.3 Transaction processing 47
4.3.1 Transaction Identifier 47
4.3.2 Transaction data fields 47
4.3.3 Payment processing 49
4.3.4 Acquirer transaction processing 50
4.3.5 Issuer transaction processing 50

5 Mobility Adjacent Segments 51

5.1 Overview 51
5.2 Cardholder Present overview 51
5.2.1 Card processing 52
5.2.2 Transaction Identifier 52
5.2.3 Transaction data fields 52
5.3 Cardholder Not Present overview 54
5.3.1 Card processing 55
5.3.2 Transaction Identifier 55
5.3.3 Transaction data fields 55

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 6
Visa Urban Mobility Contents
Implementation Guide

Contents (Continued)

6 Urban Mobility operator security requirements 58

6.1 Introduction 58
6.2 PCI DSS requirements 58
6.3 Security best practice 59
6.3.1 Maintaining Compliance as BAU 59
6.3.2 Purpose-designed solutions for Payment Systems 60
6.3.3 Card List Processing 60
6.3.4 Networks and Systems Segmentation 61

7 Card personalization 62
7.1 Support ODA 62
7.2 International use 62

8 Customer service 63
8.1 Urban Mobility operators 63
8.1.1 Conditions of carriage 63
8.1.2 Handling customer queries 63
8.1.3 Online access to transaction data 64
8.1.4 Using the Payment Account Reference 65
8.1.5 Customer education 67
8.2 Issuers 67
8.2.1 Handling customer queries 67
8.2.2 Statement data 67
8.3 Cardholder verification 68

9 Dispute resolution 69
9.1 Urban Mobility operators 69
9.2 Issuers 69
9.3 Acquirers 70
9.4 Dispute resolution summary 70

10 Testing 72
10.1 Urban Mobility operator and vendor responsibilities 72
10.1.1 EMV Level 2 accreditation 72
10.1.2 Visa Level 3 testing 73
10.2 Acquirer responsibilities 73

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 7
Visa Urban Mobility Contents
Implementation Guide

Contents (Continued)

10.2.1 System testing 73

10.2.2 System audit 73
10.3 Issuer responsibilities 74
10.3.1 System testing 74

11 Deployment preparation 75
11.1 Technical readiness checklist 75
11.2 Operational readiness checklist 76
11.3 Market communications readiness checklist 76

12 Appendix
12.1 Visa Acceptance Solutions 77

Tables
Table 1: Document organization 11
Table 2: Definitions 12
Table 3: Document conventions 16
Table 4: Visa Urban Mobility frameworks 17
Table 5: High-level comparison of MTT and KFT frameworks 18
Table 6: Key fields used in original MTT & debt recovery Authorizations 32
Table 7: MTT data fields 37
Table 8: Dates used for an MTT 39
Table 9: Dates used for a tap initiated debt recovery transaction 40
Table 10: KFT data fields 47
Table 11: Key fields used in Contact & Contactless Authorizations 52
Table 12: Key fields used in Contactless-only Authorizations 53
Table 13: Key fields used in Contactless-only Tap to Phone real-time Authorizations 53
Table 14: Key fields used in Contactless-only Estimated/Incremental Authorizations 53
Table 15: Key fields used in E-commerce Authorizations 55
Table 16: Key fields used for In-App Authorizations 56
Table 17: Key fields used in Unscheduled Card-on-File Authorizations 56
Table 18: Dispute resolution condition titles and numbers 71

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 8
Visa Urban Mobility Contents
Implementation Guide

Contents (Continued)

Figures
Figure 1: Overview of the MTT framework 20
Figure 2: Tap processing 21
Figure 3: Fare calculation and submission 25
Figure 4: Merchant initiated debt recovery 34
Figure 5: Tap initiated debt recovery 35
Figure 6: Card not present cardholder initiated debt recovery 36
Figure 7: Overview of Unscheduled Card-on-File and MIT frameworks 57
Figure 8: Overview of Payment Account Reference 66

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 9
Visa Urban Mobility
Implementation Guide

About this
document

1.1 Purpose
This document defines the requirements and provides guidelines for stakeholders involved in the
acceptance and processing of Visa Contactless payments for automatic fare collection in mass transit
or Urban Mobility systems.

1.2 Audience
This document is intended for the following clients:
• Mass transit or Urban Mobility operators and their technology partners implementing contactless
acceptance in conjunction with Deferred Authorization
• Financial institutions and payment service providers acquiring transactions for mass transit or
Urban Mobility operators utilizing Deferred Authorization transaction processing
• Financial institutions issuing contactless-enabled cards (which includes mobile payment devices
and other form factors)

1.3 Scope
This document provides requirements and recommendations to be considered when designing and
building a mass transit or Urban Mobility system that accepts Visa Contactless cards as a method of
automatic fare collection, and requests a card present environment authorization after the cardholder
has left the point of transaction (Deferred Authorization). It also introduces the principal activities that
should be considered to prepare for a successful launch.
This document primarily focuses on best practice, rules, and requirements for implementing
contactless-only Urban Mobility payment frameworks utilizing Deferred Authorizations (i.e. Known
Fare Transactions or Mobility & Transport Transactions).
Retail based Urban Mobility solutions utilizing real-time authorizations are out of scope for Known Fare
Transactions. Card present and card not present retail frameworks may be utilized in Urban Mobility or
adjacent segments, and are covered at a high level within section 5 of this document.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 10
Visa Urban Mobility 1: About this document
Implementation Guide

1.4 Document organization

This document has the following sections:

Table 1: Document organization

Section Description

About this Describes the purpose, audience, scope and organization of this guide.
document

Overview of Visa Describes the high-level background and key features of each of the Visa
Urban Mobility Urban Mobility frameworks.
frameworks

Mobility & Describes the processes, rules, and potential impact to operator, acquirer
Transport and issuer systems in accepting Deferred Authorization Visa Mobility &
Transaction Transport Transactions.
framework

Known Fare Describes the processes, rules, and potential impact to operator, acquirer
Transaction and issuer systems in accepting Deferred Authorization Visa Known Fare
framework Transactions.

Mobility Adjacent Describes the key considerations and processing requirements for some of
Segments the payment methods available to operators accepting other types of Visa
transactions.

Urban Mobility Describes specific security requirements arising from the handling of Urban
operator security Mobility Deferred Authorization transactions, and introduces lessons
requirements learned from current deployments.

Card Highlights the key personalization requirements for Visa Contactless cards
personalization (and other device form factors).

Customer service Describes the considerations that operators and issuers should take into
account when designing their customer service operations and systems.

Dispute Describes how disputes arising from contactless Urban Mobility

resolution transactions should be handled.

Testing Describes how testing should be carried out by clients for their respective
host systems, terminals, or cards.

Deployment Provides a set of checklists to help prepare for launch.

preparation

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 11
Visa Urban Mobility 1: About this document
Implementation Guide

1.5 Definitions
This document uses the following terms and abbreviations.

Table 2: Definitions

Acronym
Description
or term

AD Account Data (e.g. CHD and SAD), as defined in [PCI DSS].

Amount, A data element (tag ‘9F02’) included in an Authorization message that contains
Authorized the amount transmitted to the card when it was tapped on the reader.

ARQC Authorization Request Cryptogram.

ATC Application Transaction Counter.

AVR Account Verification Request. Request submitted to the issuer by the operator’s
acquirer to verify that the account is in good standing and has not been blocked
for any reason. An AVR is not a sales Authorization request and will not verify the
financial standing of the funding account.

Back Office A component within a UM operator’s systems which process taps received from
UM readers, and performs any or all journey construction, fare calculation, risk
management, and payment processing.

CAP Card Additional Processes. A data element within the payment application that
indicates a card’s processing capabilities.

Capping A fare policy implemented by some UM operators whereby the overall fare for
a chargeable period (e.g. a day, week, or month) may be limited to a threshold
that gives the cardholder a favorable price compared to the sum of the individual
journey prices.

Card Clash May occur when more than one contactless card is presented to a UM reader.
The outcome could vary depending on how it has been configured, but
could include the reader denying entry to the UM system or the wrong card
transacting.

CDCVM Consumer Device Cardholder Verification Method.

CHD Cardholder Data, as defined in [PCI DSS].

CIT Customer Initiated Transaction.

CoC Conditions of Carriage. The terms under which a UM operator accepts

passengers for travel.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 12
Visa Urban Mobility 1: About this document
Implementation Guide

Table 2: Definitions (Cont.)

Acronym
Description
or term

Contactless A cardholder payment device carrying the Visa Contactless application. It may
Card or Card be implemented on a plastic card, a mobile phone, a wearable device, or an
alternative form factor.

CVL The Cardholder Verification Limit is the transaction amount above which a valid
CVM is required.

CVM The Cardholder Verification Method is used to evaluate whether the person
presenting a payment device is the legitimate cardholder.

DDA Dynamic Data Authentication. A method of ODA in which a cryptographic value

is dynamically generated by a chip on a card using transaction specific data
elements, and is verified by a chip-reading device to protect against skimming.

Deferred A card present environment Authorization that is requested after the cardholder
Authorization has left the point of transaction.

Deny List Method for blocking cards that have not been accepted for travel within the UM
operator’s system.

EMVCo The international body that governs the standards used by chip-based payment
cards and terminals.

fDDA fast Dynamic Data Authentication. An optimized form of Offline Data

Authentication.

GPO Get Processing Options. A command used by the reader to request that a card
perform a payment transaction.

Issuing BIN First 6 or 8 digits of the PAN. A numeric value used to identify the issuing
institution.

Issuing A numeric value used to define issuing processing. Multiple Issuing BINs can be
Identifier linked to the same Issuing Identifier.

Journey The process of analyzing individual taps received from UM readers and forming
Construction logical journeys performed by cardholders.

Known Fare A contactless transaction performed at the turnstile, gate, or point of access to
Transaction a UM operator’s services where the fare amount is known prior to travel and the
(KFT) authorization request is deferred.

MaaS Mobility as a Service.

Mobility & A contactless transaction performed at the turnstile, gate, or point of access
Transport to a UM operator’s service where the final fare amount is calculated using
Transaction data derived from one or more taps of a Visa card during a travel period. The
(MTT) transaction authorization request is deferred.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 13
Visa Urban Mobility 1: About this document
Implementation Guide

Table 2: Definitions (Cont.)

Acronym
Description
or term

MCC Merchant Category Code.

MID Merchant ID. An acquirer-assigned code identifying the card acceptor for the UM
operator. A UM operator may have one or multiple MID(s) for different purposes.

MIT Merchant Initiated Transaction.

MOTO Mail Order/Telephone Order transaction.

ODA Offline Data Authentication. A method by which a reader ensures a card is genuine.

P2PE Point-to-Point Encryption. P2PE is used to cryptographically protect Account Data

(AD) from the operator’s reader until it reaches a secure environment.

PAN Primary Account Number.

PAR Payment Account Reference. A non-financial unique identifier assigned to each

Visa payment account, in order to link payment activity across the ecosystem,
and facilitate account identification across multiple cardholder payment devices
without using sensitive cardholder data.

Pass-back Operator-specific processing to prevent a single card being used more than once
protection in a given timeframe, to prevent cardholder misuse and potential revenue loss
from re-use.

Pay As You Refers to a cardholder presenting a card at a UM reader to authorize travel without
Go (PAYG) having previously paid for their journey.

Pay-in- Includes Visa Prepaid and Private Label solutions. Physical and digital cards can be
Advance issued for both.
(PIA)

PCI DSS Payment Card Industry Data Security Standard. A standard that ensures that card
and payment data are stored, processed, and transmitted in a secure manner.

Pre- Refers to a cardholder purchasing their ticket or other UM product as a right to

purchase travel before they present it at a UM gate or reader.

QSA Qualified Security Assessor, as defined in [PCI DSS].

SAD Sensitive Authentication Data, as defined in [PCI DSS].

SCA Strong Customer Authentication.

Shared The maximum fare amount that can be submitted to Clearing on an initial decline
Liability response for first card use or a decline response immediately following a previous
Limit (SLL) approval within the MTT framework.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 14
Visa Urban Mobility 1: About this document
Implementation Guide

Table 2: Definitions (Cont.)

Acronym
Description
or term

STIP Stand-In Processing. Service in which Visa will act on behalf of an issuer in the
Authorization process.

Tap Refers to the act of presenting a contactless card at a UM reader. Sometimes

referred to (outside of this document) as “touch”.

Tap Data The data that is captured at a tap for future use by a UM operator, which may
include time and date of tap, mode of transport, and any additional data relevant
to fare calculation.

TC Transaction Certificate.

Token A Visa Network value that replaces and uniquely identifies a PAN, using different
(Visa representation from the original PAN.
Network)

Transaction Also known as Tran ID. This is a unique identifier assigned by Visa to each
Identifier transaction submitted.

UCOF Unscheduled Card-on-File.

UM Urban Mobility.

UM Gate or A physical barrier which controls access to a UM system. Incorporates a UM reader.

Gate

UM A provider of Urban Mobility transport or MaaS offerings assigned MCC 4111

Operator (Local and suburban commuter passenger transportation, including ferries), 4112
(UMO) (Passenger railways), or 4131 (Bus lines), which uses one or more of the frameworks
described in this document to accept Visa card payments.

UM Reader A Visa-approved contactless reader to which the cardholder presents their

or Reader contactless card to gain access to a UM system.

UM A Visa-approved contactless validator to which the cardholder presents their

Validator or contactless card to gain access to a UM system.
Validator

Travel A fixed period (no longer than 24 hours) within which an operator performing
Period Mobility & Transport Transactions accumulates journey tap data for any passenger
using their services.

Visa A card-present transaction using a short-range radio communication from a card in

Contactless compliance with Visa Contactless Payment Specification (VCPS).

VOL Visa Online. A repository for Visa documentation and other stakeholder supporting
materials.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 15
Visa Urban Mobility 1: About this document
Implementation Guide

1.6 Document conventions

The following table lists the conventions used in this document:

Table 3: Document conventions

Convention Description

Important Highlights important text in the guide

Note
Note Provides more information about a topic

Italics Indicates document titles or specific data elements

1.7 Requirement terminology

The terminology for requirements and recommendations is as follows:
• Use of the word “must” denotes a mandatory requirement
• Use of the word “should” denotes a strong recommendation
• Use of the word “may” denotes an optional feature

1.8 Visa requirements

Requirements derived from the Visa Core Rules and Visa Product and Service Rules (“Visa Rules”)
specific to Urban Mobility are embedded in this document as requirements. Each requirement is
included in the following format:

Requirement Number: Rule Subject

(Rule: See ID# of the Visa Rules)
An extract of the key elements of the rule

The summaries of the rules for Urban Mobility found throughout this document are provided for
information only. Please refer to the current version of the Visa Rules for the full definition of the
relevant rule.
Some information found in this document refers to VisaNet transaction processing requirements,
which are applicable only where Visa processing is used.

1.9 For further information

For further information about Visa Urban Mobility frameworks, or for questions about this document,
issuers and acquirers may contact their Visa representative. Urban Mobility operators should contact
their acquirer. Technology partners should contact either the Visa Ready for Transit or Technology
Partners team.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 16
Visa Urban Mobility
Implementation Guide

Overview of Visa
Urban Mobility
frameworks

Urban Mobility operators vary in terms of size and network complexity. The fares charged can be
affected by:
• Single or multiple modes of transport (e.g. bus, metro, tram, rail, and ferries)
• Distance or route travelled and/or time of journey
• Concessionary fares (e.g. the elderly, students, or staff)
• Fare capping policies that impose limits on the amount charged
Visa has developed multiple flexible frameworks that enable the acceptance of “open-loop” payment
cards based on contactless EMVCo technology for fast, convenient, and secure automatic fare
collection within UM environments, as described in the following table.

Table 4: Visa Urban Mobility frameworks

Framework Description Examples

Mobility & A Visa Contactless card is used at points The UM reader may be connected
Transport of access to the UM service on readers to a gate, turnstile, or validator.
Transaction that accept contactless payments only. Some UM operators may require
(MTT) the card to be used at entry-only,
framework The final fare charged is not always
while others may require use at
known at the time of travel, but is
entry and exit. The UM operator
calculated at the end of a travel period
(no longer than 24 hours) by the UM may charge flat, distance, or time
operator based on journeys made during based fares.
that period.

The transaction authorization request is

deferred.

Known Fare A Visa Contactless card is used at points An on-vehicle UM reader, where
Transaction of access to the UM service where the operator may either charge
(KFT) the fare charged is always known by flat or distance based fares.
framework the reader that accepts contactless
payments only.
The transaction authorization request is
deferred.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 17
Visa Urban Mobility 2: Overview of Visa Urban Mobility frameworks
Implementation Guide

Table 4: Visa Urban Mobility frameworks (Cont.)

Framework Description Examples

Retail A ticket is purchased using a card A ticket vending machine, a ticket

framework(s) through a channel which accepts all Visa office, a contact and contactless
card payments, and the ticket (paper or ticket terminal, contactless-
smart) is used to access the UM system. only, website and In-app
There are multiple frameworks available based e-commerce, or stored
for UM operators and providers in UM credentials.
adjacent segments which are discussed
in the guide.
The transaction authorization request is
performed in real-time.

2.1 High-level comparison of MTT and KFT frameworks

The following table explores the key differences between the MTT and KFT Deferred Authorization
frameworks that are described in this document:

Table 5: Visa Urban Mobility Deferred Authorization frameworks

Characteristics MTT KFT

Designed for very high customer throughput Yes Yes

Fare amount always known at the time the journey is started No Yes

UM reader accepts contactless payments only Yes Yes

Intended for complex fares, including “capping” or multi-modal Yes No

Allows accumulation of multiple journeys into a single transaction Yes No

Account Verification Requests performed on card’s first use Yes No

Intended for Deferred Authorizations Yes Yes

Special liability model included (shared liability limit) Yes No

Requires declined cards to be blocked using deny lists Yes Recommended

Requires operator back office for fare calculation Yes Recommended

Authorization resubmissions for debt recovery Yes Recommended

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 18
Visa Urban Mobility
Implementation Guide

Mobility &
Transport
Transaction
framework

3.1 MTT Overview

The Mobility & Transport Transaction (MTT) framework is a flexible framework where the fare for each
journey may not be known at the time the card is tapped on the UM reader. The total fare amount is
calculated and charged by the UM operator at the end of the travel period.
The key characteristics of this framework are:
• UM readers accept contactless payments only (they do not have contact chip reader or magnetic-
stripe reader)
• When a card is tapped on a reader it is authenticated and tap data is generated
• Cards are checked against a deny list before the cardholder can be accepted for travel
• Taps are accumulated in a back office system and the amount to be charged is calculated at the
end of the travel period
• An MTT is submitted online as a Deferred Authorization at the end of the travel period, where the
amount charged is equal to the total fare calculated
• Liability is shared between the UM operator (through their acquirer) and the issuer through a
defined MTT liability model, where eligible
This shared liability model – sometimes referred to as the “first ride risk” framework – provides limited
protection to UM operators for the first declined transaction on a Visa Contactless card up to a defined
MTT shared liability limit. Eligible transactions may be submitted to Clearing, and may not be disputed,
even if the issuer has declined the Authorization request. For transaction amounts above the limit,
liability is accepted by the UM operator.
Financial risk is managed by:
• Using Offline Data Authentication (ODA) to validate that the card is genuine when it is tapped on
the reader. Cards which fail ODA must not be accepted for travel
• Performing an Account Verification Request (AVR) immediately after a contactless card is first used
on a UM operator’s network, to quickly identify cancelled, lost, or stolen cards
• Centralizing tap data frequently (typically at least every hour)
• Authorizing and Clearing each transaction at the end of the travel period, to limit the total amount
of any outstanding fares due to the UM operator
• Maintaining and updating deny lists frequently (at least every hour) to prevent cards from being

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 19
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

used for further travel where an issuer declined the Authorization request
• Resubmitting previously declined Authorization requests, in attempt to recover debt owed to the
UM operator (e.g. unpaid fares), and remove cards from the deny list if a subsequent Authorization
request is approved.
The MTT framework is designed to be attractive to multi-modal UM operators with the need for high
passenger throughput and/or where complex fare calculation policies are operated. This allows for
more flexible fare charging policies to be introduced, which may offer a more compelling customer
experience.
UM operators can use Tap to Phone technology to accept contactless payments and/or perform
revenue inspection under the MTT framework. Please refer to the latest version of Visa Ready Tap to
Phone Solution Requirements for details.
3.2 Processing overview
A high-level overview of the MTT framework is given in Figure 1.

Figure 1: Overview of the MTT framework

Tap processing

Validate card

ODA, check
deny list

Submit AVR
Account for new card
Acquirer Verification
Add to deny
Request Merchant
list on decline
Merchant
initiated request
Tap data
System genererated MIT
All cards

Fare submission Debt recovery

Calculate fare at end Format new

of travel period Authorization request

Submit Submit new

Authorization Authorization
Authorization Authorization
Acquirer request Acquirer
request & Add to deny Remove from deny
Clearing list on decline list on approval
Record

Customer
initiated request
Via web, MOTO or
tap initiated debt recovery
Cardholder

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 20
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

The following sections describe how the MTT framework may be implemented, covering the following
key areas of functionality as illustrated in figure 1:
• Tap processing – describing how the tap and validation of the card is performed
• Fare calculation and submission – clarifying the functionality required to encode and submit
transactions for Authorization and Clearing
• Debt recovery – explaining how operators can attempt to recover any unpaid fares
• Transaction processing – describing how key Visa processing fields must be used
• Exception handling – outlining some of the most common exception events that should be
considered and handled

3.3 Tap processing Figure 2: Tap processing

Tap processing is how cards are
handled at a UM reader to support an
MTT. For a full technical description of
contactless processing requirements,
please refer to [VCPS] and [VCTKS],
and for full details of the additional
No
requirements for MTT acceptance ODA
please refer to [VUMTIG]. passed?

Yes
Note
Yes Card not approved
Expired?
for travel
A Visa card cannot
“fall-forward” to a No

contact transaction at a
On deny Yes
contactless-only UM reader
list?
since such a terminal does
No
not have a card contact
chip reader or magnetic- Travel
stripe reader (see [VUMTIG] permitted

for details). Therefore it

is not possible for a Visa Yes
card to be rejected on the Account
New card?
Verification Request
grounds that it attempted
to fall-forward.
No
Add to
Approved?
No deny list

Yes

Tap data to
fare calculation

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 21
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.3 .1 Offline Data Authentication (ODA)

Note
In order to authenticate the card, the reader performs ODA
(specifically fast Dynamic Data Authentication, fDDA) as Successful completion
part of a zero value transaction. ODA must be performed
of ODA means that the
successfully to consider the card eligible within the MTT
framework. terminal can rely on the
card being genuine and
unaltered since issuance.
Important

If ODA fails or is not returned by the card (i.e. ODA is

not supported), the reader will reject the card as not
accepted for travel within the MTT framework.

Req 01: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Acquirer must ensure that its Urban Mobility
Merchant performs Offline Data Authentication (ODA)
using fast Dynamic Data Authentication (fDDA).

3.3 .2 Expiry date check

Note
UM operators must reject expired cards since there is a risk
that the Deferred Authorization may be declined at the end UM operators should
of the travel period. Refer to [VUMTIG] for details.
ensure that the reader
date settings are accurate
Important to avoid false acceptance
or rejection of cards based
Issuers must be aware that cards that have expired may
on their expiry date.
be rejected by UM readers.

The expiry date tag (Application Expiration Date) used when

a card is presented to a UM reader must be consistent with
the tag used in any other part of the UM system, to avoid data
mismatches that may result in unnecessary Authorization
request declines.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 22
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.3.3 Deny list check

Note
The UM operator must block cards that receive a decline
response to a Deferred Authorization or AVR. UM operators The deny list is normally
must manage a deny list that is stored on, or accessible to,
managed in the UM
the UM readers. The list comprises of card data (typically
non-reversible hashed PANs, expiry date, and card sequence operator’s back office system
number). If a tapped card is on the deny list, the card should and shared with the UM
not be accepted for travel.. readers. Depending on
performance and throughput
requirements, it may be
Important
possible for UM readers to

Any card data held on a deny list must be secured as lookup a deny list that is held

described in section 6.3.3 centrally in the back office.

However, typically, a copy
of the deny list is held on
the UM reader, and changes
(or “deltas”) are broadcast
regularly to all readers in order
to synchronize them (at least
every hour).

3.3.4 New card check

The UM operator must be able to identify if a card is being used for the very first time on its services or
system.
If the card has not been used before on their network (i.e. it is treated as a “new card”), an Account
Verification Request (AVR) must be performed as soon as possible after the card is tapped on the
reader and the cardholder is accepted for travel. This enables UM operators to minimize financial loss
from closed accounts and lost or stolen cards.

Req 02: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Acquirer must ensure that its Urban Mobility Merchant:
• Submits an Account Verification Request when a Card is first used at the Merchant
• Blocks a Card from being used for travel within 1 hour of receiving an Account Verification
Request decline response from the Issuer

If the card has been used previously then there is no need for the UM operator’s back office to perform
an AVR, although they are free to use AVRs periodically in accordance with their risk appetite (e.g.
some UM operators might consider all cards as “new cards” every 14 days).

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 23
 AVR Visa standart
Visa Urban Mobility
iso kodlarına bağlı 3: Mobility & Transport Transaction framework
Implementation Guide olarak Fieldlarla
cevap vermeli
Issuer tarafında
An AVR requires the following processing:
• AVR messages have a similar format to a sales Authorization, with key differences being that the
transaction amount data (Amount, Authorized) is always set to zero and the POS Condition Code
data in Field 25 is set to “51”. Full Track 2 data must be present and sent unaltered in Field 35 and
Chip data must be present and sent unaltered in Field 55 as per any contactless transaction.
Message formats are detailed in Table 7 of section 3.6
• Issuers should respond to AVRs in Field 39 with “85” (No Reason to Decline) if the account is in
good standing

Important

If the issuer declines an AVR, the UM operator is liable for any journeys using that card after
the first hour. To minimize this risk, UM operators should ensure no further acceptance of
the card by immediately placing it on the deny list as described in sections 3.3.3 and 3.4.3.

Where the issuer has declined the AVR, the UM operator must still submit a transaction for
Authorization, either shortly after the journey has been completed or at the end of the standard travel
period. This Authorization is based on the charge for the journey completed before the card was
placed on the deny list (within the first hour after the AVR decline response was received). Acquirers
have dispute protection up to the MTT shared liability limit.
UM operators enabling a tap in and tap out environment should ensure passengers are able to exit the
system in situations where the card was placed on the deny list during travel.

3.3.5 Deferred Authorization

As UM operators defer online Authorizations, these must be submitted in accordance with the Visa
Rules. Issuers must be able to process these transactions correctly.

Req 03: Urban Mobility Merchant Requirements

(Rule: See ID# 0030061)
An Acquirer must ensure that its Urban Mobility Merchant:
• Submits a Deferred Authorization with the indicator 5206 present in Field 63.3
• Obtains the Authorization response within 4 days of the transaction date

Issuers should exclude any transactions identified with a Deferred Authorization flag from ATC
tracking. Please refer to the latest ATC Tracking White Paper available on VOL for further details on how
to handle ATC for Deferred Authorizations.

Important

While the 4 days deferred submission period allows for late data scenarios as described in
section 3.7, where possible UM operators must submit Authorizations at the end of each
travel period as per section 3.4.2.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 24
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.3.6 Urban Mobility operator proprietary processing

Note
In addition to the transaction processing required at the UM
reader by [VCPS] and [VUMTIG], operators may implement
UM operators should ensure
their own specific processing based on their fare policies. For
example, UM operators may implement “pass-back” checks that if the PAN is used for
to prevent multiple passengers using the same card at the establishing the card identity,
same reader, gate, or station within a given timescale, in it must be protected (see
contravention of the operator’s conditions of carriage.
section 6).

3.3.7 Urban Mobility operator revenue protection devices

UM operators may use readers, typically portable terminals, to verify passenger compliance with
their fare policy. Such a device performs some of the same functions as a conventional reader (i.e. it
authenticates the card, checks the deny list, and generates tap data which is sent to the operator’s
back office). As such, these devices are subject to the same requirements and certification as readers
installed elsewhere on their network.
UM operators can use the Tap to Phone technology to perform revenue inspection under the MTT
framework. Additionally, UM operators may also wish to use the Tap to Phone technology in order to
apply penalty charges outside the scope of MTT for their revenue protection needs. Please refer to the
latest version of Visa Ready Tap to Phone Solution Requirements for details.

3.4 Fare calculation and Figure 3: Fare calculation and submission

submission
To implement the MTT End of
framework, a back office system travel period
is required to calculate the fare
based on the taps from a card
accumulated during the travel
Calculate
period, before a transaction can fare
be submitted to Authorization
and Clearing.
An overview of the typical Submit
processes is given in Figure 3. Authorization

No
Authorization Add to deny list
approved?

Yes

Within Shared No
Liability?

Yes

“Zero
Clear Authorized Clear under amount” Initiate debt
transaction Shared Liability recovery
Debt
recovery

End

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 25
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.4.1 Fare calculation

For each card used for contactless travel during the travel period, the UM operator will use tap data
gathered from the readers to determine the journeys made and calculate the accumulated fare that
will be charged to each card. The methods used for journey calculation and fare pricing policies are
outside the scope of this document, as the UM operator may wish to utilize a flat, distance, or time
based (or multi-modal combination) fare structure to suit their needs.
The MTT framework allows UM operators to introduce flexible fare charging policies, which in turn may
provide their customers access to the best fares, including fare capping, discounts and concessions.
It is recommended to offer fare price parity for an MTT based solution with any existing ticketing fare
policy to achieve the best results and encourage ridership.
Introducing fare capping features by offering free rides once the passenger has paid for a set number of
journeys over a given amount of time can incentivize them to travel more frequently. Passengers don’t
need to think about planning or paying up front for their regular journeys to get the most value. Instead,
they can use their existing Visa Contactless card to pay for journeys directly, and be guaranteed the
best price for those journeys over an extended period (i.e. daily, weekly, or monthly capping).
In the interest of making travel as accessible and affordable as possible for everyone, UM operators
may also offer concessions. The processes to apply for, verify and renew entitlements are managed
directly by the UM operator. Some examples of concessionary travel include discounted rates for
young people, students, or seniors.

Important

UM operators must ensure that the methods and amounts used to calculate travel fares are
clear and readily available to their customers.

UM operators should not permit the purchase of a separate closed-loop travel pass through the MTT
framework. It is possible to incentivize ridership through an effective fare capping policy. Any ticketing
solutions designed to allow a pre-determined period of travel of more than 24 hours that are sold at
the point of passenger boarding should be done so using a retail based approach only (as described in
section 5.2 or 5.3).
Visa also offers a suite of Pay-in-Advance (PIA) solutions that can help promote financial inclusion
for the un-banked and under-banked. Please refer to the latest version of Visa International Prepaid
Program Guidelines and Visa International Private Label Guidelines for details.

3.4.2 Authorization requirements

At the end of the travel period, the UM operator must request an online Deferred Authorization based
on the single fare charge calculated for accumulated journey(s) on that card.
This approach substantially simplifies the implementation within the UM operator’s back office
systems, improving reconciliation, simplifying transaction dispute processes, and ensuring full
compliance with the MTT framework.

Req 04: Mobility & Transport Transaction Authorization Requirements

(Rule: See ID# 0030049)
A Merchant performing a Mobility & Transport Transaction must submit an Online
Authorization Request at the end of each travel period

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 26
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Once an Authorization response is obtained, UM operators should submit transactions to Clearing

on the calendar day following the end of the travel period as described in section 3.4.4. An approval is
valid for 3 calendar days from the date of response to allow for any late data scenarios as described in
section 3.7.

Req 05: Approval Response Validity Timeframes

(Rule: See ID# 0029524)
An approval response for a Merchant performing a Mobility & Transport Transaction is valid no
later than 3 calendar days from the date of the approval response.

3.4.2.1 Card sequence number

Important

Although this data element (EMV data tag ‘5F34’) is defined as optional within [VCPS], this
only means it is optional for an issuer to include it within their contactless-enabled card. It is
essential that, if it is retrieved by the reader from the card presented by the cardholder, all UM
acceptance and acquirer data processing systems must forward this data element unaltered
as part of the Authorization message and Clearing record sent on to the issuer. This data
element is used in the validation of the online authentication process, and if it is not returned
correctly when present in the card, will cause the Authorization to be declined. If this value is
not present on the card, it should be assumed it is ‘00’ for all cryptographic purposes.

When capturing card data at the point of interaction, the PAN and expiry date must be
transmitted securely, along with the card sequence number, for both deny list management
and transaction processing.

3.4.2.2 Authorization amount

A UM operator must submit an Authorization request for the final transaction amount.

Req 06: Authorization Amount Requirements

(Rule: See ID# 0025596)
An Urban Mobility Merchant must submit an Authorization Request for the final transaction
amount.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 27
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.4.2.3 Transaction date

The transaction date must be the day of the last journey made in the travel period.

Req 07: Transaction Date Limits

(Rule: See ID# 0005753)
For a Mobility & Transport Transaction, the Transaction Date must be the last day on which a
journey took place.

3.4.2.4 Purchase date

The purchase date must be the day of the first journey made in the travel period, as this date should
appear on the issuer statement.

Important

Acquirers must ensure that the purchase date in the Clearing record is the day the cardholder
took the first journey in that travel period. In cases where the operator’s transaction processing
day is not on the same calendar day as the first journey was made, the purchase date must be
set to the day the cardholder first used their card for travel.

3.4.3 Deny list management

UM operators must add cards to the deny list within one hour of receiving a decline response to an
Authorization request (or AVR) in order to ensure the card is no longer accepted for travel.

Req 08: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Urban Mobility Merchant must block a Card from being used for travel within 1 hour of
receiving either: a decline response; or an Issuer response to an Account Verification Request
indicating that the transaction should not be completed with that Card.

UM operators must remove cards from the deny list within one hour of receiving an approval response
to an Authorization request, in order to ensure the card is accepted for travel as soon as possible after
an issuer approval.

Important

Operators must prevent declined cards from entering the system until an Authorization
approval has been received from the issuer. UM operators may also remove a card from the
deny list only after it has already expired.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 28
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

It should be possible for a customer to establish if their card is on a deny list and the process for its
removal (i.e. through one of the debt recovery mechanisms used for the same card that was declined,
as described in section 3.5). The UM operator is responsible for this element of customer servicing.

Req 09: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
Upon receipt of an approval response to an Authorization Request, the travel block on a Card
must be removed within 1 hour.

3.4.4 Clearing
UM operators may submit a transaction to Clearing if the issuer approved the Authorization.
An MTT must be submitted to Clearing no later than the timeframe specified in the Visa Rules, which
is typically within 8 days from the end of the travel period. Most UM operators will aim to submit
transactions to Clearing on the calendar day following the end of the travel period unless a late data
scenario has occurred.

Req 10: Acquirer Processing Timeframes

(Rule: See ID# 0027796)
An Acquirer must process transactions within the timeframes specified in the “Acquirer
Processing Timeframe Requirements” table in the Visa Rules.

With the exception of transactions that are eligible under the MTT shared liability limit, UM operators
are liable for all transactions where the Authorization request is declined by the issuer.

3.4.4.1 MTT Shared Liability Limit (SLL)

The MTT shared liability limit, also sometimes referred to as “first ride risk protection” for UM operators,
aims to mitigate the risk and exposure and distribute liability for an MTT where the Authorization at the
end of the travel period is declined by the issuer.

Req 11: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
If the Urban Mobility Merchant receives a decline response from an Issuer, it may submit a Clearing
record for that MTT only if all of the following apply:
• The transaction is a domestic transaction or in some cases may be an intra-regional transaction
• Either: the transaction is the first transaction on the Card at the Merchant or the previous
Mobility & Transport Transaction for which Authorization was requested received an approval
response
• ODA using fDDA was performed
• The transaction amount is less than or equal to the market or region specific values specified in
the MTT Shared Liability Limits of the Visa Rules

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 29
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

The UM operator may therefore submit an MTT to Clearing

before commencing any debt recovery processes, if the Note
issuer declined the Authorization request, provided:
To determine which of
• The issuer declined in response to the very first MTT
these transactions may be
Authorization request for this card
submitted to Clearing based
• The issuer declined in response to the first MTT
Authorization request for this card since a previous MTT on the established domestic
Authorization approval response or (if permitted) intra-regional

• The transaction amount is less than or equal to the MTT shared liability limits, UM
shared liability limit defined for that market. Please refer operators can identify the
to the Mobility & Transport Transaction Processing country of issuance by using
Requirements in the Visa Rules for complete list of eligible
the Application Program
transactions
Identifier, tag ‘9F5A’, present
on all cards. This tag contains
Important the region, country and
currency codes of a card, and
UM operators are not permitted to submit declined
is identified by the reader
inter-regional transactions to Clearing. This means that
when it is tapped.
if the declined transaction originates from a card issued
in a region outside that in which the operator is located,
the shared liability limit is effectively zero, and a Clearing
record cannot be submitted for that card.

UM operators are not permitted to submit transactions to

Clearing where the amount has been reduced to meet the
criteria governing the MTT shared liability limit. This practice,
sometimes referred to as “part-clearing”, represents a
violation of compliance with MTT rules.

Req 12: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
For a transaction that received a decline response, a UM Merchant must not submit a Clearing
record with a lower transaction amount in order to meet submission criteria.

Important

Acquirers must ensure that an MTT cleared under the MTT shared liability limit is correctly
labelled with the value of “VFT000” in the Authorization Code of the Clearing record. The Tran
ID that is generated during Authorization must be used for the corresponding Clearing record.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 30
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.5 Debt recovery

An issuer may decline some Authorization requests. This may be for financial reasons, due to cyclical
variations in an account balance (e.g. where a cardholder has insufficient funds before a salary
payment is received), or for other reasons defined by the decline response code provided by the
issuer.
To enable blocked cards to be accepted for travel again, a UM operator must receive an approval
response to a sales Authorization. AVR approval responses are not permitted to be used for removing
blocked cards from deny lists. If an approval response is given by an issuer to a debt recovery
transaction on the same card that is blocked, the UM operator must remove that card from the deny
list within one hour of receiving the Authorization approval response.
There are multiple methods to attempt to Authorize a previously declined transaction (i.e. to unblock
the card for travel). These methods can be either merchant initiated or cardholder initiated. UM
operators must use the same fare amount that was previously declined, on the same card that is
blocked to remove that card from the deny list.
Additionally, UM operators should use a different Merchant ID (MID) than the primary MTT MID
for each of the different types of debt recovery options available. This may be for the purpose of
operator reconciliation or to provide clearer cardholder statement narrative. The same MIDs used in
Authorization requests must be used in Clearing messages.

Req 13: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
To obtain an approval response, a UM Merchant must request an online Authorization using
either of the following amounts:
• The amount of any outstanding fare
• If no fare is outstanding, the transaction amount that was cleared under the Shared
Liability Limit following the decline response, and the Authorization request must then be
reversed
Upon receipt of an approval response, the travel block must be removed within 1 hour.

3.5.1 Data fields in debt recovery

The methods of debt recovery Authorization requests permitted on the following channels are
identified by the values in specific data fields given in the table below. For Merchant Initiated
Transactions (MITs), the following data fields are additional to those introduced in section 3.5.3 below.

Important

UM Operators should use different MIDs for the original Authorization and each of the
methods of debt recovery as shown below.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 31
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Table 6 Key fields used in original MTT & debt recovery Authorizations

Merchant Card Field Field Field Field Field Field

ID Present 22 25 60.1 60.2 60.9 63.3
Field 42 (with chip
data)

Original MTT AVR e.g. Yes 07 51 3 8 3 —

Authorization 123456789
Sales Auth. 00 3 8 3 5206

Merchant Initiated Transaction e.g. No 01 00 0 0 — 3901

987654321

Cardholder Tap e.g. Yes 07 00 3 8 3 5206*

Initiated 543216789 or —

MOTO e.g. No 01 08 0 0, 1 4 —
678954321 or 9

E-commerce 59 0 0, 1 4 —
or 9

*This value must be used if the operator is not supporting real-time cardholder tap initiated debt recovery requests.

Please refer to Section 3.6.2 for further information around these key fields.

Important

Issuers must not automatically send a decline response based solely on a missing CVV2 for
resubmitted MITs originating from a UM operator.

3.5.2 Zero amount debt scenario

In some cases, the outstanding debt may in fact be zero, since a Clearing record may have been
submitted under the MTT shared liability limit, yet the card is blocked since the issuer declined the
Authorization request.
In this scenario, the Authorization amount should be equal to the amount that was previously
submitted to Clearing under the MTT shared liability limit for that card. In the event that the
Authorization request is approved by the issuer, the operator must immediately reverse this
transaction to avoid double charging the customer, and ensure the card is removed from the deny list.
To optimize the cardholder experience, UM operators should support the debt recovery mechanisms
described below, some of which can be used regardless of whether there is outstanding debt or not to
remove a card from the deny list following a previous decline.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 32
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.5.3 Merchant initiated

UM operators must resubmit a declined Authorization request under the Merchant Initiated
Transactions framework, see [MIT]. This can be done automatically via a system generated submission
process in the operator’s back office. MIT Resubmissions are not considered “stored credentials” or
“credentials-on-file” due to the fact they do not enable recurring payments or allow the operator to
initiate subsequent new charges.

Req 14: Resubmission following a Decline Response to an Urban Mobility Transaction

(Rule: See ID# 0030046)
An Acquirer that has received a Decline Response to a transaction that originates from an
Urban Mobility Merchant may enter that transaction into Clearing if the following applies:
• The Merchant has received an approval response to a subsequent Authorization request
that included the data from the original declined transaction
• The Merchant has not exceeded the number of permitted Authorization requests that can
be submitted:
• For a KFT, following the initial decline response, more than 2 Authorization requests
within 14 calendar days of the initial decline response
• For an MTT, following the initial decline response, more than the number of permitted
Authorization requests within the market or region timeframes specified in the MTT
Decline Response Thresholds of the Visa Rules

UM operators handling automated debt recovery transactions for declines within the MTT framework
are typically allowed up to 4 resubmissions to Authorize within a 14 calendar day period since the
original contactless Authorization request was declined. The number of resubmissions within the
MTT framework can vary depending on the market as defined in the Mobility & Transport Transaction
Processing Requirements table in the Visa Rules. UM operators must limit the decline response codes
that they submit system generated resubmitted Authorization requests for to align with the [MIT]
framework and mitigate further unnecessary decline responses. The below listed decline response
codes would never be approved by an issuer if a UM operator attempts to resubmit them for debt
recovery after the original decline, and are therefore prohibited from resubmission attempts.

Req 15: Resubmission following a Decline Response to an Urban Mobility Transaction

(Rule: See ID# 0030640)
An Urban Mobility Merchant that receives a Decline Response must not resubmit the
Transaction for Authorization in an attempt to receive an Approval Response if the original
Decline Response code is one of the following:
• 04 (Pick up card) • 43 (Stolen card, pick up)

• 07 (Pick up card, special condition) • 46 (Closed account)

• 12 (Invalid Transaction) • 57 (Transaction not permitted to cardholder)*

• 14 (Invalid account number) • R0 (Stop payment order)

• 15 (No such issuer) • R1 (Revocation of authorization order)

• 41 (Lost card, pick up) • R3 (Revocation of all authorizations order)

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 33
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

For the above Category 1 decline response codes any resubmission or re-attempt to authorize will be
assessed a fee.
*For UM Operators response code 57 has been temporarily removed from the Issuer Will Never
Approve—Reattempt System Integrity Fee.

A typical process for merchant initiated debt recovery is illustrated in Figure 4.

Figure 4: Merchant initiated debt recovery

Merchant
initiated

No Yes
Submission Resubmit Authorization
limit exceeded? authorization approved?

Yes No

Card remains Card removed

on deny list from deny list

It is recommended that the first resubmission attempt should be attempted shortly after the original
Authorization request was declined, on the same day, to maximize the opportunity of removing the
customer from the deny list as quickly as possible. If this is also declined, a second resubmission may
be attempted after 1, 2, or 3 days, and so forth.

Important

All UM operator system generated Authorization requests must be submitted as a

“Resubmission” category under the Merchant Initiated Transactions framework, see [MIT].

In the resubmitted Authorization request, the [MIT] framework

Note
requires the UM operator to identify the transaction was
initiated as an MIT and:
If these conditions are met,
• Identify the intent of the MIT by specifying Reason Code an “out of scope for Strong
3901 (Resubmission) in the message Reason Code (Field
Customer Authentication
63.3) of the transaction. Please see Table 6 above for further
information on other key field values for MITs (SCA)” indicator will be added
to TLV Field 34 Dataset ID
• Provide proof of a preceding transaction by using the
Transaction Identifier (i.e. Tran ID) of the original transaction 02 Tag 80 in the inbound
in the Tran ID data field (Field 62.2 or Field 125, Usage 2, message to the issuer; a value
Dataset ID 03, Tag 03). The same principle applies for any of 1 indicating a Merchant
MIT resubmission even if there is more than one attempt
Initiated Transaction.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 34
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.5.4 Card present tap initiated

A cardholder attempting to use a blocked card at the UM operator’s reader may create a fresh debt
recovery Authorization request (even if the actual outstanding debt is zero). While the card will not be
accepted for travel, the tap may be used to trigger a fresh contactless Authorization request using the
chip data from the new tap, along with the fare amount of the previous declined Authorization.

Figure 5: Tap initiated debt recovery

Tap initiated

Access denied Submit new

to UM system authorization

No Authorization
approved?

Yes

Card remains Card removed

on deny list from deny list

Important
There are no specific limits on the number of
To provide the best possible cardholder experience, Authorization re-attempts that a cardholder can
operators may consider an optimized approach to tap initiate in trying to pay unpaid fares and/or unblock
their card for travel. UM operators may wish to
initiated debt recovery transactions. For example, by
limit the number of re-attempts performed to one
enabling real-time Authorizations in these cases only, Authorization within a given time if the cardholder
which if approved, will update the deny list and allow the does tap their card multiple times in a short period.
cardholder to travel immediately. UM operators may not resubmit or re-attempt a
transaction when the previous decline response code
is a Category 1 response code.

Note

UM operators should consider if they continue to support tap driven debt recovery channels for a previously
declined card after an 11 month period. At this time the likelihood of the card being used again typically diminishes
due to expiry or being lost. While the card must remain on the deny list until a successful approval response to
a sales Authorization is received (or it has expired), if tapped at the UM reader, a prompt may be given for the
passenger to contact customer services. This will ensure risk can be minimized before attempting to settle
payment for outstanding fares via a call center or web-based transaction and remove the card from the deny list.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 35
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.5.5 Card not present cardholder initiated

A Cardholder may also be invited by the operator to pay unpaid fares for their blocked card via a
website, call center or other means if they have registered that card with the operator. On receipt of
approval of this fresh debt recovery Authorization request, the UM operator must remove the card
used to settle the unpaid fare from the deny list within one hour.

Figure 6: Card not present cardholder initiated debt recovery

Cardholder initiated

Note

Cardholder UM operator E-commerce initiated debt

contacts operator submits CNP
recovery transactions must
Authorization
Via: be protected by Visa Secure
• Website where required, as described
• Telephone call centre
in the Visa Rules.

No Authorization
approved?

Yes

Card remains Card removed

on deny list from deny list

There are no specific limits on the number of

Authorization re-attempts that a cardholder can
initiate in trying to pay unpaid fares and/or unblock
their card for travel. The card blocked from travel
must be the card used to settle unpaid fares.

3.6 Transaction processing

3.6.1 Transaction Identifier

Transactions originating from a UM reader
operating under the MTT framework must be
identified correctly, as per the Visa Rules. The Tran
ID that is generated during Authorization must be
used for the corresponding Clearing record.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 36
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.6.2 Transaction data fields

Important

For an MTT, acquirers and issuers should not expect a match between the cryptogram
amount in Field 55 and the transaction amount specified in Field 4.

The important data fields and values in the AVR, Authorization, and Clearing messages for an MTT
are shown in the following table. Issuers can use data values in the Authorization fields underlined to
identify MTTs:

Table 7 MTT data fields

Authorization Clearing Value Remarks

Amount, Source Variable For an MTT, the value here will not match the
Transaction Amount value of tag ‘9F02’ in Field 55.
Field 4
TCR 0
Position Note
77-88
This field will contain the accumulated fare
amount of all journeys made within the
travel period. The amount in Field 55 will
contain zero and it, along with all the other
cryptogram data, will be obtained from
the final tap within the travel period.

Transmission N/A Variable The value here must contain the date and time
Date and Time at which the acquirer submits the Authorization
request message.
Field 7

Local Purchase Variable Purchase Date

Transaction Date
Date TCR 0 Note
Position
Field 13
58-61 The purchase date must be the day of the
first journey made in the travel period.

Merchant Merchant Indicates a UM operator:

Category Code Category
4111 4111: Local and Suburban Commuter Passenger
Code
Field 18 Transportation, including Ferries
TCR 0
Position 4112 4112: Passenger Railways
133-136
4131 4131: Bus Lines

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 37
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Table 7 MTT data fields (Cont.)

Authorization Clearing Value Remarks

POS Entry Mode POS Entry Mode 07 Indicates a contactless-read

TCR 0 Position transaction.
Field 22.1
162-163

Card Sequence Number Card Sequence Variable EMV data tag ‘5F34’,
Number optionally present on a
Field 23
card, if received by the
TCR 7 Position 7-9
reader, must be forwarded
to the acquirer.

POS Condition Code N/A 00 Authorization (containing

chip data in F55)
Field 25

51 Account Verification
Request (containing chip
data in F55)

ICC Related Data Terminal Variable Transaction Date

Transaction Date
Field 55 - Transaction Date
TCR 7 Position
Tag ‘9A’ Note
10-15
(Field 146 for third bitmap
issuers) The transaction date
must be the day of the
last journey made in the
travel period.

ICC Related Data Cryptogram 0.00

Amount
Field 55 - Amount,
Authorized TCR 7 Position
For an MTT, the value here
87-98
Tag ‘9F02’ will not match Field 4.
(Field 147 for third bitmap
issuers)

Terminal Type Acceptance 3 The value here must be

Terminal Indicator set to an Unattended
Field 60.1
TCR 1 Position 124 Cardholder Activated
Terminal (UAT). See
[VUMTIG].

Terminal Entry Capability POS Terminal 8 Indicates that the terminal

Capability is a contactless reader only.
Field 60.2
TCR 0 Position 158

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 38
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Table 7 MTT data fields (Cont.)

Authorization Clearing Value Remarks

Cardholder ID Cardholder ID 3 Unattended Terminal, no PIN pad.

Method Indicator Method
This value is not required in
TCR 0 Position
Field 60.9 Authorization request messages
160
from the acquirer, however VisaNet
will add this in messages to the issuer.

Message Reason N/A 5206 To be populated for all MTTs. The

Code (Deferred value here indicates the transaction is
Authorization) a Deferred Authorization, and should
be excluded from ATC tracking.
Field 63.3

3.6.3 Dates in Authorization and Clearing

The operator’s travel period can start and end on different calendar days even if operating a standard
24 hour travel period. For example, from 04:30am on (calendar) day 1 to 04:29am on (calendar) day 2.
A journey that commences on day 1 and finishes on day 2 must be identified in Clearing (TCR0 Position
58-61, Purchase Date) with the date corresponding to day 1. This will appear on the issuer statement.
Table 8 below shows the dates used in Authorization and Clearing message data field for a typical MTT
with a card used at a UM reader. Table 9 below shows the dates used in Tap initiated debt recovery
transaction.

Table 8 Dates used for an MTT

Field 7 Field 55 TCR0 Pos 58-61 TCR7 Pos 10-15

Authorization Date and Date of the N/A N/A

time at which last tap in the
acquirer travel period.
submits the
request.

Clearing N/A N/A Date of the first Date of the last

tap in the travel tap in the travel
period. period.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 39
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Table 9 Dates used for a tap initiated debt recovery transaction

Field 7 Field 55 TCR0 Pos 58-61 TCR7 Pos 10-15

Authorization Date and Date from N/A N/A

time at which the tap that
acquirer initiated the
submits the debt recovery
request. transaction.

Clearing N/A N/A Date of the Date from

first tap in the the tap that
original travel initiated the
period. debt recovery
transaction.

3.6.4 Transaction Authorization amount

The transaction amount in Field 4 will indicate the actual amount calculated by the UM operator’s back
office. This is the amount to be charged to the cardholder.
For an MTT, the cryptogram amount in Field 55 tag ‘9F02’ (or in the case of a third bitmap issuer in Field
147) will be zero.

3.6.5 Acquirer transaction processing

This section describes the impact of an MTT from the acquirer viewpoint. As with a typical retail
transaction, if there is a connection error message or no response given by the issuer or from Visa to
the Authorization request, the acquirer may attempt the same transaction again in order to obtain
the necessary Authorization response. If a response code is provided either by the issuer or Visa, then
UM operators are not permitted to re-attempt this transaction unless it is an MIT Resubmission to a
declined transaction. UM operators may not resubmit or re-attempt a transaction when the previous
decline response is a Category 1 response code.

3.6.5.1 Cryptogram and Cryptogram data

The cryptogram included in online Authorization and Clearing messages may be a Transaction
Certificate (TC) or an (ARQC). The UM operator must use the chip data from the most recent available
tap they received from their terminals for that travel period.

Important

Acquirers must ensure that Track 2 and chip data in the online message have not been altered
from the card data received by the UM reader.

The data fields forming the Authorization request are given in Table 7 above.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 40
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.6.5.2 Operator name and location

UM operators must make cardholder assistance for fare payments easily available. To help passengers,
UM operators must pass their contact details to issuers in the Merchant Name and Merchant City fields
of Clearing messages. In turn, issuers must reproduce these fields in limited characters on statements
(e.g. ”UM operator travel charge, www.UMoperator.com/contactless”). The operator name should be
clear and consistent for each transaction. It should be the name most prominently displayed by the
UM operator and by which cardholders will recognize them.

Important

Acquirers must transmit the Merchant Name and Merchant City fields unaltered in the
Clearing records.

3.6.5.3 Authorization Code in Clearing

Important

Acquirers must ensure that any MTT submitted to Clearing under the MTT shared liability limit
(i.e. ones that were declined by the issuer) is labelled correctly with the value of “VFT000” in the
Authorization Code (i.e. Sales Draft Data, TCR 0 Position 152–157, Authorization Code). The Tran
ID that is generated during Authorization must be used for the corresponding Clearing record.

Otherwise, acquirers must ensure that the correct value for the Authorization Code is used.

3.6.5.4 Incorrect transaction processing

Visa reserves the right to assess penalties for acquirers who regularly submit incorrect or invalid
transactions, such as improper shared liability transactions or resubmissions.
In the Europe region only, if an issuer suspects the UM operator is not complying with the MTT
framework rules, then they may raise a compliance case against the acquirer.

Important

A Europe acquirer may be subject to a Visa non-compliance assessment of EUR 30 for each
MTT processed incorrectly by its operators.

3.6.6 Issuer transaction processing

3.6.6.1 Account Verification Requests

Issuer hosts should expect to receive a greater number of AVR from operators implementing the MTT
framework. The UM operator will send an AVR as soon as possible after a card is used for the first time
in the UM network.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 41
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

Issuer hosts should expect that AVRs will be identified with a zero amount from a contactless-only UM
reader with POS Condition Code data field set to “51”.

3.6.6.2 Cryptogram types

Issuer hosts should expect to receive Authorization requests that can contain either TCs (offline
approval cryptograms) or ARQCs (online request cryptograms). This is because the chip data present
in the deferred online Authorization will correspond to the last tap performed by the cardholder,
as explained in section 3.6.5.1. For the same reason, issuer hosts should expect to receive Clearing
records that can contain either TCs or ARQCs.

3.6.6.3 Application Transaction Counter (ATC) tracking

Issuer hosts should expect to receive Authorization requests where the value of the ATC is out of
sequence (e.g. when a customer has performed transactions after travel but before the MTT is
submitted at the end of the travel period). As with all Deferred Authorizations, issuers can optimize
approval rates by excluding MTTs with this indicator present from ATC tracking. Please refer to the
latest ATC Tracking White Paper available on VOL for further details on how to handle ATC for Deferred
Authorizations.

Important

Issuers must not automatically decline an MTT based on an unexpected sequence of ATC
received in the online Authorization request.

Req 16: Issuer Processing of Mobility & Transport Transactions

(Rule: See ID# 0002064)
An Issuer must be able to correctly process an Authorization request for a Mobility &
Transport Transaction, and must:
• Not send a decline response based solely on the value of the Application Transaction
Counter (ATC)

3.6.6.4 Issuer Stand-In Processing (STIP)

Issuers should be aware of the peak volumes of transactions that will be processed by UM operators
at the end of each travel period (typically during evening or overnight hours). Visa recommends
that issuers review their risk parameters and Issuing Identifier STIP and Chip STIP routing option
settings. This will help ensure that these are appropriate for potentially high volumes of low value
Authorizations that may be received during times where the issuer host systems are unavailable.

3.6.6.5 Limited Use Keys (LUK)

Issuers participating in mobile payment application using Host Card Emulation (HCE) based devices
may wish to review the parameters that define the frequency with which LUKs are replenished.
LUKs are used in Android based digital wallets for cryptogram validation in online Authorization and
can be used for a limited period. LUKs may be replenished after a mobile device has been tapped
at a UM reader but before the Deferred Authorization request is submitted. When any of the three
different velocity checks are exceeded, LUK replenishment will happen.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 42
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

The network or device bound parameter settings that may be specified by each issuer are: Time
to Live, Number of Transactions and Cumulative Total Transaction Amount. Visa may decline
Authorization requests on behalf of issuers based on their LUK configuration. Reviewing and adjusting
LUK parameters may influence the STIP decision making, and improve approval rates.
3.6.6.6 Strong Customer Authentication
The Second European Payment Services Directive PSD2 requires that SCA is applied to all electronic
payments - including proximity payments - within the European Economic Area (EEA). The SCA
mandate is complemented by some limited exemptions that aim to support a frictionless customer
experience when a transaction risk is low. In addition, some transaction types are out of scope of SCA.
Unattended transport terminals Article 12 of the SCA Regulatory Technical Standards (RTS) states that
PSPs shall be allowed not to apply SCA, where the payer initiates an electronic payment transaction
at an unattended payment terminal for the purpose of paying a transport fare under the following
merchant category codes (MCCs):
• MCC 4111—Local and Suburban Commuter Passenger Transportation, Including Ferries
• MCC 4112—Passenger Railways
• MCC 4131—Bus Lines

3.7 Exception handling

3.7.1 Late or lost data scenario

Accurate fare calculation relies on a complete set of tap data being available in the UM operator’s back
office for processing at the end of the travel period. However, for various operational reasons (e.g.
station or equipment loses connectivity for a period of time), some tap data may fail to arrive into the
back office in time.
In these scenarios, UM operators may wish to defer fare calculation until a complete set of tap data
is available, as long as this meets Deferred Authorization timeframe requirements (i.e. 4 days). This
would avoid the application of charges for incomplete journeys where the operator is aware of a
technical issue or condition with its systems.

3.7.1.1 Tap data arrives after online Authorization (before Clearing)

If the revised amount, after fare calculation, exceeds amount previously Authorized (e.g. the late tap
data resulted in a higher fare), the UM operator must reverse the original Authorization, and submit a
fresh request for the correct amount using the newly received chip data.
Otherwise, if the revised amount is lower (e.g. an incomplete journey charge was corrected to a lower
fare), the UM operator may submit the lower transaction amount in the Clearing record (i.e. lower than
the amount in the original Authorization).

3.7.1.2 Tap data arrives after Clearing

If the revised amount, after fare calculation, is less than that in the original Clearing record, the UM
operator should issue a refund to the customer as soon as possible.
If the revised amount, after fare calculation, is greater than that in the original Clearing record the UM
operator must Authorize the difference between the original and revised amount (using the newly
received chip data) before submitting a Clearing record for the difference. If the Authorization is
declined, it must be treated the same as any other decline response.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 43
Visa Urban Mobility 3: Mobility & Transport Transaction framework
Implementation Guide

3.7.2 Refunds
A refund transaction must be initiated if the cardholder has been overcharged
(e.g. because of late data).

Important

Refunds should be initiated as soon as possible after discovering the overcharging. There is no
requirement to submit online Authorization requests prior to initiating refunds.

Req 17: Urban Mobility Merchant Requirements

(Rule: See ID# 0008605)
An Urban Mobility Merchant must be able to correctly refund a customer that has been
overcharged, but is not required to submit an online Authorization request for the amount of
the credit transaction first

3.7.3 Revenue protection charges

Typically, UM operators may wish to simplify revenue protection processes by incorporating an end of
day back office check of all cards captured through revenue inspection devices against their primary
list of all tap data captured for travel purposes. In cases where there is no match, they may choose to
apply “maximum fare charge” policy instead of a full penalty fare notice. Should a UM operator wish
to enable real time validation of a passenger’s right to travel, they may consider implementing either
immediate back office look up protocols, or perform secure reader-to-reader transfer of data in order
to perform appropriate validation.
A UM operator’s fare policy may include a provision to impose specific penalty charges if a passenger
is found to be travelling in contravention of their conditions of carriage (e.g. customer did not tap their
card when accessing the UM service).
Any charges that are processed in connection with violation of fare policy by a UM operator must be
processed as a separate charge on the cardholder account. That is, the operator should Authorize and
Clear these charges as separate transactions from the MTT travel charges and provide the following
information that should be placed on the issuer statement:
• A clear reason for the charge
• How the cardholder may challenge the charge
UM operators can use the Tap to Phone technology to perform revenue inspection under the MTT
framework. UM operators may also wish to use the Tap to Phone technology in order to apply penalty
charges outside the scope of MTT for their revenue protection needs. Please refer to the latest version
of Visa Ready Tap to Phone Solution Requirements for details.

Important

Conditions under which inspection charges may be imposed and the amount(s) should be clearly
stated in the UM operator’s conditions of carriage, which should be freely available to cardholders.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 44
Visa Urban Mobility
Implementation Guide

Known Fare
Transaction
framework

4.1 KFT overview

The Known Fare Transaction (KFT) framework is a “pay as you go” framework where the fare for each
journey or ticket is known at the time the card is tapped on the UM reader.
The key characteristics of this framework are:
• UM readers accept contactless payments only (no contact chip or magnetic stripe) and must be
capable of completing online Deferred Authorizations
• The amount of the fare charged is always known before the card is tapped
• Transaction amounts are likely to be restricted to the market specific contactless Cardholder
Verification Limit (CVL), since the reader has no card contact chip reader or magnetic-stripe reader
• There is no special shared liability model available like there is with the MTT framework. All
transactions must be Authorized and approved before they may be submitted to Clearing
Urban Mobility solutions utilizing real-time Authorizations are considered retail payments and are out
of scope of this section.
UM operators can use Tap to Phone technology to accept contactless payments and/or perform
revenue inspection under the KFT framework. Please refer to the latest version of Visa Ready Tap to
Phone Solution Requirements for details.

4.2 Tap processing

The interaction of the card and reader for the KFT framework is similar to any retail contactless
transaction. However, a UM reader does not support contact chip or magnetic stripe acceptance, or
need to offer customer receipts.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 45
Visa Urban Mobility 4: Known Fare Transaction framework
Implementation Guide

4.2.1 Handling of Deferred Authorizations

UM operators will defer online KFT Authorizations in order to maintain service continuity where higher
rates of customer throughput are required (e.g. long queue at a vehicle stop).

Urban Mobility operators that defer online Authorizations should be aware of the following:
• UM readers must successfully perform ODA on accepted cards to remove risk of counterfeit card
use (see previous section 3.3.1 for further detail)
• UM readers must check the expiration date of the card and reject expired cards (see previous
section 3.3.2 for further detail)
• UM readers should operate deny list checks to prevent denied cards from travel (see previous
sections 3.3.3 and 3.4.3 for further detail)
• UM operators are permitted to employ additional proprietary processing (see previous section
3.3.6 for further detail)
• UM operators must submit the Deferred Authorization request in accordance with the Visa Rules
and issuers must be able to process these transactions correctly
• UM operators should implement debt recovery processes (see previous section 3.5 for further
detail)

Req 18: Urban Mobility Merchant Requirements

(Rule: See ID# 0030061)
An Acquirer must ensure that its Urban Mobility Merchant:
• Submits a Deferred Authorization with the indicator 5206 present in Field 63.3

Issuers should exclude any transactions identified with a Deferred Authorization flag from ATC
tracking. Please refer to the latest ATC Tracking White Paper available on VOL for further details on how
to handle ATC for Deferred Authorizations.

Important

While the 4 days deferred submission period allows for late data scenarios within MTTs as
described in section 3.7, as the final fare is known for a KFT, UM operators should submit
Authorizations for every journey as soon as possible.

As the transaction is deferred, UM operators handling the KFT framework may resubmit an
Authorization for a previously declined Authorization request twice in a 14 day period, under the [MIT]
framework (please see section 3.5.3 and Table 6 for further detail).
UM operators should not permit the purchase of a separate closed-loop travel pass through the KFT
framework. Any ticketing solutions designed to allow travel for more than a single journey that are sold
at the point of passenger boarding should be done so using a retail based approach only (as described
in section 5.2 or 5.3).

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 46
Visa Urban Mobility 4: Known Fare Transaction framework
Implementation Guide

4.3 Transaction processing

4.3.1 Transaction Identifier

Transactions originating from a UM reader operating under the KFT framework must be identified
correctly, as per the Visa Rules. The Tran ID that is generated during Authorization must be used for the
corresponding Clearing record.

4.3.2 Transaction data fields

Important

For a KFT, acquirers and issuers should expect a match between the cryptogram amount in Field
55 and the transaction amount specified in Field 4.

The important data fields and values in the Authorization and Clearing messages for a deferred KFT
are shown in the following table. Issuers can use data values in the Authorization fields underlined to
identify KFTs:

Table 10 KFT data fields

Authorization Clearing Value Remarks

Amount, Source Variable For a KFT, the value here must match the
Transaction Amount value of tag ‘9F02’ in Field 55.
Field 4 TCR 0 Position
77-88

Transmission N/A Variable The value here must contain the date and
Date and Time time at which the acquirer submits the
Authorization request message.
Field 7

Local Purchase Date Variable The value here should contain the date
Transaction Date TCR 0 Position on which travel first took place.
58-61
Field 13

Merchant Merchant 4111 Indicates a UM operator:

Category Code Category Code 4112
4111: Local and Suburban Commuter
TCR 0 Position 4131
Field 18 Passenger Transportation, including
133-136
Ferries
4112: Passenger Railways
4131: Bus Lines

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 47
Visa Urban Mobility 4: Known Fare Transaction framework
Implementation Guide

Table 10
Authorization Clearing Value Remarks

KFT data
POS Entry Mode POS Entry Mode 07 Indicates a contactless-read
fields
TCR 0 Position transaction.
(Cont.) Field 22.1
162-163

Card Sequence Card Sequence Variable EMV data tag ‘5F34’, optionally
Number Number present on a card, if received by
TCR 7 Position 7-9 the reader, must be forwarded to
Field 23
the acquirer.

POS Condition Code N/A 00 Identifies transaction conditions

at the point of sale. For use in the
Field 25
Authorization request message.

ICC Related Data Terminal Variable Transaction Date.

Transaction Date
Field 55 - Transaction
TCR 7 Position
Date Tag ‘9A’
10-15
(Field 146 for third
bitmap issuers)

ICC Related Data Cryptogram Variable For a KFT, the value here must
Amount match Field 4 since the fare
Field 55 - Amount,
TCR 7 Position amount was known at the time the
Authorized
87-98 card was presented to the reader.
Tag ‘9F02’
(Field 147 for third
bitmap issuers)

Terminal Type Acceptance 3 The value here must be set to an

Terminal Indicator Unattended Cardholder Activated
Field 60.1
TCR 1 Position 124 Terminal (UAT). See [VUMTIG].

Terminal Entry POS Terminal 8 Indicates that the terminal is a

Capability Capability contactless reader only.
TCR 0 Position
Field 60.2
158

Cardholder ID Cardholder ID 3 Unattended Terminal, no PIN pad.

Method Indicator Method
This value is not required in
TCR 0 Position
Field 60.9 Authorization request messages
160
from the acquirer, however
VisaNet will add this in messages
to the issuer.

Message Reason N/A 5206 The value here indicates the

Code (Deferred transaction is a Deferred
Authorization) Authorization, and should be
excluded from ATC tracking.
Field 63.3

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 48
Visa Urban Mobility 4: Known Fare Transaction framework
Implementation Guide

4.3.3 Payment processing

UM readers operating the KFT framework must be configured
as per Table 10 above.
For payment processing, the UM operator back office will:
• Perform online Deferred Authorization requests for each
transaction
• Perform Settlement for approved transactions (i.e.
submit them to Clearing)
• Perform debt recovery processes when implemented
• Receive and process disputes
• Manage revenue protection needs through use of
inspection devices

UM operators may use readers, typically portable terminals,

to verify passenger compliance with their fare policy. Note
Such a device performs some of the same functions as
a conventional reader (i.e. it authenticates the card, and Operators, payment service
generates tap data which is either checked in real time or providers, and acquirers
sent to the operator’s back office). As such, these devices are must ensure that storage,
subject to the same requirements and certification as readers
processing, transmission of
installed elsewhere on their network. Please refer to previous
section 3.7.3 for further detail. PAN, or other account data

UM operators can use Tap to Phone technology to perform complies with [PCI DSS].
revenue inspection under the KFT framework. Additionally,
UM operators may also wish to use the Tap to Phone
technology in order to apply penalty charges outside the
scope of KFT for their revenue protection needs. Please refer
to the latest version of Visa Ready Tap to Phone Solution
Requirements for details.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 49
Visa Urban Mobility 4: Known Fare Transaction framework
Implementation Guide

4.3.4 Acquirer transaction processing

Acquirers must ensure that UM operators handling the KFT framework configure their readers as per
Table 10 above. Other than being deferred and including the necessary message reason code indicator
of 5206, the processing of transactions from operators handling the KFT framework is similar to
contactless-only retail transactions.
Acquirers must not submit any transactions to Clearing that have not been Authorized and approved.
Acquirers that resubmit declined Authorization requests must follow the processes defined in the
[MIT] framework, as explained in the previous section 3.5.3.

4.3.5 Issuer transaction processing

Issuers can identify a KFT based on the configuration of the UM reader (i.e. a UAT capable of
contactless payments only from MCC 4111, 4112 or 4131) where the fare was known at the point the card
was tapped (i.e. Field 4 is equal to Amount, Authorized).

4.3.5.1 Application Transaction Counter (ATC) tracking

As with MTTs in section 3.6.6.3, issuer hosts should expect to receive Authorization requests where
the value of the ATC is out of sequence to a previously received ATC value (e.g. if a customer has
performed transactions after travel but before the KFT is submitted), as KFTs are deferred. As with
all Deferred Authorizations, issuers can optimize approval rates by excluding KFTs with this indicator
present from ATC tracking. Please refer to the latest ATC Tracking White Paper available on VOL for
further details on how to handle ATC for Deferred Authorizations.

Important

Issuers must not automatically decline a KFT based on an unexpected sequence of ATC received
in the online Authorization.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 50
Visa Urban Mobility
Implementation Guide

Mobility
Adjacent
Segments

5.1 Overview
There are multiple other payment options available for UM operators and providers in UM adjacent
segments, such as those in the cable-car (MCC 4789), cycle/scooter hire (MCC 7999), EV charging
(MCC 5552), parking (MCC 7523), and tolls (MCC 4784) sectors. These are typically based on existing
retail frameworks available for merchants or operators providing services in broader segments;
either using cardholder present or cardholder not present capabilities. This section describes the key
considerations, payment flows, and transaction processing requirements for some of the payment
options available. This is provided for informational purposes only. UM operators and their acquirers
must follow Visa rules, and may contact their local Visa representative to obtain further information if
wishing to implement any of these solutions.

5.2 Cardholder Present overview

Some of the cardholder present retail options are “pay as you go” frameworks where the fare for each
interaction is typically known at the time the card is presented to the reader.
The key characteristics of these frameworks are:
• Readers accept either contact and contactless chip or contactless payments only, and must be
capable of completing online Authorizations in real-time
• The amount of the fare charged is typically known before the card is inserted/tapped
• Transactions will be Authorized online
• Transaction amounts may be above the market specific contactless Cardholder Verification Limit
(CVL), only if the reader is enabled with PIN entry and CVM capabilities
• There are typically no debt recovery options available like there are with the KFT or MTT
frameworks. All transactions must be Authorized and approved before they may be submitted to
Clearing
• There is no special shared liability model available like there is with the MTT framework. All
transactions must be Authorized and approved before they may be submitted to Clearing

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 51
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

5.2.1 Card processing

The interaction of the card and the reader is similar to retail transactions in any sector, and as such, the
Authorization is typically not deferred, so no deny list management, back office requirement, or debt
recovery mechanisms are needed. The key features are:
• The card is inserted into/tapped on a reader, and a transaction for the fare amount is processed.
The operator can charge a flat, time, or distance based fare to suit their needs
• The transaction will be Authorized online
• The Authorization decision will be shown on the reader once the transaction completes
• Only if the Authorization is approved may the transaction be submitted to Clearing
• The reader may support contact and contactless chip, and may produce receipts

5.2.2 Transaction Identifier

Transactions originating from a reader operating under any of the cardholder present retail frameworks
must be identified correctly, as per the Visa Rules. The Tran ID that is generated during Authorization
approvals must be used for the corresponding Clearing record.

5.2.3 Transaction data fields

The important data fields and values in the Authorization messages for each of the cardholder present
retail frameworks are shown in the following tables:

Table 11 Key fields used in Contact & Contactless Authorizations

Card Field Field Field Field Field Field

Present 22 25 60.1 60.2 60.9 63.3
(with chip
data)

Contact Chip Yes 05 0 0 5 0 —

Authorization

Contactless Yes 07 00 0 5 0 —
Authorization

The final fare amount is known by the cardholder and displayed on the reader, or nearby, before they
insert/tap their card. This option is available to operators in any sector.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 52
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

Table 12 Key fields used in Contactless-only Authorizations

Card Field Field Field Field Field Field

Present 22 25 60.1 60.2 60.9 63.3
(with chip
data)

Contactless-only
Yes 07 00 3 8 3 —
Authorization

The final fare amount is known by the cardholder and displayed on the reader, or nearby, before they
tap their card. This option is available to operators in any sector.

Table 13 Key fields used in Contactless-only Tap to Phone real-time Authorizations

Card Field Field Field Field Field Field Field

Present 22 25 55 60.1 60.2 60.9 63.3
(with chip Tag
data) ‘9F6E’

Contactless-only
Yes 07 00 1b 9 8 1 —
Authorization

The final fare amount is known by the cardholder and displayed on the reader, or nearby, before they
tap their card. This option is available to operators in any sector.
UM operators can use the Tap to Phone technology to accept contactless payments. Please refer to
the latest version of Visa Ready Tap to Phone Solution Requirements for details.

Table 14 Key fields used in Contactless-only Estimated/Incremental Authorizations

Card Field Field Field Field Field Field

Present 22 25 60.1 60.2 60.9 63.3
(with chip
data)

Estimated
Yes 07 00 3 8 3 —
Authorization

Incremental
No 01 00 0 0 — 3900*
Authorization

*For the U.S.: “I” (Incremental) value in Field 62.1 (Authorization Characteristics Indicator)

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 53
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

An estimated authorization is an authorization-type approval that occurs before an operator knows

the final transaction amount. It enables an operator to secure approved funds based on the estimated
value of the goods or services the cardholder will purchase. It is typically used when the cardholder
consumes or is in the process of obtaining goods or services before the final purchase amount is
known.
An incremental authorization enables an operator to increase the amount of funds if the initial
estimated amount is insufficient. Incremental authorizations may only be used if the purchase
transaction was initiated with an estimated authorization. The incremental authorization request
is always a Merchant Initiated Transaction (MIT) as this transaction relates to a previous cardholder
initiated transaction, but is conducted without the active participation of the cardholder.
This option is available to operators in all sectors, but is prohibited for certain transaction types. Please
refer to the Visa Rules.

Important

Merchants must use the Estimated Authorization Request indicator identified in Field 60.10
with a value of either 2 or 3 for the first transaction, and the Incremental Authorization Request
indicator in Field 63.3 with a value of 3900* for any subsequent Authorization Requests, using
the same Tran ID in Field 62.2 for all Authorization Requests associated with the fare charge.

When submitting the first Estimated Authorization Request for UM operators, the operator must
inform the Cardholder both:
• That the Authorization Request is not final and that there may be subsequent Authorization
Requests
• Of the amount of the Estimated Authorization Request

5.3 Cardholder Not Present overview

Some of the cardholder not present retail options may be “pay as you go” frameworks where the fare
for each interaction may be known, or not, at the time the interaction is taking place.
The key characteristics of these frameworks are:
• There are no physical card acceptance device readers, and transactions are handled through a
back office environment
• The amount of the fare charged may be known, but could also be unknown, before the card is
used to initiate a purchase, depending on the specific framework used
• Transactions must be Authorized online, but may not be performed until after the interaction/
journey has been completed and the final charge amount determined
• There may be limited debt recovery options available
• There is no special shared liability model available like there is with the MTT framework. All
transactions must be Authorized and approved by the issuer before they may be submitted to
Clearing

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 54
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

5.3.1 Card processing

The interaction of the card and the operator is different from a cardholder present retail payment. As
there is no physical interaction between the card and a reader, back office management is required so
transactions can be generated and sent. The key features are:
• The PAN is typically entered into a website or stored securely using Visa Click to Pay upon the
successful completion of an initial online account registration. The operator can use this to charge
a flat, time, or distance based fare to suit their needs
• The transaction will be Authorized online in real time when initiated by the customer, or at the
completion of the interaction if the customer has registered their card for future recurring use
through stored credentials
• Online cardholder verification may be performed, with CVV2 captured in Field 126.10 of the
Authorization, and transactions protected by Visa Secure where required
• Only if the Authorization is approved may the transaction be submitted to Clearing
• Receipts are generally handled digitally through the operator website or via email
• If the operator is storing payment credentials they must fulfil cardholder disclosure, agreement &
acceptance requirements as part of their conditions of service

5.3.2 Transaction Identifier

Transactions originating from a UM operator handling payments under any of the cardholder not
present retail frameworks must be identified correctly, as per the Visa Rules. The Tran ID that is
generated during Authorization approvals must be used for the corresponding Clearing record.

5.3.3 Transaction data fields

The important data fields and values in the Authorization messages for each of the cardholder not
present retail frameworks are shown in the following tables:

Table 15 Key fields used in E-commerce Authorizations

Card Field Field Field Field Field Field

Present 22 25 60.1 60.2 60.9 63.3
(with chip
data)

Website
E-commerce No 01 59 0 9 4 —
Authorization

The final fare amount is known by the cardholder and displayed on the website before they enter their
card details. This option is available to operators in any sector.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 55
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

Table 16 Key fields used for In-App Authorizations

Card Present Field Field Field Field Field Field

(w/ chip data) 22 25 60.1 60.2 60.9 63.3

In-App
E-commerce No 10 59 0 9 4 —
Authorization

The final fare amount is known by the cardholder and displayed via the App using stored credentials
tokenized in-App. This option is available to operators in any sector.

Table 17 Key fields used in Unscheduled Card-on-File Authorizations

Card Present Field Field Field Field Field Field

(w/ chip data) 22 25 60.1 60.2 60.9 63.3

First
01 / 51 /
Unscheduled No 0 9 4 —
10 59
Card-on-file

Subsequent
Unscheduled
No 10 59 0 9 4 —
Card-on-file (or
resubmission)

The final fare amount is not always known by the cardholder but is displayed via digital receipt
following completion of the payment using the stored credentials. This option is available to operators
in any sector.
Passengers can securely register their Visa card for fare billing or reimbursement. If real-time payment
processing is required, Visa Direct allows businesses and financial institutions to send money to
financial accounts or wallets worldwide, using these same credentials.
Unscheduled Card-on-file (UCOF) transactions are similar to recurring payments, but at non-fixed
dates (e.g. can be used to initiate an automatic payment for toll usage linked to a card through
a registered Radio Frequency Identification (RFID) transponder or other vehicle identification
technology).

Important

UM operators must use the First UCOF transaction type for registering a customer’s card,
which is a Customer Initiated Transaction (CIT). Subsequent UCOF transactions for any charges
incurred for the provision of services are considered a Merchant Initiated Transaction (MIT). If
the issuer declines this, the operator may submit the Subsequent UCOF Authorization Request
again, using the Tran ID from the First UCOF, or the most recent approval received for that card.
The Tran ID must be present in F62.2 or in TLV F125 Dataset 03 Tag 03.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 56
Visa Urban Mobility 5: Mobility Adjacent Segments
Implementation Guide

An overview of the key transaction fields for some of the Cardholder Not Present payments within the
Stored Credentials framework are given below. Please see [MIT] for further details.

Figure 7 Overview of Unscheduled Card-on-File and MIT frameworks

UCOF MIT
Framework Framework

Field Field Field Field

Transaction Category and Type according to [MIT]
22 126.13 63.3 125

Customer Initiated (CIT) – putting card on

file for the first time 01 /
1 CIT C N/A N/A
(e.g. to set up payment details on 10
account for future use)

CIT with stored Credential (e.g. shopping

2 CIT 10 — N/A N/A
online at a merchant or using an app)

01 /
5 CIT First Unscheduled Card-on-File C N/A N/A
10

Subsequent Unscheduled Card-on-File Initial

6 MIT (e.g. accessing a toll with RFID or other 10 C — Tran
vehicle identification methods) ID

Important

For Recurring, Installment, and Unscheduled Card-on-File MITs, the appropriate value in Field
126.13 must be used to indicate the type of MIT instead of using a Message Reason Code in
Field 63.3.

UM operators and providers may wish to offer App-to-Ride propositions. These can be provided
by or on behalf of the UMO, typically the operator itself, service provider, aggregator or even a city
or government entity. App-to-Ride enables passengers to plan, pay and complete their transport
journeys using a mobile device.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 57
Visa Urban Mobility
Implementation Guide

Urban Mobility
operator
security
requirements

6.1 Introduction
UM operators are required to meet the relevant security requirements of the payments industry
including:
• [PCI DSS] due to the storage, processing and transmission of account data
• Additional security requirements for readers within the Visa specifications (e.g. the protection of
scheme public keys)
• Good security practice, such as that specified in [ISO27001]

6.2 PCI DSS requirements

PCI DSS is a global standard designed to help businesses process payments securely, reducing
the risk of card fraud or reputational damage from stolen cardholder data through implementing
controls on the storage, processing, and transmission of account data. The [PCI DSS] standard
provides comprehensive security requirements that apply to any organization involved in the storage,
processing, or transmission of account data. Account data must never be stored in the clear.
[PCI DSS] defines account data as consisting of cardholder data and sensitive authentication data. If
account data is stored, processed, or transmitted by a UM operator or their processor, appropriate
measures must be taken to protect it.

Important

The best practice tips are intended to provide stakeholders with learnings they may apply
where appropriate. They do not replace a thorough risk analysis against [PCI DSS] or the
engagement of a Qualified Security Assessor (QSA).

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 58
Visa Urban Mobility 6: Urban Mobility operator security requirements
Implementation Guide

6.3 Security best practice

The most efficient method to reduce the risk to account data and the effort to implement and
maintain the required security controls required to protect it is to reduce account data storage. There
are various solutions that can be employed, for example tokenization, to reduce the systems where
account data is stored, processed or transmitted.
When defining their security architecture, as best practice, a UM operator should take particular care to
consider:
• Maintain the compliance throughout the year as Business-as-Usual (BAU)
• A purpose designed solution for payment systems
• Card list processing
• Segmentation between networks and systems where account data is stored, processed or
transmitted
To ensure compliance is achieved with minimal impact, it is important that a UM operator engage with
a QSA early in the lifecycle of a deployment project. For a list of Qualified Security Assessors, please
refer to PCI Security Standards Council web site:

https://www.pcisecuritystandards.org/assessors_and_solutions/qualified_security_assessors.

6.3.1 Maintaining Compliance as BAU

One of the main reasons for security breaches is a gap in compliance, where the security controls are
not maintained after being put in place. The following key principles can assist in implementing and
maintaining security controls throughout the year:
• Sustainable compliance program, that is evolved to support changes in threat and compliance
landscape.
• Program, policy and procedures to help drive behavior and maintain repeatable business and
operational processes
• Assign ownership for security activities, with a management-level individual assigned the
responsibility for continue monitoring of compliance.
• Educate employees in information security, and evolve the security awareness program with
content that is kept up to date with the latest trends in breaches.
• Define performance metrics to measure successes and failures, and continuously monitor
implemented security controls.
Refer to PCI DSS 4.0 section 5. Best Practices for Implementing PCI DSS into Business-as-Usual
Processes, and Best Practices for Maintaining PCI DSS Compliance in the Document Library on the PCI
SSC website (https://www.pcisecuritystandards.org/document_library/) for additional guidance.

Important

To protect themselves, UM operators must strive for ways to maintain a continuous state of
compliance throughout the year rather than seeking point-in-time validation.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 59
Visa Urban Mobility 6: Urban Mobility operator security requirements
Implementation Guide

6.3.2 Purpose-designed solutions for Payment Systems

There are numerous solutions, products and devices that are designed specifically to protect account
data and payment information, such as PCI Point-to-Point Encryption (P2PE), End-to-End, or Non-
listed Encryption Solutions Assessment (NESA) solutions, and PCI PTS POI hardware devices. PTS
POI devices are not only purpose-built for PIN entry and payment security, but are secure, fast, and
reliable for contactless-only reading capabilities without PIN entry. These devices and/or solutions are
evaluated to rigorous security requirements, and can support various integration and deployment
methods (e.g. attended, unattended, standalone, integrated, etc.) and payment acceptance channels
(e.g. contact, contactless, card not present, etc.)
There are other security standards to be considered when using Tap to Phone technology to accept
contactless payments and/or perform revenue inspection, such as PCI Contactless Payments and
COTS (CPoC), Mobile payments on COTS (MPoC), and Visa Ready Tap to Phone solutions. Please refer
to the latest version of Visa Ready Tap to Phone Solution Requirements for details, and the Visa Ready
online directory for certified Tap to Phone solutions.

6.3.3 Card List Processing

A UM operator’s approach to cardholder data protection can affect the management of card lists.
Card lists may be used for a number of possible reasons, for example:
• Deny lists – to prevent further travel by cards deemed not accepted for travel (e.g., following an
online Authorization decline)
• Pass-back lists – to prevent the same card being used multiple times at the same time on a
reader. This feature is one that a number of UM operators use to ensure compliance with their
conditions of carriage
• Accept lists – a list that positively identifies cards that have been pre-approved as accepted for
travel
The use of suitably protected card lists, held at readers and/or centrally in a UM system, is an expected
design solution to meet Visa’s requirements for risk management.
A common requirement across the processing of these lists is the need to match the card presented
at a reader with the card data on an applicable list. UM operators are advised to employ one-way
functions, such as hashing based on strong cryptography or acceptable truncation method, to avoid
the need to store PANs for matching purposes. It is also a recommended practice, but not specified
requirement, that a salt be included when employing hash functions.
Please refer to FAQs 1089, 1091, 1308 and 1492 on PCI Security Standards website (https://www.
pcisecuritystandards.org/faqs/) for additional guidance on acceptable truncation formats.

Important

Due to the risk of unauthorized third parties attempting to discover PANs, if hashed and
truncated versions of the same PAN, or different truncation formats of the same PAN, are
present in an environment, additional controls must be in place such that the different versions
cannot be correlated to reconstruct the original PAN.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 60
Visa Urban Mobility 6: Urban Mobility operator security requirements
Implementation Guide

6.3.4 Networks and Systems Segmentation

It is important to segment or isolate the systems that store, process or transmit account data from
the remainder of the networks, such that less secure network segments will not impact the security
of account data. While segmentation is not a PCI DSS requirement, it is strongly recommended as a
method that can reduce the scope and the cost of PCI DSS assessment, as well as the effort and the
cost to implement and maintain PCI DSS controls. The arrival of account data in the back office may be
the trigger for a number of processes, such as:
• Fare calculation
• List management
• Authorization and Clearing requests
• Customer servicing
Multiple back office systems may need access to account data, which potentially extends the scope
of [PCI DSS] to these systems. This is something that most UM operators seek to minimize, and their
systems should be designed to avoid PAN data (or any other sensitive account data) being stored in
multiple locations, which increases risk.
Scope of PCI DSS requirements does not only apply to systems that store, process or transmit account
data, but have unrestricted connectivity to systems and networks that do, as well as systems that
provide security services, systems that facilitate segmentation and systems that can impact the
security of account data.
For additional guidance, refer to PCI DSS 4.0 section 4 Scope of PCI DSS, and Information Supplement:
Guidance for PCI DSS Scoping and Network Segmentation on the PCI SSC website (https://www.
pcisecuritystandards.org/document_library/).

Important

UM operators may wish to consider securely storing just one copy of the PAN or token, and
design their solution such that the PAR and an unrecognizable representation of the PAN or
token is available for use by other systems.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 61
Visa Urban Mobility
Implementation Guide

7
Card
personalization

Visa’s MTT and KFT frameworks are designed to accept all contactless cards, regardless of the
country of issuance, that are capable of performing ODA (specifically fDDA). However, there are two
personalization settings that issuers should be aware of in particular, and verify, to ensure their cards
are accepted at all UM operators worldwide.

7.1 Support ODA

In accordance with the Visa Rules, issuers must personalize cards for ODA with online Authorization as
defined in [VCPS] 2.1 or later.

Req 19: Urban Mobility Issuer Requirements

(Rule: See ID# 0029157)
An Issuer must ensure that all newly issued Visa Contactless chip cards support Offline Data
Authentication (ODA) with Online Authorization using fast Dynamic Data Authentication
(fDDA) as specified in VCPS 2.1 or later.

7.2 International use

Issuers should personalize cards to allow international transactions, as defined in [VCPS].

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 62
Visa Urban Mobility
Implementation Guide

Customer
service

UM operators and card issuers must consider how they are going to support cardholders using a
UM system, especially how support is shared between organizations. This section discusses the key
considerations.

8.1 Urban Mobility operators

8.1.1 Conditions of carriage (CoC)

The charges applied when using contactless cards in UM, including inspection, penalty or “maximum”
fare charges, are subject to the UM operator’s conditions of carriage. At a minimum, the following must
be satisfied:
• Conditions of carriage must be readily available to cardholders
• If entry to the UM system is deemed to imply acceptance of the conditions of carriage, then
prominent notices must be present at points of entry to the network as well as communicated on
the network itself

8.1.2 Handling customer queries

Cardholders using a UM system after presenting their card may query the charge. This may be for a
number of reasons, particularly in the MTT framework where the fare calculation may be relatively
complex (e.g. due to distance travelled, time of journey, use of different travel modes, or capping).
Although a transaction may appear on a statement, the issuer will not have access to the data
necessary to respond to a query. UM operators should offer the following support to their customers:
• Clear messaging to avoid known issues (e.g. card on deny list)
• Advice for customers on how to get support, preferably through self-service

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 63
Visa Urban Mobility 8: Customer service
Implementation Guide

8.1.3 Online access to transaction data

Since UM readers operating under the MTT framework do not provide transaction receipts,
journey information must be made available to cardholders via alternative means as the following
requirement states:

Req 20: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Acquirer must ensure that its Urban Mobility Merchant, upon completion of a transaction,
provides the Cardholder with access to all of the following information for a minimum of 120
days following the Transaction Processing Date:
• Merchant name
• Total transaction amount in the transaction currency
• Details of each individual journey completed during the travel period, including the start
and end time of each journey
• Final Transaction Date (last journey in travel period)
• Purchase Date (first journey in travel period)
• Any discounts applied

Many queries can be answered by providing the cardholder with online access to their travel history,
including information from tap data captured and charges made to the card. This can help avoid the
need for customers to contact customer services, and can reduce operator and issuer customer
service costs.
UM operators can make online “digital receipts” available for cardholders using either a standard
contactless card or a device-based tokenized form of payment. A secure web interface can be used
to capture, for example, the PAN, expiry date, the date of travel and fare amount in order to provide
the necessary information.
Some UM operators will already provide web-based portals for customers to log in to and may wish
to provide this information within that.
• For card users (PAN), the cardholder would register an account and link their card by completing
a secured e-commerce transaction (to prove the card is in possession of the cardholder). Once
linked, the transaction history for that card can be shown
• For device-based users (token), the cardholder would register and link their card in the same way
as above. The Payment Account Reference (PAR) may be used to associate the linked card (the
PAR value is returned in the Authorization response when the card was linked) with the tokenized
transaction history (the same PAR value is provided in the original Authorization response for the
device used to travel)
• Alternatively, the UM operator may wish to perform a fresh PAR inquiry through a number of
available channels such as Authorization message formats or the Visa Developer Platform. This
will enable the latest PAR information to be captured, and used, for customer servicing needs.
UM operators should be able to identify daily customer journeys regardless of credential used.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 64
Visa Urban Mobility 8: Customer service
Implementation Guide

8.1.4 Using the Payment Account Reference

A Payment Account Reference (PAR) is a unique identifier associated with a specific payment account.
This reference is used with a Visa account to link various payment form factors to one underlying
payment account. For example, once a token has been provisioned on a mobile device, the numeric
on this device will be different from the PAN. This introduces customer service challenges, as the
cardholder may only know their PAN. The PAR can be used in place of sensitive cardholder data such
as the PAN, and transmitted across the payments ecosystem to facilitate account identification and
customer servicing regardless of payment device form factor. PAR allows issuers, acquirers and
operators to link all activity related to the underlying payment account across multiple form factors
(e.g. card, mobile, wearable) without relying on the PAN as the identifier.
During a transaction, using a mobile device, a token (present in tag ‘5A’ and part of tag ‘57’) and PAR (if
present on the device, in tag ‘9F24’) are transmitted. The operator processes an Authorization request
including the token and PAR (if present). As long as the acquirer is certified to receive the PAR value
through standard ISO messaging formats, they will then receive an Authorization response including
the PAR value in Field 56, regardless of whether PAR was present on the mobile device or not.

Req 21: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Acquirer must ensure that their Urban Mobility Merchants are:
• Able to receive a Payment Account Reference (PAR)

The PAR may also be useful for customer service uses in offering a replacement for the PAN across
systems, increasing security, and reducing PCI compliance requirements. For example;
• Real time cardholder identification
• Risk / fraud / management
• Omni-channel CRM
• Enhanced opt-in loyalty / rewards programs
• Better account lifecycle management
PAR allows operators, acquirers and issuers to track and manage accounts regardless of the form factor
presented. Once assigned to a payment account, the PAR will not change, even if the card is reissued.
PAR cannot be used to identify the card product or issuer.
While PAR should be used for providing effective customer servicing, it is not recommended for
deny list management or journey tap data accumulation across multiple devices, as it can lead to an
inconsistent customer experience or operational process for UM operators.
In order to obtain the necessary PAR value in a customer servicing environment, UM operators may
submit a standard AVR Authorization request, a PAR inquiry Authorization request, or subscribe to the
Visa Developer Platform (directly or via their systems integrator). In each case, the PAR value will be
returned for the given PAN, so a secure cross-check can be performed using this numeric to identify
where the same PAR value is linked to other payment device form factors.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 65
Visa Urban Mobility 8: Customer service
Implementation Guide

Figure 8 Overview of Payment Account Reference

Merchants Acquirers Issuers

PAN use Service offering Fraud prevention Fraud prevention

PAN often central to the Acquirers employing Issuers employing transaction
merchant core offering transaction monitoring monitoring fraud programs use
and used to drive the fraud programs use PAN to PAN to identify potentially
service to a consumer identify potentially fraudulent account use
fraudulent account use
Opt in services
PAN often used to identify
consumers in rewards
programs and provide access
to value-add services

Payment Account Reference (PAR)

PAR (EMVCo) allows all participants in the ecosystem to
Solution
have visibility of a single, non-sensitive value assigned to
a consumer payment account.

Req 22: Security of Account Numbers and Payment Account References

(Rule: See ID# 0029276)
An Acquirer must ensure all of the following:
• That the Account Number associated with a payment Token in a transaction is not
disclosed to the Merchant
• That a Payment Account Reference (PAR) is not stored with its associated full Account
Number(s) or payment Token(s) in the clear
• That a transaction is not initiated with a PAR
• That a PAR is used only for the following:
• Providing or managing only customer service
• Performing fraud and risk control activities
• Supporting value-added services in which the Cardholder has opted to participate
• Aiding compliance with applicable laws or regulations

Important

While PAR is not identified as sensitive data in PCI, PAR data should be used and protected in
accordance with national, regional, and local laws and regulations, including privacy laws.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 66
Visa Urban Mobility 8: Customer service
Implementation Guide

8.1.5 Customer education

Some of the more common questions that cardholders may raise regarding card usage can be
mitigated by the provision of clear, timely, and consistent information before and during travel. For
example:
• Reminding the cardholder of the need to present only the card they wish to use in the reader field
to avoid “card clash”
• Reminding the cardholder of the need to tap in and out using the same card or device for the
entire journey to get the best fare (if capping applies). UM operators should be contacted for
assistance with any query
• Reminding mobile users they may need to have the payment screen ready in advance of travel
to avoid the need to enter their passcode or unlock with a biometric authentication as they pass
through a gate

8.2 Issuers

8.2.1 Handling customer queries

To handle customer queries effectively, issuers should ensure their customer service systems and staff
can identify UM transactions and manage them in an appropriate way.
Issuers should prepare analysis and resolution paths for the most common queries. For example, the
following may be some of the types received:
• Card being denied at the reader – issuers should be able to identify that a card transaction has
recently been declined at the UM operator, resolve any outstanding account based issues, and
then advise the customer to contact that operator
• Charges being applied – issuers should handover or direct the cardholder to the UM operator who
can answer specific fare queries

8.2.2 Statement data

The Merchant Name and Merchant City
fields are populated in Clearing records
and should contain operator contact
information for cardholders (e.g. a
website address or telephone number).
The operator name should be clear and
consistent for each transaction. It should be
the name most prominently displayed by
the UM operator and by which cardholders
recognize them.

Important

Issuers should include the name and

contact information provided by the UM
operator in cardholder statements.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 67
Visa Urban Mobility 8: Customer service
Implementation Guide

8.3 Cardholder verification

As cardholder verification on the UM reader is not possible, transaction amounts are typically restricted
to below the contactless CVL.

Important

For MTTs, as the final fare is not known at the time a card is presented to a reader, if the accumulated
charge at the end of the day results in a transaction higher than the market contactless CVL, a valid
CVM would still not have been captured for the Authorization request. Therefore, issuers should not
decline an MTT based solely on a missing CVM.

Mobile-capable devices may require the entry of a CDCVM on the handset, such as a fingerprint or
passcode for all transaction types, including Urban Mobility. To ensure fast throughput at UM readers
and to improve the cardholder experience, operators and issuers should explain that cardholders may
be required to get the payment functionality ready prior to arrival at the reader.
Some mobile digital wallet providers may choose to bypass the requirement for CDCVM on their
devices used in the UM environment to enable the fastest passenger throughput. UM operators
should work with the digital wallet providers to ensure a seamless customer experience at point of
entry to the UM system, and perform extensive testing prior to launch. Refer to [VUMTIG] for details
how to enable this feature.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 68
Visa Urban Mobility
Implementation Guide

Dispute
resolution

9.1 Urban Mobility operators

Where a cardholder has a dispute about a UM transaction, they should in the first instance contact the
UM operator, as described in section 8.
In order to answer such disputes, the UM operator must be able to make purchase information and
accumulated transaction information available to a cardholder for at least 120 days after the processing
date of the transaction, please refer to section 8.1.3.

9.2 Issuers
Issuers may dispute a transaction for some of the following reasons:
• Where a transaction amount above the MTT shared liability limit is submitted to Clearing after the
issuer has declined an online Authorization request (Condition Number 11.2), as follows:

Req 23: Dispute Rights and Limitations

(Rule: See ID# 0030266)
A dispute of a Mobility & Transport Transaction is valid for the full transaction amount if a decline
response was sent and the transaction amount was greater than the MTT shared liability limit, see
Condition Number 11.2.

• Where a card that did not support ODA was accepted for travel on the UM network under the MTT
framework (Condition Number 11.3)
• Where subsequent declined transactions are submitted after a declined Authorization request.
This condition remains in place until the issuer approves an Authorization request for a transaction
made with the card (Condition Number 11.3)
However, issuers may not dispute Authorized transactions on the grounds of an incorrect account
number or cases of fraud, nor a credit refund initiated without an Authorization:

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 69
Visa Urban Mobility 9: Dispute resolution
Implementation Guide

Req 24: Invalid Disputes

(Rule: See ID# 0030241, 0030247, 0030272, and 0030293)
Condition Numbers 10.2, 10.3, 11.3, and 12.4 are invalid for Mobility & Transport Transactions.

9.3 Acquirers
Acquirers may receive disputes related to UM transactions for any of the principle reasons detailed
in section 9.2 above. Acquirers have the same pre-arbitration rights as for other disputes with these
condition titles and numbers.

9.4 Dispute resolution summary

It is recommended that the resolution of cardholder disputed transactions should first be attempted
through the UM operators. Any disputes presented by issuers or acquirers must be provided with
relevant evidence of a breach of the Visa Rules. Some of the more common dispute scenarios across
the 4 conditions, both valid and invalid for UM transactions, are summarized in the following table
(please refer to the dispute resolution category condition titles in the Visa Rules for full details):

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 70
Visa Urban Mobility 9: Dispute resolution
Implementation Guide

Table 18: Dispute resolution condition titles and numbers

Valid Invalid

Condition title
Description Description
and number

Fraud: 10.2 or 10.3 Non-Counterfeit

or Other Fraud
(Card-Present
Environment)

Authorization: 11.2 Declined Authorization:

Can be used for when transactions above the
market or region values specified in the MTT shared
liability limits table in the Visa Rules are submitted to
Clearing.

Authorization: 11.3 No Authorization: No Authorization:

Can be used for when transactions on cards that Credit Refund
did not support ODA are accepted for travel, are transactions
submitted after a previous declined Authorization
request, or when the Authorization is not obtained
or submitted within specified timeframes.

Processing Errors: Incorrect Account

12.4 Number

Processing Errors: Incorrect Transaction Amount:

12.5 The fare has been miscalculated.

Processing Errors: Declined Authorization:

12.6
Can be used for when transactions above the
market or region values specified in the MTT shared
liability limits table in the Visa Rules are submitted to
Clearing.

Consumer Credit Not Processed:

Disputes: 13.6
The UM operator acknowledges that a refund is due
and attempts to credit the cardholder, but it is not
received.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 71
Visa Urban Mobility
Implementation Guide

10

Testing

10.1 Urban Mobility operator and vendor responsibilities

Operators must ensure UM readers comply with all Visa requirements defined for the frameworks
described in this guide, including relevant tests detailed in EMVCo. For information about EMV
certification, visit www.emvco.com. The Visa Level 2 test plan for UM readers aligned with the MTT
and KFT Deferred Authorization frameworks must be followed as defined in [VCTKS]. An acquirer must
successfully complete Visa’s Level 3 (L3) using the latest version of Visa’s EMV-Compliant Global L3
Test Set Files and an EMVCo-Qualified and Visa-Confirmed L3 Test Tool.
For guidance on this terminal testing process or obtaining the Visa Certificate Authority Public Keys
(including those required for mobile device HCE-based payments), UM operators should contact
their acquirer, and any other technology partner should contact either the Visa Ready for Transit or
Technology Partners team.
EMV accreditation is required to ensure that UM readers meet the minimum requirements to
communicate with Visa Contactless cards. UM readers must be certified to EMV Level 1 and EMV
Level 2, before they can be integrated with an acquirer to process payments and complete Visa Level
3 testing. UM operators should also complete full end-to-end integration testing with their systems
integrator and acquirer. It is also recommended to perform Visa’s “Go Live” Proving test cases as a final
self-validation step prior to commercial launch. Please contact your local Visa representative to obtain
these and complete production pilot testing.
Some certification testing requirements, such as those for Level 1, may differ for Tap to Phone devices.

10.1.1 EMV Level 2 accreditation

EMV Level 2 type approval accreditation for UM readers focuses on certifying the software kernel that
runs within the reader, which ultimately communicates with the contactless card presented. This
certification process ensures that the application within UM readers correctly interacts with cards, and
generates the data used for transactions in compliance with requirements of [VCTKS] and [VUMTIG].
The UM reader vendor is required to work with an accredited test lab where kernel specific tests
aligned with [VCTKS] will be carried out. Once the test lab submits the reports, Visa can support in this
certification process, ultimately providing the required Letter of Approval for EMV Level 2 following
review by the Approval Services function. This certification step is intended to mitigate the risk of
launching with non-compliant hardware solutions that may result in card acceptance issues.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 72
Visa Urban Mobility 10: Testing
Implementation Guide

10.1.2 Visa Level 3 testing

Visa Level 3 testing is a mandatory phase of testing. It helps ensure that chip terminals are
interoperable and takes place once the acceptance solution is configured and ready for deployment. It
improves acceptance of Visa-branded products.
An acquirer must successfully complete Visa Level 3 testing using the Visa Global L3 Test Set Files.
Please refer to the latest version of the Visa Global Level 3 Testing Guidelines and Frequently Asked
Questions and EMVCo -qualified and Visa-Confirmed L3 Test Tools documents (available on Visa

10.2 Acquirer responsibilities

To avoid implementation problems, acquirers should work closely with both Visa and UM operators
as soon as they begin to implement an MTT or KFT project. Acquirers do this to ensure their UM
operators understand the requirements and are able to implement them successfully. Acquirers
must share the Visa Certificate Authority Public Keys (including those required for UM cloud-based
payments) with their UM operator, and should contact their local Visa representative to obtain these.

Req 25: Urban Mobility Merchant Requirements

(Rule: See ID# 0030050)
An Acquirer must ensure that its Urban Mobility Merchant does all of the following:
• Registers with Visa
• Deploys contactless-only acceptance devices
• Meets all of the requirements of this guide and the Visa Rules

Acquirers seeking to implement MTT projects can use Visa Card Present Connect (CPC) to
potentially accelerate support of MTT. further details can be found at https://docs.cybersource.
com/en/index.html

10.2.1 System testing

Acquirers of UM operators must test their host systems to ensure compliance with Visa MTT
processing requirements.
This can be performed through the acquirer host system MTT certification testing process managed
by Visa’s Client Implementation and Global Client Testing teams, who will provide guidance on the
MTT implementation process and the required test scripts for certification. This certification step is
intended to mitigate the risk of launching with non-compliant transaction processing solutions that
may result in sub-optimal Authorization quality.

10.2.2 System audit

In cases where UM operators are suspected of handling the MTT framework incorrectly, Visa may
perform, or require acquirers to perform, an audit of the UM operator’s systems and processes to
ensure compliance with Visa Rules.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 73
Visa Urban Mobility 10: Testing
Implementation Guide

Req 26: Mobility & Transport Transaction Processing Non-Compliance Assessments

(Rule: See ID# 0030055)
An Acquirer may be subject to a non-compliance assessment for each Mobility & Transport
Transaction processed incorrectly by its Merchants.

10.3 Issuer responsibilities

To avoid problems with card usage in UM environments, issuers should work closely with Visa prior
to contactless issuance in order to carry out the necessary card personalization validation and UM
specific host system testing.

Req 27: Issuer Processing of Mobility & Transport Transactions

(Rule: See ID# 0002064 & 0029985)
An Issuer must be able to correctly process an Authorization request for a Mobility & Transport
Transaction, and not send a decline response based solely on:
• The value of the Application Transaction Counter (ATC) for a contactless MTT
• A missing CVV2 for an MIT resubmission to a previously declined transaction

10.3.1 System testing

Issuers must test their host systems to ensure compliance with Visa transaction processing
requirements, and ensure payments originating from a UM operator performing a KFT or MTT are
processed correctly, without unnecessary decline responses.
This can be performed through the issuer host system MTT certification testing process managed
by Visa’s Client Implementation and Global Client Testing teams, who will provide guidance on the
MTT implementation process and the required test scripts for certification. This certification step is
intended to mitigate the risk of card issuers performing incorrect transaction processing that may
result in sub-optimal Authorization approval rates.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 74
Visa Urban Mobility
Implementation Guide

11

Deployment
preparation

Successful UM implementations require careful planning. The checklists that follow in this section
provide a high-level overview of the key factors when implementing the MTT or KFT frameworks.
In addition, stakeholders should engage with Visa directly for assistance with specific questions or
clarifications.

11.1 Technical readiness checklist

Key technical readiness elements for UM operators:

• Technical requirements described in this document have been correctly implemented

• Terminals have been correctly configured as described in the [VUMTIG] document
• Terminals read all required card data from the correct tag(s)
• The required reader certifications, such as EMV Level 1 & 2, have been achieved
• Level 3 testing with acquirer has been completed successfully
• All required cryptographic keys, including the Visa Certificate Authority Public Keys required for
UM cloud-based payments, have been successfully installed on terminals
• Deny lists have been correctly configured including update procedures
• Middle office Payment Service Provider (PSP) gateway functionality is correctly set up to receive
and transmit data
• Acquirer functionality has been integrated into the overall system
• Acquirer host system certification testing (for MTT) completed with Visa to ensure acquirer
systems are capable of submitting all required transaction data fields
• Acquirer host system certification testing completed with Visa to ensure acquirer systems are
capable of receiving the PAR value and passing it on to the UM operator for customer servicing
purposes
• Messaging between the acquirer and third parties (e.g. PSPs) is correctly handled
• Back office is correctly configured to implement the required UM rules
• Back office is capable of providing customer service interface
• The overall system has been assessed and certified as PCI DSS compliant by a QSA

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 75
Visa Urban Mobility 11: Deployment preparation
Implementation Guide

• Revenue inspection devices have been correctly set up and tested

• Visa’s “Go Live” Proving test cases have been performed and evaluated
• Limited pilot testing (e.g. friends and family) is successfully completed
• Soft launch (e.g. limited use in live environment) is successfully completed

11.2 Operational readiness checklist

Key operational readiness elements:
• UM operators’ business rules have been correctly integrated into the system
• All key customer journey scenarios can be successfully handled (e.g. “happy path” journey as well
as unsuccessful or incomplete journeys)
• Issuers have reviewed their risk parameters and Issuing Identifier STIP and Chip STIP routing option
settings, to appropriately manage high volumes of low value transactions
• Issuers have reviewed their risk parameters for Limited Use Keys (LUKs) to appropriately manage
high volumes of low value transactions performed on devices
• Debt recovery processes have been tested and are managed according to the Visa requirements
(e.g. Merchant Initiated Transactions, Cardholder initiated payments)
• Understanding UM operator and issuer responsibilities for customer support
• Implementing FAQs for customer support staff
• Understanding call center requirements (scripts and handover)
• Incorporating market specific regulatory and “conditions of carriage” requirements
• Understanding testing and launch schedules
• Planning rollout of training to internal teams

11.3 Market communications readiness checklist

• Key communication elements:Ensuring communication in local media prior to launch to raise
awareness
• Press release, digital channels, and social media communication leading up to and on the day of
the launch
• Local station communication advising passengers that they can use contactless payments as a
method of fare collection
• Local environment publicity (e.g. posters and regular announcements)
• Station announcements to advise cardholders to avoid “card clash”
• Ensuring coordination with all stakeholders
• Contributing towards creating a “platform of awareness” for all customers

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 76
Visa Urban Mobility
Implementation Guide

12

Appendix

Visa Acceptance Solutions

Visa Acceptance Solutions provides an open infrastructure that connects sellers, buyers and financial
institutions with innovative solutions as the enabler of digital commerce. Designed for ease-of-
integration, growth and built to support urban mobility standards, Visa Acceptance Solutions focus on
key success factors including time-to-market, scalability, and futureproofing. Ideally positioned and
ready to partner with cities, urban mobility operators and technology partners to drive the continued
evolution in the urban mobility ecosystem.
Visa Acceptance Platform provides access to acquirers, technology, and platform providers
globally. One connection into the Visa Acceptance Platform provides reach and scalability enabling
Urban Mobility technology providers to open up new market opportunities with reduced integration
challenges.
Visa Platform Connect supports multiple payment channels and forms of payments. This creates a
strong foundation for a diverse range of multi-channel, future-proof Urban Mobility solutions, including
support for in-app solutions (digital ticketing, on board retail, etc.) A global payment gateway that
creates a secure, reliable, and scalable foundation for flexible mass transit payment solutions. Offering
solutions that are payment scheme and payment type agnostic, providing Urban Mobility operators
with maximum flexibility and choice.
• Speed-to-market: with complex acquirer integrations already in place, overall project burden can
be reduced.
• Continuity of operations: support for complex environments combining multiple ticketing and
payment types; adding new payment types alongside existing; minimize disruption for travelers.
• MTT scheme compliant: designed to support the best cardholder experience with an efficient
and transparent solution built for Urban Mobility.
• Authorization to travel: uses open-loop, globally accepted EMV card credentials as a convenient
and secure Authorization to travel.
• Reduce PCI DSS: PCI-DSS compliant data storage for transaction Authorization at end of the day;
also reduces the PCI DSS compliance burden on the transit operator and its solution partner.
• Security: Fraud screening for account-based solutions. Includes account setup screening, etc.
• Deferred Authorization: Deferred transaction Authorization enables tap to ride without delay.
• Support for online channels and more: including moto payments, unattended ticket machines
and retail sales through partners.
• Established delivery model: leveraging our experience and expertise to help UM operators
realize their vision of next generation of Urban Mobility without disruption.
• Future-proofed: our commitment to functional enhancements and mandated changes reduces
the burden on UM operators and partners.

Jan 2024 | Version 2.1 | Visa Confidential | © Visa 2024. All rights reserved 77