Visa Token Service Implementation Guide For Issuers

Visa Europe
Visa Token Service

Implementation Guide for Issuers
Version 3.0
November 2016
Visa Europe Confidential
The Visa Europe Confidential label signifies that the information in this document is
confidential and proprietary to Visa and is intended for use only by Visa Europe clients and
other third parties that have a current nondisclosure agreement (NDA) with Visa Europe that
covers disclosure of the information contained herein.
This document is protected by copyright restricting its use, copying, distribution, and de-
compilation. No part of this document may be reproduced in any form by any means without
prior written authorization of Visa.
Changes are periodically added to the information herein. At any time, Visa Europe may make
improvements and/or changes in the product(s) and/or the programme(s) that are described in
this document.
Every reasonable effort has been made to ensure the accuracy of information provided by Visa
Europe. Visa Europe shall not be held liable for any inaccurate information of any nature,
however communicated by Visa Europe.
Visa and other trademarks are trademarks or registered trademarks of Visa.
All other product names mentioned herein are the trademarks of their respective owners.
Visa Europe 2016
Visa Confidential Version 3.0

Visa Europe 2 of 40 November 2016
Visa Token Service Contents
Implementation guide for Issuers
Contents
1 About this guide .............................................................................................................................. 6

1.1 Document purpose ........................................................................................................................... 6
1.2 Audience................................................................................................................................................6
1.3 Scope ...................................................................................................................................................... 6
1.4 Document organisation ...................................................................................................................6
1.5 Related publications ......................................................................................................................... 7
1.6 Definitions.............................................................................................................................................8
1.7 Document conventions................................................................................................................. 10
1.8 For more information .................................................................................................................... 10
2 About the Visa Token Service .....................................................................................................11
2.1 What are payment tokens ........................................................................................................... 11
2.2 Visa product eligibility .................................................................................................................. 12
2.3 Token type support ........................................................................................................................ 12
2.4 Use case support ............................................................................................................................. 12
2.5 Token processing ............................................................................................................................ 12
2.5.1 Generic token processing .......................................................................................................... 13
2.5.2 Easy token processing ................................................................................................................. 13
3 Implementing the Visa Token Service ......................................................................................14
3.1 Implementation process............................................................................................................... 14
3.1.1 Pre-onboarding ............................................................................................................................. 14
3.1.2 Service considerations ................................................................................................................ 14
3.2 Testing and certification ............................................................................................................... 21

3.2.1 Sample test cases: ......................................................................................................................... 21
3.2.2 Entry criteria for testing .............................................................................................................. 22
3.2.3 Exit criteria for testing ................................................................................................................. 22
3.2.4 Keys .................................................................................................................................................... 22
3.3 Onboarding ....................................................................................................................................... 22

4 Cryptographic keys and key management .............................................................................25
4.1 Cryptogram (AC MDK) .................................................................................................................. 25
4.1.1 Secure element (SE) implementation: ................................................................................... 25
4.1.2 Cloud based payments (CBP) implementation: ................................................................ 25
4.2 iCVV keys............................................................................................................................................ 26

4.3 CVV2 keys (C2K) .............................................................................................................................. 26

4.4 ODA certificates and key pairs ................................................................................................... 27
4.4.1 Offline transactions and online with ODA transactions................................................. 27
4.5 Web service security ...................................................................................................................... 27

4.5.1 Connecting to the Visa Europe Payment Token Service API ....................................... 27
4.5.2 Web service data encryption and decryption keys ......................................................... 28
4.6 Mobile banking app step-up authentication ....................................................................... 28

4.7 Zone control master key (ZCMK) .............................................................................................. 29
5 Tools and methods for supporting the service ......................................................................30
5.1 Web services ..................................................................................................................................... 30
5.1.1 Web service summaries .............................................................................................................. 30
5.1.2 Web service testing ...................................................................................................................... 32
5.2 Visa Card Metadata Manager..................................................................................................... 32

5.2.1 VCMM Functions ........................................................................................................................... 32
5.2.2 Access to VCMM ........................................................................................................................... 33
5.2.3 Browser support for VCMM ...................................................................................................... 33
5.2.4 VCMM documentation ............................................................................................................... 33
5.2.5 Uploading card art........................................................................................................................ 33
5.3 Visa Risk Manager .......................................................................................................................... 33

5.3.1 Rule outcomes ............................................................................................................................... 34
5.3.2 Guidance on VRM rules for token provisioning ............................................................... 34
5.3.3 Access to VRM Rules Manager ................................................................................................ 36
5.3.4 Browser support for VRM Rules Manager .......................................................................... 36
5.3.5 Visa Risk Manager documentation for token authentication rules .......................... 36
5.4 Token Life Cycle Management................................................................................................... 36

5.4.1 Token life cycle event types ...................................................................................................... 36
5.4.2 Options for managing token life cycle events ................................................................... 37
5.4.3 TLCM tool functions ..................................................................................................................... 37
5.5 Visa Token Reporting Service ..................................................................................................... 38

5.5.1 VTRS documentation ................................................................................................................... 38
5.5.2 Accessing VTRS .............................................................................................................................. 38
5.5.3 Browser support for VTRS ......................................................................................................... 38
Appendix A. Comparison of Generic and Easy token features........................................39

Tables
Table 1: Document sections....................................................................................................................................................... 6

Table 2: Definitions ........................................................................................................................................................................ 8
Table 3: Document conventions ........................................................................................................................................... 10
Table 4: Properties of payment tokens .............................................................................................................................. 11
Table 5: Bin clean-up example ............................................................................................................................................... 16
Table 6: Properties of payment tokens .............................................................................................................................. 18
Table 7: Features of Generic and Easy token ................................................................................................................... 39
Figures
Figure 1: Visa Europe Payment Token Service onboarding process ...................................................................... 24

Visa Token Service About this guide
1 About this guide
1.1 Document purpose

This document provides information for Visa Europe issuers who want to take part in the Visa
Token Service.
Important This document should be read in conjunction with the Visa Token Service
Product Overview and the Visa Token Service Introduction for Issuers. These
documents, available on Visa Online, provide higher level descriptions of the
service and processes.
1.2 Audience
The primary audience for this guide is issuer and third party processor staff responsible for
client implementation of payment tokens and their integration with the Visa Token Service.
The reader should have knowledge of Visa Europe Authorisation Service (VEAS), Visa Member
Test System (VMTS) and Visa Test System (VTS/3).
1.3 Scope
This document provides
An introduction to the Visa Token Service
Implementation requirements and procedures for issuers who want to take part in the
Visa Token Service
Information on new and updated authorisation message fields that include token and
token related data
Additional information on the tools available for issuers to manage and support their
implementation of the service
Details of additional service documentation
1.4 Document organisation

This document contains the following sections:
Table 1: Document sections
Section Detail
About this guide This section contains general information.
About the Visa Token Service This section provides an introduction and overview of the Visa
Token Service. In addition, see the documents Visa Token
Service Product Overview and the Visa Token Service
Introduction for Issuers.
Implementing the Visa Token Service The section describes the processes and information required
to participate in the Visa Token Service, such as engaging with
service partners, preparing to implement and onboarding.

Section Detail
Cryptographic keys and key This section contains information on cryptographic keys used
management by the Visa Token Service.
Tools and methods for supporting the This section describes methods to support management of the
service service. These include a set of web services and online tools
available via Visa Online.
1.5 Related publications

The following documents are available on Visa Online:
About the Visa Token Service
Visa Token Service Product Overview

Visa Token Service Introduction for Acquirers
Visa Token Service Introduction for Issuers
Visa Token Life-Cycle Management (TLCM) User Guide
Visa Risk Manager - Getting Started
Visa Risk Manager - Rule Manager Token Authentication Rule User Guide
Visa Risk Manager - Rule Criteria Quick Reference Guide for Token Authentication Rules
Visa Token Reporting Services (VTRS) Issuer Reports User Guide
Other Visa Europe guides
Visa Europe Dual Message System Authorisation (DMSA) technical specifications

Visa Europe Dual Message System Clearing (DMSC) technical specifications
Visa payWave Transit Solutions Variable Fare - Issuer implementation guide
Visa File Exchange Service Token Bulk PAN Update
Important Updates to these documents are published as Business Enhancement News on
Visa Online.
Tokenisation enhancements published to date are available from the following:
October 2016 VisaNet Business Enhancements Global Technical Letter and

