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)




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:

• Tag 01 with the token


• Tag 02 with the token assurance level value


• Tag 03 with the token requestor ID



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:

• 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.




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

• 07 Contactless EMV
• 91 Contactless Mag Stripe

• Track 2 Data


• Token PAN
• Token Expiration Date

• EMV data


• If Entry Mode = 07




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


• 07 Contactless EMV
• 91 Contactless Mag Stripe
• 82 Card on file ( Mastercard)

• Track 2 Data

• PAN
• Expiration Date

• Token Data (each interface may send a combination of)

• 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




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