Vts Description Guide Vdep Third Party Solutions

Visa Token Service
Service Description Guide for Issuer Participation in

VDEP Third-Party Solutions
Version 1.8
7 November 2018
Visa Confidential
Important Information on Confidentiality and Copyright
© 2015–2018 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.
The Visa Confidential label signifies that the information in this document is confidential and
proprietary to Visa and is intended for use only by Visa Clients subject to the confidentiality
restrictions in the Visa Core Rules and Visa Product and Service Rules, non-Client Third-Party
Processors that have an executed and valid VisaNet Letter of Agreement on file with Visa, and other
third parties that have a current participation agreement, including confidentiality provisions, or other
non-disclosure agreement with Visa that covers disclosure and use of the information contained
herein.
This document is protected by copyright restricting its use, copying, distribution, and
decompilation. No part of this document may be reproduced in any form by any means without prior
written authorization of 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.
THIS PUBLICATION IS PROVIDED ON AN “AS IS, WHERE IS” BASIS, “WITH ALL FAULTS” KNOWN AND
UNKNOWN. 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. WHERE POTENTIAL FUTURE FUNCTIONALITY IS HIGHLIGHTED, VISA
DOES NOT PROVIDE ANY WARRANTY ON WHETHER SUCH FUNCTIONALITY WILL BE AVAILABLE OR
IF IT WILL BE DELIVERED IN ANY PARTICULAR. 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.
If you have technical questions or questions regarding a Visa service or questions about this
document, please contact your Visa representative.
Contents
Visa Token Service Service Description Guide for Issuer Participation in VDEP Third-Party Solutions
Contents
Tables .............................................................................................................................................................................. iii

Figures .............................................................................................................................................................................. v
Introduction .................................................................................................................................................................... 1
Audience....................................................................................................................................................................................... 1
Scope ............................................................................................................................................................................................. 1
Related Publications................................................................................................................................................................. 1
1 Tokenization Overview ........................................................................................................................................ 3
1.1 Background on Tokenization ..................................................................................................................................... 3
1.2 Payment Token Standard ............................................................................................................................................ 3
1.3 Tokenization Stakeholders .......................................................................................................................................... 4
1.3.1 Token Requestor ..................................................................................................................................................... 4
1.3.2 Issuer and Issuer Processor ................................................................................................................................. 4
1.3.3 Cardholders ............................................................................................................................................................... 5
1.3.4 Merchants and e-Commerce Enablers ............................................................................................................ 5
1.3.5 Acquirer and Acquirer Processor ...................................................................................................................... 5
1.3.6 Visa ............................................................................................................................................................................... 5
2 Visa Token Service Overview ............................................................................................................................. 7
2.1 Visa Token Service Core Services and Capabilities ............................................................................................ 9
2.1.1 Token Generation and Provisioning ................................................................................................................ 9
2.1.2 Identity & Verification (ID&V) .......................................................................................................................... 10
2.1.3 Card Metadata Management ........................................................................................................................... 11
2.1.4 Token Lifecycle Management (TLCM) ........................................................................................................... 11
2.1.5 Token Transaction Processing .......................................................................................................................... 13
2.1.5.1 NFC Transactions ............................................................................................................................................. 13
2.1.5.2 Merchant-Presented QR Code Transactions ......................................................................................... 14
2.1.5.3 Push Payment Transactions ......................................................................................................................... 15
2.1.6 Active Key Management (AKM)....................................................................................................................... 16
2.1.7 Transaction Alerts and History ......................................................................................................................... 16
7 November 2018 Visa Confidential i

Contents
2.1.8 Notifications ............................................................................................................................................................ 17

2.2 Issuer Participation ....................................................................................................................................................... 17
2.2.1 Testing and Certification .................................................................................................................................... 17
2.2.2 Customer Support ................................................................................................................................................ 17
2.2.3 Participating Issuer Approval and Additional Conditions...................................................................... 18
3 Enrolling in Visa Token Service ........................................................................................................................ 19
3.1 Visa Digital Configuration System (VDCS) .......................................................................................................... 19
3.2 Visa Risk Manager ........................................................................................................................................................ 20
3.3 Visa Card Metadata Management ......................................................................................................................... 20
4 Implementation Planning .................................................................................................................................. 21
ii Visa Confidential 7 November 2018

