Vts Description Guide Participant Branded Solutions PDF

Visa Token Service
Service Description Guide for Participant-Branded

Solutions (Issuer Wallet)
Version 1.2
20 June 2016
Visa Confidential
Important Information on Confidentiality and Copyright
© 2015-2016 Visa. All Rights Reserved.
Notice: This information 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.
THIS DOCUMENT IS PROVIDED ON AN "AS IS”, “WHERE IS”, BASIS “WITH ALL FAULTS” KNOWN AND
UNKNOWN. TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW, VISA EXPLICITLY
DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, REGARDING THE INFORMATION CONTAINED
HEREIN, INCLUDING ANY IMPLIED WARRANTY OF MERCHANTABILITY, FITNESS FOR A PARTICULAR
PURPOSE, AND NON-INFRINGEMENT.
THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE

MAINTAINED IN CONFIDENCE IN ACCORDANCE WITH THE VISA RULES OR THE TERMS AND
CONDITIONS OF THE APPLICABLE SERVICES AGREEMENT BETWEEN YOU AND VISA INC., VISA
INTERNATIONAL SERVICE ASSOCIATION, AND/OR VISA EUROPE LIMITED.
Note: This document is not part of the Visa Core Rules and Visa Product and Service 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 Core Rules and Visa Product and Service Rules, the Visa Core Rules and Visa
Product and Service Rules shall govern and control.
Contents
Visa Token Service – Service Description Guide for Participant-Branded Solutions (Host Card Emulation – Issuer Wallet)
Contents
Introduction to the Visa Token Service–Service Description Guide for Participant-Branded Solutions
(Issuer Wallet) ................................................................................................................................................................ 5
Audience....................................................................................................................................................................................... 5
Scope ............................................................................................................................................................................................. 5
Related Publications................................................................................................................................................................. 6
Changes from Version 1.1...................................................................................................................................................... 8
1 Tokenization Overview ...................................................................................................................................... 10
1.1 Background on Tokenization ................................................................................................................................... 10
1.2 Payment Token Standard .......................................................................................................................................... 11
1.3 Tokenization Stakeholders ........................................................................................................................................ 11
1.3.1 Token Requestor ................................................................................................................................................... 11
1.3.2 Card Issuer ............................................................................................................................................................... 12
1.3.3 Cardholders ............................................................................................................................................................. 12
1.3.4 Merchant .................................................................................................................................................................. 12
1.3.5 Acquirer and Acquirer Processor .................................................................................................................... 12
1.3.6 Visa ............................................................................................................................................................................. 12
2 Visa Token Service Overview ........................................................................................................................... 14
2.1 Visa Token Service ........................................................................................................................................................ 14
2.2 Visa Digital Solutions SDK ......................................................................................................................................... 15
2.3 Token Requestor Mobile Application Platform ................................................................................................. 15
2.4 Token Requestor Mobile Application ................................................................................................................... 16
2.5 Visa Token Service Core Services and Capabilities .......................................................................................... 16
2.5.1 Core Services........................................................................................................................................................... 16
3 Enrolling in the Visa Token Service ................................................................................................................ 23
3.1 Token Service Enrollment Tool ................................................................................................................................ 23
3.2 Visa Risk Manager ........................................................................................................................................................ 24
3.3 Visa Card Metadata Management ......................................................................................................................... 24
3.4 Visa Digital Solutions Developer Center .............................................................................................................. 24
4 Implementation Planning ................................................................................................................................. 25
27 August 20156 Visa Confidential i

Contents
5 VDEP Participation Requirements and Terms of Use ................................................................................ 27

5.1 Use of Card Art and Other Marks ........................................................................................................................... 27
5.2 Licenses; Proprietary Rights ...................................................................................................................................... 27
5.3 Definitions ....................................................................................................................................................................... 28
5.4 Exhibits.............................................................................................................................................................................. 32
5.4.1 Exhibit A .................................................................................................................................................................... 32
ii Visa Confidential 20 June 2016

Tables
Tables
Table 1: Related Publications.......................................................................................................................................... 6
Figures
Figure 2–1: Major Program Components ....................................................................................................................... 14

Figure 2–2: Token Transaction Processing Flow .......................................................................................................... 19
20 June 2016 Visa Confidential iii

Figures
iv Visa Confidential 20 June 2016

Introduction to the Visa Token Service–Service Description Guide for Participant-Branded Solutions (Issuer Wallet)
Introduction to the Visa Token Service–Service Description

Guide for Participant-Branded Solutions (Issuer Wallet)
A key component to Visa Digital Solutions, the Visa Token Service (VTS) allows issuers to manage the
digital issuance of token payment credentials. Through this service, Visa provides the payment
ecosystem a flexible and scalable way to securely provision and manage digital token credentials.
These capabilities are available and complemented through a common set of Visa ISO and
appropriate interfaces.
The Visa Token Service – Service Description Guide for Participant-Branded Solutions (Issuer Wallet) (this
document) provides a high-level overview, features, and capabilities of Visa Token Service to provision
and manage digital credentials on issuer-developed mobile applications on Android™ mobile devices.
This document assumes the reader has read the Visa Cloud-Based Payments Program Description and
is familiar with the concepts around Visa cloud-based payments.
Audience
This document is intended for issuers and issuer processors participating in issuer developed mobile
applications participating in the Visa Digital Enablement Program (VDEP).
Scope
Visa Token Service (VTS) is intended to address the enablement of multiple digital payment use cases
over time. This document addresses issuers using the Visa Token Service with their own single issuer-
branded payment solutions for their own eligible Visa BINs (e.g. issuer-branded NFC mobile payment
application using host card emulation on Android mobile devices).
The Visa Token Service – Service Description Guide for Issuer Participation in VDEP Third-Party Solutions
is available for issuer participation in third-party wallet solutions that support NFC payments using
host-card emulation, solutions that facilitate tokenization of e-commerce transactions (including Visa
Checkout), and tokenization for merchant card-on-file transactions.
The Visa Token Service – Service Description Guide for Issuer Participation in Apple Pay is available for
issuers using the Visa Token Service with Apple Pay.
20 June 2016 Visa Confidential 5

Related Publications
Table 1 provides a list of documentation that issuers and processors can use to obtain additional
technical details, system processing requirements, and implementation information to support
Visa Token Service.
Table 1: Related Publications
Title Description Location
EMV® Payment Tokenisation Effective 1 March 2014, describes the payment Click here to obtain from
Specification Technical token system landscape, the types of entities www.emvco.com
Framework that provide key support for the use of payment
tokens, the details to implement multiple use
cases, and the benefits of adopting a unified
approach.
April 2014 VisaNet Business Article 2.15 – Changes to BASE II and Edit https://vpc.visaonline.com
Enhancements Global Package Visa Publication Center
Technical Letter and Article 3.3 – Changes to U.S. Routing Tables (published Mar 2014)
Implementation Guide, Version (Acquirers)
3.0
Article 3.6 – New SMS Raw Data Record for
Token Data Elements
Article 3.9 – Changes to the TC 33 Acquirer
Capture File (Acquirers)
Article 3.10 – Changes to TC 33—Authorization
Records and the POSA File (Acquirers)
Article 4.1 – New Visa Network Token Service
U.S. Only
Article 11.1.1 – U.S. Mandate for Support of
Payment Token Standard Fields
6 Visa Confidential 20 June 2016

