What is a token payment?
Tokenization payment is a payment token which is an "alternate identifier" that can be used in place of the
Personal Account Number (PAN) to initiate a payment transaction.
In other words, Payment token is a surrogate value for a PAN that is a 13 to 19-digit numeric value that must pass basic
validation rules of an account number, including the Luhn check digit Payment Tokens must not have the same value as or conflict with a real PAN.
Meaning that Tokenization is a process by which the PAN is replaced with the Payment Token.
Tokenization may be undertaken to enhance transaction
efficiency, improve transaction security, increase service transparency, or to provide a method for third-party enablement. In short a
token vault of Security Token Services.
A token Vault is a repository,implemented by a Tokenization system that maintains the established Payment Token to PAN mapping.
The Token Vault may also maintain other attributes of the Token Requestor that are determined at the time of registration and may be used by the
token service provider (or security token Services) to apply domain restrictions or other controls during transaction processing.
The Token Requestor is an entity that is seeking to implement Tokenization and initiates requests that PANs be Tokenized by submitting
Token Requests to the Token Service Provider.

Each token requestor will be registered and identified uniquely by the Token Service Provider (or security token Services) within the
tokenization system.
The token request is a process in which a Token Requestor requests a Payment Token from the security token Services or Token Service Provider.
Tokenization involves Token Provisioning, Acquirer Processing, Issuer Processing, Token Data Elements and Token Processing.
One terminology you might see: VTS - Visa Token service - This is the "global" scheme - VEPTS is Visa Europe.
The MasterCard scheme is known as MDES and the VISA scheme is known as VEPTS.
MasterCard tokenization services is offer to the merchants with app, eletronic commerce or e-commerce, subscription-based payment
environments and recurring billing card-on-file programs, further protecting consumers and increasing convenience when storing MasterCard cards
in merchant databasess.
By expanding its Digital Enablement Services (MDES) to serve merchants needs, MasterCard and VISA continues to lead the
industry in securing cardholder credentials - no matter where they are stored. These new experiences all involve storing card numbers.
There is also a scheme called MasterCard Cloud Based Payment (MCBP) which is the MasterCard specification for doing HCE using
MasterCard cards but without MasterCard providing the tokenization and cryptographic authentication etc.
There is a VISA equivalent called "VISA Mobile Cloud".
Note that VTS/VEPTS/MDES all related to where the card scheme is providing the Token Service Provider (TSP) function, where the
token seen at the acquirer is converted into the real PAN, as seen by the issuer, by Visa or MasterCard.
This need not be the case, and issuers can do their own thing and convert the token themselves. Note that you also have
"Card on File", this is where the merchant acquirer can request Visa to translate the token to a real PAN.
Magnetic Secure Transmission (MST) is something clever introduced by Samsung (one of the three "Pays"). They have
a widget in their phones that zaps a magnetic pulse to an ordinary track 2 reader in a POS terminal, so the merchant does not need
an NFC-capable device.
VISA Europe provide Visa Europe Payment Token Service (VEPTS) and Visa Europe Authorization Service (VEAS).
In this scenario, HSBC Bank or Citi Bank or Barclaycard could be the issuer, and wish to allow their cardholders to use Ali Pay,
Amazon Pay, Apple Pay, Facebook Pay, Google Pay or Samsung pay, etc.
With Visa Token service (VTS). Field 4 (amount data) should contain a 0 (zero) in the token activation requests (TAR),
and field 7 should contains the date and time when the token activation request was created.
The token expiration date is three years from the PAN (personal account number) expiration date.
Token activation requests must contain one of the following response codes, 00 (unconditional approval [provision and activate immediately
for payment]) or 85 (Conditional approval [provision,but do not activate until additional consumer verification is performed].)
Visa requires a response of 00 for 0620 Token Notification Advice with message reason code 3700 (Token create).