Implementation Guide Version 3.0
April 2016 VisaNet Business Enhancements Global Technical Letter and Implementation
Guide Version 3.0
April 2015 VisaNet Business Enhancements Global Technical Letter and Implementation
Guide Version 3.0
Member letters
Member Letter VE 01/15: Introduction of the Visa Token Service

Member letter VE 41/15 Availability of the Visa Europe Payment Token Service for Mobile
The following documents are available from your Visa Europe Relationship Manager:
Visa Europe Payment Token Service issuer web service interface development guide
Mobile Banking Authentication Code Technical Specification
The following documents are available from the EMVCo website:
EMV Payment Tokenisation Specification: Technical Framework version 1.0
1.6 Definitions
This document uses the following terms and definitions:
Table 2: Definitions
Acronym or term Definition

Application-based A type of transaction where a mobile application uses token-specific, chip-based
e-commerce authentication data within a mobile device to perform an e-commerce payment,
transaction without the need to request the cardholder to enter payment card data or use
card data previously stored on file.
BAU Business as usual
CAVV Cardholder Authentication Verification Value
CVK Card verification key
DKI Derivation Key Index
iCVV Integrated chip card verification value
LUK Limited Use Key
MDK Master Derivation Key
MIQ Member implementation questionnaire
OTP One time passcode
PCAS Positive Cardholder Authorisation Service
PCAS provides a set of risk control services that allow issuers to specify
transaction processing controls for authorisation requests. Issuers establish a set
of parameters (PCAS parameters) that determine when to route transactions to
the issuer for processing or to stand-in processing (STIP).
STIP Stand-in processing
TAR Token Activation Request
A modified ISO 0100 message used in the process of provisioning of a token,
sent by Visa Europe to the issuer to request approval of the token issuance.
Token assurance A value (created by the token service provider) indicating the confidence level of
level the payment token to PAN/cardholder binding. It is determined as a result of the
type of identification and verification (ID&V) performed and the entity that
performed it. The token assurance level is set when issuing a payment token and
may be updated if additional ID&V is performed.
Note Token assurance level is not currently supported.


Token domain Controls applied to a transaction by the Token Service Provider to ensure that
controls payment tokens are only used for the purposes for which they were issued.
Token or payment A token is a surrogate value used instead of the PAN in token-based
token transactions, for example Visa contactless transactions and application-based e-
commerce transactions. A token is a 13 to 19 digit numeric value that must pass
basic rules of validation, including the Luhn Mod-10 digit check. Payment tokens
are generated within a BIN range that has been designated as a token BIN
Range and flagged accordingly in appropriate BIN tables. Tokens may not have
the same value as or conflict with a real PAN.
A PAN may have several associated tokens.
Currently Visa Europe payment tokens are 16 digits in length. This may change
in the future.
Tokenisation The replacement of a PAN with a surrogate value (token).
TLCM Token Life Cycle Manager
An online tool, available on Visa Online for managing life cycle events for
payment tokens.
See 5.4 Token Life Cycle Management.
Token requestor A token requestor is an organisation that has registered with a Token Service
Provider to request payment tokens. These may typically be: digital wallet
providers, card issuers, card-on-file merchants, acquirers, acquirer processors
and payment service providers operating on behalf of merchants.
Token service An organisation providing and managing a payment token service. For Visa
provider Token Service Visa Europe is the token service provider.
Token vault A secure repository for storage of PAN and associated token data. When Visa
Europe receives an authorisation request for a payment initiated with a token,
we access the vault to look up the token to PAN link, verify the token domain
controls and retrieve the PAN.
UDK Unique Derived Key
Variable fare transit A transaction authorisation model developed by Visa Europe to allow
model cardholders to use Visa payWave in public transit systems. As the passenger
uses the transit system, terminals collect information about the Visa payWave
card or mobile device. Throughout the day, the data is sent to the transit
merchants processing system. At the end of each day, the transit merchants
processing system calculates the total daily fare and submits the transaction to
the acquirer for authorisation and clearing.
VEAS Visa Europe Authorisation Service
VRM Visa Risk Manager
A risk management engine within VTS. VRM is used to create token
authentication rulesets that allow Visa Europe to respond appropriately to token
provisioning requests on your behalf. This is done using the VRM Rules Manager
online tool, available on Visa Online.
See 5.3 Visa Risk Manager


VTRS Visa Token Reporting Service
An online tool available on Visa Online that provides reports to assist in token
portfolio maintenance.
See 5.5 Visa Token Reporting Service.
1.7 Document conventions

This document uses the following conventions:
Table 3: Document conventions
Convention Description
Important Highlights important text in the guide

Note Provides more information about a topic
Italics Indicates document titles
Italics in blue A cross reference to another part of this
document
1.8 For more information

For more information, contact your Visa Europe Relationship Manager.

Visa Token Service About the Visa Token Service
2 About the Visa Token Service
The Visa Token Service provides a number of benefits:
Promotes the development of new payment initiatives, such as Visa payWave contactless
transactions using a mobile device and application-based e-commerce transactions with
chip-based authentication data.
Reduces the complexity of introducing new payment mechanisms
Improves security by providing an enhanced approach to assessing the risk for payment
token transactions
Prevents cross-channel fraud by restricting the use of payment tokens to the channel(s)
for which they have been issued.
2.1 What are payment tokens

A payment token is a surrogate for a payment card that can be used in payment transaction
processing. Payment tokens are subject to controls that restrict how and where they can be
used. Table 4 shows payment token properties.
Table 4: Properties of payment tokens
Token property Details

Value The token value is a 13 to 19 digit numeric value that must pass the basic
validation rules of a PAN (including the LUHN Mod-10 digit check).
Payment tokens must not have the same value as or conflict with
cardholder PANs. The EMV Payment Tokenisation Specification: Technical
Framework version 1.0 defines tokens as following the same rules as PANS
and may have values between 13 to 19 numeric digits.
Note Currently Visa Europe payment tokens are 16 digits in length. This
may change in the future.
BIN ranges Payment tokens are generated within token ranges that have been
designated as a token BIN range and flagged accordingly in all
appropriate BIN tables.
Expiration date The expiration date of the token is generated by and maintained in the
token vault.
A token expiration date may be before, after or the same as the expiration
date of the PAN to which it is linked.
Token reference ID The token reference ID is unique for a token requestor. A token may be
uniquely identified either by the token value or the combination of token
requester ID and token reference ID.
Token requestor ID The token requestor ID is a value that uniquely identifies the token
requestor.

Token property Details

Token assurance level A value (created by the token service provider) indicating the confidence
level of the payment token to PAN/cardholder binding. It is determined as
a result of the type of identification and verification (ID&V) performed and
the entity that performed it. The token assurance level is set when issuing
a payment token and may be updated if additional ID&V is performed.
Note Token assurance level is not currently supported.
Token Cryptogram A cryptogram that is uniquely generated to validate token-based
transactions.
2.2 Visa product eligibility

Please refer to the Implementation Guide of the specific use case you are implementing
regarding product eligibility for specific token requestors.
2.3 Token type support

The Visa Token Service supports the following token types:
The e-commerce enabler token type is intended for use in browser-based wallets and
can be used to initiate a payment with any participating merchant, at any device from
which the consumer can access their wallet via a compatible internet browser.
A card-on-file token is intended for use at a particular merchant or payment processor as
a replacement for payment card details.
A secure element token is loaded on the secure element in a consumer device, such as a
mobile phone, tablet or wearable technologies such as a watch, ring or fitness band.
A device-based wallet token is issued for use via devices when a secure element is not in
use. Tokens stored outside a secure element for use in device-based wallets use the
cloud based payment (CBP) token type to support cloud based contactless and in-app
payments.
As part of your onboarding you will be set up for e-commerce enabler and card-on-file token
types. Appropriate tests cases will be provided as part of your implementation. For details,
refer to Articles 3.4 and 3.8 of the April 2016 VisaNet Business Enhancements Global
Technical Letter and Implementation Guide Version 3.0 and Article 5.21 of the October 2016
VisaNet Business Enhancements Global Technical Letter and Implementation Guide Version
3.0.
2.4 Use case support

Please refer to the Visa Token Service Product Overview for information on the use cases
supported by the Visa Token Service.
2.5 Token processing