October 2014 VisaNet Business Article 2.6 – Changes to the Edit Package ARDEF https://vpc.visaonline.com
Enhancements Global Table Visa Publication Center
Technical Letter and Article 3.1 – Changes to Support the Payment (published Sep 2014)
Implementation Guide, Version Token Framework Fields and Visa Token Service
3.0 for Interlink Messages
Article 3.6 – Changes to the Visa Payment Token
Framework
U.S. Only
Article 11.2.3 – New U.S. CPS/Recurring Bill
Payment Program
Article 11.3.1 – U.S. Mandate for Support of
Payment Token Fields in Interlink Messages
Article 11.3.4 – Changes to Recurring
Transactions Originated with Payment Token
Data
Article 11.4.5 – Changes to the Visa Token
Service to Support Visa On-Behalf-Of Issuer
Provisioning
April 2015 VisaNet Business New Changes to Visa Token Service Related to https://vpc.visaonline.com
Enhancements Global Host Card Emulation Visa Publication Center
Technical Letter and Global (published Mar 2015)
Implementation Guide, Version
Articles 4 and 5
3.0
Appendices
Appendix B – BASE I and VIP Token Messages
Appendix C – BASE I and VIP Token Convert for
NFC Visa payWave Messages
Appendix D – BASE I and VIP Full Chip Data for
Appendix E – BASE I and VIP Early Chip Data for
Appendix H – BASE I and V.I.P. Token
Maintenance File Error Codes
Article 3.2 – Oct 2015-653 Changes to BASE I and VIP Token Messages for Visa representative
Host Card Emulation Mobile Devices - March
2015 VBN
Article 4.1 – Oct2015-613 Changes to the Visa Token Service for Cloud- Visa representative
Based Payment Token Transactions with
Magnetic Secure Transmission (MST) – March
2015 VBN

October 2015 VisaNet Business New Changes to Visa Token Service Related to https://vpc.visaonline.com
Enhancements Global Secure Element, Host Card Emulation, E- Visa Publication Center
Technical Letter and Commerce / Card on File (published June 2015)
Implementation Guide, Version Global
2.0
Articles 3 , 4
Additional for AP Clients
Article 6.2.2 – Support of Payment Token Data
Fields for Issuers in Singapore, Hong Kong,
Macau, and Malaysia
Article 6.5.1 – Payment Token Processing for
Issuers in the Asia Pacific Region (optional)
Additional for UAE Clients:
Article 8.2.2 – Support of Payment Token Data
Fields for Issuers in UAE
Additional for U.S. Clients
Service to Support E-Com / Card-on-File
Tokenization
Service to Support Application-Based E-
Commerce Transactions From Host Card
Emulation Mobile Devices
Changes from Version 1.1
Removed Language added to the Visa Rules, effective June 1, 2016 and re-ordering Section 5 (VDEP
Participation Requirements and Terms of Use).
Moved certain terms to Visa Digital Enablement Program Issuer Participation Agreement.
Moved operational terms (Customer Support, Priority Updates, Review & Approval, Maintenance and
Operations) to Section 2 (Visa Token Service Overview)
Created a new Exhibit with supplemental terms extending coverage of terms moved to the VDEP Issuer
Participation Agreement to issuers that signed legacy agreements which were not written in accordance
with the June, 2016 VTS Rule Change.

Inclusion of the issuer in-app payment use case.

Tokenization Overview
1 Tokenization Overview
This chapter provides an overview of payment tokenization and includes:
• Background on tokenization
• Payment token standard
• Introduction to token interactions
1.1 Background on Tokenization
The payments industry is evolving to support payment technologies that provide increased protection
from counterfeit, account misuse, and other forms of fraud. While EMV® chip cards can provide
substantial protection for card-present transactions, a similar need exists to minimize unauthorized
use of cardholder account data and to reduce cross-channel fraud in emerging transaction
environments that combine mobile devices, e-commerce, and point-of-sale environments.
Tokenization holds substantial promise to address these needs.
Payment tokens are surrogate values that replace Primary Account Numbers (PANs) stored
electronically throughout the payments ecosystem and can be used to securely conduct payment
transactions. In order for payment tokens to provide improved protection against misuse, the token is
limited to use in a specific domain, such as device or channel. These underlying usage controls are a
key benefit of payment tokens.
There are benefits for all stakeholders in the payments ecosystem that may help encourage adoption
of payment tokens:
• Card issuers and cardholders may benefit from new and more secure ways to pay, improved
transaction approval levels, and reduced risk of subsequent fraud in the event of a data breach in
which payment tokens are exposed instead of the underlying PANs.
• Acquirers and merchants may experience a reduced threat of online attacks and data breaches, as
payment token databases may be less appealing targets given their limitation to a specific domain.
Acquirers and merchants may also benefit from the higher assurance levels that payment tokens
offer.
• Payment processing networks have adopted a common specification that facilitates
interoperability and simplifies token processing for issuers, processors, and acquirers.

1.2 Payment Token Standard
In October 2013, Visa, MasterCard, and American Express announced the creation of a framework for a
new global standard to enhance the security of digital payments and simplify the purchasing
experience when shopping on a mobile phone, tablet, personal computer, or other smart device. This
framework allows issuers, merchants, and digital wallet providers to request a payment token so that
when an accountholder initiates an online or mobile transaction, the payment token, not the
traditional card account number, is used to authorize, clear, and settle the transaction in the same way
traditional card payments are processed today.
In January 2014, EMVCo (which is collectively owned by American Express, Discover, JCB, MasterCard,
UnionPay, and Visa) announced that it would expand its scope to lead the payments industry in its
work to standardize tokenization. The new specification helps provide the payments community with a
consistent, secure, and globally interoperable environment. This may encourage industry efficiencies
and security enhancements for digital commerce.
The EMV® Payment Tokenisation Specification Technical Framework, Version 1.0, published in March
2014, describes the payment token system landscape, the types of entities that provide key support
for the use of payment tokens, the details to implement multiple use cases, and the benefits of
adopting a unified approach. Effective with the April 2014 VisaNet Business Enhancements Global
Technical Letter and Implementation Guide, Visa implemented network- and processing-level changes
for new and existing fields to align with the EMV® Payment Tokenisation Specification Technical
Framework, Version 1.0. These changes support acquirer, merchant, and issuer token implementations
to provide enhanced data security for the cardholder PAN in payment transactions.
1.3 Tokenization Stakeholders
Tokenization requires participation of the existing stakeholders in the payment card ecosystem. A new
stakeholder, “token requestor,” is introduced and is described in the following sections, along with the
other tokenization stakeholders.
1.3.1 Token Requestor
Token requestors can be traditional participants within the payments industry or new participants
bringing innovation to the payment ecosystem. Examples of token requestors include third-party
wallet providers, issuers offering their own mobile payment applications to their own cardholders,
card-on-file merchants, and Visa Checkout. The token requestor is an entity that has a direct consumer
relationship or manages one on behalf of a merchant. In order to request tokens from Visa Token
Service, token requestors are required to register and comply with certain participation requirements