Tables
Tables
Table 1: Related Publications.......................................................................................................................................... 2
7 November 2018 Visa Confidential iii

Tables
iv Visa Confidential 7 November 2018

Figures
Figures
Figure 2–1: Summary of Differences between Device-Bound Tokens and Non-Device-Bound Tokens.. 8
Figure 2–2: Major Program Components ......................................................................................................................... 9
Figure 2–3: Example of a Visa PayWave Transaction Processing Using Token ................................................ 14
Figure 2–4: Merchant-Presented QR Code Transaction Processing Using Token .......................................... 15
7 November 2018 Visa Confidential v

Figures
vi Visa Confidential 7 November 2018

Introduction
Introduction
A key component of Visa Digital Solutions, Visa Token Service allows issuers to manage the issuance
of digital token payment credentials. Through this service, Visa provides a flexible and scalable way to
securely provision and manage token credentials. These capabilities are available and complemented
through a common set of Visa interfaces.
The Visa Token Service Service Description Guide for Issuer Participation in VDEP Third-Party Solutions
(this document) provides a high-level overview of the features and capabilities of Visa Token Service
to provision and manage digital credentials on third-party mobile wallets, including e-commerce and
card-on-file (COF) tokenization. This document is intended to be read in conjunction with the
supporting documents listed in Table 1, Related Publications.
Audience
This document is intended for issuers and issuer processors participating in payment solutions offered
by third-party token requestors participating in the Visa Digital Enablement Program (VDEP). VDEP is a
commercial framework addressing the interaction between issuers and token requestors using Visa
Token Service. VDEP is intended to simplify and accelerate the roll-out of new payment solutions.
Scope
Visa Token Service is intended to address the enablement of multiple digital payment use cases over
time. This document addresses issuer participation in third-party wallet solutions and issuer-branded
wallet solutions that support NFC, quick-response (QR) code, and push (AFT and OCT) payments using
Host Card Emulation (HCE) or Secure Element (SE), as well as solutions for tokenization of e-commerce
transactions through in-app, QR code, push payment, Visa Checkout and other e-commerce enablers,
IoT devices, and card-on-file merchant solutions.
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.
7 November 2018 Visa Confidential 1

Introduction
Table 1: Related Publications
Title Description Location
Visa Token Service Implementation Guide for Implementation requirements for Visa Token Visa Online
Issuer Participation in VDEP Third-Party Service, the Visa Digital Enablement
Solutions Program, and issuer participation in third-
party wallets.
Visa Token Service Description Guide for Provides a high-level overview of Visa Token
Participant-Branded Solutions Service, the Visa Digital Enablement
Program, for issuers building their own
wallets.
Visa Token Service Implementation Guide for Implementation requirements for Visa Token Visa Online
Participant-Branded Solutions Service, the Visa Digital Enablement
Program, for issuers building their own
wallets.
The Visa Token Service – Service Description Provides a high-level overview of Visa Token Visa Online
Guide for Issuer Participation in Apple Pay Service, and the Visa Digital Enablement
Program for issuers participating in
ApplePay.
VDEP Participation Requirements and Terms Visa Rules and VDEP participation Please contact
of Use agreement based on scope and nature of your Visa
participation. Required in the U.S. representative
EMV® Payment Tokenisation Specification Describes the payment token system www.emvco.com
Technical Framework 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.
2 Visa Confidential 7 November 2018

Tokenization Overview
1 Tokenization Overview
This chapter provides an overview of payment tokenization and includes:
• Background on tokenization
• Information about the payment token standard
• Descriptions of tokenization stakeholders
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. Today, consumers use multiple channels
to transact and merchants offer seamless multi-channel shopping experiences through mobile
devices, mobile applications, and web browsers.
Payment tokens are surrogate values that replace Primary Account Numbers (PANs) 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.
Tokenization limits the exposure of cardholder account data and mitigates the fraud risk for
transactions occurring in both point-of-sale and e-commerce environments.
Other benefits include:

• 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 become less appealing targets for fraud, given their limitation to a
specific domain. Acquirers and merchants may also benefit from improved authorization rates
due to the higher assurance levels that payment tokens offer.
• The payments system benefits from a standard specification made available by EMVCo that
facilitates interoperability and simplifies token processing for issuers, processors, and acquirers
across networks.
1.2 Payment Token Standard
Visa, MasterCard, and American Express announced the creation of a framework for a 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 a cardholder 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.
This effort resulted in publication of the EMV Payment Tokenisation Specification Technical Framework,
which standardizes tokenization and helps provide the payments community with a consistent, secure,
and globally interoperable environment. It 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.
Visa offers the Visa Token Service, based on the EMVCo specifications, to enable secure digital
payments for point-of-sale and e-commerce environments.
1.3 Tokenization Stakeholders
Tokenization requires participation of existing payment card stakeholders. 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. Examples of token requestors include third-party wallet providers, issuers offering
their own mobile payment applications to their 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 Issuer and Issuer Processor
Issuers maintain their current role in owning the cardholder relationship, as well as having
authorization and ongoing risk management responsibilities. Active VTS issuers decide which payment
solutions they would like to participate in and control token provisioning decisions. Visa Token Service
offers the issuer’s cardholders more innovative payment methods with a reduced risk of their payment
credentials being compromised. Issuers will obtain better visibility as to where their PANs are being
tokenized and when and where they are used to initiate a transaction.
The issuer processor facilitates issuer participation in VDEP by supporting integration of the
processing changes related to tokenization.

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 Merchants and e-Commerce Enablers
Payment tokens transact and process in the same manner as traditional PANs and the underlying
payment infrastructure supported by merchants is the same.
Visa payWave terminals are able to support transactions originating from mobile devices using an NFC
interface.
Merchants can also accept payments using merchant-presented QR codes in accordance with Visa
specifications and requirements. The cardholder can initiate a transaction using a mobile device to
scan a QR code presented by a merchant.
Merchants processing token transactions in e-commerce environments can be either token requestors
or token acceptors:
• Merchants with cardholder PANs on file (card-on-file) can integrate directly with Visa Token
Service as token requestors and must comply with all Visa token requestor requirements.
Merchants acting as token requestors enroll PANs and receive unique tokens from Visa Token
Service that can be used instead of PANs to conduct transactions.
• Merchants that sell goods and services and process payments indirectly through integration with
e-commerce enablers (e.g., Visa Checkout and other third-party entities) receive token
information from their e-commerce enabler and are considered token acceptors.
e-Commerce enablers can be traditional participants within the payments industry or new participants
bringing innovation to the payments ecosystem. e-Commerce enablers also integrate directly with
Visa Token Service and receive tokens for PANs that may be shared across their multiple merchant
base.
1.3.5 Acquirer and Acquirer Processor
Acquirers process token transactions in the same manner they process card account numbers. 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 described in this
document as well as the EMV Payment Tokenisation Specification Technical Framework.


Visa Token Service Overview
2 Visa Token Service Overview

Visa Token Service is designed to support a number of payment use cases that fall into the following
categories (see Figure 2–1):
• Device-bound tokens:
- Require cardholder participation
- Must be provisioned and activated before they can be used for a payment transaction
- May require additional verification of the cardholder’s identity by issuer
- Are restricted and bound to a specific device only
Examples of transactions using device-bound tokens include:
- NFC mobile contactless (Visa payWave) payments using Host Card Emulation or Secure
Element
- In-app e-commerce payments
- Internet of Things (IoT) devices such as wearables, home automation, automobile
- Merchant-presented QR code payments
- Consumer-presented QR code payments
- Push payments using Account Funding Transactions (AFTs) and Original Credit Transactions
(OCTs)
• Non-device-bound tokens:
- Can be provisioned and activated without cardholder knowledge
- Can be provisioned during a purchase transaction (this is an in-transaction experience, as
tokens can be requested during an actual payment transaction and therefore must be
provisioned in an “active” status only)
- Can be provisioned prior to the cardholder making a purchase; for example, in a batch process
for cardholders that previously stored their card with the merchant
- Are not restricted to a specific device but may be restricted to a specific merchant
Examples of transactions using these tokens include:
- Payments initiated by e-commerce enablers such as Visa Checkout and third parties
- Merchants storing tokens instead of cardholder PANs (card-on-file) in their payment systems
- Merchant-presented QR code payments
- Push payments using Account Funding Transactions (AFTs) and Original Credit Transactions
(OCTs)