All Visa payment token use cases require some level of basic solution development,
regardless of use case. The specific level of change required will vary based on your choice of
token processing option and the token types that you support. However, the core level of

implementation required to support the Visa Token Service (as described in this document)
can be re-used across multiple different use cases.
For full details of the messages used to process Visa token payment transactions, refer to the
Visa Europe Dual Message System Authorisation (DMSA) technical specifications.
2.5.1 Generic token processing

The Visa Token Service authenticates the token during each transaction and we provide you
with token data elements required for transaction processing and customer service.
You will need to certify to be able to receive token initiated transactions, to identify that a
transaction is a token transaction and to identify authenticated token data.
Generic token processing provides you with additional information to assist you further in
your decision. Refer to the Implementation Guide for each specific use case you are
implementing for further details.
Important You must certify to be able to receive token data in Field 123 and Field 125 tag
length value (TLV) format. This can be discussed further with your Client
Implementation representative.
2.5.2 Easy token processing

Easy token processing provides a subset of the Visa Token Service features with reduced-
effort implementation and minimal changes to host systems.
Important You should discuss your requirements with your Client Implementation
representative to ensure you choose the most appropriate processing option.
Important Certification is still required for Easy token processing. Test cases are a cut down
version of Generic token processing certification (e.g. no 0620s received in Field
123).
For a comparison of the options available in Generic token and Easy token processing, see
Appendix A Comparison of Generic and Easy token features.

Visa Token Service Implementing the Visa Token Service
3 Implementing the Visa Token Service
This section outlines the processes involved in implementing the Visa Token Service.
3.1 Implementation process

To begin the implementation process, contact your Visa Europe Relationship Manager.
3.1.1 Pre-onboarding
Pre-onboarding involves decision making and preparations for the formal onboarding
process:
1. You contact your Visa Europe Relationship Manager who will contact the Market
Readiness Team.
Note You will need to use a Token Requester in order to benefit from the full
functionality of the Visa Token Service.
2. The Market Readiness Team will contact you to arrange initial meetings to discuss and
formalise the approach to implementing the service:
Provide a technical presentation on tokenisation
Communicate a high-level milestone plan
3. We will ensure you have all relevant documentation that is available.
4. You must decide on a number of service considerations as outlined in 3.1.2 Service
considerations.
5. You begin the development work to ensure your own systems can support the service as
per the technical letter.
3.1.2 Service considerations

In planning your implementation of the Visa Token Service there are a number of important
considerations.
3.1.2.1 Token authentication rules

The VRM Rules Manager is an online tool that allows you to create a set of rules that define
how you want to handle token provisioning requests. You access the tool via Visa Online as
part of your onboarding and implementation phases and create rules based on your token
authentication rules and criteria. The rules are checked by Visa Risk Manager (VRM) during
token provisioning against the parameter values supplied by the token requestor and/or the
Visa Token Service.
You need to decide the rules that you want to use for token provisioning, then access the
VRM Rules Manager via Visa Online to set up your rules. We can provide guidance on the
typical rules you may want to create, but we do not specify or require any particular rules.
The token requestor may also have specific rules that they require you to use, which they
should share with you directly. See 5.2 Visa Card Metadata Manager.

3.1.2.2 Step-up authentication

When a cardholder requests provisioning of a token, the token requestor or issuer may
require some additional authentication of the cardholder. There are a number of options
available for step-up authentication for issuers that support the Visa Token Service API:
You send a Visa-generated one time passcode (OTP) to the cardholder by email or text
message and the cardholder enters this in the mobile app or digital wallet into which the
payment token is being provisioned. There is web service and ISO methods for this step-
up option.
The cardholder authenticates directly with your mobile platform and you provide an
activation code to the token requestor. Alternatively you activate the token directly.
The cardholder calls your call centre to provide authentication
Your call centre contacts the cardholder to request authentication
Issuers that have chosen not to support the Visa Token Service API for step-up authentication
have the option to receive a Visa-generated OTP in an 0100 authorization request in the
Merchant Name field, Field 43. Issuers must be able to provide the OTP to cardholders online.
See Table 4: Format of OTP in the Merchant Name field for details of the field format.
Issuers display the Visa-generated OTP to the cardholders account in the issuers mobile
banking application, from where it can be retrieved and entered in the Android Pay
wallet into which the payment token is being provisioned. Visa will validate the OTP and
notify the issuer of activation using an 0620 notification advice.
Issuers need to configure the URL of their mobile banking application in VCMM - 'step
up details' -> Support Activation via Auth -> Mobile / Online Banking URL.
You must choose which type or types to support. The token requestor may also have a
preference for the type of step-up authentication and the final choice may be a subject of
your negotiations with your token requestor partner.
Table 5: Format of OTP in the Merchant Name field
Field number and name Description

Field 43Card Acceptor This field will contain
Name/Location, CODE_NNNNNN_XXXXXXXXXXXXX, where:
positions 125 CODE = positions 14
NNNNNN = 6-digit access code generated by Visa in positions
611
Note When the authorization posts to the cardholder account, the
cardholder can retrieve the access code from the banking
online website or application.
XXXXXXXXXXXXX = Up to 13-character wallet descriptor in
positions 1325, left-justified
Note The wallet descriptor is the digital wallet that initiated the
authentication request
You must choose which type or types to support. The token requestor may also have a
preference for the type of step-up authentication and the final choice may be a subject of
your negotiations with your token requestor partner.

3.1.2.3 Design and implement your payment token solution

Taking part in the payment token service may involve some development work to ensure
successful interaction with the Visa Token Service. The nature of your development depends
on:
If you will use Visa Token Service API to support the service.
See 5.1 Web services. You will need to develop your web service interface to
specifications set out by us. See 1.5 Related publications.
Being able to receive and process new or updated data fields in a number of ISO
message types. You will need to update your systems to process these messages, some
of which contain new or updated fields or field values
Note For a summary of the usage of ISO messages in the Visa Token Service, see the Visa
Token Service Introduction for Issuers. For full details of the format of these
messages, see the Visa Europe Dual Message System Authorisation (DMSA) technical
specifications.
3.1.2.4 Choose BINs to enrol in the service

You must choose the BINs to enrol in the service. These are the BINs that will be eligible for
tokenisation.
Note Some BIN related activities may be required. These include, but are not limited to,
installation of new MDKs and confirmation of CVV2 expiry date format. New CVK /
C2Ks are not required if they have already been shared, and WSKs are only required
in specific API cases.
Important The Visa Token Service is activated at the PCR and BIN level. If you are also an
acquirer and are using the same PCR for acquiring and issuing, you must certify
as an active acquirer. See the Visa Token Service for Acquirers Implementation
Guide, available on Visa Online.
3.1.2.5 BIN clean-up

Account ranges must not be split past the 9th digit. This means that the low range must have
0s for digits 10-16, and the high range must have 9s for digits 10-16.
Example below:
Table 6: Bin clean-up example
6 DIGIT LOW RANGE HIGH RANGE

BIN (000-999) (000-999)
400001 000 0000000 005 9999999
400001 100 0000000 100 9999999
If account ranges are split past the 9th digit these will need to be either reduced or expanded
so they meet the requirements above. Your Implementation Consultant will do account range
analysis for the BINs which you submit in the MIQ.

3.1.2.6 Token account range assignment

Visa Europe will assign token account ranges (9 digits) for all corresponding active card
account ranges i.e. account ranges on which you currently issue cards or plan to issue cards
in the next 12 months. Your Implementation Consultant will be able to provide you with an
extract of which account ranges have seen transactions in the last 12 months. Any unused
PAN ranges will be closed.
3.1.2.7 0100 token activation requests

When the token requestor submits a request to provision a token for a cardholder, you will
receive an ISO 0100 token activation request (TAR) message to which you must respond
accordingly.
When processing TARs, you should check the information provided, including CVV2 data and
card expiration date before making an authorisation decision. TARs also contain an indication
of the results of rules processing. See 5.3 Visa Risk Manager to assist you in your decision.
Your response (in the form of an ISO 0110 message) will be to approve provisioning of the
token, decline provisioning of the token or request that additional authentication is
performed before the token is activated, depending on your defined risk criteria.
You will need to support some or all of the following response codes in Field 39 of your ISO
0110 TAR response messages depending on the requirements of the token requestor, as they
may require the return of specific response codes (marked as Conditional in the following
table).
Note All response code values other than 00 and 85 are handled by the Visa Token Service
as a decline of the token provisioning request.