1.3.2 Card Issuer
Issuers maintain their current role in owning the accountholder relationship, as well as having
authorization and ongoing risk management responsibilities. Issuers decide which payment solutions
they would like to participate in, and control token provisioning decisions. In order to use the
Visa Token Service, issuers must the implement tokenization-related processing changes outlined in
the VisaNet Business Enhancements Global Technical Letters and Implementation Guides. .
The issuer processor facilitates issuer participation in VDEP by supporting integration through VisaNet
of the processing changes related to tokenization.
Note: In the case of tokens issued for issuer mobile applications on Android mobile devices, issuers
are also playing the role of the token requestor. In addition to the traditional activities around
credential issuance and transaction processing, issuers supporting their own payment
programs can also be involved in developing mobile payment applications or adding payment
capabilities to existing mobile banking applications, requiring them to connect to Visa Token
Service as a token requestor in addition to integrating as a card issuer.
1.3.3 Cardholders
Tokenization is largely transparent to the end consumer. In most cases, the consumer is unaware that
a token is being used to conduct a transaction. If a token requestor chooses to educate the consumer
regarding tokenization, Visa recommends referring to the token as a “digital account number.”
1.3.4 Merchant
Tokens transact and process identically to traditional PANs, so there are typically no required changes
to the underlying payment infrastructure supported by merchants. Existing and future Visa payWave
terminals are able to support mobile transactions conducted with payment tokens. With respect to
tokens used for e-commerce and card-on-file transactions, merchants may need to implement
additional changes. Merchants can also be token requestors depending on the use case.
1.3.5 Acquirer and Acquirer Processor
Acquirers process token transactions in the same manner as they process card account numbers
today. This includes authorization, clearing, settlement, and exception processing. Acquirers may need
to support additional data included in tokenized transactions.
1.3.6 Visa
Visa is a token service provider. In this role, Visa provides all the functionalities as further described in
this document as well as EMV® Payment Tokenisation Specification Technical Framework.


Visa Token Service Overview
2 Visa Token Service Overview

Visa Token Service is developed and offered based on EMV® Payment Tokenisation Specification
Technical Framework, Version 1.0. It is designed to support a number of payment use cases including:
• NFC mobile contactless payments (Visa payWave) using host card emulation or hardware-based
secure elements
• In-app e-commerce payments
• Merchant card-on-file payments
• Browser-based e-commerce payments initiated by digital wallets
For issuer-developed mobile applications for their own eligible Visa BINs (based on product type)
participating in the Visa Digital Enablement Program (VDEP), Visa Token Service supports an issuer’s
ability to provision and manage tokens to support Visa cloud-based payments programs for Android
mobile devices so that merchants can accept Visa mobile payments in-app or in-store using existing
Visa payWave contactless infrastructure.
Figure 2–1: Major Program Components
2.1 Visa Token Service
The Visa Token Service ensures that proper domain restrictions are applied during provisioning and
risk parameters are managed based on the specific token use case initiated by the token requestor.
Furthermore, Visa Token Service is fully integrated into the processing capabilities of VisaNet. When a
transaction is initiated using a Visa-issued token, VisaNet identifies the transaction and routes it to
Visa Token Service for de-tokenization and validation of domain restrictions. De-tokenization provides
the link between the token and the PAN. Tokenized transactions not only have increased security due

to domain restrictions, but also benefit from additional risk and security features applied to all
transactions routed through VisaNet.
The network-based entity labeled “Visa Token Service” in Figure 2–1 is the service that handles all the
interactions between the Visa Token Vault and a Visa token requestor.
Components labeled “Visa Digital Solutions SDK”, “Token Requestor Mobile Application Platform”, and
“Token Requestor Mobile Application” apply to issuers that want to support issuer-branded wallets.
2.2 Visa Digital Solutions SDK
Issuers are required to either use the Visa Digital Solutions SDK or an approved Visa technology
partner (third-party) SDK for issuer-branded NFC and HCE-based mobile payment applications.
Note: The technology partner's SDK and the issuer’s mobile payment application must comply with
Visa’s cloud-based payment specifications.
The Visa Digital Solutions SDK resides in the mobile application on the mobile device and provides the
following features:
• Visa payWave logic
• Visa Digital Solutions APIs
• Secure Storage
• Reference User Interface
2.3 Token Requestor Mobile Application Platform
The mobile application platform is the server that the token requestor uses to communicate to the
mobile application on an Android device. Typically, the mobile application platform provides functions
such as:
• Authenticate the accountholder (ID&V) (e.g., online banking credentials)
• Send card art
• Send the mobile application alerts or notifications for the server
• Interface with the Visa Digital Solutions APIs
For issuer-branded mobile payment applications, the issuer uses the mobile application platform to
authenticate the consumer for the issuer’s payment application. The mobile application platform also
sends the corresponding card art to the mobile application for each account provisioned.
The mobile application platform generates all of the messages to communicate with Visa Token
Service. The issuer must develop its mobile application platform to interface with the Visa Digital
Solutions APIs in this integration path.

2.4 Token Requestor Mobile Application
The mobile application provides the user interface experience for the consumer on Android and other
eligible devices. For issuer-branded mobile payment applications, the consumer uses the issuer's
mobile application to enroll accounts into the service, initiate payments, and manage those accounts
over their lifecycle.
In addition to the user experience, the issuer’s mobile application also provides logic to facilitate
communications between the issuer’s mobile application platform and the Visa Digital Solutions SDK.
Interactions between the issuer’s mobile application and the issuer’s mobile application platform are
proprietary to the issuer’s implementation
The mobile application communicates with Visa Digital Solutions SDK to utilize the SDK functions.
Issuers may also choose to implement the mobile payment application completely in-house or by
outsourcing the development to a third-party.
The technology partner's SDK and the issuer’s mobile payment application must comply with Visa’s
cloud-based payment specifications.
2.5 Visa Token Service Core Services and Capabilities
Visa Token Service capabilities are described in Section 2.5.1, Core Services. Unless otherwise explicitly
noted below, participating issuers are required to utilize and support each of the Core Services in
order to comply with the terms of the Visa Digital Enablement Program (VDEP).
Note: VDEP participation requirements and Terms of Use are further described in Chapter 5, VDEP
Participation Requirements and Terms of Use.
2.5.1 Core Services
1. Token Generation and Provisioning
Upon request from an authorized token requestor, the Visa Token Service generates a token for
any issuer’s designated Visa accounts that are eligible for tokenization with the token requestor.
Once the token is generated, it is mapped to the primary account number (PAN) and stored in the
Visa Token Vault along with metadata such as token type and the relevant domain restrictions. The
Visa Token Vault is the “token vault of record” with respect to the token-to-PAN mapping. The
token’s activation status is based on whether successful completion of the Identification and
Verification process has occurred. In some cases, the token may be inactive until further validation
by the consumer.