Figure 2–1: Summary of Differences between Device-Bound Tokens and Non-Device-Bound Tokens
Visa Token Service supports an issuer’s ability to provision and manage tokens. The service helps to
ensure that proper domain restrictions are established during provisioning and that risk parameters
are managed based on the specific token use case initiated by the token requestor.
Visa Token Service is fully integrated into Visa’s processing capabilities (see Figure 2–2). When a
transaction is initiated using a Visa-issued token, Visa systems identify the transaction and route it to
Visa Token Service for de-tokenization and validation of domain restrictions. De-tokenization provides
the link between the token and the PAN.
The network-based entity labeled “Visa Token Service” in Figure 2–2 handles all the interactions
between the Visa Token Vault (which stores the token-to-PAN mapping) and a Visa token requestor.

Figure 2–2: Major Program Components
2.1 Visa Token Service Core Services and Capabilities
Visa Token Service capabilities are described in the following sections. Unless otherwise explicitly
noted, participating issuers are required to utilize and support each of the core services.
Note: Issuers in the U.S. must agree to participate in VDEP. The VDEP Participation Requirements
and Terms of Use are available on Visa Online or from your Visa representative.
2.1.1 Token Generation and Provisioning
Upon request from an authorized token requestor, Visa Token Service generates a token if the card
details provided are from an account range an issuer has designated as eligible for tokenization with
the token requestor. As soon as the token is generated, it is mapped to the primary account number
(PAN) and stored in the Visa Token Vault along with other data 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 (see Section 2.1.4) is based on successful completion of
the identification and verification (ID&V) process (see Section 2.1.2). In some cases, the token may be
inactive until further validation by the consumer.
Note: Non-device tokens are provisioned in “active” status.

2.1.2 Identity & Verification (ID&V)
ID&V is performed in order to help determine if the actual cardholder has authorized the token
requestor to initiate the token request. As part of this process, Visa contacts the issuer (or the issuer’s
processor) through the existing ISO connection to Visa to confirm certain information about the
account (e.g., CVV2, address verification). Only successful ID&V results are sufficient to generate a
token.
In addition, the ID&V process includes the use of Visa Risk Manager (VRM), a tool that allows issuers
to apply risk decisioning rules in support of provisioning requests. VRM evaluates data provided by
the token requestor to determine the risk associated with the individual request. Issuers create and
manage risk-based provisioning rules through Visa Risk Manager in order to assess the probability
that the consumer attempting to load a Visa account into a third-party wallet is the cardholder.
Issuers are required to support step-up authentication methods to be invoked when the risk-based
provisioning rules within VRM trigger a requirement for additional authentication.
Issuers must support at least two different forms of step-up authentication—one primary option and
one (or more) secondary options. Call center must be one of the options. The primary option is always
displayed to the cardholder at time of step-up. A secondary option(s) is not required to be displayed
as a step-up option at the time of provisioning. The issuer may choose to display secondary options as
a fallback if the consumer is not able to complete the provisioning with the primary option.
The step-up methods currently supported by Visa Token Service include:

• Call Center: The issuer provides a phone number, which is displayed in the user interface of the
token requestor’s solution. The cardholder is instructed to contact the issuer to complete the
token activation process. Upon successful verification of the cardholder, the issuer notifies Visa to
activate the token through the Token Lifecycle Management Tool or through other interfaces.
• Mobile Banking Application Authentication: Issuers may implement this method by integrating
a Visa-provided specification into the issuer’s mobile banking application. Cardholders that have
installed the issuer’s mobile banking application can then verify themselves by logging into the
issuer’s mobile banking application. Upon successful authentication, the issuer sends a lifecycle
request or an encrypted payload to activate the token. If validated, Visa then activates the token
and sends a message to the token requestor's mobile wallet to activate on device.
• One-Time Passcode (OTP): The OTP is generated by Visa and passed to the issuer. The issuer
sends the OTP to the cardholder using a tenured contact method (email or SMS message to
mobile phone number). Following receipt, the cardholder enters the OTP into the user interface
of the token requestor’s mobile wallet. The token requestor then returns the OTP to Visa. If the
OTP matches the original value generated by Visa, Visa Token Service activates the token.
Note: The OTP step-up method may not be available in all locations.
• Visa Access Code in Authorization Message (VACAT): Allows issuers to use their existing online
banking website to display the access code as a pending transaction to the cardholder. When a

cardholder selects this method to complete additional verification, an access code is generated
by Visa and delivered using the existing ISO message infrastructure to the issuer endpoint.
Cardholders log in and authenticate themselves through the existing online banking website via
a browser or mobile application on their device to retrieve the access code. The cardholder then
returns to the token requestor’s wallet application and inputs this access code, which is
forwarded to Visa for verification. Only after successful verification of the access code, Visa
activates the token and sends a request to the token requestor's wallet application to activate on
device.
Note: VACAT may not be supported by all token requestors.
Non–device-bound tokens do not require step-up authentication, as the token provisioning decision
results in either “approve” or “decline” by the issuer. When an attempt to tokenize a card results in a
“decline” outcome, no token is provisioned and the token requestor resumes the e-commerce
transaction with a PAN as usual.
2.1.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. Issuers must submit (and update as necessary) card
metadata through the Visa Card Metadata Management (VCMM) tool (Section 3.3).
A successful non–device-bound token provisioning event triggers Visa Token Service to pass the
cardholder’s card art image and last four digits of the PAN to the token requestor. The last four digits
of the PAN are displayed to the cardholder and the card art may also be displayed, depending upon
the token requestor’s capability and user interface.
2.1.4 Token Lifecycle Management (TLCM)
The Token Lifecycle Management Tool or other LCM interface 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 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 event 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 cardholder may DELETE a token directly
through the user interface of the token requestor’s solution. The token requestor initiates DELETE
on the cardholder’s behalf. The issuer may receive notification that the token has been deleted.
• Suspend: The issuer may initiate SUSPEND 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 the token (following a SUSPEND event) so existing
account parameters are enabled for payment and replenishment.
• Update PAN Expiration: When the expiration date of a tokenized PAN changes, the issuer is
required to provide Visa with the new expiration date. Visa updates the 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 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,
which eliminates the need for the cardholder to delete and re-provision the active token.
Issuers can also use 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.
Lifecycle management is performed using Visa’s Token Lifecycle Management (TLCM) tool, ISO
messages sent through the issuer’s existing connection to Visa, or other interfaces that may be
supported by Visa. 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 nearly
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.
Note: Non–device-bound tokens are also impacted by token lifecycle events (delete, suspend, and
resume) and PAN lifecycle events (PAN replacement, PAN expiration date update). Issuers
should continue to manage the underlying PAN account and complete subsequent lifecycle
actions on tokens as described above.

2.1.5 Token Transaction Processing
All tokenized Visa transactions must be routed to the Visa Token Vault for de-tokenization. During
transaction processing, 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.
Note: For some locations and card types, VisaNet must be used to process any transaction (including
authorization, clearing, settlement, and exception processing) initiated by a token provisioned
through Visa Token Service. Check with your Visa representative for specific requirements.
As soon as a token is provisioned, 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. Visa does process token transactions that contain the above referenced response
codes in stand-in processing (STIP). Visa does not accept a referral response and if provided, the
response is converted to a decline.
Token transactions should not be declined for account closed, expired PAN, or invalid account
response codes as token lifecycle management interfaces should be used to update the PAN status for
the token. In the event that the issuer’s submission of lifecycle maintenance to update the PAN is
delayed and the issuer responds to a token transaction with a decline for account close, expired PAN,
or invalid account response codes, the response is communicated to the acquirer/merchant.
2.1.5.1 NFC Transactions
An example of a Visa payWave transaction using a token provisioned to an NFC-enabled mobile