Table 7: Properties of payment tokens
Field 39 Description Support Notes

value Required
00 Provision and activate Mandatory The token provisioning request is

approved by the issuer. Further
authentication is not required before the
token can be made active.
05 Do not provision Mandatory The token provisioning request is not

approved by the issuer (general decline)
52 No current account Conditional The token provisioning request is not

approved by the issuer (specific decline
when the card account linked to the PAN
has been closed)
54 Expiry date incorrect Conditional The token provisioning request is not

when the expiry date provided is
incorrect)
85 Provision in inactive Mandatory The token provisioning request is

state; requires further approved by the issuer. The token can be
consumer provisioned to the device in an inactive
authentication prior to state but further authentication is
activation required before the token can be made
active.
N7 Decline for CVV2 failure Conditional The token provisioning request is not
when the CVV2 is incorrect)
3.1.2.8 STIP token notification advices

On some occasions we may receive a token provisioning request linked to one of your
payment cards that we decline on your behalf (for example if you have already told us that
the card has been lost or stolen). In such cases we will inform you of our action in the form of
an 0120 STIP token notification advice message, with a new value included in Field 63.4 to
indicate that the token provisioning request has been declined by the Visa Token Service.
Alternatively, should you have a BIN set up to receive advices in the TC48 of the Clearing File
rather than an 0120 ISO message, you will be notified that Visa has declined a provisioning
request in the TC48 instead.
We will make provisioning decisions on your behalf in these cases:
You have defined rules in VRM that result in a deny or retry action
You do not respond in the TAR processing time frame of 2.0 seconds and have defined
specific STIP token provisioning rules in VRM

Note See 5.3 Visa Risk Manager for more details about VRM rules
You must ensure that your system is able to receive the new fields and values defined for
these STIP advices.
3.1.2.9 0620 token notification advices

You may choose to receive token notification advice messages, indicating when the state of a
token has changed (for example, the token has been activated, suspended, resumed or
deleted, or the PAN or PAN expiry date mapped to the token has changed).
Note For cloud-based implementations, 0620 are also used to let issuers know the Limited
Use Keys (LUK) have been replenished.
If you choose to receive token notification advices, then you must ensure your systems are
able to receive ISO 0620 messages and you must be certified by Visa Europe to receive them.
Important To receive 0620 token notification advice messages, you must receive your STIP
advices as 0120s. You must be certified by Visa Europe to receive 0120 STIP
advice messages.
3.1.2.10 TC 33 token advice reports

You may choose to receive TC 33 token notification results instead of 0620 token notification
advice messages. This report is generated daily for subscribing Issuers and delivered in the
standard file delivery schedule. It contains details of all the 0620 token notification advices
received in the last report period.
Report content is configurable per Issuer, using the VECSS UI, to either include or exclude the
following advice groups at a BIN level:
Token provisioning events (activation, all step-up authentication flows other than call
centre activation, device provisioning)
Tokens Lifecycle event (deactivate, suspend, resume, call centre activation)
Tokens PAN maintenance event (PAN Replacement / Expiry Date update)
Note LUK refreshes, used in cloud based implementations, are not included in these
reports.
You will be required to provide the following to initiate subscription:
Issuer BIN subscription (to identify the subscription options)

Delivery CIB (the address to be used to deliver the TC 33 record notification)
Note No testing is required in order to implement TC 33 token advice reports.
3.1.2.11 0302 token maintenance file requests

If you choose to perform token life cycle actions using 0302 messaging, then you must
ensure your systems are able to send the requests and process the responses and you must
be certified by Visa Europe to use them. See 5.4.1 Token life cycle event types for a description
of the token life cycle actions that may be undertaken.
Note 0302 messaging is not available for Easy token issuers, as it requires support for
Field 123 token data.

3.1.2.12 0100 transaction authorisation requests

The Visa Token Service ensures that payment tokens are only used for the purposes for which
they were issued through the enforcement of token domain controls. The Visa Token Service
will have identified the PAN associated with the token that was presented, and this will be
present in the transaction authorisation request as it is for non-token transactions. However,
these authorisation requests will also contain fields or field values that are specific to
payment token processing. For example, the request will also include details of the token,
indicators that this is a token transaction, and result codes that show the outcome of token
and transaction verifications such as CAM and iCVV. See 4 Cryptographic keys and key
management.
Token transactions must be authorised online, regardless of any floor limit overrides for non-
token based processing.
Business rules that enable merchants to override floor limits are not permitted for token
transactions. Token transactions are not permitted to be cleared without gaining an online
authorisation.
Authorisation response codes are returned by issuers in Field 38 of 0110 authorisation
response messages which are in turn submitted by acquirers in clearing transactions.
Important Submitted transactions that do not carry a valid online authorisation response
code will be rejected during clearing processing (by EditPackage or by VECSS).
For details of invalid/offline authorisation response codes for token transactions, refer to the
Visa Europe Dual Message System Authorisation (DMSA) technical specifications.
You must ensure that your systems are able to identify token-based transaction authorisation
requests and process them accordingly.
3.1.2.13 Token life cycle management

You have a choice of methods for managing the status of payment tokens:
ISO 0302 messages via the Visa Europe Authorisation Service

Integrated web services via the Visa Token Service Lifecycle Management API
Note The Visa Europe Payment Token Service Lifecycle Management API is only
offered on an exception basis. Contact your Client Implementation
representative to discuss availability.
Token life cycle management tool (TLCM) via Visa Online
You must decide the methods you want to use and assess the impact this will have on your
development program. See 5.4 Token Life Cycle for more information on these options.
3.1.2.14 PCAS parameters review

The same PCAS parameters apply to token initiated payment transactions as the card
equivalent that was used to create the token. If you want to make changes to your PCAS
parameters please let us know during the implementation phase.

3.2 Testing and certification

Certification for the Visa Token Service consists of running a combination of online and
offline test cases. Your implementation consultant will provide you with the relevant test
cases. A PAN is required per funding source (e.g. credit/debit).
Note The token requestor organisation is not involved in this stage.
Test cases will be run:
Offline by the issuer using the Visa Test System (VTS/3) tool, connecting this directly to
the host and providing the application logs to the implementation consultant.
Online, initiated by Visa Europe using the Visa Member Test Service (VMTS). VMTS is a
test environment that simulates (as closely as possible) the Visa production environment.
Visa Europe validates test results to verify that you can successfully perform specific
transaction processing requirements particular to each Visa service. Once certification has
been passed, Visa Europe can activate the service in production (go live).
Important Go-live must happen within 6 months of being certified.
For web service testing please see 5.1.2 Web service testing.
3.2.1 Sample test cases:

Authorisation:
The following ISO messages can be tested online:
0100/0110 POS authorisation

0100/0110 token POS authorisation
0100/0110 token in-app
0302/0312 life cycle management
0120/0130 STIP advices for token POS transactions
0400/0410 token reversal
The following ISO messages can be tested offline:
0100/0110 token activation request (TAR)

0620/0630 advices
0120/0130 STIP advices for token activation requests (TAR)
Clearing and Settlement:
The Visa Europe Clearing & Settlement Service will be tested as per the standard process but
with token information present.
1. Visa Europe will raise an acquiring outgoing file containing Token POS transactions. The
outgoing file will contain the financial PAN in the TCR 0. The Token PAN will be placed in
the TCR 5.
2. The issuer processes the incoming file and returns chargebacks ensuring that the token
PAN in TCR 5 is retained and returned in the chargeback.

3.2.2 Entry criteria for testing

Host certification for issuers
You must have provided all required data for testing

PAN/Expiry date/CVV2 for creating a token
VCMS host station
PCR
CIB
MIQ
Physical plastic contactless chip card for regression testing, created with the test
keys
Your test host systems must have been modified to support the Visa Token Service
All test cases essential to assessment of the exit criteria have been agreed between you
and Visa Europe.
You must supply a list of all known issues that may have an impact on testing
3.2.3 Exit criteria for testing