Note: EMVCo designates a unique value for each Token Service Provider (TSP). Visa’s TSP ID is
400 and is included in all Visa token requestor identifiers.
2. Identity & Verification (ID&V), including step-up authentication and Visa Risk Manager
(VRM)
Issuers need to determine the approach for verifying the identity of the cardholder before a token
is provisioned. For issuer-developed issuer-branded mobile applications, the issuer has the choice
to perform traditional ID&V validation or may choose to assert ID&V. VRM is utilized to support
configuration of the parameters for an issuer wallet. Visa Token Service provisions tokens upon
direct request from an authenticated issuer’s mobile application.
3. Card Metadata Management
Card metadata includes the issuer’s card art, cardholder terms and conditions, and other metadata,
such as contact and additional verification information presented to the cardholder through the
user interface of the token requestor’s wallet solution. Because the issuer is also playing the role of
the token requestor, the issuer’s mobile application platform may send the corresponding card art
to the issuer-branded mobile application for each account provisioned or the issuer can rely on
the VCMM tool to support delivery of this information.
4. Token Lifecycle Management (LCM)
The Token Lifecycle Management tool manages the token within the Visa Token Vault and within
the token requestor’s solution (e.g., within the mobile application on the consumer’s device in the
case of a mobile wallet). After Visa Token Service has provisioned a token, the token requestor and
the issuer are required to support token lifecycle management through the Visa Token Service.
Changes in either the account (PAN) or the token require a lifecycle management event.
Lifecycle management events for tokens include:

• Activate: Because some token types may be pre-provisioned before cardholder verification
(ID&V) successfully completes, this capability allows issuers to notify Visa to activate the token
after the cardholder has been validated. A token must be active before any purchase
transaction can occur.
• Delete: The issuer may initiate ‘DELETE’ on behalf of the consumer (e.g., lost device) or for
internal risk and customer protection reasons (e.g., account compromised). This action
terminates the token-to-PAN mapping in the Visa Token Vault. The accountholder may initiate
‘DELETE’ of token directly through the user interface of the token requestor’s solution. The
token requestor initiates ‘DELETE’ on the accountholder’s behalf. The issuer may receive
notification that the token has been deleted.
• Suspend: The issuer may initiate ‘SUSPEND’ of token to temporarily deactivate the token (e.g.,
consumer traveling, suspicious activity). This action does not permanently delete the token
from the Visa Token Vault or the token requestor’s solution. The mobile application may also
initiate ‘SUSPEND’ based on internal service interaction.

• Resume: The issuer may initiate ‘RESUME’ of token (following a ‘SUSPEND’ event) so existing
account parameters are enabled for payment and replenishment.
• Update PAN Expiration: When the expiry date of a tokenized PAN changes, the issuer is
required to provide Visa with the new expiry date. Visa updates the expiry date in the Visa
Token Vault to extend the use of the token/PAN combination.
• Update PAN: When the underlying PAN associated with an active token (or tokens) is changed
by the issuer, the issuer must notify Visa with the new PAN information. Visa then updates the
token-to-PAN mapping in the Visa Token Vault. This allows the new PAN to be mapped to the
existing token(s), which eliminates the need for the accountholder to delete and re-provision
the active tokens.
Lifecycle management queries:

• Token Inquiry: The issuer requests a list of all tokens for a particular PAN or PAN Reference
ID.
• Token Inquiry Detail: The issuer requests token details for a specific token.
Issuers must use Visa’s Lifecycle Management (LCM) tool, ISO messages sent through the issuer’s
existing connection to VisaNet, or other interfaces that Visa may support. Issuers must support at
least one of these methods, and must complete a lifecycle event to notify Visa when a change has
occurred to the underlying PAN information.
The issuer should promptly inform Visa at the time the issuer receives notification from a
cardholder or when the issuer makes a decision to change or reissue the cardholder PAN. This
includes status changes (e.g., closed, reissued, or suspended). All updates to the Visa Token Vault
are immediate upon receipt.
It is the issuer’s responsibility to manage the lifecycle of the PAN and to maintain accurate and up
to date information in the token vault. Token transactions should NOT be declined for account
closed, expired PAN, or invalid account response codes.
5. Token Transaction Processing
VisaNet must be used to process any transaction (including authorization, clearing and settlement,
and exception processing) initiated by a token provisioned through the Visa Token Service.
During transaction processing, the Visa Token Service:

• Validates token cryptograms
• Applies token domain restrictions
• Performs token velocity checks
• Validates the Token Authentication Verification Value (TAVV) for certain token types, such as in
app e-commerce transactions and merchant card-on-file transactions

All tokenized Visa transactions must be routed to VisaNet for de-tokenization and transaction
processing. Mobile contactless (NFC)-initiated transactions from U.S. debit programs may be
exempt from this requirement if routed by U.S. merchants using the Common Debit AID licensed
to an unaffiliated debit network.
As soon as the issuance of a token occurs, the issuer must manage the underlying PAN. Ideally this
occurs at the time of the customer notification or at the action of the issuer. Token transactions
are ineligible for referral responses, or any account status condition such as account closed or
suspended, expired card, or invalid account. VisaNet does process token transactions that contain
the above reference response codes in stand-in processing (STIP). VisaNet does not accept a
referral response and if provided, the response is converted to a decline. It is the issuer’s
responsibility to manage the lifecycle of the PAN and to maintain accurate and up to date
information in the token vault. Token transactions should NOT be declined for account closed,
expired PAN, or invalid account response codes.
An example Visa payWave transaction using a token provisioned to an NFC-enabled mobile phone
through the Visa Token Service is shown in Figure 2–2.
Figure 2–2: Token Transaction Processing Flow
1. Consumer initiates a purchase at an NFC-enabled terminal at merchant location.
2. Merchant submits a token in place of the PAN to its acquirer.
3. Acquirer passes the token (processed identically to the PAN) to VisaNet.
4. VisaNet detects the token, exchanges it with the PAN via Visa Token Service, and performs LUK
velocity checks.
5. VisaNet passes the PAN and token to the issuer for an authorization decision.