phone or an IoT device through Visa Token Service is shown in Figure 2–3.

Figure 2–3: Example of a Visa PayWave Transaction Processing Using Token
1. Consumer initiates a purchase at an NFC-enabled terminal at a 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
Limited Use Key (LUK) velocity checks for HCE tokens.
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.
Note: e-Commerce enablers and card-on-file merchants request Visa Token Service to send a valid,
one-time use cryptogram to be used at the time of payment authorization using a provisioned
token. This cryptogram is then submitted in the transaction, to be validated by Visa with the
results forwarded to the issuer for approval in the authorization message.
2.1.5.2 Merchant-Presented QR Code Transactions
Figure 2–4 shows an example of a Visa merchant-presented QR code transaction through Visa Token
Service using a token provisioned to a Scan-and-Pay–enabled mobile phone.

Figure 2–4: Merchant-Presented QR Code Transaction Processing Using Token
Issuer
Authorization request
Consumer Wallet Provider VTS 4 AFT/AFTR
1 Scan & Pay 2 Payment API
3 PAN
Acquirer
Payment
7 Approval 6 response
(or Decline)
Authorization response
5 OCT
1. Consumer initiates Scan-and-Pay by scanning a merchant-presented QR code through the

enabled, participating wallet provider application.
2. Wallet provider generates and sends the payment transaction to Visa (Token ID and merchant
data from QR).
3. Visa Token Service exchanges token with the PAN.
4. Visa sends the PAN based AFT (and optional AFTR) message to cardholder’s issuing bank.
5. Visa sends the OCT message to the merchant acquiring bank.
6. Visa sends the authorization response based on both transactions (AFT and OCT).
7. Wallet provider displays the Scan-and-Pay transaction completion as a success or failure.
2.1.5.3 Push Payment Transactions
Push payment program providers can use tokens in the process of securing funds from the sender’s
account and pushing those funds to a recipient’s Visa account. These operations are enabled through
two ISO transaction types:
• Account Funding Transaction (AFT): Used by the originating institution of the push payment
program provider to secure funds from the sender.
• Original Credit Transaction (OCT): Used by originators to push funds to an eligible Visa account.
Token requestors can enable cardholders to initiate push payments using connected devices. Push
payment use cases supported by tokenization include:
• Person-to-Person (P2P) transaction: A push payment transaction in which an individual sender
sends funds to another individual’s account. Senders can use in-app, browser-based, or call
center methods to send funds to the recipient.
• Person-to-Merchant (P2M) transaction: A push payment transaction in which an individual
sender sends funds to a business, government, or non-profit agency’s account. Senders can pay
merchants using a P2M push payment at a storefront using a merchant-presented QR code.

• Funds disbursement transaction: A push payment transaction in which a business, government,

or non-profit agency sends funds directly to a recipient’s account. Funds disbursement
transactions are only available in a card-not-present environment.
2.1.6 Active Key Management (AKM)
Issuers are required to configure active key management parameters during enrollment in Visa Token
Service for tokens on devices using Visa’s cloud-based payment specifications (i.e., device-bound Host
Card Emulation). Visa Token Service manages LUK replenishment for any Visa HCE use cases. LUKs are
used to generate cryptograms for Visa payWave mobile contactless transactions.
During the provisioning process, the active key management capability in Visa Token Service
generates an 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 for a
particular account indicate that the LUK on the device requires replacement, Visa Token Service
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 Visa Token Service.
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
Active Key Management is a device-based service and thus is not applicable to non-device-bound
tokens.
2.1.7 Transaction Alerts and History
For token requestor solutions that support the display of transaction history and alerts to the
consumer, Visa Token Service provides transaction data to the token requestor on behalf of the issuer.

