Upload
duongxuyen
View
244
Download
0
Embed Size (px)
Citation preview
1 of 37
Fall Mandate Notification – September 3, 2015
2015 Fall Mandate Notification
CO-OP Financial Services will implement the code changes required to support card association and
EFT network Fall Mandates on Friday, October 16, 2015, unless otherwise noted.
CO-OP has identified requirements that may impact your host processor. The requirements in
support of these mandates are detailed in this update. While CO-OP forwards copies of our
Hardware/Software Compliance Updates to our known software vendor contacts, it is up to each
credit union to check with their software vendor to make sure their vendor has the information
needed to support these changes. If a 3rd party authorizes transactions on your behalf, often
referred to as a service bureau, you should forward this information to them.
Please note: DataNavigator will be taken offline at 7 p.m. PT on October 16, 2015, to install
the code changes required to support the mandates. DataNavigator will be unavailable for
approximately two hours.
Questions regarding your credit union network participation should be verified with the sponsorship
or contracts administrator within your organization. Some credit unions have issued a Debit
MasterCard with Plus sponsorship or a Visa Debit card with Cirrus sponsorship. In these cases, both
the MasterCard and Visa changes would apply.
The changes dictated by the card associations and EFT Networks are required to remain in
compliance with each of the networks. The dates for compliance have been set by each card
association or network. Associations rarely offer waivers to mandates so you should pursue these
changes with your vendor as quickly as possible.
Please contact Client Services at 800.782.9042, option 2, with any questions.
2
Summary by Association/Network
Tokenization Update
Recommended for MasterCard and Visa Debit and Credit
Token Provisioning Messages - pg. 3
DE 124 Expand Length from 255 to 999 bytes – pgs. 3-4
Visa
Visa Merchant Identifier and Digital Commerce Program Indicator
Required when tokenization is enabled for PAVD, Interlink, Debit and Credit – pg. 4
EMV Liability Shift for POS Transactions Reminder - pgs. 4-5
Visa Token Service
Required when tokenization is enabled for PAVD, Interlink, Debit and Credit - pgs. 5-6
Original Credit Transactions (OCT)
Required for Interlink Issuers – pgs. 6-7
New Digital Entity Identifier for Visa Checkout
Required for Visa Debit and Credit – pg. 7
MasterCard
MasterCard Provisioning Advices
Recommended for Payment Tokenization Participants - pgs. 7-8
EMV Liability Shift for POS Transactions Reminder – pg.8
Chip On-behalf Services Enhancements
Required for Credit, Debit, Cirrus, Maestro, if participating in service – pgs. 8-9
New Cardholder Authentication Indicator
Required Credit, Debit and Maestro when EMV is enabled – pg. 9
Revised Standards for Processing Authorizations and Pre-authorizations
Required for Credit, Debit – pgs. 9-10
MoneySend Additional Data
Required for Credit, Debit, Maestro and Cirrus – pg. 10
MasterCard Digital Enablement Service Transaction Detail Service Enhancement
Required when tokenization is enabled for Credit, Debit and Maestro – pg. 10
Digital Secure Remote Payment Enhancements
Required when tokenization is enabled for Credit, Debit and Maestro - pgs. 10-11
MoneyPass
EMV, Mixed Media Deposits and Mobile Authentication transactions - pg. 11
DE 124 Payment Token Tags - pgs. 12-14
ISO 8583 Processor Interface Specification Data Elements
DE 111 - pgs. 15-25
DE 124 - pgs. 26-37
3
Tokenization Update
Provisioning Advice Messages ** This is information may apply to Visa and/or MasterCard
In support of Tokenization provisioning and to provide credit unions with a means to identify when
a member has provisioned a device, CO-OP has implemented an online 0120 Advice message. The
0120 advice messages from Visa are in production today. The 0120 advice messages from
MasterCard will be available with the October 2015 release.
MasterCard issuers currently participating in Apple Pay that would like to begin receiving the 0120
provisioning notification messages must first confirm with your core vendor that this message type
is supported. If supported and you would like to enable this functionality, a service request can be
submitted via the CO-OP Extranet; the type will be “Other” and explain that you would like to
enable token provisioning messages.
Provisioning Authorization Advice Message (0120) Attributes: Message Type – 0120
Process code – 920000
Transaction amount - $0.00
DE 60 – Advice/Reversal Reason Code (see table below)
DE 124 – Acquirer Info Text/ Payment Token Data -TLV format (see table below)
Both Visa and MasterCard provide a variety of information in both tokenized transactions and the
provisioning messages. The payment token transaction data, along with other data such as Multi-
Clearing Count and Multi-Clearing Sequence number are passed in DE 124, in various tags. See list
of Payment Token Tags below.
If you have not already enabled DE 124 and you wish to enable this feature, a service request can
be submitted via the CO-OP Extranet; the type will be “Other” and explain that you would like to
enable DE 124.
DE 124 - Expand Length from 255 to 999 bytes
Today, DE 124, FIS Tags, Acquirer, supports multiple tags and corresponding data that consist of
tokenized data that conforms to the TLV format (tag-length-variable data) for up to a maximum of
255 bytes. The data received in DE 124 is preceded by a 3-byte length indicator - indicating the
overall length of the field.
Effective October 16, 2015, the option to increase this field from a maximum of 255 bytes to a
maximum of 999 will be available. Issuers have the option to use the current length or to use the
extended length option.
The extended length option is recommended for supporting token provisioning messages. The
number of tokens and the amount of data in a tokenized message can easily exceed 255 bytes of
data. With the TLV format and a setting of 255 bytes, if the message reaches the maximum of 255
bytes in the middle of the tag, the system will drop the tag in process and only provide the last full
tag. To avoid any loss of data or potential host system issues when attempting to process the
4
message, we recommend credit unions that elect to receive DE 124 also request the expanded
length setting.
If you are already receiving token provisioning messages, be sure to verify with your vendor that
they have made the changes necessary to support the expanded length field. Once your core
supports the extended length, you will need to contact CO-OP to complete the database work
necessary to increase the message size. A service request should be submitted via the CO-OP
Extranet; the type will be “Other” and explain that you would like to increase DE 124 to a
maximum of 999 bytes.
Important Note: For hosts that receive packed numerics, the length field for any data element
that has a maximum length exceeding 255 bytes will have a 2 byte length field. All other data
elements will continue to have a 1 byte length field.
Visa
Visa Merchant Identifier and Digital Commerce Program Indicator (Required when tokenization is enabled for PAVD, Interlink, Debit and Credit)
Effective with the October 2015 release, Visa will mandate that issuers accept the fields required to
support merchant identification. These fields, populated by Visa in authorization and full financial
request messages, will establish a unique merchant identifier and a Digital Commerce Program
indicator to provide issuers with more detailed information for authorization decisions.
The merchant-level identifier is a unique Visa-assigned value that Visa will use to communicate
global merchant recognition to issuers. This field will contain a unique identifier value established
by Visa for each merchant included in the identification program. The identifier and indicator are for
informational purposes only, and will be used to identify specific merchants and transactions that
qualify for the Digital Commerce Program.
Issuers will be required to support the following:
• Visa Merchant ID –DE 111, VD format, sub-element 35, data length 8, will contain a
unique Visa-assigned merchant identifier value. Visa mentioned that the Merchant ID is
being assigned to easily identify large, sophisticated e-commerce merchants who employ
advanced risk management practices. The transactions coming in from these merchants are
presumably more trustworthy than from a small e-commerce merchant. NOTE - Issuers
can obtain a list of Visa-assigned merchant identifiers from Visa Online (VOL).
• Service Indicators – DE 111, sub-element 26, data length 6, will identify merchant
participation in the Digital Commerce Program, this is an existing field.
EMV Liability Shift for POS Transactions
Reminder: Effective October 1, 2015, Visa Rules will institute a U.S. region liability shift for
domestic and interregional counterfeit card-present POS transactions, excluding transactions
initiated at automated fuel dispensers (AFDs).
5
The EMV liability shift provides meaningful incentives for stakeholders—issuers and merchants—to
invest in new technologies to reduce fraud. From October 1, 2015, the liability for counterfeit fraud
resides with the party that did not deploy chip technology. If chip card data is compromised and a
counterfeit magnetic-stripe card is created, liability for any subsequent counterfeit fraud
transactions will reside with the acquirer or the merchant that did not deploy chip technology at the
point of sale. AFDs and ATMs are not covered until October 2017.
In addition to the impacts from the EMV liability shift, EMV chip transactions may have additional
impacts on dispute processing. In some instances, use or attempted use of EMV technology may
provide new rights of chargeback; in other instances, its use may prohibit existing chargeback
rights.
Visa Token Service
(Required when tokenization is enabled for PAVD, Interlink, Debit and Credit)
Covers:
Cloud-Based Payment Token Transactions for Host Card Emulation (HCE) Mobile Devices
Visa Token Service to Support E-Commerce and Card-on-File Tokenization for Issuers
Token Support Provisioning and Processing Changes
Visa will enhance the Visa Token Service to support provisioning and processing capabilities for
host card emulation (HCE) mobile devices. With this release, issuers will be able to enable HCE
mobile devices solutions supported by mutual partners.
New tags will be added on the request and response messages and will be passed in ISO DE 124 to
support processing of HCE and SE transactions.
The 0100/0110 Token Activation and 0120/0130 STIP Advice Messages for HCE Mobile Devices will
contain new Advice/Reversal Reason codes and new tags in DE 124.
New reason codes will be passed in DE 060 – Advice/Reversal Reason Code to support two new
Visa reason codes:
DE 60
Advice Reason Description
Acqr Msg Reason Code in
DataNavigator
2P Replenishment confirmation of limited
use keys
3715
2R Call center activation 3702
The advice/reversal reason code descriptions displayed on settlement reports will be:
2P = ‘REPL LUK’
2R = ‘CAL ACTV’
We will be adding two new tags in DE 124 in the 0100/0110 messages in support of both HCE and
SE transactions.
Tag W2 - Wallet account ID
6
Tag WA - Wallet account email address
Other Tag changes in the Token Activation and STIP Advice Messages:
Tag D1 - added new device types. See full list of device types in the DE 124 Payment
Token Tags list below.
The existing tag T5 will have a new value “VI” to identify the token provider. The value 4 is being
removed from tag T5. This value is not in the provisioning messages today but will be added with
the October release.
Issuers that support the following chip options, token convert, full chip data, early chip data, icvv
convert and for Visa payWave NFC POS transactions initiated from HCE mobile devices must be
prepared to receive these new tags:
Tag TE - Elapsed Time to Live
• Tag TF - Count of Number of Transactions
• Tag TG - Cumulative
Visa has continued to expand the Visa Token Service to support proximity payments for issuer
wallets and additional third-party wallet providers.
The Visa Token Service will be further enhanced to support token provisioning, transaction
processing, and lifecycle management for application-based e-commerce payments from additional
third-party wallet providers and tokenization of Visa cards at e-commerce wallet providers and
other e-commerce enablers, such as Visa Checkout.
Issuers that participate in the Visa Token Service and support e-commerce and card-on-file tokens
will see two new tags.
Tag W2 = Wallet account ID
Tag WA = Wallet account email address
Original Credit Transactions (OCT)
(Required for Interlink Issuers)
Effective with the October 2015 release, Visa will require all Interlink issuers to support their
money transfer product, Original Credit Transaction (OCT). Acquirer support is optional and is not a
part of this mandate implementation.
Issuer OCT transaction will use the following process code:
Process code
information:
Online and
User File
Process Code
Message
Level
Report
Acronym
Description
550000 0100 PE Auth Funding Payment
550000 0200 PF Funding Payment to 3rd Party
7
550009 0200 PO Payment from 3rd Party to Other
550010 0100 PH Auth Savings Payment
550010 0200 PS Savings Payment from 3rd Party
550020 0100 PB Auth DDA Payment
550020 0200 PD DDA Payment from 3rd Party
550030 0100 PA Auth Credit Payment
550030 0200 PC Credit Payment from 3rd Party
550009 0200 PC Payment from 3rd Party to Other
560000 0200 P4 Pmt from 3rd Party to Funding (P2P)
560009 0200 P6 Pmt from 3rd Party to Other (P2P)
560010 0200 P7 Pmt from 3rd Party to Savings (P2P)
560020 0200 P8 Pmt from 3rd Party to Checking (P2P)
560030 0200 P9 Pmt from 3rd Party to Credit (P2P)
Visa also supports an associated, optional, account funding transaction (AFT) that can be used to
collect funds from a sender’s Visa account. The AFT transaction is a debit to your member’s
account for the purposes of funding a subsequent Original Credit Transaction. This transaction
would appear as a 0100/0200 level authorization, process code 000000. The 0100 level
authorization will be followed by a subsequent 0220 force post transaction.
New Digital Entity Identifier for Visa Checkout
(Required for Debit and Credit)
Effective with the October 2015 release, Visa will require issuers to support merchant identification.
There will be new fields in DE 111, VD format, in authorization and full financial request messages
that will establish a unique merchant identifier and a Digital Commerce Program indicator to
provide issuers with more detailed information for authorization decisions for Visa Checkout
transactions.
The new field in DE 111, VD format is Agent Unique ID, sub-element 36 for a length of 5. The
Agent Unique ID for Visa Checkout = VCIND. See DE 111, VD format below.
MasterCard
MasterCard Provisioning Advices
(Recommended for Payment Tokenization Participants)
MasterCard will begin supporting the sending of advice messages to notify an issuer that
MasterCard has issued a token on their behalf and for other token maintenance events.
These advices can be sent as 0120 messages to your host. The following are the MasterCard
Advice/Reversal Reason Codes.
DE 60
Advice Reason Description
Acqr Msg Reason Code in
DataNavigator
2J Deactivate token 3701
2K Suspend token 3702
2L Resume token 3703
8
2M Tokenization complete 3711
2Q Tokenization exception event 3716
The Token tags that may be sent in DE 124 for a 0120 Provisioning/Token Event messages are:
Token Description Token Description
D1 Device Type TL Token Unique Reference
D2 Consumer Language TP Token Service Provider Identifier
D5 Device Name W1 Wallet ID
T1 Token WB Contactless Usage
T2 Token Assurance Level WC Card on File E-Commerce Usage
T3 Token Requestor ID WD Mobile/Digital Wallet E-Commerce Usage
T6 Token Expiration Date WG Final Token Decision
T8 PAN Unique Reference WH Final Tokenization Decision Indicator
T9 Token Type WI T&C Identifier
TH Correlation ID WJ T&C Date and Time
TI Number of Active Tokens for the PAN
WK Number of Activation Attempts
TK Event Requestor
EMV Liability Shift for POS Transactions
Reminder: MasterCard Global Readiness for the U.S. Region’s Inclusion in the Chip
The Chip Liability Shift program exists to motivate issuers and acquirers to migrate to EMV
technology, by protecting the EMV-capable party in a transaction from counterfeit fraud in the
event that the other party has not yet migrated. This is based on the assumption that, if EMV
technology was available and used, then the fraud would not have taken place.
Effective October 1, 2015, for transactions taking place at point-of-sale (POS) terminals, the
interregional Chip Liability Shift, will be in effect for the U.S. Region, which joins all other Regions.
The Chip liability shift means that when a counterfeit, fraud transaction occurs in a country or
region that has migrated to the EMV chip card platform, the liability for the transaction will shift to
the non–chip-compliant party.
In addition, if PIN is the preferred or required CVM in a country or MasterCard region, the liability
for lost, stolen, and never-received cards resulting in fraudulent MasterCard transactions when one
customer is not yet able to support chip/PIN transactions will be borne by that customer.
Chip On-behalf Services Enhancements
(Required for Debit, Credit, Cirrus, Maestro, if participating in service)
MasterCard is enhancing the M/Chip Cryptogram Pre-Validation Service (On-behalf Services/OBS)
with a decline option indicator for MasterCard to decline transactions on-behalf of participating
issuers when the Application Request Cryptogram or the chip data validation for the transaction is
9
not successful. Currently, MasterCard will only deny a transaction that fails ARQC or chip data
validation in stand-in.
The result of MasterCard’s validation will be passed in DE 123 under the existing tag “QR”. If
MasterCard declines a transaction that fails validation, in the 120/220 advice message they will
send a new value of “115” – Transaction Processed via On-behalf Service Decision, in DE 111, tags
MC and MD, under a new field “Advice Reason Code”. MasterCard is also adding new Advice Detail
Codes that will be sent in DE 111, MC tag in existing field “Advice Detail Code” and MD tag new
field “Advice Detail Code”. The Advice Detail Code values are:
0032 - Chip Data Processing Error
0037 - No matching key file for this PAN, PAN expiry date and KDI combination-
Validation of ARQC and CVR/TR not performed.
0038 - Security platform time out
0040 - Security platform error
0059 - DE055 format error
The implementation date for this article is January 22, 2016, for Maestro and Cirrus and February
12, 2016, for MasterCard Debit and Credit signature transactions.
New Cardholder Authentication Indicator
(Required Credit, Debit and Maestro when EMV is enabled)
MasterCard is introducing a new indicator for cardholder authentication to enable certain
government programs to confirm the identity of the cardholder. Transactions will be processed
through the MasterCard network through EMV Chip contact or EMV Contactless interface (POS
Entry mode value 05 or 07) as Account Status Inquiry transactions. Account Status Inquiry
transactions are 0100 messages with a transaction amount of $0.00 and process code 00xx00. The
Authentication Indicator can also be passed in a standard purchase or cash transaction.
The Cardholder Authentication Indicator, “1”-Transaction qualified for Authentication Service Type
1 or “2”-Transaction qualified for Authentication Service Type 2, will be passed in DE 111 under the
MC, MD and MI tags in a new field, Authentication Indicator.
MasterCard has stated they will supply additional information regarding support of the new
Authentication Indicator and Authentication Service Types 1 and 2 in future publications.
Revised Standards for Processing Authorizations and Pre-authorizations
(Required for Credit, Debit)
MasterCard is extending the usage of incremental authorization to all merchant types. Incremental
authorizations are currently restricted to Travel and Entertainment merchant types. Incremental
authorizations allow a merchant to associate multiple pre-authorizations to a single clearing
presentment.
Merchants may submit incremental authorizations for either an additional amount or zero ($0.00)
dollar amount. Incremental authorizations for an additional amount may be used to increase the
10
authorized amount held against the card account and to extend the chargeback protection
associated with the original pre-authorization. Incremental authorizations for a zero amount may
be used to extend only the chargeback protection period associated with the original pre-
authorization.
MoneySend Additional Data
(Required for Credit, Debit, Maestro and Cirrus)
MasterCard will be sending additional information in DE 109-Sender Data and DE 110-Receiver
data for MoneySend transactions.
Tag “DB”-Date of Birth and tag “AN”- Account Number will be added to DE 110-Receiver Data. Both
those tags are already present in DE109-Sender Data. A new tag “PI”-Participation ID is being
added to DE 109-Sender Data.
If you are not currently receiving DE 109 and DE 110 and wish to receive this data, please submit a
service request via the CO-OP Extranet to enable DE 109 and DE 110. Once enabled, DE 109 and
DE 110 may appear in transactions other than MasterCard MoneySend transactions. Host systems
will be required to handle any transaction containing DE 109 and DE 110.
MasterCard Digital Enablement Service Transaction Detail Service Enhancement
(Required when tokenization is enabled for Credit, Debit and Maestro)
MasterCard will be calculating a token transaction identifier for all authorization requests, financial
transaction requests, and advice messages where the MasterCard Digital Enablement Service has
been performed and correctly formatted cryptography data is available. The token transaction
identifier is used by the wallet provider to match transaction details to specific token transactions
initiated via contactless or Digital Secure Remote Payment (DSRP), or that leverage magnetic
induction technology at magnetic stripe POS terminals.
The token transaction identifier will be passed in DE 124 in a new tag “TM”-Token Transactions
Identifier. It can be present in 0100/0120 messages for signature transactions and 0200/0220 for
pinned transactions. See list of Payment Token Tags below.
Digital Secure Remote Payment Enhancements
(Required when tokenization is enabled for Credit, Debit and Maestro)
MasterCard will be performing UCAF validation (SecureCode) for Digital Secure Remote Payment
transactions when both the merchant and issuer are UCAF enabled. The result of that validation will
be passed in DE 123 “VR” tag.
CAVV Result Description
0 CAVV authentication results invalid
2 CAVV passed validation-authentication
D CAVV was not validated-authenticated
11
On a partial shipment or recurring payment, MasterCard will not perform UCAF validation, but will
pass a new UCAF Collection Indicator value of “7”. The value will be passed in DE 111 “MC” tag,
field name, UCAF Collection Indicator.
MasterCard UCAF
Values
Description
0 UCAF data collection is not supported by this merchant
1 UCAF data collection is supported by the merchant, but UCAF data was
not populated
2 UCAF data collection is supported by the merchant and UCAF data must
be present
3 UCAF data collection is supported by the merchant and UCAF
(MasterCard assigned Static Accountholder Authentication Value) data
must be present
4 Reserved for future use
5 MasterPass transaction goes thru 3DS protocol, authenticated
transaction using issuer’s risk based decisioning
6 MasterPass transaction does not go thru 3DS protocol, merchant does
not participate in SecureCode but has their own risk based decisioning
enabled
7 (New) Partial shipment or recurring payment. Liability will depend on the
original UCAF values from the initial transaction
MoneyPass
EMV, Mixed Media Deposits and Mobile Authentication Transactions
MoneyPass has mandated processors be able to support EMV as well as two additional features. In
addition to EMV support, CO-OP will be compliant with these requirements effective October 16,
2015. The new features are:
Mixed Media deposits - processors are required to pass the Deposit Type Token
Support for Mobile Authentication transactions
12
DE 124 Payment Token Tags
Tag Description T1 Token for Original PAN
T2 Token Assurance Level – contains a value indicating the confidence level of the token to PAN/Cardholder relationship
T3 Token Requestor ID – the ID assigned by the Token Service Provider (TSP) to the Token Requestor
T4 PAN Information – can be the full PAN, PAN range, last 4 digits of PAN, etc.
T5 Token Transaction Identifier – contains the network from which the token transaction came from
Values: MC – MasterCard generated token data PU – Pulse generated token data
NY – NYCE generated token data ST – STAR generated token data VI –Visa generated token data
T6 Token Expiration Date – expiration date associated with the token
T8 Token Reference Number – contains the value used as a substitute for the payment token
T9 Token Type – contains how the token transaction was initiated
Values: CF – Card on File SE – Secure Element HC – HCE (Host Card Emulation)
TA Token Status – contains the current status of the token
Values: A – Active for payment I – Inactive for payment (not yet active)
S – Temporarily suspended for payments D – Permanently deactivated for payments
TB Token Lookup Tran ID – contains a TSP-provided reference from the original de-
tokenization process
TC Token Activation Verification Result
TD Active Account Management (AAM) Velocity Checking Result.
TE Elapsed Time to Live
TF Count of Number of Transactions
TG Cumulative Transaction Amount
TH Correlation ID – identifier assigned by MC to associate related tokenization request/notification messages
TI Number of Active Tokens for the PAN – Number of existing active tokens for the primary account number, including the current token, but excluding Card on File tokens
TJ Tokenization Event Reason Code
TK Event Requestor – if the tokenization Event Indicator contains a value of 3 (Deactivate), 6 (Suspend), or 7 (Resume), this field will contain a value indicating the party that requested the event. If the Tokenization Event Indicator contains a value of 8 (tokenization Exception Event) this field will be space filled.
Values: 0 - Indicates the Tokenization Event was requested by the Wallet Service Provider 1 - Indicates the Tokenization Event was requested by the Funding Account issuer 2 - Indicates the Tokenization Event was requested by the Cardholder 3 - Indicates the Tokenization Event was requested in relation to a systematic event triggered by Mobile PIN Validation security (applicable to Tokenization Event Indicator value of 6 or 7 only)
4 - Indicates the Tokenization Event was requested in relation to a systematic event
13
triggered by Mobile PIN Change Validation security (applicable to Tokenization Event
Indicator value of 6 or 7 only) 5-9 – Reserved for future use
TL Token Unique Reference – Service allocated unique reference to the token
TM Token Transaction Identifier – a value calculated by MC or Visa when cryptography data is provided in token transactions initiated via contactless, DSRP or magnetic induction technology at magnetic stripe POS terminals
TP Token Service Provider Identifier – contains information on which network/entity is the TSP Values: MC – MasterCard VI – Visa ST – STAR
FD – FDC IS – Issuer AQ - Acquirer
D1 Device Type Values:
00 – Unknown 01 – Mobile Phone 02 – Tablet 03 – Watch 04 – Wrist Band 05 – Key Fob 06 – Card
07 – MNO Wallet 08 – Mobile Tag 09 – Mobile Case/Sleeve 10 – Mobile Phone MNO Fixed SE (car etc) 11 – Mobile Phone Removable SE 12 – Mobile Phone Fixed SE Wallet
13 – Tablet MNO Removable SE
14 – Tablet MNO Fixed SE 15 – Tablet Removable SE 16 – Tablet Fixed SE 99 – Other
D2 Device Language Code
D3 Device Secure Element ID
D4 Device Number
D5 Device Name
D6 Device Location
D7 IP Address
W1 Wallet ID
W2 Wallet account ID
W3 Wallet Provider Risk Assessment
W4 Wallet Provider Risk Assessment Version
W5 Wallet Provider Device Score
W6 Wallet Provider Account Score
W7 Wallet Provider Reason Score
W8 PAN Source
WA Wallet Email ID
WB Contactless usage – contains value indicating if the token is permitted for use in contactless transactions Values:
0 – Token is not permitted for use in contactless transactions 1 – Token is permitted for use in contactless transactions
WC Card on File Electronic Commerce Usage – contains value indicating if the token is permitted for use in card on file electronic commerce transactions.
14
Values:
0 – Token is not permitted for use in COF e-commerce transactions 1 – Token is permitted for use in COF e-commerce transactions
WD -Mobile/Digital Wallet e-Commerce Usage – contains value indicating if the token is permitted for use in mobile/digital wallet e-commerce transactions. Values: 0 – Token is not permitted for use in mobile/digital wallet e-commerce transactions 1 – Token is permitted for use in mobile/digital wallet e-commerce transactions
WE Issuer Product Configuration ID – unique card art product configuration identifier provided by the issuer associated with the graphical and text card art assests
WG Final Tokenization Decision – the final tokenization decision that was used in the tokenization of the card Values:
1 – Approved 2 – Approved but requires additional authentication
WH Final Tokenization Decision Indicator – the element of the Service that was
responsible for determining the final tokenization decision Values:
1 – Tokenization Eligibility Response 2 – Tokenization Authorization Response
WI T&C Identifier - Identifier associated with the version of terms and conditions accepted by the consumer In case of card on file- T&C is between consumer and merchant
WJ T&C Date and Time - Date and time that the consumer accepted the terms and conditions of the Service specified in UTC units Format: YYMMDDhhmm
WK Number of Activation Attempts – Number of activation code entry attempts by the cardholder when an Activation Code was entered
WM Payment Application Instance ID
WN identifying Cardholder Name
15
111 ADDITIONAL DATA, PRIVATE ACQUIRER (FIS-DEFINED)
Format: LLLVAR
Attributes: FIS: ans..255
ISO: ans..999
Description:
This data element is reserved by ISO for private definition and use.
FIS defines this data element as Additional Data, Private Acquirer,
which contains additional information for Visa® DCS, Visa EVES, Visa
DCS CRISSM, Benefits Transfer, MasterCard® CIS, MasterCard IPM and
PLUS® format. The layouts for this data follow.
Status
Visa® DCS Format
Subelement Name/Contents
Data
Length
Visa Bit
No.
FINIPC Bit
No.
Data Identifier. Value: VD 2 NA NA
Data Length plus the variable data. 3 NA NA
Data Byte Map. See FINIPC Bit Number. 8 NA NA
Variable Data: (based on byte map)
Authorization Characteristics Indicator 1 62.1 1
Market-Specific Data Indicator 1 62.4 2
Duration 2 62.5 3
Prestigious Property Indicator 1 62.6 4
Purchase Identifier 26 62.7 5
Check In/Check Out Date 6 62.8 6
No Show Indicator 1 62.9 7
Extra Charges 6 62.10 8
16
Restricted Ticket Indicator 1 62.13 9
Requested Payment Service 1 62.15 10
Chargeback Rights Indicator 2 62.16 11
Electronic Commerce Goods Indicator 2 62.19 12
Merchant Verification Value (MVV) 10 62.20 13
CAVV Result 1 44.13 14
Risk Score 4 62.21 15
Risk Condition Codes 6 62.22 16
Processing Codes 6 3 17
Terminal Type 1 60.1 18
Additional POS Information 2 60.8 19
Excl Transaction ID Reason Code 1 62.18 20
STIP Reason Code 4 63.4 21
Visa Charge Indicator. Value to indicate the
International Service Assessment (ISA).
Blank = Fee Not Assessed
S = Fee Assessed
R = Fee Rebated
B = Fee Assessed
E = Fee Assessed
1 63.21 22
Latin America Caribbean Optional Issuer International
Service Assessment
15 46 23
Consumer Credit Account-Level Product Identification 2 62.23 24
Cardholder ID Method 1 60.9 25
MIS Reason 4 63.3 25
Recurring Pay Ind. 1 126.13 25
17
Service Indicators (Deferred Bill) 6 126.12 26
Response Code 2 39 27
Payment Type Indicator (DE104/x"57") reserved 1 104 28 reserved
for future use
DE48 - Usage 4 38 48 29
Business Application Identifier 2 104
usage 2
hex 57
Tag 01
30
Visa AVS Result Value 1 44.2 31
Byte Map 2 8 N/A 32
Dynamic Currency Conversion Indicator 1 126.19 33
Spend Qualified Indicator 1 62.25 34
Visa Merchant ID 8 126.5 35
Agent Unique ID 5 126.18 36
MasterCard® CIS Format
Subelement Name/Contents
Data
Length
MasterCar
d Bit No.
FINIP
C Bit
No.
Data Identifier. Value: MC 2 NA NA
Data Length plus the variable data. 3 NA NA
Data Byte Map. See FINIPC Bit Number. 8 NA NA
Variable Data: (based on byte map)
Merchant Advice Code 2 48.84 1
18
Fraud Data. This data contains the following three
subfields for a total length of 9:
2
POS Entry Mode 3 22
Response Code 2 39
POS Data - POS Terminal Attendance
POS Data - POS Cardholder Presence
POS Data - Card-Activated Terminal Level
POS Data - POS Card Data Terminal Input Capability
1
1
1
1
61.1
61.4
61.10
61.11
Advice Detail Code 4 60.2 3
Magnetic Stripe Compliance Status Indicator 1 48.88 4
Magnetic Stripe Compliance Error Indicator 1 48.89 5
Postal Code 10 61.14 6
POS Card Presence
0 = Present
1 = Not Present
1 61.5 7
Payment Type Indicator 3 48.77 8
MC Assigned ID 6 48.32 9
MC Fraud On-Behalf Result 1 48.71.2 10
MC Fraud Score Information 3 48.75.1 11
MC Healthcare IIAS Exemption 1 48.61.3 12
Processor Pseudo ICA 7 48.16 13
Authorization System Advice Date and Time 10 48.15 14
Account Data Compromise Event Messaging Service Data
Result
1 48.71.2 15
Account Data Compromise Event Messaging Service Data 30 48.39 16
Partial Approval Terminal Support Indicator 1 48.61.1 17
19
MC Fraud Score Reason Code 2 48.75.2 18
POS Transaction Status Indicator 1 61.7 19
Remote Payments Program Type Identifier 1 48.48.1 20
Payment Initiation Channel Device Type 2 48.23.1 21
UCAF Collection Indicator 1 48.42.1.3 22
Transit Transaction Type Indicator 2 48.64.1 23
Transportation Mode Indicator 2 48.64.2 24
PPOL Identifier 3 48.26.1 25
Final Auth Indicator 1 48.61.5 26
Terminal Compliant Indicator 2 48.65 27
MC On-behalf Service 2 48.71.1 28
MC On-behalf Result 1 1 48.71.2 29
Merchant Fraud Score 4 112.28 30
Payment Facilitator ID 11 48.37.1 31
Secondary Bit Map 8 N/A 32
Sales Organization ID 11 48.37.2 33
Sub Merchant ID 15 48.37.3 34
Authentication Indicator 1 48.17 35
Advice Reason Code 3 60.1 36
20
MasterCard® MDS Format
Subelement Name/Contents
Data
Length
MasterCard Bit
No.
FINIP
C Bit
No.
Data Identifier. Value: MD 2 NA NA
Data Length (byte map + variable data) 3 NA NA
Data Byte Map (See FINIPC Bit No.) 8 NA NA
Variable Data (Based on Byte Map)
Tier Merchant ID 6 DE110.1 1
Cross Border Indicator 2 2
Transaction Indicator-Position 1 DE126, position 14
Y = Qualifies as a cross-border transaction
N = Does not qualify as a cross-border
transaction
Currency Indicator-Position 2 DE126, position 15
X = Transaction does not qualify as a cross-
border transaction.
Y = Transaction was submitted in the
currency of the country where the
merchant is located.
N = Transaction was not submitted in the
currency of the country where the
merchant is located.
ISA Flag
0 = No International Fee
1 = International Fee Debited
2 = International Fee Credited
1 DE 110.4 3
Financial Network Code 2 DE63, subfield 1 4
Card Present 1 DE61, position 5 5
21
Operating Environment 1 DE61, position 3 6
POS Terminal Attendance Indicator 1 DE61, position 1 7
POS Cardholder Presence Indicator 1 DE61, position 4 8
Cardholder Activated Terminal Level Indicator 1 DE61, position 10 9
POS Card Data Terminal Input Capability Indicator 1 DE61, position 11 10
POS Entry Mode 2 DE22 11
Payment Type Indicator 3 48.77 12
MC Assigned ID 6 48.32 13
MC Healthcare IIAS Exemption 1 48.61.3 14
POS Transaction Status 1 61.7 15
Remote Payments Program Type Identifier 1 48.48.1 16
Payment Initiation Channel Device Type 2 48.23.1 17
Transit Transaction Type Indicator 2 48.64.1 18
Transportation Mode Indicator 2 48.64.2 19
Maestro Pin-less Program Indicator 1 48.81 20
Acquiring Institution Id 11 32 21
Card Acceptor ID 15 42 22
PPOL Data 3 48.26 23
Terminal Compliant Indicator 2 48.65 24
MC On-behalf Service 2 48.71.1 25
MC On-behalf Result 1 1 48.71.2 26
AllPoint Surcharge-Free Alliance Indicator 1 43, subfield 2 27
22
Merchant Fraud Score 4 112.28 28
Payment Facilitator ID 11 48.37.1 29
Sales Organization ID 11 48.37.2 30
Sub Merchant ID 15 48.37.3 31
Secondary Bit Map 8 NA 32
Authentication Indicator 1 48.17 33
Advice Reason Code 3 60.1 34
Advice Detail Code 3 60.2 35
MasterCard® IPM Format
NOTE This format does not apply to the MasterCard 0100 authorization
messages.
Subelement Name/Contents
Data
Length MasterCard Bit No.
Data Identifier. Value: MI. 2 NA
Data Length plus the variable data. 3 NA
Processing Code 6 IPM DE 3
POS Condition Code. This data contains the following 12
subfields for a total length of 12.
IPM DE 22
Card Data Input Capability 1 IPM DE 22-S1
Cardholder Authentication Capability 1 IPM DE 22-S2
Card Capture Capability 1 IPM DE 22-S3
Terminal Operating Environment 1 IPM DE 22-S4
23
Cardholder Present Data 1 IPM DE 22-S5
Card Present Data 1 IPM DE 22-S6
Card Data Input Mode 1 IPM DE 22-S7
Cardholder Authentication Method 1 IPM DE 22-S8
Cardholder Authentication Entity 1 IPM DE 22-S9
Card Data Output Capability 1 IPM DE 22-S10
Terminal Data Output Capability 1 IPM DE 22-S11
PIN Capture Capability 1 IPM DE 22-S12
Card Acceptor Inquiry Information. This data contains
the following three subfields for a total length of 57:
IPM PDS 0170
Customer Service Phone Number 16 IPM PDS 0170-S1
Card Acceptor Phone Number 16 IPM PDS 0170-S2
Additional Contact Information 25 IPM PDS 0170-S3
Card Acceptor Postal Code 10 IPM DE 43-S4
Local Date and Time 12 IPM DE 12
Airline/Railway Ticket Number 15 IPM PDS 0506
Program Registration ID 3 IPM PDS 0043
Interchange Life Cycle 15 IPM PDS 0263
Cross Border Transaction Indicator 1 IPM PDS 0177-S1
Y = Qualifies as a cross-border transaction
N = Does not qualify as a cross-border
transaction
Cross Border Currency Indicator 1 IPM PDS 0177-S2
24
Blan
k = Transaction does not qualify as a cross-
border transaction.
Y = Transaction was submitted in the
currency of the country where the
merchant or ATM is located.
N = Transaction was not submitted in the
currency of the country where the
merchant or ATM is located.
MasterCard Assigned ID 6 IPM PDS 0176
Payment Transaction Initiator 3 IPM PDS 0192
CVC 2 Validation Program Indicator 1 IPM PDS 0044 subfield
1
QPS/PayPass Chargeback Eligibility Indicator 1 IPM PDS 0044 subfield
2
Remote Payments Program Type Identifier 1 IPM PDS 0194
Payment Initiation Channel Device Type 2 IPM PDS 0198
Transit Transaction Type Indicator 2 IPM PDS 0210, subfield
1
Transportation Mode Indicator 2 IPM PDS 0210, subfield
2
PPOL Identifier 3 IPM PDS 0207
Terminal Compliant Indicator 2 IPM PDS 0211
Payment Facilitator ID 11 PDS208
Sub Merchant ID 15 PDS208
Sales Organization ID 11 PDS209
Authentication Indicator 1 PDS 0072
25
FIS Requirements
Message Types Status Information
0100, 0110, 0120, 0200,
0210, 0220, 0420
Optional.
0600 Administrative Risk
and Administrative
Request
Conditional if Network Management Information Code
(bit 070) equals 601, 810, 811, 812, 821, or 822.
26
124 FIS TAGS, ACQUIRER / INFO, TEXT (FIS-DEFINED)
Format: LLLVAR
Attributes: FIS: ans..999
ISO: ans..999
Description: FIS defines this data element for use in financial messages to provide
additional capability for exchanging data between acquirer hosts. Data
passed in these data elements must be tokenized, assuming a TLV
format (tag, length, variable length data), for financial messages.
FIS defines this data element as Info, Text, additional information used
for AP file update information in AP file update transactions. It is also
used for administrative and network management transactions. (See
“0600/0620 Administrative Message Information” on page 464.”)
Layout for Financial Messages
DE124 (FIS Tags, Acquirer) is activated to provide acquirers the ability to pass additional
information to issuer hosts on financial requests or reversals.
In order to optimize this ISO field for general purpose, this data element consists of tokenized
data that conforms to the TLV format (tag-length-variable data). This is enforced via edit-
checking upon receipt of this data element.
DE124 supports multiple tokens and corresponding data for up to a maximum of 999 bytes each.
The data received in DE 124 is preceded by a 3-byte length indicator - indicating the overall
length of the field. The sub-elements contained in either ISO data element must conform to the
following format:
xxyyzzzz
where:
xx Is a 2-byte arbitrary alpha-numeric tag ID.
yy Is 2-bytes containing the length of data to follow. Values range from 00 to a
maximum of 99.
zzzz Is the data for length defined in yy.
Following is an example for DE124 (FIS Tags, Acquirer):
Example
023T105xxxxxT210yyyyyyyyyy
In this example, the length of the field is "023". The Tag ID is identified as "T1" has a data length
of "05" where the data contains "xxxxx". Tag ID "T2" has a data length of "10" where the data
contains 10 bytes with a value of "yyyyyyyyyy".
Payment Token Data The Payment Token is of the following format:
27
T1LLzzzT2LLyyyT3LLxxxT4LLwwwT5LLvvvT6LLuuuT8LLtttT9LLsssTALLrrrTBLLqqqT
PLLppp
where:
Tag Description
T1 Is the 2 byte literal identifying Token for original PAN.
LL Is the length of Token for Original PAN.
zzz Is the Token for Original PAN.
T2 Is the 2 byte literal identifying Token Assurance Level.
LL Is the length of Token Assurance Level.
yyy Is the Token Assurance Level. Token Assurance level contains a value
indicating the confidence level of the token to PAN/Cardholder
relationship
T3 Is the 2 byte literal identifying Token Requestor ID.
LL Is the length of Token Requestor ID.
xxx Is the Token Requestor ID. Token Requestor ID is the ID assigned by
the Token Service Provider (TSP) to the Token Requestor.
T4 Is the 2 byte literal identifying PAN Information.
LL Is the length of PAN Information
www Is the PAN Information. PAN Information can be the Full PAN, PAN
range, Last four digits of PAN etc.
T5 Is the 2 byte literal identifying Token Transaction Identifier.
LL Is the length of Token Transaction Identifier.
28
vvv Is the Token Transaction Identifier. Token Transaction Identifier
contains the network from which the token transaction came from.
Currently defined values are:
MC = MasterCard generated token data
VI = Visa generated token data
PU = Pulse generated token data
NY = NYCE generated token data
ST = STAR generated token data.
T6 Is the 2 byte literal identifying Token Expiration Date.
LL Is the length of Token Expiration Date.
uuu Is the Token Expiration Date. Token Expiration Date contains the
Expiration date associated with the token.
T8 Is the 2 byte literal identifying Token Reference Number.
LL Is the length of Token Reference Number.
ttt Is the Token Reference Number. Token Reference Number contains
the value used as a substitute for the Payment Token that does not
expose information about the Payment Token or the PAN that the
Payment Token replaces.
T9 Is the 2 byte literal identifying Token Type.
LL Is the length of Token Type.
sss Is the Token Type. Token Type contains how the token transaction
was initiated. Currently defined values for Token Type are:
CF = Card on File
SE = Secure Element
HC = HCE (Host Card Emulation).
TA Is the 2 byte literal identifying Token Status.
LL Is the length of Token Status.
rrr Is the Token Status. Token status contains the current status of the
token. Currently defined values for Token Status are:
A = Active for payment
I = Inactive for payment (not yet active)
S = Temporarily suspended for payments
D = Permanently deactivated for payments.
TB Is the 2 byte literal identifying Token Lookup Tran ID.
29
LL Is the length of Token Lookup Tran ID.
qqq Is the Token Lookup Tran ID. Token Lookup Tran ID contains a TSP-
provided reference from the original de-tokenization process.
Payment Token Tags
TC Is the 2 byte literal identifying Token Activation Verification Results.
LL Is the length of Token Activation Verification Results.
abc Is the Token Activation Verification Results. Token Activation
Verification Results contains one of the following OTP verification
result and mobile banking application code values:
1 = Successfully verified
2 = Verification code expired
3 = Verification code failed
4 = Verification code missing
5 = Verification code retries exceeded.
TD Is the 2 byte literal identifying Active Account Management (AAM)
Velocity Checking Result.
LL Is the length of AAM Velocity Checking Result.
abc Is the AAM Velocity Checking Result. This tag contains one of the
following Host Card Emulation (HCE) transaction verification result
values
:
2 = Time-to-live exceeded
3 = Count exceeded
4 = Amount exceeded.
TE Is the 2 byte literal identifying Elapsed Time to Live.
LL Is the length of Elapsed Time to Live.
abc Is the Elapsed Time to Live. This tag will contain the elapsed time in
hours since the current LUK was provisioned or replenished on the
device.
TF Is the 2 byte literal identifying Count of Number of Transactions.
LL Is the length of Count of Number of Transactions.
30
abc Is the Count of Number of Transactions. This tag will contain the
cumulative count of
the transactions for the current LUK.
TG Is the 2 byte literal identifying Cumulative Transaction Amounts.
LL Is the length of Cumulative Transaction Amounts.
abc Is the Cumulative Transaction Amounts. This tag will contain the
cumulative total of transaction amounts in USD for the current LUK.
TH Is the 2 byte literal identifying Correlation ID.
LL Is the length of Correlation ID.
abc Is the Correlation ID. Correlation ID is the identifier assigned by
MasterCard to associate related tokenization request/notification
messages.
TI Is the 2 byte literal identifying Number of Active Tokens for the PAN.
LL Is the length of Number of Active Tokens for the PAN.
abc Is the Number of Active Tokens for the PAN. This field indicates the
number of existing active tokens associated with the primary account
number.
TJ Is the 2 byte literal identifying Tokenization Event Reason Code.
LL Is the length of Tokenization Event Reason Code.
abc Is the Tokenization Event Reason Code. This field contains a value
that indicates the event reason. Currently defined values are:
00 = Activation code retries exceeded
01 = Activation code expired
02 = Activation code entered incorrectly by cardholder
03 = Replacement primary account number update failure.
TK Is the 2 byte literal identifying Event Requestor.
LL Is the length of Event Requestor.
31
abc Is the Event Requestor. This field will contain a value indicating the
party that requested the event. Currently defined values are:
0 = Wallet Service Provider
1 = Funding Account issuer
2 = Cardholder
3 = Mobile PIN Validation security
4 = Mobile PIN Change Validation security.
TL Is the 2 byte literal identifying Token Reference Number.
LL Is the length of Token Reference Number.
abc Is the Token Reference Number. Token Reference Number contains a
service-allocated unique reference to the token.
TM Is the 2 byte literal identifying Token Transaction Identifier.
LL Is the length of Token Transaction Identifier.
abc Is the Token Transaction Identifier. Token Transaction Identifier is
calculated by networks to identify the transaction. It is to be retained
and used to provide the transaction details associated with an
original purchase and subsequent reversal messages. It is a 44-byte
value for MC BIN ranges and a 64-byte value for Visa BIN ranges.
TP Is the 2 byte literal identifying Token Service Provider (TSP)
Identifier.
LL Is the length of Token Lookup Service Provider Identifier.
ppp Is the Token Service Provider Identifier. This field contains
information on which network/entity is the TSP. Currently defined
values for TSP Identifier are:
MC = MasterCard
VI = Visa
ST = STAR
FD = FDC
IS = Issuer
AQ = Acquirer.
Token Device Tags
D1 Is the 2 byte literal identifying Device Type.
LL Is the length of Device Type.
32
abc Is the Device Type. This field indicates the type of device used for
Tokenization. Currently defined values for Device Type are:
00 – Unknown
01 – Mobile Phone
02 – Tablet
03 – Watch
04 – Wrist Band
05 – Key Fob
06 – Card
07 – MNO Wallet
08 – Mobile Tag
09 – Mobile Case/Sleeve
10 – Mobile Phone MNO Fixed SE (car etc)
11 – Mobile Phone Removable SE
12 – Mobile Phone Fixed SE Wallet
13 – Tablet MNO Removable SE
14 – Tablet MNO Fixed SE
15 – Tablet Removable SE
16 – Tablet Fixed SE
99 – Other.
D2 Is the 2 byte literal identifying Device Language.
LL Is the length of Device Language.
abc Is the Device Language. This field indicates the preferred language
selected by the Cardholder.
D3 Is the 2 byte literal identifying Device Secure Element ID.
LL Is the length of Device Secure Element ID.
abc Is the Device Secure Element ID. This field contains the Device
Secure Element ID – currently present only for Visa token
transactions.
D4 Is the 2 byte literal identifying Device Number.
LL Is the length of Device Number.
abc Is the Device Number. This field contains full or partial mobile phone
number.
D5 Is the 2 byte literal identifying Device Name.
LL Is the length of Device Name.
33
abc Is the Device Name. This field contains the name that the consumer
has associated to the device with the wallet service provider.
D6 Is the 2 byte literal identifying Device Location.
LL Is the length of Device Location.
abc Is the Device Location. This field contains latitude and longitude of
the device the consumer is attempting to tokenize a card.
D7 Is the 2 byte literal identifying Device IP Address.
LL Is the length of Device IP Address.
abc Is the Device IP Address. This field contains the IP address of the
device at the time of the provisioning request.
Card Holder Wallet Tags
W1 Is the 2 byte literal identifying Wallet ID.
LL Is the length of Wallet ID.
abc Is the Wallet ID. Wallet ID indicates who the Wallet Provider was for
the token transaction.
W2 Is the 2 byte literal identifying Wallet Service Provider Account ID
Hash.
LL Is the length of Wallet Service Provider Account ID Hash.
abc Is the Wallet Service Provider Account ID Hash. Wallet Service
Provider Account ID Hash contains hash of the consumer’s account
ID with the wallet provider.
W3 Is the 2 byte literal identifying Wallet Service Provider Tokenization
Recommendation.
LL Is the length of Wallet Service Provider Tokenization
Recommendation.
34
abc Is the Wallet Service Provider Tokenization Recommendation. This
field indicates the risk assessment by the Wallet Service Provider.
Currently defined values are:
0 = Decline
1 = Approve
2 = Require additional authentication.
W4 Is the 2 byte literal identifying Wallet Service Provider Standard
Version.
LL Is the length of Wallet Service Provider Standard Version.
abc Is the Wallet Service Provider Standard Version. This field contains
the version of standards the wallet service provider is using to
determine the suggested tokenization recommendation.
W5 Is the 2 byte literal identifying Wallet Service Provider Device Score.
LL Is the length of Wallet Service Provider Device Score.
abc Is the Wallet Service Provider Device Score. This field contains the
score assigned by wallet service provider for the device.
W6 Is the 2 byte literal identifying Wallet Service Provider Account Score.
LL Is the length of Wallet Service Provider Account Score.
abc Is the Wallet Service Provider Account Score. This field contains the
score assigned by wallet service provider for the primary account
number.
W7 Is the 2 byte literal identifying Wallet Service Provider Reason Codes.
LL Is the length of Wallet Service Provider Reason Codes.
abc Is the Wallet Service Provider Reason Codes. This field contains the
code indicating the specific reason the wallet service provider is
suggesting the tokenization recommendation.
W8 Is the 2 byte literal identifying PAN Source.
LL Is the length of PAN Source.
35
abc Is the PAN Source. This field identifies the method which the
cardholder is attempting to tokenize a primary account number.
Currently defined values are:
1 = Card on File
2 = Card added manually
3 = Card added via application.
WA Is the 2 byte literal identifying Wallet Account Email Address.
LL Is the length of Wallet Account Email Address.
abc Is the Wallet Account Email Address. This field contains the e-mail
address of the Cardholder as provided in the Wallet Account.
WB Is the 2 byte literal identifying Contactless Usage Flag.
LL Is the length of Contactless Usage Flag.
abc Is the Contactless Usage Flag. This field contains a value indicating if
the token is permitted for use in contactless transactions. Currently
defined values are:
0 – Token cannot do contactless
1 – Token can do contactless.
WC Is the 2 byte literal identifying Card on File E-Commerce Usage Flag.
LL Is the length of Card on File E-Commerce Usage Flag.
abc Is the Card on File E-Commerce Usage Flag. This field contains a
value indicating if the token is permitted for use in Card on File E-
commerce transactions. Currently defined values are:
0 – Token cannot do Card on File E-commerce
1 – Token can do Card on File E-commerce.
WD Is the 2 byte literal identifying Mobile/Digital Wallet E-Commerce
Usage Flag.
LL Is the length of Mobile/Digital Wallet E-Commerce Usage Flag.
abc Is the Mobile/Digital Wallet E-Commerce Usage Flag. This field
contains a value indicating if the token is permitted for use in
Mobile/Digital Wallet E-commerce transactions.Currently defined
values are:
0 – Token cannot do Mobile/Digital Wallet E-commerce
1 – Token can do Mobile/Digital Wallet E-commerce
WE Is the 2 byte literal identifying Issuer Product Configuration ID.
36
LL Is the length of Issuer Product Configuration ID.
abc Is the Issuer Product Configuration ID. This field contains the unique
card art product configuration identifier provided by the issuer
associated with the graphical and text card art assets.
WG Is the 2 byte literal identifying Final Tokenization Decision Flag.
LL Is the length of Final Tokenization Decision Flag.
abc Is the Final Tokenization Decision Flag. This field contains the final
tokenization decision that was used in the tokenization of the
card.Currently defined values are:
1 = Approve
2 = Approve, requires additional authentication.
WH Is the 2 byte literal identifying Final Tokenization Decision Indicator.
LL Is the length of Final Tokenization Decision Indicator.
abc Is the Final Tokenization Decision Indicator. This field contains the
element of the Service that was responsible for determining the final
tokenization decision. Currently defined values are:
1=Tokenization Eligibility Resp.
2=Tokenization Authorization Response
3=Issuer predefined tokenization rules.
4=Mobile Application.
WI Is the 2 byte literal identifying Terms and Conditions Identifier.
LL Is the length of Terms and Conditions Identifier.
abc Is the Terms and Conditions Identifier. This field contains the
identifier associated with the version of terms and conditions
accepted by the consumer. In case of card on file - T&C is between
consumer and merchant.
WJ Is the 2 byte literal identifying Terms and Conditions Date/Time.
LL Is the length of Terms and Conditions Date/Time.
abc Is the Terms and Conditions Date/Time. This field contains the date
and time that the consumer accepted the terms and conditions of the
Service.
WK Is the 2 byte literal identifying Number of Activation Attempts.
37
LL Is the length of Number of Activation Attempts.
abc Is the Number of Activation Attempts. This field contains the number
of activation code entry attempts by the cardholder when an
Activation Code was entered.
WM Is the 2 byte literal identifying Payment Application Instance ID.
LL Is the length of Payment Application Instance ID.
abc Is the Payment Application Instance ID. This field contains the
identifier associated with the payment application instance ID on a
device.
WN Is the 2 byte literal identifying Cardholder Name.
LL Is the length of Cardholder Name.
abc Is the Cardholder Name. This field contains the name of the
Cardholder.