Security Token Services
Payment transaction using security token services or payment tokens at Point of Sale (NFC/Contactless), where Authorization request and
Authorization response messages are sent.
1 Consumer smart phone user initiates a purchase using their device at an NFC/contactless - enabled merchant.
2 Merchant submits token in place of PAN to their acquirer.
3 Acquirer passes token (looks and feels like PAN) to payment network.
4 Payment network excahnges token with the PAn from token vault and validates rightful use of payment token.
5 Payment network passes PAn and token to the issuer for authorization.
6 Issuer or their processor authorizes or declines transaction andreturns to payment network. Payment network
exchanges PAN back to token acquirer and on to merchant.
Token Location
Token location indicates the storage location of the payment token:
• 01 - Remote storage
• 02 - EMVCo / Payment Network type approved secure element / ICC
• 03 - Local Device storage
• 04 - Local hardware secured storage
• 05 - Remote hardware secured storage
Token Assurance Level
Token assurance level is a value that allows the Token Service Provider to indicate 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.
It may also be influenced by additional factors such as the Token location.
Token assurance level is set when issuing a Payment Token and may be updated if additional ID & V is performed. The token assurance level
value is defined by the Token Service Provider.
Near-Field Communication (NFC)
Near-field communication NFC (also known as Contactless) is a set of communication protocols that enable two electronic devices,
one of the which is usually a portable device such as a smartphone, to establish communication by bringing them within about 4 cm
(2 in) of each other.
Secure Element (SE)
Secure element (SE) (or nfc secure element) is a certified chip designed to securely store card/cardholder data and does
cryptographic processing.
During a payment transaction it emulates a contactless card using industry standard protocols to help authorized a transaction.
The Secure Element could either be embedded in the phone or embedded in your network operator's SIM card - embedded secure element.
The secure element is an industry-standard, the Device Account Number in the secure element is unique to your device and to each credit or
debit card added.
Token Data Elements
Meaning of Token Elements:
T1 Token PAN
The full Token value, surrogate value for the PAN
T2 Token Assurance Level (2 bytes)
The Token Assurance Level is set when issuing a Payment Token and may be updated if additional Identification & Verification (ID&V) is performed.
It is a two-digit value ranging from 00 which indicates the Payment Token has no ID&V that has been performed to a value of 99 indicating the highest possible assurance.
The specific method to produce the value is defined by the Token Service Provider.
T3 Token Requestor ID
This value uniquely identifies the pairing of Token Requestor with the Token Domain.
T4 Real PAN
Typically last 4 digits of actual PAN
T5 Token Transaction Identifier (2 bytes)
• C = MasterCard Digital Enablement Service Device Account Number
• F = MasterCard Card on File token
• O = MDES Card on File Account Range - IPM
• 4 = Visa generated token data
• PU = Pulse generated token data
• NY = NYCE generated token data
• ST = STAR generated token data.
T6 Token Expiration Date
The expiration date of the Payment Token that is generated by and maintained in the Token Vault
T9 Token Type (2 bytes)
• CF = Card on File
• SE = Secure Element
• HC = HCE (Host Card Emulation)
TA Token Status (2 bytes)
• A = Active for payment
• I = Inactive for payment (not yet active)
• S = Temporary suspended for payments
• D = Permanently deactivated for payments
TB Token Lookup Tran ID (2 bytes)
TP Token Service Provider Identifier (2 bytes)
• MC = MasterCard
• VI = Visa
• ST = STAR
• FD = FDC
• IS = Issuer
• AQ = Acquirer
Host Card Emulation (HCE)
Host card emulation (HCE) is the term use to describing on-device technology that permits a phone to perform card emulation on an Near Field
Communication NFC-enabled device without relying on access to a secure element.
When a Google wallet (not google secure element) picks up the request from the host operating system (OS) and responds to the
communication with a virtual card number and uses industry standard contactless protocols to complete thetransaction.
This is the card emulation part. The transaction proceeds and reaches the Google cloud servers (or google cloud security or
google cloud services) where the virtual card numbers is replaced with real card data and authorized with the real Issuer.
Card on File
Card on file (not credit card on file form) refers to scenarios where an e-commerce Merchant that has payment card data
on file (or credit card on file) in a database seeks to remove the underlying security exposure of storing card data by replacing the
PANs with Payment Tokens.
In such scenarios, these merchants will likely be the Token requestor.
Once Payment Tokens are returned to these Card-on-file Merchants, all subsequent e-commerce transactions that are processed will use the
Payment Token and the Token Expiry Date in lieu of the PAN and PAN Expiry Date fields.
what is token provisioning?
The process of enabling a mobile or digital device to process Token transactions involves a number of steps. For example:
• Cardholder applies for a token using a mobile phone app
• MasterCard/VISA verified that the card is eligible for tokens and decides to proceed or decline
• Apple applies a score and decides to proceed or decline
• A provisioning request is sent to the issuer
- This may be an Account Inquiry if MasterCard or VISA provision services are employed
- This may be a series of provisioning transactions if the issuer makes the decisions
- A reply is sent to the cardholder with a decline or activation code
As a first step the cardholder uses a mobile app to enter the payment information for a specific card.
• Card number
• Expiration Date
• CVV2/CVC2
The request is sent to Visa or MasterCard to determine if the card is eligible for provisioning.
Token provisioning occurs when a token requestor (e.g. Apple Pay, Samsung pay, Ali Pay, Facebook Pay, Google Pay or Amazon Pay etc. in this case)
processes a card digitization request on behalf of the card holder, so that the digital version of the Bank debit card or credit card is
incorporated into the on-device secure element.
•Performs initial validity checks against the Bank Identification Number (BIN) ranges agreed by the issuer as
eligible.
If this checks fails, a STIP (Stand-in-process, where for example, Visa performs some processing on behalf of the issuer, and then
notifies the issuer of the result by means of a STIP advice) Advice is sent to the Issuer.
•VEPTS sends a Token Activation Request (TAR) request to the issuer which, if approved
VEPTS initiates token provisioning onto the mobile device.
•If the TAR times-out then VEPTS uses a stand-in rule set to determine if provisioning takes place.
If the rules indicate that the provisioning request should be denied, or if there is a failure, a STIP advice is sent to the issuer.
VIP or V.I.P. (VisaNet Integrated Payment) System is Visa's main transaction processing system.
The V.I.P. System, often called simply V.I.P. or VIP, is a major system component of the VisaNet network, which receives and
processes cardholder transactions for Visa products and services, as well as for other proprietary cards.
When we talk of Token Service, it means Acquirers must send the token PAN in requests. V.I.P. changes the
token PAN to the cardholder PAN prior to forwarding messages to the issuer.
Security Token Service: Field 4 of TAR must contains a 0 (zero) in token activation requests.
Security Token Service: Field 7 contains the date and time when the token activation request was created.
Field 14, the token expiration date is three years from the PAN expiration date.
Security Token Service: Field 22 can have a value of 07 (contactless device-read originated using VSDC chip data rules) or
91 (contactless device-read originated using magnetic stripe data rules) is required for iCVV convert service,
early chip data, and full chip data for messages with token data.
E-Commerce messages containing token data must be submitted with a value of 01 (manual key entry).
Security Token Service: Field 23 (Card Sequence Number) is required for early and full chip data and will contain the PAN sequence number of the token.
Security Token Service: Field 25 (Point-of-Service Condition Code) must contain a value of 00 (normal transaction of this type)
or 06 (preauthorized request) in messages containing token data. This field is required for E-Commerce authorization and full
financial messages containing token data.
Security Token Service: Field 35 (Track 2 Data) is present in messages containing token data. If a request is submitted with token data,
participating host issuers must support the following:
T• iCVV Convert Service: This field contains the cardholder PAN, card expiration date and service code
for magnetic stripe, and the CVV according to issuer configuration.
• Full and Early chip: This field contains the token, token expiration date, and the dCVV or iCVV based on the token.
Security Token Service: Field 39 (Response Code) Token activation response must contain one of the following response codes, 00
(unconditional approval [provision and activate immediately for payments]) or 85 (Conditional approval [provision, but do not activate until additional consumer verification is performed].)
Visa requires a response of 00 for 0620 Token Notification Advice with message reason code 3700 (Token create).
This token service field must contain a value of 00 or 06 for 0620 Token Notification Advice with message reason code
3701 (Token deactivate), 3702 (Token suspend), 3703 (Token resume), and 3711 (Device provisioning result).
This security token service field must contain the value of 00 for 0630 Token Notification Advice response with message
reason code 3700, 3701, 3702, 3703 and 3711.
This security token service field must contain a value of 00 or 06 for 0620 Token Notification Advice with message reason code 3712
(OTP verification result) and 3714 (Mobile banking app activation).
This token service field must contain the value of 00 for 0630 Token Notification Advice response with message reason code 3712 and 3714.
Security Token Service: Field 44.13 (CAVV Results Code), for E-Commerce transactions containing token data this field must be present with a
value of 0, 1, or 2.
Security Token Service: Field 44.15 (Primary Account Number, Last Four Digits for Receipt) - This field is present in messages containing token data.
Security Token Service: Field 52 (Personal Identification Number PIN Data) - This field contains token specific data. V.I.P. converts the PIN block
from token to cardholder PAN prior to forwarding request messages.
Security Token Service: Field 55 (Usage 1 - VSDC Chip Data) - Acquirers must submit this field when token data is present.
Security Token Service: Field 55 (Usage 2 - Chip Card Data) - This field must be present in authorizations and full financial messages containing token data.
Security Token Service: Field 60 (Additional POS Information) - A value of 5 or 8 is required in field 60.2 in messages with token data. A value
of 4 in field 60.6 is required in messages with token data.
Authorizations and full financial messages using iCVV convert service, early chip data or full chip data must include field 60.6 in requests
containing token data.
This field is required for E-Commerce authorization and full financial messages containing token data. A value of 5 is required in
field 60.8 for E-Commerce messages with token data.
Security Token Service: Field 62.1 (Authorization Characteristics Indicator)[Bitmap Format] - Authorization and full financial requests must be
submitted with a value of Y or P. If a request meets token and CPS processing requirements V.I.P. will insert a value of B in the response.
Security Token Service: Field 63.3 (Message Reason Code) - Message Reason Codes for Visa Token Service:
Reason Code |
Description |
3700 |
Token create |
3701 |
Token deactivate |
3702 |
Token suspend |
3703 |
Token resume |
3711 |
Device provisioning result |
3712 |
OTP verification result |
3713 |
Call Center activation result |
3714 |
Mobile banking app activation |
Security Token Service: Field 70 (Network Management Information Code) - The code must be 890 in 0620/0630 messages.
Token Service: Field 91 (File Update Code) - This field contains a 2 for 0302/0312 token maintenance file requests/responses.
This field contains a 2 for 0302/0312 primary account number maintenance file requests/responses.
This field contains a 5 for 0302/0312 token file inquiry request/responses.
Security Token Service: Field 123 (Verification Data) [Fixed Format] - Fixed format AVS data must not be submitted for token processing.
Authorizations and full financial messages using iCVV convert service, early chip data or full chip data must include the appropriate tags
from Field 123, Usage 2, Dataset ID 68-Token Data. This field must be used when submitting address verification data or token data.
Token Service: Field 126.9 (Usage 3: 3-D Secure CAVV, Revised Format) - This field is required with a value of 3 in position 7, byte 16 - version
and authentication in E-Commerce messages containing token data.
VISA Mobile Provisioning Service
Visa Provisioning support
VISA online messages for token provisioning:
Token activation request message
This is a request message sent (by Visa) to an issuer with a notification that a token belonging to the issuer has been requested
to be activated and to subsequently expect transactions containing this token. It is sent as a 0100 message.
Respond with an 0110 response message, the action taken the token service will be dependent on the value provided in Field 39 -
Response Code, as follows:
- 00 - Unconditional approval (provision token and activate immediately for payments)
- 85 - Conditional approval (provision token but do not activate until additional consumer verification has been performed)
- Any other value - Decline (do not provision token)
- Tag 01 with the token
- Tag 02 with the token assurance level value
- Tag 03 with the token requestor ID
- The cardholder enters an incorrect Activation Code value on the first and second attempts.
- The number of invalid attempts has been exceeded on the third attempt.
- The Activation Code is invalidated or expired, either on a fourth attempt or an attempt after the validity period has expired.
- 07 Contactless EMV
- 91 Contactless Mag Stripe
- Token PAN
- Token Expiration Date
- If Entry Mode = 07
- 07 Contactless EMV
- 91 Contactless Mag Stripe
- 82 Card on file ( Mastercard)
- PAN
- Expiration Date
- T1 Token PAN - optional
- T2 Token Assurance Level (normal)
- T3 Token Requestor ID (normal)
- T4 Pan Account Range (Full PAN or last 4 digits of PAN) (normal)
- T5 Token Transaction Identifier - optional
- T6 Token Expiration Date - optional
- T7 Token Reference ID / Token Type - optional
- T8 PAN Reference ID - optional
- T9 Token Type - optional
- TA Token Status - optional
- TB Token Lookup Tran ID - optional
- TP Token Service Provider Identifier - optional
Issuer Token Notification Advice Message
For issuers that choose to implement the issuer notification advice message, Visa will send the 0620 advice to notify the
participating issuers that Visa has performed device provisioning or activation at their cardholder's request.
Account verification service
The Account Verification Service Request is a non-financial, information-only request that can be used to validate cardholder account
information.
Issuer Token Notification Advice
Visa has implemented a new 0620/0630 Issuer token notification advice and response message. Visa will forward an 0620 advice
to participating issuers to notify them that Visa has issued a token on their behalf.
Visa will forward a 0620 advice to participating issuers with the following key fields and values:
• Field 14-Date, Expiration; will contain the PAN expiration date which is currently the same
as the token expiration date.
• Field 63.4-STIP/Switch Reason Code, will contain the new value of 9095
(Issuer notification of token vault provisioned or status change).
• Field 70-Network Management Information Code, will contain the new value of 890
(Issuer token advice).
• Field 123, Usage 2, Dataset ID 68; will contain:
Token Payment Transactions
(or Visa Europe Payment Token Service [VEPTS])
Once token provisioning is complete then the digital representation of the card in the mobile device can be used to perform
contactless payments.
The resulting authorization requests transactions are processed as normal, with VEPTS replacing the token with the real PAN.
Token-based authorization messages will have one of the following values in in Field 22 (Point-of-Service Entry Mode Code) of the BASE I message:
• 07 for Visa payWave for mobile
• 01 for application-based e-commerce or card not present
This rule is enforced forced by Visa and will not be validated on payment system.
TAuthorization messages may be received with additional data relating to token processing, for example:
• Token number linked to the card
• Token Requestor ID
• Token expiry date
• Token type (for example secure element, or CBP).
Depending on the processing options configured by an Issuer and on the type of transaction taking place, an Issuer will receive
different results codes:
• For NFC transactions (contactless): either field 44.5 together with field 44.8 - Card Authentication Results Code, or field 44.8 on its own.
• For application-based Electronic Commerce Transactions: field 44.13 - CAVV Results Code on its own.
Token Life Cycle Management
For token life cycle management, you need to consider tokenizing a PAN and provisioning a device or card-on-file system is just
the first step in a token's use. A PAN is subject to a number of events that affect the token.
It can expire or obtain an invalid status. A card or mobile device can be lost or stolen. Issuers reissue cards with new numbers.
As a result of any of these events, you may need to suspend, deactivate, reactivate, or cancel a token.
American Express, MasterCard, and Visa provide Web portals through which you can manage tokens, perform certain research tasks,
and monitor token activity.
In addition to the portals, MasterCard and Visa offer batch services. For example, if you reissue a large number of cards, you can send
the details directly to the brand in a batch and they will update the PANs associated with tokens for you.
The following options for Token Lifecycle Management (TLCM) can be considered:
• Option 1 - Payment system support for VEAS token-based payment authorizations, Token activation request (TAR) and Synchronous file update (TLCM) messages (i.e. Payment system product modified to support end-to-end 0302 file updates). Support for 0620 and 0120.
• Option 2 - reduced scope due to the use of Visa Web Services for TLCM. Payment system support for VEAS token-based payment authorizations, Token activation request (TAR). Support for 0302, 0620 and 0120. I.e., all TLCM messages.
• Option 3 - some Lifecycle management messages switched to asynchronous, with some as synchronous (with error reporting).
• Option 4 (introduce additional real-time notifications for lifecycle management). Same as Option 1, support for 0620 and 0120.
Online bank payment system require support for Token Activation Requests. This is a normal 0100 BASE I requet message with
addition elements provided related to the tokenization processing.
Token Activation Request (TAR) transactions will be pre-screened on payment system, and sent to the Online Bank Host as 1100 requests
using normal payment systems request processing. If the Issuer Host is unavailable, payment system will Stand-in and decline the transaction.
Pre-screen processing will be limited to the following checks typical of a Card Not Present transaction:
•Card valid (exists in the CARD data record)
•Card status check
•Card expiry date check
•CVV2 check
•Account valid
•Account status check
•AVS check. This check should not affect the authorization decision, but the results of th echeck are returned to Issuer host.
Token Card Verify by MasterCard/Visa
MasterCard / Visa verify the token card. The next step in token provisioning a card is to verify that the account range
is suitable for digitization.
An account range is a specific series of available PANs based on the Bank BIN {The first 6 digits of a credit card number are known
as the Issuer Identification Number (IIN), previously known as Bank Identification Number (BIN)} or prefix of the card.
• A token request is first sent to MasterCard or Visa where a token card check is applied to validate that
the selected payment card belongs to a BIN ranges that support token transactions.
• A approval or decline is returned
An issuer may enable as few or as many of their PAN ranges as they wish.
A cardholder's card whose PAN falls within an enabled PAN range is indicated as potentially available for digitization
(subject to the issuer's additional processes).
When a card's PAN falls outside an enabled PAN range, it is indicated as not available for digitization.
Apple Scores the Token Request
Token Cards that are eligible for digitization will be subject to a number of conditions as defined by Apple (not apple stock).
The device and account scores will provide a summary of transaction and experience information concerning the specific device and Apple account
requesting provisioning.
Apple will calculate these scores based on behavior across Apple's lines of business and programs.
Apple will consider various factors in coming up with the score including historic and recent transactions, anomalous behaviour and linkages
to known bad actors or activity.
• Apple will provide a tokenization recommendation of "Approve" or "Require additional authentication".
MasterCard Token
MasterCard provides these online message for token provisioning:
• Tokenization Eligibility Request (TER)
• Tokenization Authorization Request (TAR)
• Activation Code Notification (CAN)
• Tokenization Complete Notification (TCN)
• Tokenization Event Notification (TVN)
Each message will be sent as Authorization Request/0100 or Financial Transaction Request/0200.
Tokenization Eligibility Request
This message is sent to the Issuer host when a card is within an account range eligible for tokenization.
This message gives the Issuer advanced notice that a cardholder may request tokenization so that Issuer systems are prepared to receive
the subsequent Tokenization Authorization Request messages containing additional details.
Tokenization Authorization Request
This message is sent to the Issuer host when tokenization of a PAN is requested. It contains the score assigned by Apple.
Activation Code Notification Request
The Activation Code Notification is a digitization service-specific network message containing the Activation Code and Expiration
Date/Time to be provided to the cardholder using the selected communication channel.
Tokenization Complete Notification
When the tokenization process is complete, the issuer may choose to receive a Tokenization Complete Notification (TCN) payment network
message informing them of the token designated and other information regarding the digitization process.
Tokenization Event Notification
The issuer may select to receive Tokenization Event Notification (TVN) payment network messages that may be triggered during
the Activation process.
A TVN will be sent to the issuer with an appropriate reason code when:
Acquirer Processing
For Acquirer processing, the acquirer interfaces need to support sending a token instead of a PAN in the request message and receiving
the PAN in the response message.
Request Message:
• For the majority of cases there are no changes as the request message is processed as any contactless EMV or
contactless mag stripe message. The token appears in track data.
Response Message:
• The response message requires changes to be able to accept the token specific data elements returned by the
TSP and to extract the PAN in the clear (last 4 digits usually) for receipt printing.
Request Message
A customer makes a purchase at a NFC terminal using the Apple Pay app on a mobile phone. The POS interface needs to
build the outgoing message as below:
Request Message Contains
• Entry Mode
• Track 2 Data
• EMV data
Issuer Processing
The Role of the Token Service Provider (TSP) - Transactions that contain a token instead of a PAN must first be verified and converted to
a PAN belonging to the issuer. This is the role of the Token Service Provider (TSP).
The network connected to the issuer will recognize if a transaction contains a token using a BIN range and will make a call to the
appropriate TSP before sending the transaction to the issuer.
The TSP will perform the following verification functions:
• Check the status and the expiration date of the token to either decline or continue processing the transaction
• Application Transaction Counter (ATC) check on all transactions
• Cryptogram validation for transactions initiated as contactless Payment with full EMV data
• Dynamic CVC 3/CVV validation for transactions initiated as contactless magnetic stripe
• Decline transaction that fail verification steps
big>For valid transactions:
• Rebuild track 2 data with the associated PAN and expiration date
• Set POS entry mode 82 (for MasterCard)
• Supply associated token data elements
By the time the message reaches the issuer, the TSP has converted the token and supplied any additional token related data.
Request message processing includes
• An upgrade to set the token transaction as non-EMV transactions in the internal message. The means to
determine this setting may differ for each interface
• Track 2 data is moved as with any message
• The token data elements from the network message need to be moved to the internal message
Response message processing includes
• There are no token specific response message processing changes required
After the TSP has converted the token, the interface builds the internal message.
An indicator that this is an Apple Pay transaction is required (different for each interface)
• Entry Mode
• Track 2 Data
• Token Data (each interface may send a combination of)
Payment Token Definition
By definition, Payment Token is a "non-financial identifier" that replaces the original payment credential (PAN) which
shall be used in its stead to initiate payment activity. Tokenization may be undertaken to enhance transaction efficiency, improve transaction
security, increase service transparency or provide a method for thrid party payment enablement (for example, Near Field Communication (NFC) contactles,
Wallet, Quick Response (QR) codes, Other Emerging Technologies, etc).
For clarity, the payment token definition focuses on "Payment Token" used for payment obligations between parties as opposed
to "Non-Payment Tokens" used for localized functions such as card security.
Tokenization involves the replacement of the card-account number with a "non-financial identifier" which may be used in its stead to initiate payment activity.
Payment Token Standard
Why Payment Token Standard? - To increased protection against counterfeit, account misuse and other forms of fraud,
American Express, MasterCard and Visa teamed up to propose a global interoperable method to facilitate payments using
"Payment Token".
• October 1st: Standard Announcement - The proposal addresses principles, Token format, data fields and
Identification / Verification (ID & V) considerations by way of a Standard.
• October 22: Working Group in EMVCo - Standards body EMVCo in agreement to create a dedicated task force
capable of owning "Payment Token Standard".
The payments industry is evolving to support payment form factors that provide increased protection against counterfeit, account misuse
and other forms of fraud.
While EMV chip cards can provide substantial protection for card-present transactions, a similar need exists to minimise unauthorized use
of Cardholder account data and to reduce cross channel fraud for card-not-present transactions.
Payment Tokenization systems hold substantial promise to address these needs. In order for the Payment Tokens to provide improved
protection against misuse, the Payment Token is limited to use in a specific domain, such as to a specific Merchant or channel.
Common tokenization standard minimizes impact by ensuring compatibility with current payment technologies and enabling support
for emerging payment innovations.
These underlying usage controls are a key benfit of Payment Tokens. There are benefits for all stakeholders in the payments ecosystem
that will help encourage adoption of Payment Tokens:
• Acquirers and Merchants may experience a reduced threat of online attacts and data breaches, as Payment Token databases
will be less appealing targets given their limitation to a specific domain. Acquirers and Merchants may also benefit from the higher assurance
levels that Paymet Tokens offer.
• Card Issuers and Cardholders may benefit from new and more secure ways to pay, improved transaction approvals levels,
and reduced risk of subsequent fraud in the event of a data breach in which Payment Tokens are exposed instead of PANs.
• Payment processing networks will be able to adopt an open specification that facilitates interoperability and helps reduce
data protection requirements for the Payment Network and its participants.
• Card re-issuance not required if merchant database is compromised.
• Reduced threat of sensitive cardholder data being compromised.
• Reduces overall cost of fraud by minimizing card re-issuance.
• Reduced risk of subsequent fraud in the event of merchant data breach.
• Issuers benefit from new and more secure ways to pay.
• A common approach to tokenization simplifies the process for merchants for contactless, online or emerging payments.
• Increased data protection as sensitive card number (PAN) is not passed through the ecosystem.
Payment Token Standard Objectives
The objectives of payment token standard is to make sure that the Tokens must add value to its processing environment
while improving visibility and protecting cardholder information.
• Secure way to pass payment credential
• Support for new form factors at point-of-sale (POS)
• Ability to retain End-to-End payment integrity
• Recognition of new entities in payment flow
• Interoperable standard based approach to third party payment enablement