2.1.8 Notifications
Visa Token Service delivers a notification to the issuer (or the issuer’s processor) for the following
events:
• A token provisioning request is received
• Token provisioning
• Token activation
• LUK replenishment (device bound HCE-NFC tokens only)
• Certain lifecycle management events
Issuers are required to notify the cardholder when a device-bound NFC token has been provisioned,
along with the identity of the token requestor.
However, for non–device-bound tokens, cardholder notifications are optional. Issuers should ensure
that communication to cardholders regarding account tokenization is either suppressed or
appropriately messaged.
When deciding on a notification approach for non–device-bound tokens, please note that the
cardholder may not have had recent interaction with the merchant prior to tokenization, and thus may
be confused by messaging relating to a tokenization event. Should an issuer decide to notify
cardholders, an example of a potential message is “Your card on file at token requestor/merchant ABC
has been replaced with a digital account number that provides enhanced security for your account.”
Such notifications should also avoid contextually inappropriate references, such as “NFC”, “device”,
“stores”, etc.
2.2 Issuer Participation
To participate actively in Visa Token Service, issuers must plan for the following considerations.
2.2.1 Testing and Certification
Visa provides testing and certification assistance as part of the issuer onboarding process for Visa
Token Service. Issuers are required to successfully complete testing and certification to participate in
Visa Token Service, and additional testing and certification may be required for existing Visa Token
Service issuers prior to live participation in new token requestor solutions and new token use cases.
2.2.2 Customer Support
In general, any inquiries concerning a cardholder’s payment account will be handled by the
participating issuer. Token requestors will handle inquiries related specifically to use of a solution, but
not inquiries concerning a cardholder’s payment account or any charges related to the payment

account. The 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.
Note: Visa Global Customer Assistance Services (GCAS) can provide customer support services for
VTS.
2.2.3 Participating Issuer Approval and Additional Conditions
Participating issuers must successfully complete testing, requirements, and approval processes in
order to participate in the program and use the service as set forth in the program and services
documentation. Participation in the program and use of the service may be delayed, revoked or
suspended, in whole or in part, at Visa’s discretion, if a participating issuer is not participating in the
program or using the services in accordance with these terms of use or the program and services
documentation.
Note: Participating issuers in some locations (including the U.S.) must execute the VDEP Participation
Requirements and Terms of Use agreement.

Enrolling in Visa Token Service
3 Enrolling in Visa Token Service

Issuer enrollment in Visa Token Service consists of several steps. Visa provides three primary tools that
issuers and processors can use to initiate the enrollment process:
• Visa Digital Configuration System
• Visa Risk Manager
• Visa Card Metadata Management
There are no issuer enrollment steps for non–device-bound tokens, as all existing issuer BINs already
participating in Visa Token Service are automatically enrolled for e-commerce enabler and card-on-file
tokens. Issuers may request to opt out of participation with specific e-commerce and card-on-file
token requestors by managing their CORE settings or by creating a rule in VRM to decline token
provisioning requests for that individual token requestor. Issuers cannot opt out of tokenization of
Visa cards through Visa Checkout.
3.1 Visa Digital Configuration System (VDCS)
Visa provides issuers and issuer processors with a web-based tool called the Visa Digital Configuration
System (VDCS), available on Visa Online. The following information must be entered into VDCS:
• The issuer or the issuer’s authorized representative selects the particular token requestor
solution(s) in which it desires to participate. Wallet solutions that support NFC 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 participation. For such solutions, Visa
provides a link and/or displays the additional terms through VDCS. Issuers or their authorized
representatives are required to acknowledge acceptance of the additional terms.
• 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 for the personalization of device–bound tokens and generation of
transaction cryptograms, or to request Visa to generate and provide a new master key specifically
to be used for token transaction processing.