Exit criteria for both phases include:
All critical and previously agreed test scenarios are executed and evaluated
Any defects or failed test scenarios have been evaluated and risks have been accepted,
based on requirements and risk tolerance, that the service can be taken into a
commercial phase
3.2.4 Keys
Visa Europe recommends issuers to use the Visa test keys for certification. These can be
found at the bottom of the Visa Token Service (VTS) member implementation questionnaire
(MIQ).
Note In addition to the transaction processing testing, regression testing also takes place
where applicable.
3.3 Onboarding
The main onboarding process will begin when all pre-onboarding activities and development
projects have been completed. This process involves several Visa Europe teams working in
parallel:
The Client Implementation team:
Collects the required information for setting up service parameters and card
metadata in the test and live environments.
Manages token-related BINs and cryptographic keys, and handles any modifications
required (by both Visa Europe and you as an issuer)
Provides you with access to service management tools on Visa Online
Provides you with access to the test web service platform if required
Prepares for client testing. See 3.2 Testing and certification

If you choose to use the Visa Token Service API to manage your service, our
development support team works with your development teams to configure and set up
the web service connections into it
Note On completion of successful testing the service goes live to allow you limited
end-to-end testing of the complete service before it is released to consumers.
Figure 1: Visa Token Service onboarding process provides a high level view of this process.

Figure 1: Visa Token Service onboarding process

Visa Token Service Cryptographic keys and key management
4 Cryptographic keys and key management
The Visa Token Service requires the use of a number of cryptographic keys. This section
describes these changes.
Some of these keys are new and are used as part of processing related to the payment token
service. Certain keys do not need to be shared with the issuer/processors.
4.1 Cryptogram (AC MDK)

Token transactions are authorised online and Visa Token Service verifies the cryptogram (AC)
returned by the mobile payment application as part of the de-tokenisation and domain
control checking process.
For contactless payment transactions, the processing at POS is identical to that for a standard
Visa payWave contactless transaction, including the generation of the application cryptogram
(specifically, an ARQC for an online qVSDC transaction).
Application-based e-commerce token transactions generate and use the application
cryptogram in a different manner to Visa payWave contactless transactions. A Cardholder
Authentication Verification Value (CAVV) is generated by the mobile payment application as
part of a token transaction. The mobile payment application encrypts the CAVV (along with
other data) before forwarding it to the merchant who passes it to the acquirer. The acquirer
forwards it to the Visa Token Service in the authorisation request (Field 126.9, Usage 3
(Version 3) CAVV Data).
As with contactless payment transactions, the Visa Token Service performs the verification
during de-tokenisation and sends the verification result to the issuer. The issuer will not
receive the CAVV value and therefore doesnt need to validate it.
Visa will generate an AC MDK key and store this in the Visa Token Service. Visa will assign a
unique DKI for this MDK to be used exclusively for tokenisation. The DKI assigned will be
decided during implementation to make sure it is not already being used by the issuer. The
same MDK can be used for secure element and cloud based payment tokens.
4.1.1 Secure element (SE) implementation:

The application cryptogram (AC) is generated from a Unique Derived Key (AC UDK) stored in
the token profile, which is, in turn, derived from the master key (AC MDK).
Visa Token Service generates the AC UDK during token provisioning and verifies the AC
during de-tokenisation. The issuer does not need to have the AC MDK key installed in their
system as Visa will send the card authentication result to the issuer in the authorisation
request. The AC is not sent in the authorisation request for the issuer to check.
4.1.2 Cloud based payments (CBP) implementation:

For cloud based payment implementations the Application Cryptogram (AC) is generated
from a Limited Use Key (LUK) stored in the token profile. The LUK is derived from the UDK
(Unique Derived Key) using an Account Parameter Index (YHHHHCC); this is the time stamp
of the LUK, where Y=the last number of the year (for example, for 2016, Y=6), HHHH=the

number of hours since the beginning of January of that year (up to the end of the first hour
Y=1, up to the end of the second hour Y=2 etc) and CC=the count of the number of LUKs
generated within that hour. The UDK is derived from the master key (AC MDK).
Visa Token Service will check the AC and send the card authentication result to the issuer in
the authorisation request. The AC is not sent in the authorisation request for the issuer to
check.
4.2 iCVV keys

The Integrated Chip Card Verification Value (iCVV) is usually stored in a payment cards chip
and protects against chip card data being used in a counterfeit magnetic stripe card to make
transactions.
In standard chip card issuance you generate (or we generate on your behalf) a card
verification key (CVK) for use in iCVV generation during personalisation of the card and in
card verification during transaction processing. Issuers who use the Visa Card Verification
Service share the CVK with us.
During personalisation of a payment token the iCVV is generated using your CVK held by the
Visa Token Service and personalised into the mobile payment application during token
provisioning.
You must share your existing CVKs and any new CVKs with us as part of implementation, as
these keys are used during both token provisioning and token-based contactless
transactions.
When a cardholder initiates a contactless transaction with a payment token the payment
token service verifies the iCVV received in the authorisation request. This is part of the de-
tokenisation process and we pass the result to you when we forward the request.
Note The token transaction will be processed in the same way as a chip based transaction.
Depending on your CVV option, Visa may forward you the iCVV result or decline the
transaction.
4.3 CVV2 keys (C2K)

In standard ecommerce transactions, you need a Card Verification Value 2 Key (C2K),
generated by you or Visa Europe. The C2K is used in CVV2 generation during personalisation
of the card and in verification during transaction processing. Issuers who use the Visa Card
Verification Service share the C2K key with us.
When a cardholder requests provisioning of a payment token to their mobile device / digital
wallet they enter their CVV2 and we always verify this value as part of the token provisioning
process. 1
1
These actions do not occur for cards that do not have a CVV2.

Note CVV2 checking in the Visa Token Service allows a number of different incorrect
values to be entered for the same card number within a period of one hour (token
provisioning will fail, but the cardholder can try again). After the limit is reached, an
incorrect CVV2 value causes an online fraud item to be created. When the limit is
exceeded for a given card, all transactions that pass through the Visa Token Service
for the card number in question are declined in STIP for one hour, after which the
online fraud item is expired automatically.
You must ensure that the C2Ks and their related expiry date format held by us are up-to-date
as Visa always validates CVV2 during token provisioning. You must also ensure that you
advise us of the expiry date format you use to calculate CVV2, for example, MM/YY or
YY/MM.
4.4 ODA certificates and key pairs
4.4.1 Offline transactions and online with ODA transactions

Transactions initiated with payment tokens must be processed online. Therefore, offline
approval of transactions is not supported for payment tokens. However, online with ODA
transactions are supported (these are typically used in deferred authorisation, variable-fare
transit processing).
Note For more details of issuer responsibilities when supporting variable fare acceptance
for public transport systems see the Visa payWave Transit Solutions Variable Fare
Member implementation guide.
All tokens intended for use within the Visa Europe region will be provisioned with support for
ODA. This enables online with ODA transactions that are required in variable fare acceptance
models. For ODA to be successfully supported, each payment token must be provisioned
with the standard ODA keys and certificates.
The ICC and issuer keys and certificates are fully managed by the Visa Token Service. You do
not need to create new key pairs or certificates.
4.5 Web service security

If you are using the Visa Token Service API (see 5.1 Web services) to manage your
implementation of the payment token service, you will need to comply with our web service
security requirements.
4.5.1 Connecting to the Visa Europe Payment Token Service API

The following security requirements apply when connecting to web services hosted by Visa
Europe (currently token life cycle management and card metadata updates):
Use SSL/TLS for exchanging messages with Visa Europe

Authenticate using two factor authentication:
Authentication credentials (system account ID and password) passed in the HTTPs
Basic Authorisation header
An SSL/TLS X.509 Visa Client Certificate linked to the identity supplied in the
Authorisation header

Authentication credentials will be provided by Visa Europe. These credentials are

different for the VCM/CTE/Sandbox environment and the Production environment.
The following security requirements apply when Visa Europe is connecting to web services
hosted by you (currently eligibility checking, cardholder verification method selection and
sending of OTP):
Transport Security
All Services must use SSL/TLS for exchanging messages with Visa Europe.
SSL/TLS X.509 Client Certificates
All Services must use mutual authentication (2-way SSL). Use of established and
recognised public Certificate Authority may be considered.
You must whitelist the Visa Europe external IP addresses, which we will provide to you
Full details for connectivity are provided in the document Visa Europe Payment Token Service
issuer web service interface development guide.
4.5.2 Web service data encryption and decryption keys