6. Issuer or its processor authorizes or declines the transaction and returns a response to VisaNet.
VisaNet exchanges the PAN back to a token and sends a response to the acquirer and on to
the merchant.
6. Active Key Management (AKM)
Issuers are required to configure active key management parameters during enrollment in the Visa
Token Service with respect to tokens using Visa’s cloud-based payment specifications (i.e., NFC
host-card emulation). The Visa Token Service manages Limited Use Key (LUK) replenishment for
any Visa cloud-based (i.e., NFC host card emulation) use cases. LUKs are used to generate
cryptograms for Visa payWave mobile contactless transactions.
During the provisioning process, the active key management capability in VTS generates the initial
LUK that is provisioned to the token requestor’s payment solution on the consumer’s mobile
device. The LUK is provisioned together with token information generated during provisioning and
is derived using dynamic information used for velocity checking during token transaction
processing.
During token transaction processing, if the service profile parameters configured by the issuer in
VTS for a particular account indicate that the LUK on the device requires replacement, VTS initiates
contact with the token requestor’s solution to replenish the LUK. Alternatively, if the on-device
service profile parameters indicate that LUK replenishment is (or will soon be) needed (threshold
management from the token requestor’s mobile application), then the mobile application sends a
request for account parameter replenishment to VTS.
Visa allows the issuer to establish the risk parameters that govern the expiration and
replenishment of the LUKs. These parameters include velocity controls for the use of the LUKs. The
velocity controls include:
• Number of transactions that can be executed with an LUK
• Time-to-live for a specific LUK
• Total cumulative amount that can be purchased with transactions initiated from an LUK
7. Transaction Alerts and History
For payments in issuer-branded mobile applications, Visa Token Service may support transaction
history capability. The issuer may provide this capability if desired to its cardholders.
8. Notifications
The Visa Token Service delivers a notification to the issuer (or the issuer’s processor) each time a
token provisioning request is received, and upon token provisioning, token activation, and certain
lifecycle management events. Issuers are required to notify their cardholders when a token has
been provisioned.

9. Testing and Certification
Visa provides certain testing and certification assistance to issuers as part of the issuer onboarding
process for the Visa Token Service. Issuers are required to successfully complete testing and
certification to participate in the Visa Token Service, and additional testing and certification may
be required for existing VTS issuers prior to live participation in new token requestor solutions and
new token use cases.
10. Customer Support.
Cardholder inquiries relating to the Program will be handled in accordance with Visa’s Program
and Services Documentation as updated from time to time. In general, any inquiries concerning a
Cardholder’s Payment Account (including charges) will be handled by Participating Issuer. Token
Requestors will handle inquiries to the extent related specifically to use of a Solution, but not
inquiries concerning a Cardholder’s Payment Account or any charges related to the Payment
Account. Participating Issuer, Visa and Participating Token Requestors will work and cooperate
reasonably to define and implement customer support methods associated with Solutions,
including back office coordination, data exchange (if any), and customer-facing communications,
among other methods.
11. Priority Updates.
Participating Issuer must prioritize the immediate implementation of Core Services or Core Service
feature or functionality enhancements designated as “Priority Updates” (the “Priority Updates”).
Priority Updates are deemed by Visa to impact security, integrity of the Visa brand, or compliance
with applicable Laws and must be deployed by Participating Issuer when released by Visa or on an
accelerated schedule agreed by the Parties when discretion is possible.
12. Review and Approval.
Participating Issuers will propose their issuer developed mobile application solutions to Visa for
review and approval pursuant to the applicable solution approval process and, if such solutions are
approved, then participating Issuers will maintain and operate the payment solutions only in the
approved jurisdiction(s) and in accordance with this document, any related documentation made
available by Visa, and any conditions and communications accompanying such approval.
13. Maintenance and Operation.
Participating Issuers will maintain and operate the Issuer wallet payment solutions in a high quality
and professional manner and at a service level that supports and enhances Visa’s goodwill and the
Visa payment experience and that is consistent with Visa, but at a minimum payment industry,
standards. If any such payment solution suffers impaired performance (speed or integrity of
payment process), security issues, or any other issue that in Visa’s reasonable business judgment
inhibits the Visa payment experience or negatively impacts Visa’s goodwill in its brand, Visa
reserves the right to require correction. Issues not remedied may lead to re-certification being
required, and/or termination thereof.


Enrolling in the Visa Token Service
3 Enrolling in the Visa Token Service

Issuer enrollment in the Visa Token Service consists of several steps that must be completed by the
issuer (or the issuer’s designated processor acting on the issuer’s behalf). Visa provides three primary
tools which issuers and processors use to initiate the enrollment process:
• Token Service Enrollment Tool
• Visa Risk Manager
• Visa Card Metadata Management
Issuers for their own branded wallets are also playing the role of a token requestor and must perform
additional enrollment steps to integrate with Visa Token Service. Issuers acting as token requestors
have the option to deploy this capability either as a standalone issuer-branded application or within
their existing mobile banking application. Visa provides additional tools via the Visa Digital Solutions
Developer Center to issuers to integrate as a token requestor.
3.1 Token Service Enrollment Tool
Visa provides issuers and issuer processors with a web-based portal called the Token Service
Enrollment Tool or TSE Tool, which is available on Visa Online. The following information is required to
be entered into the TSE Tool:
• The issuer selects the particular token requestor solution(s) in which it desires to participate. Wallet
solutions that support NFC (Visa payWave) transactions through device-bound tokens require
explicit opt-in by the participating issuer. Issuers are automatically enrolled in other use-cases,
including Visa Checkout tokenization, third-party solutions that facilitate e-commerce transactions,
and tokenization for merchant card-on-file transactions. Certain token requestors may establish
supplemental terms of participation that are not addressed in the standard terms of the issuer’s
VDEP agreement. For such solutions, Visa provides a link to the additional terms through the TSE
Tool.
• Product Eligibility: For each token requestor solution in which the issuer decides to participate, the
issuer enters the Visa account BINs that the issuer wants to make eligible for participation in that
particular solution. Visa then assigns token BIN ranges that are used to generate tokens for each
eligible PAN BIN range.
• Designation of Master Keys: The issuer designates whether it wants to use existing master keys
already on file with Visa or request Visa to generate and provide a new master key to be used for
token transaction processing.
• Selection of processing options, including active account management parameters for tokens used
in solutions based on NFC host-card emulation technology.

Enrolling in the Visa Token Service
• Issuers can select the option to receive notifications for token provisioning, lifecycle management,
and active key management events.
• Issuers can also request access to other enrollment tools (i.e., VRM, TLCM, and VCMM).
3.2 Visa Risk Manager
Visa Risk Manager (VRM) is a web-based portal available on Visa Online. Issuers and processors use
VRM to configure risk decisioning rules that Visa will apply on the issuer’s behalf to incoming token
provisioning requests from token requestors. Issuers may configure a rule to block token provisioning
to specific third-party solution providers and specific card-on-file merchants by entering the token
requestor ID of each such requestor.
3.3 Visa Card Metadata Management
The Visa Card Metadata Management (VCMM) online tool is accessible via the Visa Online (VOL)
portal. Issuers and processors use the VCMM tool to help manage card art configuration, terms and
conditions, and other metadata at account range-level for tokenized BINs. These consumer terms and
conditions are displayed to cardholders who are attempting to load their card accounts into a
particular token requestor solution.
3.4 Visa Digital Solutions Developer Center
Visa Digital Solutions Developer/Production Center (Sandbox / Production) is available for token
requestors to test and deploy the platform components they develop, mainly the mobile application
and mobile application platform. With access to the sandbox the token requestor is able to:
• Generate the Visa Digital Solutions API key and shared secret.
• Add additional issuer developer accounts.
• Create mobile application profiles.
• Access the Visa Digital Solutions SDK and development documentation.