Enrolling in Visa Token Service
• Selection of processing options, including active key management parameters (for device-bound
HCE tokens only).
• Issuers can select the options to receive notifications for token provisioning, lifecycle
management, and active key management events (for device-bound HCE tokens only).
• Issuers can also request access to other enrollment tools (i.e., VRM, LCM, 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 or specific card-on-file merchants by entering the token
requestor ID of each such requestor. Issuers cannot block Token Requestor ID for Visa Checkout.
3.3 Visa Card Metadata Management
The Visa Card Metadata Management (VCMM) online tool is accessible via Visa Online. Issuers and
processors use the VCMM tool to help manage card art configuration, terms and conditions, and
other metadata at the 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.

Implementation Planning
4 Implementation Planning
Visa provides either a standard or customized implementation option 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 issuer’s processing system. It is designed to enable an issuer to quickly
participate in the Visa Token Service. The standard option uses:
• The issuer’s existing connection to Visa systems
• Standard ISO-based message formats
• Risk-based decisioning and account management tools
The customized implementation option may require extensive implementation time and a greater
number of changes to an issuer’s processing system. It is designed to provide issuers with flexibility in
supporting the 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.
Issuers should contact their Visa representative to obtain the appropriate documentation for
additional information related to implementation and integration and the details of each option.

Implementation Planning

Vts Description Guide Vdep Third Party Solutions

Caricato da

Informazioni sul documento

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Vts Description Guide Vdep Third Party Solutions

Caricato da

Copyright:

Formati disponibili

Visa Token Service

Service Description Guide for Issuer Participation in

© 2015–2018 Visa. All Rights Reserved.

Tables .............................................................................................................................................................................. iii

7 November 2018 Visa Confidential i

2.1.8 Notifications ............................................................................................................................................................ 17

ii Visa Confidential 7 November 2018

Table 1: Related Publications.......................................................................................................................................... 2

7 November 2018 Visa Confidential iii

iv Visa Confidential 7 November 2018

7 November 2018 Visa Confidential v

vi Visa Confidential 7 November 2018

7 November 2018 Visa Confidential 1

Table 1: Related Publications

Title Description Location

2 Visa Confidential 7 November 2018

1.1 Background on Tokenization

Other benefits include:

1.2 Payment Token Standard

7 November 2018 Visa Confidential 3

1.3 Tokenization Stakeholders

Tokenization requires participation of existing payment card stakeholders. A new stakeholder—token

1.3.1 Token Requestor

1.3.2 Issuer and Issuer Processor

4 Visa Confidential 7 November 2018

1.3.4 Merchants and e-Commerce Enablers

1.3.5 Acquirer and Acquirer Processor

7 November 2018 Visa Confidential 5

6 Visa Confidential 7 November 2018

2 Visa Token Service Overview

7 November 2018 Visa Confidential 7

8 Visa Confidential 7 November 2018

Figure 2–2: Major Program Components

2.1 Visa Token Service Core Services and Capabilities

2.1.1 Token Generation and Provisioning

7 November 2018 Visa Confidential 9

2.1.2 Identity & Verification (ID&V)

The step-up methods currently supported by Visa Token Service include:

10 Visa Confidential 7 November 2018

2.1.3 Card Metadata Management

2.1.4 Token Lifecycle Management (TLCM)

Lifecycle management events for tokens include:

7 November 2018 Visa Confidential 11

Issuers can also use lifecycle management queries:

12 Visa Confidential 7 November 2018

2.1.5 Token Transaction Processing

2.1.5.1 NFC Transactions

An example of a Visa payWave transaction using a token provisioned to an NFC-enabled mobile

7 November 2018 Visa Confidential 13

Figure 2–3: Example of a Visa PayWave Transaction Processing Using Token

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

2.1.5.2 Merchant-Presented QR Code Transactions

14 Visa Confidential 7 November 2018

Figure 2–4: Merchant-Presented QR Code Transaction Processing Using Token

1. Consumer initiates Scan-and-Pay by scanning a merchant-presented QR code through the

2.1.5.3 Push Payment Transactions

7 November 2018 Visa Confidential 15

• Funds disbursement transaction: A push payment transaction in which a business, government,

2.1.6 Active Key Management (AKM)

2.1.7 Transaction Alerts and History

16 Visa Confidential 7 November 2018

2.2 Issuer Participation

2.2.1 Testing and Certification

2.2.2 Customer Support