When you exchange sensitive information in the Visa Token Service API, this data must be
encrypted. Visa Europe has defined a new data encryption key for this purpose: the WSD data
encryption key. This key is defined in the Visa Europe Payment Token Service issuer web
service interface development guide.
4.6 Mobile banking app step-up authentication

Note Use of a mobile banking app as a step-up authorisation method is available as an
option. It can only be tested with a token requester. If applicable, see your relevant
token requester implementation guide for details.
One method of step-up authentication supported by the Visa Token Service is verification of
the cardholders credentials through your mobile banking app. See the Mobile Banking
Authentication Code Technical Specification for additional information. After the cardholder
has been authenticated via your mobile banking app and the payment token information has
been obtained from the token requestor or digital wallet, there are two ways to activate the
provisioned token:
Option 1 Cryptographic OTP (an activation code)

The activation code is generated by your server and encrypted using the web services
data encryption key (WSD key), and is then sent to the mobile banking app. This in turn
sends it to the token requestor (via the digital wallet) which forwards the activation code
to Visa Europe for decryption. Once decrypted, the token(s) identified in the request are
activated in the vault.
Option 2 Token life cycle request
Token activation is performed by a direct request from you to the vault using either the
Visa Token Service API or an 0302 token life cycle message.
If you choose Option 1 you must use a WSD key generated either by Visa Europe (the
preferred approach) or by yourself. This key is exchanged using a zone control master key
(ZCMK) as part of the implementation process. This WSD key is the same key which is used

for securing data in the Visa Token Service API. See 4.5.2 Web service data encryption and
decryption keys for further information.
If you choose Option 2 there is no need to use a WSD key for this specific token life cycle
request (but it may still be in use for other requests affected using the Visa Token Service
API).
See the Mobile Banking Authentication Code Technical Specification and the Visa Europe
Payment Token Service issuer web service interface development guide for more information.
4.7 Zone control master key (ZCMK)

Visa Europe uses ZCMKs for exchanging keys such as CVK, IWK, WSDK in a secure manner.
ZCMKs may already be in place for your organisation and could be used to transport a WSDK
if required.

Visa Token Service Tools and methods for supporting the service
5 Tools and methods for supporting the service
The Visa Token Service provides a number of tools and methods to support management of
the service. These include a set of ISO messages and a number of online tools available on
Visa Online.
5.1 Web services

This section outlines the set of web services to support the management of payment token
processes.
Web services can be used to:
Authenticate a cardholder who has requested provisioning of a token on their mobile

device / digital wallet
Provide identification of card art profile and other metadata to be used during
provisioning
Provide the list of methods to be offered for cardholder step-up authentication, for
example the tenured channels to be used for OTP delivery
Deliver the OTP to you for ongoing transmission to the cardholder
Submit token life cycle commands
Retrieve the list of tokens related to a particular PAN
Retrieve the details of a specific token
The web services are implemented in the Visa Token Service API. The rest of this section
provides a summary of the functionality that they support.
For full details of the web services, API specifications, security and connectivity requirements
see the Visa Token Service Issuer Web Service Interface Development Guide.
5.1.1 Web service summaries
5.1.1.1 Consumer Authentication (Check Eligibility) Web Service

This service allows you to:
Pre-screen a cardholder who is about to start provisioning of a payment token

Provide a reference to the card art and terms and conditions (T&Cs) that are to be used
during provisioning of a payment token for a specific cardholder PAN
Capture the unique Token Reference ID that can then be used in subsequent calls to the
Visa Token Service API (for example, when sending a token life cycle request to the Visa
Token Service) instead of using the token value itself
Note Participation in this API is optional. You can decide to provide all of the required
metadata information to Visa Europe in advance and allow the Visa Token
Service to select the appropriate card art and terms and conditions during token
provisioning.

All three functions described above are optional. You may opt to use a subset of the
described functions.
5.1.1.2 Get Cardholder Verification Methods Web Service

This service enables you to provide a list of the methods of cardholder step-up
authentication that you support and the linked data for each method. For example, you can
indicate support for OTP and provide the cardholders email address and mobile number to
allow them to pick their preferred destination of the OTP. You can also indicate support for
step-up authentication via a mobile app or via your call centre.
5.1.1.3 Send Passcode Web Service

This service is used to deliver the OTP to you for onward delivery to your cardholders
selected destination (e-mail address or mobile number). The OTP is generated and checked
by the Visa Token Service. You only have to ensure it is successfully transmitted to your
cardholder using the tenured data that you hold.
Note This service is only used if you support OTP as a step-up authentication method.
5.1.1.4 Submit life cycle command web service

This service enables you to send a token life cycle command request to the Visa Token
Service. The actions you can take on a payment token are:
Activate, Resume, Suspend or Delete the payment token

Update the PAN and/or PAN Expiration Date linked to the payment token
Note You can choose whether or not to use the web service for token life cycle
management. These functions can also be performed using ISO messaging (see
3.1.2.11 0302 token maintenance file requests) and the TLCM tool (see 5.4 Token Life
Cycle Management.)
5.1.1.5 Token inquiry web service

This service enables you to retrieve information about your payment tokens held in the Visa
Token Service. You can perform a token inquiry to:
Retrieve a list of all the payment tokens associated with a particular PAN
Retrieve all the details of a specific payment token
5.1.1.6 Update card metadata web service

Note The use of this web service only applies to digital wallet based token types. Its use
may vary by Token Requester. Please refer to the Visa Token Service use case
Implementation Guides for usage by individual Token Requesters.
This service enables you to update card metadata associated with payment tokens already
provisioned to a mobile device / digital wallet. For example, after initial successful
provisioning of a payment token, the cardholders product is changed. You may take
advantage of this service to change the card art image in the mobile device / digital wallet
without requiring re-provisioning of the payment token. The new card art must be loaded by

Visa Europe after which you will be provided with the unique ID which you must reference in
the API request.
Note You can update the Terms and Conditions URL held in the mobile device / digital
wallet for a previously provisioned payment token. However, there is currently no
mechanism for performing and handling consumer acceptance of those updated
Terms and Conditions and the subsequent communication of that acceptance to the
payment network. If you require a record of the consumers acceptance of updated
Terms and Conditions for an already provisioned payment token, you must take
steps to delete the payment token from the device and initiate re-provisioning of
the PAN.
5.1.2 Web service testing

Web services are tested in the following environment:
Test environment also referred to as VCMS / CTE

The test environment simulates production. The issuer will provide PANs they want to
use for web service testing. Visa Europe will generate test tokens for PANs provided.
These tokens will be used in:
Get verification methods and send passcode API requests initiated by Visa Europe
Submit life cycle, token inquiry, and update card metadata end life cycle management
API requests initiated by the issuer.
Issuer hosted web services (check eligibility, get verification methods, and send
passcode) require attended testing, for which a test slot needs to be booked with your
Implementation Consultant.
Visa hosted web services (submit life cycle, token inquiry, and update card metadata) can
be tested by the issuer unattended once configuration is complete and tokens have been
generated for PANs supplied.
Web service testing requires the following:
Web service test environment configuration must be complete
Certificates in place
URLs, IPs and ports shared
IP addresses whitelisted on issuer side (if applicable)
WSD key installed (if applicable)
5.2 Visa Card Metadata Manager

The Visa Card Metadata Manager (VCMM) tool is an online tool to help manage card art
configuration, terms and conditions and other metadata at account range level for tokenised
BINs. The configured card art images, terms and conditions and metadata will be used by the
token requestor to render terms and conditions during a token provisioning request and
render the card art image in the consumer mobile device when provisioning is complete.
5.2.1 VCMM Functions

VCMM allows you to:

Upload card art images

Group card art images into card art groups for issuance to mobile devices during token
provisioning
Upload issuer terms and conditions for display to the consumer during token
provisioning
Upload customer contact information, mobile banking app information (for step-up
authentication), transaction notification configuration, website URLs and other metadata
Assign card art, terms and conditions, contact information and other configuration data
at the card account range level
Run reports to validate card metadata assignments that can also be filtered or easily
sorted
Note When a card in a specified card account range is provisioned on a mobile device the
metadata is applied to the app installed on the device.
Note Website URLs must be configured for HTTPs. This is enforced by VCMM.
Note Changes to an issuers card art configurations in VCMM takes up to six hours to take
effect. Card art loading from VCMM to the Visa Token Service occurs every six hours,
effective at 01:00, 04:00, 10:00, 14:00 and 20:00 GMT. Changes are subject to these
load times.
5.2.2 Access to VCMM

