Professional Documents
Culture Documents
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
Contents
Tables
Figures
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
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.
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:
1.6 Definitions
This document uses the following terms and definitions:
Table 2: Definitions
Convention Description
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.
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.
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.
This section outlines the processes involved in implementing the Visa Token Service.
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.
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
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.
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.
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.
N7 Decline for CVV2 failure Conditional The token provisioning request is not
approved by the issuer (specific decline
when the CVV2 is incorrect)
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.
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:
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.
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.
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.
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.
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.
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.
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.
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.
All three functions described above are optional. You may opt to use a subset of the
described functions.
Retrieve a list of all the payment tokens associated with a particular PAN
Retrieve all the details of a specific payment token
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.
be to decline the request, forward the request to you for approval or to request further
authentication of the cardholder.
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.
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.
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.
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.
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
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)
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).