Implementation Planning
4 Implementation Planning
Visa provides either a standard or customized implementation for issuers to participate in Visa Token
Service.
The standard implementation option requires the shortest implementation time and the fewest
number of changes to the issuers processing system. It is designed to enable an issuer to quickly
participate in the VTS. The standard option leverages the issuer’s existing connection to VisaNet, uses
standard ISO-based message formats, and uses risk-based decisioning and account management
tools to meet the VDEP requirements.
The customized implementation option requires extensive implementation time and a greater number
of changes to an issuer’s processing system. The customized option is designed to provide issuers
with flexibility in supporting their unique processing needs necessary for complex programs. This
option uses new transaction types and processing methods to communicate with issuers during the
provisioning and lifecycle management of a token in support of the VDEP requirements.
Please contact your Visa representative to obtain the appropriate documentation for additional
information related to implementation and integration and the details of each option.

Implementation Planning

VDEP Participation Requirements and Terms of Use
5 VDEP Participation Requirements and Terms of Use

This chapter provides the requirements and terms of use for the issuers that participate in Visa Digital
Enablement Program VDEP. Capitalized terms shall have the meanings as set forth in Section 5.3
Definitions.
5.1 Use of Card Art and Other Marks
a. Use by Visa. For the sole purpose of permitting Visa to provide the Program and Services to
Participating Issuer and Token Requestors and to market, advertise and promote the Program,
Solutions available under the Program, and Participating Issuer’s involvement in the Program
and such Solutions, Participating Issuer hereby grants to Visa a non-exclusive right and license
to use Participating Issuer’s name, Card art, trademarks, service names, logos and the like, that
Participating Issuer may provide to Visa (“Participating Issuer IP”). Visa agrees that: (a) nothing
herein shall give Visa any right, title or interest in the Participating Issuer IP (except the right to
use the Participating Issuer IP in accordance with the terms of these Terms of Use), (b) that the
Participating Issuer IP are the sole property of Participating Issuer or its licensors, (c) that any
and all uses by Visa of the Participating Issuer IP shall inure to the benefit of Participating Issuer.
Upon termination or expiration of these Terms of Use and termination of all use of the Program
and Services (e.g., including any wind down period) by and on behalf of Participating Issuer,
Visa’s right to use the Participating Issuer IP under this paragraph shall terminate.
b. Use of Visa Marks by Participating Issuer. Participating Issuer’s right to use Visa trademarks shall
remain unchanged by these Terms of Use and remains subject to the Visa Rules, Visa Product
Brand Standards, and any other agreements between Visa and Participating Issuer concerning
use of Visa trademarks.
5.2 Licenses; Proprietary Rights
a. Proprietary Notices. Participating Issuer shall not remove, alter, or obscure any proprietary
copyright, trademark, patent or other proprietary notices contained on or within the Program
Software, Program and Service Documentation, or other Program or Service materials or
descriptions, and Participating Issuer shall reproduce such notices on all copies (including in
derivatives).
b. Joint Development. No joint development is contemplated under this Program. If the Parties
desire to engage in joint development or other activities that may result in joint inventorship or
authorship, the Parties intend to first enter into a separate agreement addressing scope, fees (if
any), allocation of Intellectual Property Rights and any other terms and conditions that apply to
such activities. If notwithstanding the foregoing intent, however, a “joint work of authorship” (as

defined under the U.S. Copyright Act) or a “joint invention” (as defined under the U.S. Patent
Act) arises in any jurisdiction in the absence of such a separate agreement, the copyright to such
joint work or Patent rights to such joint invention (“Joint IPR”) will be jointly owned by the
Parties and each joint owner will have the right to use and otherwise exploit such Joint IPR
worldwide without any duty to account to the other Party and without any obligation to obtain
consent of the other Party to grant nonexclusive licenses under such Joint IPR or to assign its
joint ownership interest in such Joint IPR; provided, however, that such rights as a joint owner
shall not be construed as granting or conveying any right or licenses under any other Intellectual
Property Rights of the other Party even if necessary to use or otherwise exploit such Joint IPR.
5.3 Definitions
“Affiliate” means as to any entity, any other entity that, directly or indirectly, Controls, is Controlled by
or is under common Control with such entity.
“Card” means: (i) a physical card that carries a Visa owned brand or (ii) a Payment Account for which
no physical card is issued that is established primarily for completing transactions between merchants
and a cardholder over the internet or other networks to enable one or more individuals or entities to
obtain goods, services or cash from a Visa Client that qualifies as a merchant or acquirer under the
Visa Rules.
“Cardholder” means an individual who is issued, and authorized by an Issuer to use, a Card to make
payments.
“Cardholder Information” means: (a) any payment product account number, including without
limitation Card numbers, Tokens, or other information that identifies Payment Accounts of
Cardholders; (b) any transaction information concerning a Payment Account or concerning payments
made through a Payment Account; or (c) any Visa or third-party information related to (a) or (b) that
may constitute non-public personal information or from which an individual cardholder’s identity or
personal particulars are apparent or can be reasonably ascertained.
“Client” or “Visa Client” means any Issuer, acquirer, or other client of Visa or a Visa Affiliate that offers
a card-based or non-card-based payment product or service to consumers or other entities, or offers
a payment capability to merchants, in each case that utilizes a Visa Mark or Visa payment system,
product, or service.
“Confidential Information” of a Party means all confidential or proprietary information of that Party or
its Affiliate not generally known to the public. Visa’s Confidential Information includes, without
limitation, all Cardholder Information, the Program Software, and the terms and conditions of these
Terms of Use. Visa Confidential Information also includes any information that is provided or made
available by or on behalf of Visa, any Visa Affiliate or Visa Europe or any Visa Client to Participating
Issuer, its Affiliate, or any of their respective Personnel in connection with these Terms of Use, unless
the information is or becomes generally known to the public through no action or inaction of
Participating Issuer or its Affiliates..

“Control” means, with respect to any entity, the power to direct or cause the direction of the
management and policies of such entity through direct or indirect ownership of more than fifty
percent (50%) of the voting securities entitled to elect the board of such entity (or equivalent
ownership interest), but only for so long as such control exists.
“Eligible Card” means, with respect to a Solution, the Visa credit Cards, Visa debit Cards and other Visa
branded Cards that (i) Visa has indicated in Visa’s written approval of that Solution (or in another
writing signed by an executive of Visa at the senior vice president level or higher) are eligible to be
provisioned on or for the Solution or (ii) have otherwise been provisioned by or on behalf of Visa for
use with the approved Solution.
“Intellectual Property Rights” means any and all of the following, arising in any jurisdiction in the
world: (a) Patents; (b) copyrights; (c) trademarks, service marks, trade names and trade dress; (d) trade
secrets; (e) design rights; (f) data rights; (g) mask work rights; (h) moral rights; (i) foreign equivalents of
any of the foregoing; (j) any other intellectual property rights; (k) registrations of, and applications for,
any of the foregoing; and (l) the right to sue for any present or past violation, infringement or
misappropriation of any of the foregoing.
“Issuer” means a Visa Client that Visa has determined qualifies as a “Visa issuer” under the Visa Rules
and that has entered into a written agreement with a Cardholder for issuance of one or more Card
products.
“Laws” means (a) any national, state, local or other law or statute in any jurisdiction in which the
Program is offered, including any jurisdiction in which funds are received; (b) any international or
transnational treaty, law, or statute, (c) any rule or regulation issued by a regulatory body; (d) any
written or authoritative interpretation by a regulatory body of any such law, statute, rule or regulation;
and (e) any enforceable regulatory guidance, any judicial, governmental, or administrative order,
judgment, decree or ruling or written and enforceable requirements of banking industry self-
regulatory bodies and organizations.
“Network Data” shall mean: (a) all information related to the identification, qualification status, and
card-type portfolio of Visa Issuers; (b) the usage, performance, and detailed transaction level
information of transactions processed through Visa’s payment systems; and (c) any and all information
provided or created in connection with processing Provider’s transactions through Visa’s payment
systems.
“Participating Issuer IP” has the meaning set forth in Section 5.1.a.
“Patents” means patents and patent applications, including any continuations, continuations-in-part,
divisionals, counterparts, re-examinations, renewals and reissuances thereof.
“Payment Account” means an account that can be used to make payments and that is issued by an
Issuer to one or more individuals or entities using the Visa Brand, all as set forth in a written
agreement between the Issuer and such individuals or entities).