VCMM is available on Visa Online. You ask for access for your users during onboarding, using
the MIQ to identify the users. Your local Visa Online Access Manager can request access to
be granted to the Visa Online IDs of your identified VCMM users. Users granted access will
find a link to the tool in their list of services.
5.2.3 Browser support for VCMM

Visa Europe supports Internet Explorer version 9 or above, Google Chrome (last four updates)
or Firefox (last four updates) for VCMM.
5.2.4 VCMM documentation

Full details of the application can be found in the Visa Card Metadata Manager (VCMM) User
Guide for Issuers.
5.2.5 Uploading card art

It is the issuers responsibility to only upload card art that is compliant with Visa Europe
branding guidelines. After uploading card art the issuer should submit a copy of the PNG to
veptscardart@visa.com for audit purposes.
5.3 Visa Risk Manager

When Visa Europe receives a request to provision a token for a cardholder, the details of the
request are checked against a set of rules that assist in defining how to respond to process
the request. You create rules, based on your own risk assessment criteria, using the VRM
Rules Manager application. Possible outcomes from the token authentication rules check may

be to decline the request, forward the request to you for approval or to request further
authentication of the cardholder.
5.3.1 Rule outcomes

When a token request is checked against your rules there are a number of possible
outcomes:
Approve/Forward the request

For all issuers, we forward the Approve/Forward result in an ISO 0100 Token Activation
Request (TAR) message to you
Deny
Visa Europe rejects the request on your behalf, forwards the result to the token requestor
and sends you a token advice message via ISO 0120 or TC48, depending on your
configuration.
Retry
The token requests should be retried by the cardholder. This action only applies to rules
with the CVV2 Result Code parameter and is intended to allow consumers to retry
entering their CVV2. We reject the request, forward the result to the token requestor and
send you an ISO 0120 token advice message.
Request More Information
For all Visa Europe issuers, VRM forwards the Request More Information result in the ISO
0100 Token Activation Request (TAR) message to you. This indicates that your rule set
recommends step-up authentication should be performed by the cardholder before the
request is approved.
5.3.2 Guidance on VRM rules for token provisioning

Important It is important that you understand the effect that your rules have on token
provisioning requests before you implement them. Changes to rules go live
within 15 minutes (after the necessary approval has been given by your rules
administration manager in the VRM Rules Manager tool).
The VRM rule engine is very flexible. It allows you to define rules based on complex criteria
and operators, and across more than twenty parameters. Many of the parameters are also
passed to you in Field 125 of 0100 TAR messages, so you may also choose to fully perform
your token provisioning decision logic within your host system if preferred, or you may
choose to divide the logic up between the VRM rule engine and your host system. This is
entirely at your discretion, noting that the rules engine will inform you of the action either
taken or recommended on a token provisioning request, but will not inform you of the exact
rule that was triggered during each request.
For example, you may allow the VRM rules to reject all token provisioning requests with a low
token requestor account score rather than ask your host system to decide. Your host system
will receive an advice notification when such an event happens.

Note For Easy token provisioning, the outcome of the VRM ruleset outcome will override
an Approve TAR response where the outcome is not also Approve. This enables
you to fully utilise the capabilities of the VRM rules engine even though you receive
only minimal data in the TAR request.
The documents listed in 5.3.5 Visa Risk Manager documentation for token authentication rules
provide full information on how to set up token provisioning rules and what each parameter
contains. You should also refer to all relevant Visa Europe Risk Best Practice Guides, available
on Visa Online, as part of your product risk assessment. However, the following describes
some examples of VRM rules you may typically want to set up:
CVV2 Retry
If the CVV2 value entered by a cardholder is incorrect you can use a VRM rule to return
the token provisioning request back to the token requestor immediately, without having
to perform or repeat the CVV2 validation check yourself.
Maximum number of tokens for a card/PAN
You can set up a rule to limit the maximum number of tokens that can be added to
different devices for the same card/PAN. This may be a limit imposed by you or by the
token requestor.
Token requestor(s)
The token requestor ID is provided in all token provisioning requests, making it possible
for you to write a rule which applies only to specific token requestors.
Provisioning STIP rules
In cases where your host system is unavailable (for example, due to timeout or system
malfunction), and the token provisioning request falls into STIP, the VRM rule engine
allows you to pre-define a response. It is the banks choice if they want to approve,
decline, or request more information for token provisioning request in STIP.
Important You should not write rules that specifically exclude eCommerce enabler or Card
on File token types from being provisioned (see section 2.3 Token type support).
You may still decide to exclude specific token requestors dependent on local
market restrictions or conditions.
When no VRM rules are triggered during a token provisioning request, the default action that
you set up in VRM is used to indicate what should be done. The default action is not a rule in
itself but defines what you want to happen if no rules are triggered. The default action should
be set to forward you the 0100 TAR message to enable you to make the token provisioning
decision using logic in your host system.
We recommend that you test out different ruleset scenarios during your live proving/testing
to ensure that you are comfortable with the outcomes and effects of your ruleset upon your
overall token issuance profile. We also recommend that testing of your rulesets becomes a
BAU activity and not something confined to the implementation cycle.
Note During live proving (see section 3.2 Testing and certification), Visa Europe may
suggest implementing some basic VRM rules to enable initial testing to be
performed, which you can then modify later in the live proving phase or before
launch. For guidance on, see the VRM Quick Guide, available on VOL

You may also run the rule reports available within VRM Rules Manager, for example to see
the performance of your ruleset across your token portfolio. Some of these reports require
historical data to build up over time so the reported rule performance statistics have
meaning. For this reason, you will need to allow your ruleset under test to be used for a long
enough period to allow historical data to be generated and stored.
5.3.3 Access to VRM Rules Manager

The VRM Rules Manager is available on Visa Online. You ask for access for your users during
implementation, using the MIQ to identify the users. Your local Visa Online Access Manager
can request access to be granted to the Visa Online IDs of your identified VRM Rules
Manager users. Users granted access will find a link to the tool in their list of services.
There are two types of user:
Administrator
Administrators have full use of the application. We will set up administrators who will be
able to assign user roles to other users (including further administrators). You must
supply relevant IDs and user names via the MIQ during implementation.
User
Users can add or change rules. Those with the necessary permissions can also approve
rules before they are activated in the system.
5.3.4 Browser support for VRM Rules Manager

Currently, Visa Europe only fully supports Internet Explorer version 9 for VRM Rules Manager.
Later versions of Internet Explorer may be used but the Compatibility View setting must be
enabled in the Tools menu. The Google Chrome and Firefox browsers are not supported at
all.
5.3.5 Visa Risk Manager documentation for token authentication rules

Full details of the application can be found in the following documents:
Visa Risk Manager- Rule Manager Token Authentication Rule User Guide
Visa Risk Manager - Getting Started
Visa Risk Manager Rule Criteria - Quick Reference Guide for Token Authentication Rules
5.4 Token Life Cycle Management

This section describes the tools and methods available for you to manage token life cycle
events.
5.4.1 Token life cycle event types

A payment token can be fully managed through the course of its life via a number of life
cycle events. The available token life cycle events are:
Activate a token
Following successful verification of the cardholders identity the payment token
provisioned on their device is activated.

Suspend
If a cardholder has lost their device but is unsure whether this is permanent and that the
payment token may not be compromised they may want to only suspend its use
temporarily.
Resume
Following suspension a cardholder may want to re-activate (that is, unsuspend) the
payment token.
Note Currently in the Visa Token Service, only the entity who has requested the
suspension of a token can submit a resume request. For example, if an issuer
suspends a token as a result of suspected fraud, only they can submit the
resume request. If the cardholder submits a request (via their token requestor)
for the token to be resumed, the service denies the request. This behaviour will
change in a future release.
Delete/de-activate
If the customer has lost their device or suspects that the token has been compromised,
they may want to deactivate the payment token to prevent further use.
Update PAN expiry date
For issuers who need to update the expiry date of a tokenised PAN, for example when a
PAN has been re-issued.
Replace PAN for token
For an issuer who wants to replace the PAN associated with a token or set of tokens.
5.4.2 Options for managing token life cycle events

The Visa Token Service provides a number of methods for managing token life cycle events.
Important Certain options require support for Field 123 token data (0302 messages) or
significant implementation effort (web services and 0302 messages). As such,
these options are not available to you if you solely support Easy token
processing.
Using ISO messages. See 3.1.2.11 0302 token maintenance file requests.
Using the Visa Token Service API. See 5.1 Web services.
Using the Visa Token Life Cycle Manager (TLCM) tool. See 5.4.3 TLCM tool functions.
Using the Visa File Exchange Service (VFES) to process token bulk PAN updates. Full
details of the service can be found in the Visa File Exchange Service Token Bulk PAN
Update available on VOL.
5.4.3 TLCM tool functions

TLCM provides the following functions for managing token life cycle events and the status of
payment tokens:
Search for one or more payment tokens linked to a PAN

View transactions made using a payment token
Perform life cycle management as described in 5.4.1 Token life cycle event types
Customise tool user preferences

5.4.3.1 Access to TLCM

TCLM is available on Visa Online. You ask for access for your users during implementation,
using the MIQ to identify the users. Your local Visa Online Access Manager can request
access to be granted to the Visa Online IDs of your identified TLCM users. Users granted
access will find a link to the tool in their list of services.
There are two types of user:
Administrators
Administrators have full use of the application, allowing them to:
Manage token life cycle events
Manage other user accounts
Users
Ordinary users can:
Manage token life cycle events
Select a reason code for token status changes from the available list
5.4.3.2 Browser support for TLCM

or Firefox (last four updates) for TLCM.
5.4.3.3 TLCM documentation

Full details of the application can be found in the Visa Token Life-Cycle Management (TLCM)
User Guide available on VOL.
5.5 Visa Token Reporting Service

The Visa Token Reporting Service (VTRS) is a web-based tool that provides you with reports
that assist you in maintaining your token portfolio. There are a number of reports available
that show the status of your tokens, including provisioning request and declines,
authorisations, fraud reporting.
5.5.1 VTRS documentation

Full details of the application can be found in the Visa Token Reporting Service Users Guide.
5.5.2 Accessing VTRS

VTRS is available on Visa Online. You ask for access for your users during implementation,
using the MIQ to identify the users. Your local Visa Online Access Manager can request
access to be granted to the Visa Online IDs of your identified VTRS users. Users granted
access will find a link to the tool in their list of services.
5.5.3 Browser support for VTRS

or Firefox (last four updates) for VTRS.

Visa Token Service Comparison of Generic and Easy token features
Implementation guide for Acquirers
Appendix A. Comparison of Generic and Easy token features
Table 8: Features of Generic and Easy token
Feature Easy token Generic token

VRM ruleset processing Step-up consumer authentication is performed Outcome of risk rules provided to Issuer in 0100 TAR. Step-up
based on risk rule or token requestor requirement consumer authentication is performed based on Issuers TAR
where account is otherwise in good standing response or token requestor requirement
Token Activation Requests (0100 Existing Early Token TAR format Generic Token TAR format
TARs) See section 6.10 of Visa Europe Dual Message
System Authorisation (DMSA) technical
specifications for details of the Early Token TAR
format.
Transaction Authorisation Existing Early Token format Generic Token format
Messages
Cardholder verification results in Provided in field 60.9 Provided in field 60.9. Additional detail in field 123
authorisation
Token authentication results in Provided in field 44.5, 44.8 Provided in field 44.5, 44.8
authorisation and 44.13 and 44.13
Track 2 image Not provided Not provided
Field 55 or 3rd bitmap chip data Not provided Not provided
Clearing Messages Standard token format Standard token format
Token provisioning and lifecycle Offline reports (TC33) Real time advices (0620) or Offline reports (TC33)
event advices
Real-time lifecycle management Token Lifecycle Management (TLCM) tool on VOL Token Lifecycle Management (TLCM) tool on VOL Or 0302
for tokens update messages or Inbound web services (available on
special request)

Visa Token Service Comparison of Generic and Easy token features
Implementation guide for Acquirers
Feature Easy token Generic token

Bulk token lifecycle Data file submission via the Token Lifecycle Data file submission via the Token Lifecycle Management
management (for token activate, Management (TLCM) tool on VOL (TLCM) tool on VOL
suspend, resume, delete)
Bulk PAN maintenance lifecycle Data file submission via the Token Lifecycle Data file submission via the Token Lifecycle Management
management for tokens (for Management (TLCM) tool on VOL (TLCM) tool on VOL
Card renewal or replacement) or or
New Bulk PAN maintenance solution (all VE New Bulk PAN maintenance solution (all VE Issuers)
Issuers) or
or VAU (for Issuers already using VAU )
VAU (for Issuers already using VAU )
1
Outbound Web services Not normally used Optional
e.g. One Time Passcode (OTP) Available for Apple Pay
implementations on request (additional
implementation effort)
Inbound Web services Not used Available on special request (additional implementation
e.g. Card lifecycle management effort)
Step-up consumer Call Centre, Mobile AppAvailable on special Call Centre, Mobile App, Cardholder OTP
2
authentication methods request: Cardholder OTP
Address Verification Service UK Issuers: Compressed numerics, F123 usage 1 Only TLV AVS format supported (F123 usage 2, DSID 66)
(AVS) support during or
provisioning
TLV AVS Issuers (F123 usage 2, DSID 66)
1
Issuers can choose to implement web services in order to provide the desired customer experience or approach to consumer authentication, or if
required by the token.
2
Cardholder OTP requires web services implementation, so it should be avoided by Issuers wishing to roll out quickly (except where the token
requestor requires this step-up method).


Visa Token Service Implementation Guide For Issuers

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Visa Token Service Implementation Guide For Issuers

Transféré par

Droits d'auteur :

Formats disponibles

Visa Europe

Visa Token Service

Visa Confidential Version 3.0

1 About this guide .............................................................................................................................. 6

3.2 Testing and certification ............................................................................................................... 21

3.3 Onboarding ....................................................................................................................................... 22

4.2 iCVV keys............................................................................................................................................ 26

Visa Confidential Version 3.0

4.3 CVV2 keys (C2K) .............................................................................................................................. 26

4.5 Web service security ...................................................................................................................... 27

4.6 Mobile banking app step-up authentication ....................................................................... 28

5.2 Visa Card Metadata Manager..................................................................................................... 32

5.3 Visa Risk Manager .......................................................................................................................... 33

5.4 Token Life Cycle Management................................................................................................... 36

5.5 Visa Token Reporting Service ..................................................................................................... 38

Visa Confidential Version 3.0

Table 1: Document sections....................................................................................................................................................... 6

Figure 1: Visa Europe Payment Token Service onboarding process ...................................................................... 24

Visa Confidential Version 3.0

1 About this guide

1.1 Document purpose

1.4 Document organisation

Visa Confidential Version 3.0

1.5 Related publications

Visa Token Service Product Overview

Visa Europe Dual Message System Authorisation (DMSA) technical specifications

October 2016 VisaNet Business Enhancements Global Technical Letter and

Member Letter VE 01/15: Introduction of the Visa Token Service

Visa Confidential Version 3.0

EMV Payment Tokenisation Specification: Technical Framework version 1.0

Acronym or term Definition

Visa Confidential Version 3.0

Acronym or term Definition

Visa Confidential Version 3.0

Acronym or term Definition

1.7 Document conventions

Important Highlights important text in the guide

1.8 For more information

Visa Confidential Version 3.0

2 About the Visa Token Service

The Visa Token Service provides a number of benefits:

2.1 What are payment tokens

Token property Details

Visa Confidential Version 3.0

Token property Details

2.2 Visa product eligibility

2.3 Token type support

2.4 Use case support

2.5 Token processing

Visa Confidential Version 3.0

2.5.1 Generic token processing

2.5.2 Easy token processing

Visa Confidential Version 3.0

3 Implementing the Visa Token Service

3.1 Implementation process

3.1.2 Service considerations

3.1.2.1 Token authentication rules

Visa Confidential Version 3.0

3.1.2.2 Step-up authentication

Field number and name Description

Visa Confidential Version 3.0

3.1.2.3 Design and implement your payment token solution

3.1.2.4 Choose BINs to enrol in the service