“Payment Network” means any one or more of Visa, MasterCard, Discover, American Express, Japan
Credit Bureau, China Union Pay, or any other network, service, function, or party providing Payment
Network Functionality.
“Payment Network Functionality” means enabling financial transactions by providing transmission,

authorization, clearing or settlement functionality among a source of funds and multiple unaffiliated
merchants and displaying branding, a logo, or the like to communicate availability of such
functionality.
“Personnel” means a Party’s employees, agents, consultants, contractors and subcontractors, together
with the personnel of any of the foregoing.
“Program” means Visa’s program through which Visa Clients may obtain the Service and participate in
Token Requestor Solutions, all as more fully described in the Service Guides.
“Program and Services Documentation” means (i) these Terms of Use including all Exhibits and
attachments hereto; (ii) the Service description provided by Visa and applicable Service Guide; (iii)
information submitted to Visa by Participating Issuer or its designated third party processor through
the “Token Service Enrollment Tool” to activate the Services on Participating Issuer’s selected or
allocated BINs or account ranges; (iv) all applicable portions of the Visa Rules; (vi) associated
documentation, publications, communications, approvals made available or issued by or on behalf of
Visa or its Affiliate; and (vii) all updates to any of the foregoing.
“Program Software” means any software, application programming interface, or developer kit for the
Program generally made available by Visa to Issuers and Program participants, the Service Guide, and
any associated documentation, application programming interface specifications, sample code and
other materials made available by Visa for purposes of enabling Issuers and Program participants to
access the Program.
“Provisioning” means the process of identifying, validating, associating and binding an alternate form
factor (including, without limitation, a secure element, hardware, operating system or software) of a
Solution to a Token, as may be described in the Program and Service Documentation.
“Service” or “Visa Token Service” means the services made available by Visa or Visa Affiliates under the
Program for purposes of enabling tokenization of Payment Account credentials, use of tokenized
Payment Account credentials to make payments, and Token life-cycle management as such services
are provided and updated by Visa and Visa Affiliates from time to time.
“Service Guides,” means this document and any other instruction guide, other service description
guides and associated documentation for Issuers and participants in the Program with respect to the
use and implementation of the Service and Program, as such guides may be made available and
updated by Visa from time to time.
“Solution” means any payment solutions contracted and approved by Visa for the Program.

“Solution Approved Jurisdictions” means the jurisdictions, countries or markets for which a Solution is
approved by Visa for the Program.
“Technology” means any and all technology and technical information, including without limitation
software; code; servers; systems; data centers; backup technology; Internet, cloud and communications
infrastructure and services; other services; security; storage; inventions (whether or not patented or
patentable); designs; concepts; processes; techniques; know-how; specifications; works of authorship;
and any other technical subject matter.
“Term” means the term of participation in the Program by the Participating Issuer.
“Token” means a surrogate account number that (i) is mapped to a Visa primary account number
(“PAN”) and (ii) is in a form required in the Program and Services Documentation. A Token is used to
enable an alternate form factor (e.g., a mobile device) to make payments using the underlying Visa
payment product (e.g., a credit card) and is not a secondary product.
“Token Requestor” means any party to the extent that (i) the party has entered into a contract with
Visa that authorizes the party to request the creation and provisioning of a Token on behalf of an
Issuer under the Program; and (ii) the party and its Solution have successfully passed all testing and
other requirements necessary for the party and Solution to participate in the Program. A Token
Requestor, by way of example and not limitation, may be an Issuer, acquirer, merchant or digital wallet
issuer.
“Token Requestor Data” means any data Token Requestor provides in connection with the Program or
Solution as may be described in Program and Services Documentation.
“Token Requestor Solutions” means payment solutions provided by Token Requestors, which may
include but are not limited to, third party solutions, issuer wallet solutions, Visa-provided solutions
and others.
“Token Service Enrollment Tool” means the enrollment and configuration tool that Visa requires
Participating Issuer to use to submit information to Visa in order to enroll and configure designated
Participating Issuer BINs under the Program.
“Transaction Alert” means notification that a payment transaction has occurred using an Eligible Card
that has been provisioned on a Solution, as described in the applicable Program and Services
Documentation.
“Transaction History” means, with respect to an Eligible Card, data describing the history of one or
more payment transactions made over time using the Eligible Card provisioned on a Solution, as
described in the applicable Program and Services Documentation.
“Visa Affiliate” means any Affiliate of Visa, including without limitation, Visa U.S.A. Inc., Visa Canada
Corporation, Visa International Service Association, Inovant LLC, Visa Worldwide Pte. Limited,
CyberSource Corporation, Visa Inc. or a respective subsidiary or Affiliate of any of the foregoing less
the Visa entity first set forth above.

“Visa Europe” has the meaning set forth in the Visa Rules. Visa Europe is not a Visa Affiliate but it has
the legal rights to use the Visa Marks and certain Visa-owned technology and products for financial
services and participation in the Visa system.
“Visa Europe Territory” has the meaning set forth in the Visa Rules.
“Visa Marks” means the trademarks, service marks, logos or other indicia of origin identified the Visa
Rules, Visa Product Brand Standards and any other agreements between a participant and Visa.
“Visa Rules” or “Rules” means (i) the Visa International and Visa U.S.A. By-Laws; (ii) the Visa Core Rules
and Visa Product and Service Rules; and (iii) other documents governing the participation of Visa
Clients and other parties in the Visa payment system, as all such documents are revised by Visa from
time to time.
“Visa Token System” means the Program, Program Software, Tokens and Services.
“Wind-Down Period” shall have the meaning set forth in Section 5.4.1e.ii.
5.4 Exhibits
5.4.1 Exhibit A
Supplemental terms governing Issuer Participation Agreements that were written prior to Version 3.0,
which shall be deemed to be included in the Program and Services Documentation, are as follows:
a. Key Principles. These Terms of Use and the Program establish certain data use rights as set forth
in further detail below. Notwithstanding anything to the contrary and without limiting the
foregoing, Visa may use the data of Participating Issuer hereunder provided that the data are
aggregated so as not to disclose the data of any single Participating Issuer.
b. No Implied Licenses. Except for the rights and licenses expressly provided in Section 5.1 (Use of
Card Art and Other Marks), Section 5.2 (Licenses, Proprietary Rights), and this Section 5.4 (Exhibit
A) and under the Visa Rules, each party retains all of its respective Intellectual Property Rights
and no rights or licenses under Intellectual Property Rights are granted or conveyed, whether
expressly or by implication, estoppel or otherwise.
c. Disclaimer of Warranties. NOTHING IN THE PROGRAM AND SERVICES DOCUMENTATION WILL

BE CONSIDERED A REPRESENTATION, WARRANTY OR COMMITMENT OF VISA OR ANY THIRD
PARTY. VISA NEITHER REPRESENTS NOR WARRANTS THAT ANY PROGRAMS, PRODUCTS,
SERVICES, INFORMATION, DATA, TESTING, OR TECHNOLOGY PROVIDED UNDER THESE TERMS
OF USE WILL BE ERROR FREE OR UNINTERRUPTED.

d. Limitation of Liability. IN NO EVENT WILL PARTICIPATING ISSUER (INCLUDING ITS AFFILIATES)

BE ENTITLED TO RECOVER SPECIAL, PUNITIVE, INCIDENTAL OR CONSEQUENTIAL DAMAGES,
INCLUDING DAMAGES BASED ON LOST PROFITS OR LOST BUSINESS OPPORTUNITIES, ARISING
OUT OF THESE TERMS OF USE, THE PROGRAM OR SERVICES, OR VISA’S OBLIGATIONS
HEREUNDER OR THE BREACH THEREOF, EVEN IF VISA HAS BEEN ADVISED OF THE POSSIBILITY
OF SUCH DAMAGES. FOR PURPOSES OF THIS SECTION 5.4.1.d, REFERENCES TO “CLAIM”
INCLUDE ANY CAUSE OF ACTION OF PARTICIPATING ISSUER ARISING UNDER THESE TERMS OF
USE OR THE PROGRAM OR SERVICES.
e. Termination and Suspension. In addition to and not in lieu of any termination rights of Visa, the
following termination and suspension rights shall be available to Visa.
i. Additional Termination Rights. Visa may terminate Participating Issuer’s participation in the
Program by written notice in the event Participating Issuer owns, operates or otherwise
makes available any Payment Network Functionality.
ii. Wind Down. Upon no less than twelve (12) months prior notice to Visa (with an additional six
(6) months for wind down commencing at the end of such 12 month period), Participating
Issuer has the right to discontinue its participation in this Program at the end of such wind
down period (the “Wind Down Period”). The Participating Issuer and Visa will establish a
mutually acceptable plan for discontinuing participation by Participating Issuer by the end of
such Wind Down Period and will perform their responsibilities in accordance with such plan.
Participating Issuer shall provide reasonable cooperation and assistance to facilitate a
smooth wind-down of its participation in the Program.
iii. Suspension or Termination for Certain Events. Visa may elect to immediately suspend or
terminate Participating Issuer’s participation in the Program and terminate these Terms of
Use upon any of the following: (a) in the event of unauthorized access, disclosure or use of
the Program, Tokens provisioned through the Program, or Solutions; (b) if Participating
Issuer or Visa learns or has reason to believe that either of their security measures have been
breached; (c) if in Visa’s sole discretion Participating Issuer’s continued participation would
create undue financial, reputational, or legal risk or damage to Visa, Visa Clients or any of
their respective Affiliates, or would not be in accordance with applicable Laws; (d) if
Participating Issuer is no longer an Issuer in good standing of Visa; (e) if Participating Issuer
sues or otherwise initiates legal proceedings or makes a claim against Visa or its Affiliates; or
(f) if Visa determines that activities by or on behalf of Participating Issuer hereunder are not
in compliance with Laws.
iv. Effect of Termination; Survival. All rights and licenses shall terminate upon expiration or the
effective date of termination the participation in the Program unless expressly stated
otherwise herein. The provisions of Proprietary Notices, Joint Development, Definitions and
this No Implied Licenses, Disclaimer of Warranties, Limitation of Liability, and Effect of
Termination; Survival shall survive expiration or earlier termination of these Terms of Use.

Vts Description Guide Participant Branded Solutions PDF

Uploaded by

Copyright:

Available Formats

Vts Description Guide Participant Branded Solutions PDF

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Vts Description Guide Participant Branded Solutions PDF

Uploaded by

Copyright:

Available Formats

What is the purpose of the document?

What is the purpose of the document?

What stakeholders are involved in tokenization?

What stakeholders are involved in tokenization?

Visa Token Service

Service Description Guide for Participant-Branded

© 2015-2016 Visa. All Rights Reserved.

THE INFORMATION CONTAINED HEREIN IS PROPRIETARY AND CONFIDENTIAL AND MUST BE

27 August 20156 Visa Confidential i

5 VDEP Participation Requirements and Terms of Use ................................................................................ 27

ii Visa Confidential 20 June 2016

Table 1: Related Publications.......................................................................................................................................... 6

Figure 2–1: Major Program Components ....................................................................................................................... 14

20 June 2016 Visa Confidential iii

iv Visa Confidential 20 June 2016

Introduction to the Visa Token Service–Service Description

20 June 2016 Visa Confidential 5

Title Description Location

6 Visa Confidential 20 June 2016

Title Description Location

20 June 2016 Visa Confidential 7

Title Description Location

Changes from Version 1.1

8 Visa Confidential 20 June 2016

Inclusion of the issuer in-app payment use case.

20 June 2016 Visa Confidential 9

1.1 Background on Tokenization

10 Visa Confidential 20 June 2016

1.2 Payment Token Standard

1.3 Tokenization Stakeholders

1.3.1 Token Requestor

20 June 2016 Visa Confidential 11

1.3.2 Card Issuer

1.3.5 Acquirer and Acquirer Processor

12 Visa Confidential 20 June 2016

20 June 2016 Visa Confidential 13

2 Visa Token Service Overview

2.1 Visa Token Service

14 Visa Confidential 20 June 2016

2.2 Visa Digital Solutions SDK

2.3 Token Requestor Mobile Application Platform

20 June 2016 Visa Confidential 15

2.4 Token Requestor Mobile Application

2.5 Visa Token Service Core Services and Capabilities

2.5.1 Core Services

1. Token Generation and Provisioning

16 Visa Confidential 20 June 2016

Lifecycle management events for tokens include:

20 June 2016 Visa Confidential 17

Lifecycle management queries:

During transaction processing, the Visa Token Service:

18 Visa Confidential 20 June 2016

1. Consumer initiates a purchase at an NFC-enabled terminal at merchant location.

2. Merchant submits a token in place of the PAN to its acquirer.

3. Acquirer passes the token (processed identically to the PAN) to VisaNet.

20 June 2016 Visa Confidential 19

20 Visa Confidential 20 June 2016

9. Testing and Certification

20 June 2016 Visa Confidential 21