ISO Global 2008 3

©2008 First Data Merchant Services Corporation. All Rights Reserved. All information contained herein is
confidential and proprietary to First Data Merchant Services Corporation (“FDMS”). It shall not be disclosed,
duplicated, or used in part or in whole, for any purpose without prior written consent from FDMS. FDMS reserves
the right to make changes to specifications at any time and without notice. This information contained within is
believed to be accurate and reliable; however, no responsibility is assumed by FDMS for its use. All trademarks,
service marks, and trade names referenced in this material are the property of their respective owners.

Disclaimer
For future upgrades or general concerns, please contact your Relationship Manager. Please
check with your First Data Certification Representative before attempting to implement the
features described in this specification. The First Data Certification Representative will be
responsible for answering your questions, establishing connectivity, coordinating testing, and
validating message formats.
First Data Merchant Services Corporation (FDMS®) reserves the right to make changes to
specifications at any time and without notice. The information furnished in this publication is
believed to be accurate and reliable; however, no responsibility is assumed by FDMS for its
use.
Revision History
Filename: First Data ISO 8583 Global Specification 2008-311112008
The following table lists the additions, updates/modifications, and deletions made to this specification
during the last one year. All the additions and updates/modifications have been notated in blue text.
Changes made to this document in the last eighteen months
Page Brief Description of Change Version Revised Date
Title Updated the document version number to 2008-3 2008-3 10/24/2008
4-14 Bit 25 - Added a note on POS Condition code for 2008-3 10/24/2008
ECommerce Recurring Transactions.
4-17 Bit 37 - Added a note for Reversals 2008-3 10/24/2008
4-57 Added Bit 63 – Table (14) Discover NRID data 2008-3 10/24/2008
4-84 Updated Bit 63 — (Table 60 - MOTO/Bill Payment / 2008-3 10/24/2008
Electronic Commerce Additional POS Info) with
definitions of Visa and MasterCard Electronic
Commerce.
4-91 Updated Bit 63 — (Table 68) Additional 2008-3 10/24/2008
Account/Amount Information (Version 2 Usage —
Additional Account/Amount Information Support)
4-95 Updated Bit 63 — (Table 69) AUAR/TPP ID 4-94 2008-3 10/24/2008
4-112 Updated Discover Compliance Table to add Byte 2008-3 10/24/2008
4(RFU).
4-112 Field 63 (Table DS) Discover Qualification Field 2008-3 10/24/2008
Identifier Table to add NRID Field
4-117 Modified P2 table with Ecommerce - Invoice: Added 2008-3 10/24/2008
Conditional Requirement Matrix for Customer Code
and Tax Amount. Visa GSA purchase cards and Large
Ticket Programs require the Customer Code and Tax
Amount.
6-25 Added new Discover Bin Range 64500000 - 64999999. 2008-3 11/03/2008
In order to add this new bin range, existing bin range
64400000 – 64499999 was expanded to be 64400000-
64999999
6-17 Updated Currency Codes table 2008-3 11/11/2008
6-51 Added additional clarification concerning Partial 2008-3 10/24/2008
Authorization Capable Response for automated fuel
dispensers
4-9 Updated Time, Local Transmission (Bitmap 12) with 2008-2 04/22/08
mandatory requirement for Debit and EBT, and optional
but recommended for Amex and Discover transactions.
4-13 Added Network Identity Code (NII) for Canadian Debit 2008-2 04/22/08
in Bit 24
4-25 Updated Additional POS Information (Bitmap 60) to 2008-2 04/22/08
correct the error in POS type and POS (Terminal)
Capability values and their related description.
5-23 Updated the requirement of Acquirer Reference Data 2008-2 04/22/08
(Bitmap 31) as conditional in the sample messages
(Section 4) for authorization only (credit), Debit and
EBT, and Reversals.
2-11 Updated the time span (25 minutes instead of 30 2008-2 04/22/08
minutes), which merchants must submit reversal
request for Credit, Debit, and EBT host capture.
Version 2008-3 Confidential and Proprietary i
November 11, 2008 to First Data

First Data ISO 8583 Global Specification Revision History

Note: The time out consideration has been updated
throughout the document as applicable.
6-12 Updated Appendix C – Country Codes based on the 2008-2 04/22/08
most current codes received from the Card Association
6-17 Updated Appendix D – Currency Codes based on the 2008-2 04/22/08
most current codes received from the Card Association
Title Updated the legal copyright notice 2008-1 04/09/08
1-1 Updated the New Features section 2008-1 04/09/08
2-1 Added authorization and capture and capture only for 2008-1 04/09/08
host capture in the following sections:
Overview
Standard Message Types
Bit Definitions
Sample Messages
Appendix O
2-5 Updated Legends of Attributes to include Binary Code 2008-1 04/09/08
Decimal (BCD)
4-6 Added processing codes (Bit 3) for Prepaid card 2008-1 04/09/08
activation and load, Bill Payment/Recurring, and Echo
Test
4-14 Updated POS condition code 2008-1 04/09/08
Modified the following ISO Bit definitions: 2008-1 04/09/08
Bit 2
Bit 3
Bit 4
Bit 11
Bit 13
Bit 14
Bit 22
Bit 25
Bit 31
Bit 32
Bit 37
Bit 39
Bit 44
Bit 54
Bit 62
Updated Private Data Field Tables: 2008-1 04/09/08
Updated Summary of Tables
Added Merchant Advice code indicator for Visa
Recurring to indicate Direct Marketing and E-
Commerce in Updated Table Requirement for
Special Features
Added Merchant Advice code indicator for
Discover Recurring and VPAS in Updated Table
Requirement for Special Features
Modified the following tables in Bit 63:
Version 2008-3 Confidential and Proprietary ii


Revision History First Data ISO 8583 Global Specification

Table 14 - Added additional information and
examples of reversal and incremental
authorization for Visa and MasterCard
Table 20
Table 35
Table 49
Table 55 – Added Visa Recurring Payment
Cancellation
Table 60 - Added ECI Value Discover Recurring
Table 68 - Added FSA/HRA information
Table L1 (Loyalty Card)- Added Version 3
Table L2 (Loyalty Card) - Added version 2
Table PD – Added Promotional Data (PD)
Identifier table
Table P2 – Updated to include the tax amount
Made cosmetic changes in sample message types 2008-1 04/09/08
Added the following sample messages:
0100 Capture Only

0100 and 0110 Card load and activation
0210 Canadian Debit processing Response
Re-organized the Appendix sections 2008-1 04/09/08
6-2 Updated Appendix A — Response Codes in sequence 2008-1 04/09/08
by text to include Recurring transactions and exclude
ETC
6-5 Updated Appendix A - Response codes in sequence by 2008-1 04/09/08
code to include Recurring Transactions and exclude
ETC
6-17 Updated Appendix D — Currency Codes for countries, 2008-1 04/09/08
such as Venezuela, Ghana, Cyprus, and Malta
6-27 Updated Appendix G — Glossary 2008-1 04/09/08
6-39 Added TeleCheck State Codes in Appendix J 2008-1 04/09/08
6-41 Updated Appendix K — Additional Credit Card 2008-1 04/09/08
Processing Options with descriptive verbiage and
information on Visa and MasterCard Recurring
Response values and reason codes, NTIA Coupon
program, Partial Authorization Approval, and
HealthCare FSA/HRA transactions
6-57 Added Appendix L — General Information on Debit and 2008-1 04/09/08
EBT
6-71 Appendix 0 — Host Capture has been renamed as 2008-1 04/09/08
Appendix N — Host Capture. Updated Appendix N —
Host Capture to include authorization and capture, and
capture only transactions, Dual Event Settlements.
Removed Debit Function Code (Bit 124) 2008-1 04/09/08
Removed all references of Debit Store and Forward 2008-1 04/09/08
Transactions
Removed all references of ETC/SCAN 2008-1 04/09/08
Removed all references of Wright Express and 2008-1 04/09/08
Voyager including Petroleum product codes
Removed all references of INICIS 2008-1 04/09/08
Version 2008-3 Confidential and Proprietary iii


Removed Debit Preauthorization and Completion 2008-1 04/09/08
transaction messages
Removed Data Dictionary (Appendix A) and merged 2008-1 04/09/08
that with Glossary (Appendix G)
Removed Association Interchange Processes – 2008-1 04/09/08
Appendix N
Title Changed version number to 2007.3 2007-3 11/06/07
Reformatted Overview 2007-3 11/06/07
Moved out Dual Settlement section and put in new
Appendix
Indented Features section
Removed Payment Transfer from Prepaid section
and put in section of its own
Modified HealthCare information
Added Acquirer Reference Data to ISO 8583 Field 2007-3 11/06/07
definitions
Modified the following ISO Bit definitions: 2007-3 11/06/07
Bit 7
Bit 11
Bit 12/13
Bit 22
Bit 25
Bit 31
Bit 32
Bit 60
Bit 124
Bit 63 modified the following: 2007-3 11/06/07
Private Data section

Updated Special Features
Table 14
Table 31
Table 32
Table 33
Table 34
Table 37
Table 38
Table 58
Table 59
Table 60
Table 62
Table 68
Table 69
Created new section for Field Identifier Tables
Move VI and DS to it
Added new tables PE and P2
Modified Canadian Debit examples to follow same 2007-3 11/06/07
structure as other request information
Added new Appendices for SMS and Canadian Debit 2007-3 11/06/07
Version 2008-3 Confidential and Proprietary iv

Revision History First Data ISO 8583 Global Specification

4-9 Field 012 Time, Local Transmission — Added the 2007-2 09/27/07
verbiage Mandatory for Amex and Discover
transactions. Changed ‘Mandatory’ to ‘Conditional’
4-11 Field 013 Date, Transmission — Added the verbiage 2007-2 09/27/07
Mandatory for Amex and Discover transactions.
Changed ‘Mandatory’ to ‘Conditional’
43 Added the Mandatory requirement for Capture only for 2007-2 09/27/07
field 037 Retrieval Reference #
44 Added the Mandatory requirement for Capture only for 2007-2 09/27/07
field 038 Authorization Code
47 Added the line ‘Need to state numeric Country Code in 2007-2 09/27/07
field 43 Alternate Merchant info
48 Added the requirement of the field AVS Response 2007-2 09/27/07
Code for Capture only transactions
56 Corrected ZIP code verbiage in field 48 Billing address 2007-2 09/27/07
65 Added the requirement of the Visa Table 14 for 2007.2 09/27/07
Capture only transactions
67 Added the requirement of the MasterCard Table 14 for 2007-2 09/27/07
Capture only transactions, updated table filler fields
and market-specific data fields
70 Added Table 14 for Amex CAPN for Capture only 2007-2 09/27/07
transactions
83 Added Table 36 additional Addendum data 2007-2 09/27/07
88 Added the Table 49 CVV2/CVC2/CID for Capture only 2007-2 09/27/07
transactions
96 Added the Table 59 UCAF Information for Capture only 2007-2 09/27/07
transactions
104 Added the Table 65 VPAS Response for Capture only 2007-2 09/27/07
transactions
126 Renamed 0100 Authorization as ‘0100 messages 2007-2 09/27/07
Authorization only, Authorization & Capture and
Capture only’
127 Added field 38 Authorization Code to 0100 message for 2007-2 09/27/07
Auth only, Auth & Capture and Capture only message
127 Added field 44 Additional Response Data (AVS) to 2007-2 09/27/07
0100 message for Auth only, Auth & Capture and
Capture only message
193 Added the new Response Code Table in Appendix B 2007-2 09/27/07
Title Changed version number to 2007.1A 2007-1A 08/08/07
30 Update Processing Code value ’20’ for INICIS 2007-1A 08/08/07
cancellations 2007.1A
43 Update ‘Authorization Identification Response’ bit map 2007-1A 08/08/07
pos 38 with comment with INICIS changes 2007.1A
60 Update ‘Summary of Defined tables’ with new INICIS 2007-1A 08/08/07
tables I1 thought I4 2007.1A
95 Added new value for INICIS on table 63 / field 63 2007-1A 08/08/07
2007.1A
118 Added INICIS tables I1 through I4 2007.1A 2007-1A 08/08/07
Xvi Updated new features page for INICIS 2007.1A 2007-1A 08/08/07
Title Changed references to First Data to First Data (First 2007-1 07/31/07
Data Commercial Services)
Version 2008-3 Confidential and Proprietary v



Title Updated the Version Number from ISO-LL-S1-002-6.3 2007-1 07/31/07
b (Host Capture) to
ISO-LL-Host Capture-2007.1.
1 Added Dual Settlement Event topic after Overview 2007-1 07/31/07
60 Added Table 70 to the Summary of Defined tables 2007-1 07/31/07
105 Added Table 70 for Dual settlement Event 2007-1 07/31/07
xiv Added Dual Settlement Event to the list of New 2007-1 07/01/07
features
233 APPENDIX L Additional Processing Options Added 06/20/07
Canadian Debit Process
105 Added Field 63 Table DS Discover Qualification Data 05/23/07
6 Added MasterCard Payment Transaction 05/22/07
16 Added description for MasterCard Payment 05/22/07
Transaction
28 Bit 3 (Processing Code) Added Transaction Type 29 05/22/07
Payment Transaction
122 Added Canadian Debit 0200 Message 05/11/07
97 Updated Table VI 3/9/07
97 Added Field 63 (Table VI) Visa Compliance Table 3/2/07
38 Added Bit 31 Field definitions 2/7/07
103 Added Bit 31 to 0100 Message 2/7/07
121 Added Bits 31,43 to 0400 Message 2/7/07

Version 2008-3 Confidential and Proprietary vi


Contents
Chapter 1. New Features ..................................................................................................... 1-1
Chapter 2. About ISO 8583 .................................................................................................. 2-1
2.1. Target Audience ...............................................................................................................................2-2
2.2. Scope ................................................................................................................................................2-2
2.3. ISO 8583 Global Specification ..........................................................................................................2-3
2.4. Basic Message Format .....................................................................................................................2-4
2.5. Programming Considerations ...........................................................................................................2-4
2.6. Legend of Attribute Abbreviations ....................................................................................................2-5
2.7. Default Field Format .........................................................................................................................2-6
2.8. Message Type Identifier ...................................................................................................................2-7
2.9. Standard Message Types .................................................................................................................2-8
Chapter 3. Understand the Message Flow Sequence ...................................................... 3-1
Chapter 4. ISO 8583 Bitmap Definitions ............................................................................ 4-1
4.1. Data Element Index ..........................................................................................................................4-2
4.2. Message Type ID..............................................................................................................................4-3
4.3. Bitmap ...............................................................................................................................................4-3
4.4. Bitmap Definitions .............................................................................................................................4-5
4.4.1. Secondary Bitmap .................................................................................................................................... 4-5
4.4.2. Bitmap 2 — Primary Account Number ...................................................................................................... 4-5
4.4.3. Bitmap 3 — Processing Code ................................................................................................................... 4-6
4.4.4. Bitmap 4 — Amount of Transaction .......................................................................................................... 4-8
4.4.5. Bitmap 7 — Transmission Date/Time ....................................................................................................... 4-9
4.4.6. Bitmap 11 — System Trace/Debit Reg E Recipient Number .................................................................... 4-9
4.4.7. Bitmap 12 — Time, Local Transmission ................................................................................................... 4-9
4.4.8. Bitmap 13 — Date, Local Trans. (Debit/EBT)/Sales Date (Credit) .......................................................... 4-11
4.4.9. Bitmap 14 — Card Expiration Date ......................................................................................................... 4-11
4.4.10. Bitmap 18 — Merchant Category Code ................................................................................................ 4-12
4.4.11. Bitmap 22 — POS Entry Mode+ Pin Capability .................................................................................... 4-12
4.4.12. Bitmap 24 — Network International ID (NII) .......................................................................................... 4-13
4.4.13. Bitmap 25 — Point of Service (POS) Condition Code .......................................................................... 4-14
4.4.14. Bitmap 31 — Acquirer Reference Data ................................................................................................. 4-15
4.4.15. Bitmap 32 — Acquiring ID..................................................................................................................... 4-15
4.4.16. Bitmap 35 — Track 2 Data.................................................................................................................... 4-16
4.4.17. Bitmap 37 — Retrieval Reference Number ........................................................................................... 4-17
4.4.18. Bitmap 38 — Authorization Identification Response ............................................................................. 4-18
4.4.19. Bitmap 39 — Response Code .............................................................................................................. 4-18
4.4.20. Bitmap 41 — Terminal ID...................................................................................................................... 4-19
4.4.21. Bitmap 42 — Merchant ID..................................................................................................................... 4-19
4.4.22. Bitmap 43 — Alternative Merchant Name/Location .............................................................................. 4-20
4.4.23. Bitmap 44 — Additional Response Data ............................................................................................... 4-21
4.4.24. Bitmap 45 — Track 1 Data.................................................................................................................... 4-23
4.4.25. Bitmap 48 — First Data Private Use Data Element .............................................................................. 4-23
4.4.26. Bitmap 49 — Transaction Currency Code ............................................................................................ 4-23
4.4.27. Bitmap 52 — Encrypted PIN Data ........................................................................................................ 4-24
4.4.28. Bitmap 54 — Additional Amounts ......................................................................................................... 4-24
4.4.29. Bitmap 59 — Merchant Zip/Postal Code ............................................................................................... 4-25
4.4.30. Bitmap 60 — Additional POS Information ............................................................................................. 4-25
4.4.33. Bitmap 70 — Network Management Information Code ......................................................................... 4-26
4.4.34. Bitmap 93 — Response Indicator ......................................................................................................... 4-26
4.4.35. Bitmap 96 — Key Management Data ................................................................................................... 4-27
4.4.36. Bitmap 100 — Receiving Institution ID Code ........................................................................................ 4-27
4.4.37. Private Data Bitmaps ............................................................................................................................ 4-27
4.4.38. Bit 63 Private Data Field ....................................................................................................................... 4-32
Chapter 5. Sample Message Format .................................................................................. 5-1
Version 2008-3 Confidential and Proprietary i

First Data ISO 8583 Global Specification Contents
5.1. Table Layout .....................................................................................................................................5-2

5.2. 0100 Message Authorization only, and Authorization & Capture .....................................................5-2
5.3. 0100 Message Capture Only ............................................................................................................5-5
5.4. 0100 Balance Inquiry for Prepaid Cards...........................................................................................5-7
5.5. 0110 Authorization Host Response ..................................................................................................5-9
5.6. 0100 Check Guarantee/Verification................................................................................................5-10
5.7. 0110 Check Verification — Host Response ...................................................................................5-12
5.8. 0100 Prepaid Card Activation (Visa Only) ......................................................................................5-13
5.9. 0110 Prepaid Card Activation Response........................................................................................5-14
5.10. 0100 Prepaid Card Load (Visa Only)............................................................................................5-15
5.11. 0110 Prepaid Card Load Response .............................................................................................5-17
5.12. 0100 Prepaid Card Activation with Load (Visa Only) ...................................................................5-18
5.13. 0110 Prepaid Card Activation and Load Response .....................................................................5-20
5.14. 0100 Authorization (VRU Only) ....................................................................................................5-21
5.15. 0200 Financial Transaction (Debit) — Excluding Canadian Processing ......................................5-23
5.16. 0210 Financial Transaction (Debit) — Host Response ................................................................5-25
5.17. 0200 Financial Transaction (Debit) — Canadian Processing ......................................................5-27
5.18. 0210 Financial Transaction (Debit) Response — Canadian Processing .....................................5-30
5.19. 0200 Financial Transaction (EBT Card) .......................................................................................5-32
5.20. 0210 Financial Transaction (EBT) — Host Response..................................................................5-34
5.21. 0400 Reversal — Credit Card ......................................................................................................5-35
5.22. 0410 Credit Card Reversal — Host Response .............................................................................5-37
5.23. 0400 Debit Card Reversal ............................................................................................................5-38
5.24. 0410 Financial Transaction (Debit) Reversal — Host Response .................................................5-40
5.25. 0400 EBT Card Reversal ..............................................................................................................5-41
5.26. 0410 Financial Transaction (EBT) Reversal — Host Response ..................................................5-43
5.27. 0800 Log-On Message .................................................................................................................5-44
5.28. 0810 Log-On Response ...............................................................................................................5-45
5.29. 0800 Echo Test-First Data Standard Format ...............................................................................5-46
5.30. 0810 Echo Test (First Data Standard Format) — Response .......................................................5-47
5.31. 0800 Echo Test — Visa Standard Format ....................................................................................5-48
5.32. 0810 Echo Test (Visa Standard Format) — Response ................................................................5-49
5.33. 0800 New Key Request for Non Canadian Merchants using a HSM ...........................................5-50
5.34. 0810 New Key Response .............................................................................................................5-51
5.35. 0800 New Key Request for Canadian Merchants using MACing .................................................5-52
5.36. 0810 New Key Response — Canadian Merchants using MACing ..............................................5-53
5.37. Sample Messages (EBCDIC and ASCII) .....................................................................................5-54
Chapter 6. Appendix ............................................................................................................ 6-1
6.1. Appendix A — Response Codes ......................................................................................................6-2
6.1.1. Response Codes in Sequence by Text ..................................................................................................... 6-2
6.1.2. Response Codes in Sequence by Code ................................................................................................... 6-5
6.1.3. Check Guarantee/Verification — Related Messages ................................................................................ 6-8
6.1.4. Debit/EBT Card — Related Messages ..................................................................................................... 6-9
6.2. Appendix B — State Codes ............................................................................................................6-11
6.3. Appendix C — Country Codes .......................................................................................................6-12
6.4. Appendix D — Currency Codes .....................................................................................................6-17
6.4.1. Currency Name Order ............................................................................................................................ 6-17
6.5. Appendix E — Check Digit Logic/Card Type ID + 6.51 Card Type identification ...........................6-23
6.5.1. Card Type Identification (BIN Ranges) ................................................................................................... 6-25
6.6. Appendix F — Magnetic Stripe Standards .....................................................................................6-26
6.7. Appendix G — Glossary .................................................................................................................6-27
6.8. Appendix H — Escalation Procedures for Authorization Link Problems ........................................6-33
6.9. Appendix I — Address Verification Service (AVS) .........................................................................6-34
6.9.1. AVS Overview......................................................................................................................................... 6-34
6.9.2. AVS Basic Features................................................................................................................................ 6-34
6.10. Appendix J — Check Guarantee/Verification ...............................................................................6-35
Version 2008-3 Confidential and Proprietary ii


Contents First Data ISO 8583 Global Specification
6.10.1. Check Guarantee/Verification Overview ............................................................................................... 6-35

6.10.2. Check Verification ................................................................................................................................. 6-35
6.10.3. Check Guarantee.................................................................................................................................. 6-35
6.10.4. Check Guarantee/Verification Support ................................................................................................. 6-35
6.11. Appendix K — Additional Credit Card Processing Options ..........................................................6-41
6.11.1. Foreign Currency Authorization ............................................................................................................ 6-41
6.11.2. Miscellaneous Processing .................................................................................................................... 6-41
6.11.3. Contactless Transactions...................................................................................................................... 6-41
6.11.4. Cash Back ............................................................................................................................................ 6-42
6.11.5. Recurring Transactions ......................................................................................................................... 6-42
6.11.6. Deferred Billing Indicator ...................................................................................................................... 6-44
6.11.7. Installment Bill Payment ....................................................................................................................... 6-44
6.11.8. NTIA Coupon Program ......................................................................................................................... 6-45
6.11.9. Prepaid Card Processing Functionality ................................................................................................. 6-48
6.11.10. Reversal Processing ........................................................................................................................... 6-55
6.12. Appendix L — General Information on Debit and EBT.................................................................6-57
6.12.1. Debit card functionality/feature ............................................................................................................. 6-57
6.12.2. Debit card number/PAN length ............................................................................................................. 6-57
6.12.3. Debit edit checks .................................................................................................................................. 6-57
6.12.4. Debit personal identification numbers ................................................................................................... 6-57
6.12.5. Key management.................................................................................................................................. 6-57
6.12.6. Debit Authorization Request ................................................................................................................. 6-59
6.12.7. Debit Authorization Request with Cash Back........................................................................................ 6-59
6.12.8. Debit Return.......................................................................................................................................... 6-60
6.12.9. Void Processing for Debit ..................................................................................................................... 6-61
6.12.10. Reversal Processing for Debit And EBT ............................................................................................. 6-64
6.12.11. Electronic Benefits Transfer (EBT) ..................................................................................................... 6-66
6.13. Appendix M — First Data Processing Environment .....................................................................6-70
6.13.1. First Data Processing Environment Overview....................................................................................... 6-70
6.13.2. FDCS/6000 Front — End Processing Support...................................................................................... 6-70
6.14. Appendix N — Host Capture ........................................................................................................6-71
6.14.1. Dual Event Settlement .......................................................................................................................... 6-73
6.15. Appendix O — Canadian Debit Processing — Terminal MAC/EKME .........................................6-74
6.16. Appendix P — Frequently Asked Questions ................................................................................6-78
Version 2008-3 Confidential and Proprietary iii


Chapter 1. New Features

This chapter contains the list of all the new features that are added to this specification.
Please check with your First Data Certification Representative before attempting to
implement the features described in this specification. The First Data Certification
Representative will be responsible for answering your questions, establishing
connectivity, coordinating testing, and validating message formats.
Version 2008-3 Confidential and Proprietary to 1-1

November 11, 2008 First data

New Features First Data ISO 8583 Global Specification
List of New Features:
Canadian Debit Processing (for further information on this feature, see Appendix O — Canadian
Debit Processing–Terminal MAC/EKME on page 6-74)
Dual Event settlement 2007 (for further information on this feature, see Appendix N — Host
Capture on page 6-71)
Host Capture Settlement–Purchase Card 2 (P2) and Petroleum (PE) tables — Product Availability
is TBD with a target date of the End of June 2008 (for further information on this feature, see
Appendix P — Frequently Asked Questions on page 6-78)
Loyalty (Added Version 3 for Table — L1 and version 2 for Table — L2)
Discover Recurring
Visa prepaid card activation and load
Fleet card data (Bit 63, Table 24 and 25)
Discover Cash Back
MasterCard Merchant Advice Code Indicator/Visa Recurring Payment Cancellation
Discover Network Reference Identifier (NRID)
Please refer to the Revision History (pages ii-iv) for the details of all references to these features in the
manual.
Please check with your First Data Certification Representative before attempting to
implement the features described in the list of new features.
Version 2008-3 Confidential and Proprietary 1-2


Chapter 2. About ISO 8583
ISO 8583 provides a framework of a set of rules that defines the nomenclature and the
format of different transaction messages using bitmaps. The ISO 8583 Global
Specification document provides information for processing transactions using the ISO
8583 message formats. These message formats are required to interact with First Data
for real-time and optional authorization with host capture settlement processing via a
dedicated circuit.
This chapter consists of:
 Target Audience (see page 2-2)

 Scope (see page 2-2)
 ISO 8583 Global Specification (see page 2-3)
 Basic Message Format (see page 2-4)
 Programming Considerations (see page 2-4)
 Legend of Attribute Abbreviations (see page 2-5)
 Default Field Format (see page 2-6)
 Message Type Identifier (see page 2-7)


About ISO 8583 First Data ISO 8583 Global Specification
2.1. Target Audience

The ISO 8583 Global Specification document is intended for the following groups of users:
Merchants who process financial transactions using an ISO 8583 message format structure for the
following industries:
 Car Rental
 Direct Marketing/Mail Order
 E-Commerce
 Lodging
 Petroleum
 Restaurant
 Retail or Supermarket
Programmers and analysts who design, implement, and support the systems using an ISO 8583
message structure
2.2. Scope
First Data supports the following types of transactions:
Transaction Types Description

Authorization Only Authorization is the process of determining if there are sufficient funds
available on a cardholder’s account to complete a purchase.
For this type of transaction, settlement processing is supported through

a separate communications link. To perform settlement (that is,
transfer of funds from the cardholder's account to the merchant bank
for deposit into the merchant's bank account), a batch file is sent
directly to the First Data host processor.
The message format used for such settlement files is described in the
Paperless Transaction Specification (PTS) document
(PTS_Spec_2007-4.pdf) available on the First Data specifications Web
site (http://www.fdms.com/specs).
Authorization with Host Authorization with Host Capture Settlement is used to transmit an
Capture Settlement authorization request to First Data from a merchant. Here the approved
transactions are captured by the First Data host for settlement
processing.
Merchants may require additional communication changes to be made

to access the First Data front-end systems to support host capture.
Authorization with capture is supported for electronic commerce,

MOTO, and retail transactions.


First Data ISO 8583 Global Specification About ISO 8583
Transaction Types Description

Capture Only Capture Only is a transaction that has already been authorized and is
submitted to First Data host to be captured for settlement processing
only.
For instance, a merchant may initially decide to submit the transaction

as an Authorization Only request. The merchant subsequently submits
a transaction to First Data host for settlement processing. In this case,
the merchant must retain additional records from the authorization and
must send that information when submitting the transaction for
settlement.
Other examples of capture only transactions include Voice

Authorization and Return/Refund.
FDCS/6000, the First Data transaction delivery system, provides a direct and efficient pathway between
clients and all major payment systems. Operating nationwide, FDCS/6000 consists of geographically
diverse data centers interconnected by state-of-the-art fiber optics. This redundant operating strategy
enables First Data to avoid any single point of failure, allowing customers to stay on-line, even if one of
the facilities experiences an unforeseen outage or problem.
The First Data network is supported by FDCS/6000 Front End Processors (FEPs), which handle the
electronic communications of client interface systems and host level interfaces in an authorization
environment. The FEPs manage the flow of messages, networks and merchants, and control all message
transmissions between the merchant host and First Data.
First Data suggests that as a matter of good business practices all merchants and third
parties that process, transmit, or store cardholder data should become aware of Visa’s
Cardholder Information Security Program (CISP) and MasterCard’s Site Data Protection
(SDP) program. The purpose of these programs is to help protect the integrity of
cardholder information via the use of outside-vendor auditing of systems security and
server site security.
For additional information, please contact your Client Certification and Implementation
representative. Information is also available at www.visa.com and
www.mastercard.com/us/gateway.html
2.3. ISO 8583 Global Specification

This ISO 8583 document specifies the message structure, flow, format, and content as implemented by
First Data. This document also specifies the data elements and the associated values required for an
effective interface for electronic financial messages. These messages flow between the retailer and card
acquiring organizations such as First Data.
ISO 8583 uses a concept referred to as a “bitmap”, wherein each data element is assigned a position
indicator in a control field, or bitmap. The presence of a data element in a specific message is indicated
by a one (1) in the assigned position of the bitmap; the absence of a data element is indicated by a zero
(0) in the assigned position. The bits are numbered left to right from 1 to 64. The high-order bit of the first
byte is bit #1. Bit #64 is the right-most bit or the low-order bit of the eighth and last byte. The ISO 8583


Understand the Message Flow Sequence First Data ISO 8583 Global Specification
specification also define a second bitmap indicating bits 65 through 128. To activate the secondary
bitmap, enter ‘1’ in bit number one of the primary bitmap.
If this bit is on, all data elements will be shifted by an additional 8 bytes; thus, field number two (Primary
Account Number) would be found as the 17th byte following the message type rather than the 9th byte
(as would be the case if only a primary bitmap were present). Usually, the First Data implementation
supports neither the use of the second bitmap nor the fields ISO has defined for those bits. First Data
does not use all of the defined fields. The fields used by First Data are described in this document.
2.4. Basic Message Format

Below is a schematic of the basic format for all ISO 8583 messages. Descriptions of the “Message Type”
and “Remaining Data Elements” follow this section. The “Primary Bitmap” and “Secondary Bitmap” are
described above.
Remaining Data
Message Type Primary Bitmap Secondary Bitmap
Elements
2.5. Programming Considerations

The message formats are not fixed. They are subject to change. When coding to a message
specification, check the bitmap to be sure that the field requirements have not changed. Field
requirements may change for both the First Data Private Data fields and the ISO 8583 fields.


2.6. Legend of Attribute Abbreviations

Abbreviations Description
a (A) Alphabetic characters
n (N) Numeric characters
s (S) Special Characters
an (AN) Alphanumeric (alphabetic and numeric characters)
as (AS) Alphabetic and special characters
ns (NS) Numeric and special characters
ans (ANS) Alphabetic, numeric, and special characters
MM Month
DD Day
YY Year
hh Hour
mm Minute
ss Second
LL, LLL Length of variable field that follows. ‘LL’-Two-digit length indicator (1 byte BCD)
‘LLL-3-digit length indicator (2 bytes BCD)
var (VAR) Variable length field
3 Fixed length of three characters
b Binary representation of data
BCD Binary-Coded Decimal: Binary representation of each digit by 4 bits, which in
general represent the values/digits/characters 0-9.
hb (HB) Hex Binary representation of data
Z Tracks 2 and 3 code set as defined in ISO 7811 and ISO 7813
17 Variable field of up to 17. The ‘..’ is a two-digit length indicator (1 byte BCD)
specifying the number of digits defining the length of the variable data to follow.
1
125 Variable field of up to 125 characters. The ‘…’ is a three-digit length indicator (2

bytes BCD), specifying the number of digits defining the length of the variable
data to follow. (The first half byte is set to X ‘0’.)
References to “numeric characters” are meant to imply “printable” characters. For
example, the ASCII value for the number 12 is X ’31 32’.
When variable length data is numeric and an odd number of digits, set the last half byte to
X ‘0’. For example, a numeric field of three positions containing the value X ’12 30’
represents the value ‘one hundred twenty-three’.
If the length indicator is three digits (two bytes), always set the first half byte to X ‘0’.
Thus, a length indicator for a 125-position field would look like this: X ’01 25’. If the data
type for this field were numeric, the same rule of setting the last half byte to X ‘0’ would
apply, as shown above.


2.7. Default Field Format

Numeric Data Element (N)
Unless specifically stated otherwise, numeric data elements should be right justified and padded to the
left with zeros. The Track 2 Data and Primary Account Number (PAN) fields are instances of numeric data
elements that follow a different format: In the case where the variable length data has an odd number of
digits, set the right-most half byte to X ‘0’.
Alphanumeric Data Elements (AN)

Alphanumeric data elements should be left-justified, and padded to the right with spaces except where
stated otherwise. The Merchant Number and Terminal ID fields are exceptions to this rule: these fields
are both right-justified and padded to the left with zeros.
Transaction Amount
Right justified, zero filled, and two assumed decimal places for USD and most other countries. For more
information, refer to Appendix D on page 6-17. For example: a field size of 7, the string ‘0004588’ would
translate as $45.88.
Binary (B)
Any value, Hex 00 through Hex FF — the field allows the full range of binary values, without regard to
ASCII value, print ability, or command interpretation.
Binary Coded Decimal (BCD)

Binary-coded decimal (BCD) is an encoding for decimal numbers in which each digit is represented by its
own binary sequence. Its main virtue is that it allows easy conversion to decimal digits for printing or
display and faster decimal calculations. In BCD, a digit is usually represented by four bits which, in
general, represent the values/digits/characters 0-9. Other bit combinations are sometimes used for sign
or other indications.
Hex Binary (HB)

Any value, Hex 00 through Hex FF-To permit binary data to be transmitted with the asynchronous
protocol, each binary nibble (4 bits) must be converted to one byte of hexadecimal data (30 through 39,
and 41 through 46).
For example, the binary data <01>, <3A>, <7F>, with nibbles of 0, 1, 3, A, 7, and F, would be transmitted
as <30>, <31>, <33>, <41>, <37>, and <46>.
Legend of Field Requirements

Code Description
C Conditional-Based on the conditions described in the data field element description,
this field may or may not be mandatory.
M Mandatory field
O Optional field-If present, it must conform to defined format.


2.8. Message Type Identifier

All messages begin with a four-digit Identifier that describes the type and function of the message and the
transmission mode. All messages are expected to be in the ASCII character set. Exceptions to this
restriction may be granted under certain circumstances, permitting the use of the EBCDIC character set.
Please contact your First Data Network Planning Representative before beginning your application
development to request such an exception Message Type Identifier.
The first and second digits identify the class of message:
Message Identifiers Description

01 Authorization Message
02 Authorization/Financial Transaction Message
04 Reversal Message
08 Network Management Message
The 3rd/4th digits identify the message function and transmission mode.
00 Interactive Request
10 Interactive Request Response
Types of Message Identifiers used by First Data

Authorization only, authorization and capture, and capture only Messages (Credit)
0100 Authorization Request
0110 Authorization Request Response
Not all requests need be captured. The choice depends on merchant requirements

Financial Transaction Messages (Debit)
0200 Authorization/Financial Transaction Request
0210 Authorization/Financial Transaction Request Response

Reversal Messages
0400 Reversal Request
0410 Reversal Request Response
First Data does not support partial reversals for Debit.

Network Management Messages

0800 Network Management Request
0810 Network Management Request Response

2.9. Standard Message Types

Authorization Request (Credit) — ISO 8583 Message Type 0100
The authorization request message type is used to transmit a real-time authorization request to First Data
from a merchant. An authorization indicates only the availability of the cardholders’ credit limit at the time
of the authorization. The authorization is obtained from the issuing bank via First Data.
Authorization requests may or may not be captured by the merchant system or the First Data host. This is
dependent on the merchants’ application requirements and transaction type. There are three options:
Authorization only: A transaction used to transmit an authorization request to First Data where it
is not captured on the First Data host for settlement processing. Using authorization only, the
merchant is responsible to capture the approved transactions into a data capture file. Only those
transactions captured by the merchant and returned in the settlement file will be billed to the
cardholder and funded by First Data. The settlement process is supported through a separate
communications link. Settlement should be carried out by transferring a batch file directly to the
First Data host processor. The message format used for such settlement files is described in the
PTS settlement specification, which may be obtained from the fdms.com/specs Web site.
Authorization only requests are currently supported for all industries.
Authorization with host capture settlement: A transaction used to transmit an authorization
request to First Data from a merchant where the approved transactions are captured on the First
Data host for settlement processing. Merchants may require additional communication changes to
be made to access the First Data front-end systems to support host capture. Authorization with
capture is supported for electronic commerce, MOTO, and retail.
Capture Only: A transaction that was previously authorized and is submitted to First Data host to
be captured for settlement processing only. For example, a merchant may decide to initially submit
the transaction as an Authorization Only request. A subsequent transaction is then submitted to
First Data host to be captured for settlement processing. In this case, the merchant must retain
additional records from the authorization and must send that information when submitting the
transaction for settlement. Other examples of capture only transactions include Voice
Authorization and Return/Refund.
Typically transactions such as dual event, address verification only, balance inquiry only, check
authorization, or pre-authorization requests need not be captured for settlement processing. Most other
transactions are expected to be captured for settlement processing.


Check Guarantee/Verification Request (ISO Message Type 0100)

Transaction used to transmit a request for check verification/guarantee authorization. This transaction
type is not captured for settlement processing. For more information, refer to Appendix J on page 6-35.
Prepaid Card Activation Request — Visa Only (ISO Message Type 0100)
Transaction used to notify an issuer that a card has been purchased and should be activated for
cardholder usage. This transaction type is not captured for settlement processing. For more information,
refer to Appendix K on page 6-54.
Prepaid Card Load Request — Visa Only (ISO Message Type 0100)
Transaction used to notify the issuer of an amount to be loaded to a card. For existing prepaid accounts,
the transaction amount will be added to the available balance. For new prepaid accounts, the card will be
activated for usage, and the transaction amount will be added as the initial load to the card. This
transaction type is not captured for settlement processing. For more information, refer to Appendix K on
page 6-54.


Financial Transaction (Debit/EBT) Request (ISO Message Type 0200)*

With Debit and EBT, there are two options: authorization only (that would require sending in debit and
EBT transactions in the PTS settlement specification for funding the merchant) or authorization with host
capture. In order to know more on encryption, please refer to: Appendix L — General Information on
Debit and EBT.
Transaction currently used to support Debit/EBT card transactions. The Debit or EBT authorization
request messages are submitted on behalf of a request for authorization for purchase of goods or
services for a specified amount. At the time of the approved authorization response, the funds are
depleted from the cardholders account by the issuing bank.
In order for the merchant to receive payment for Debit or EBT transaction types, a settlement process
must occur. There are two options:
Authorization only: Using authorization only, the merchant is responsible for capturing the
approved transactions into a settlement file. In order for the merchant to be funded, it is necessary
that the settlement file is then transmitted to First Data. Only those transactions captured by the
merchant and returned in the settlement file will be funded by First Data. The settlement process
is supported through a separate communications link. Settlement should be carried out by
transferring a batch file directly to the First Data host processor. The message format used for
such settlement files is described in the PTS settlement specification, which may be obtained from
the fdms.com/specs Web site.
Authorization with host capture settlement: Transaction used to transmit an authorization
request to First Data from a merchant where the approved transactions are captured on the First
Data host for settlement processing. It may require additional communication changes to be made
to access the First Data front-end systems to support host capture. Canadian domiciled merchants
must use Authorization with Host Capture settlement.
*
First Data specifications abide by Debit Network operating rules and technical specifications; therefore,
merchants processing Debit / EBT transactions must comply with the requirements for those transactions,
as described within this specification.


Authorization Reversal Request Format–(ISO Message Type 0400)

Transaction used to fully or partially cancel a previously approved authorization. This function is currently
supported by Visa, Discover and MasterCard only. The data elements within the reversal request should
correspond to those in the original authorization transaction. Visa reversal request must also include the
Authorization Code and Transaction ID provided when the original transaction was approved. MasterCard
and Discover reversal requests must also include the Authorization Code and Response code. All issuers
may not support Reversal transactions.
There are two requirements depending on the transaction being an authorization only or an authorization
with capture:
For authorization only: First Data supports full and partial reversals for authorization only
transactions. Discover requires that the reversal must occur prior to transmitting the sale for
settlement processing. Visa and MasterCard do not specify when the reversal must occur,
however, best practice is to perform the reversal request prior to or immediately after the
settlement processing.
For authorization with capture: First Data supports only full reversals for authorization with
capture transaction. Merchants must submit reversal request within 25 minutes of the
transaction. FDC does not match the reversal request with the specific transaction at the point
when the request is received. However, First Data sends an approval as a response on receipt
of the reversal request. This is just an acknowledgement to the receipt of the reversal request
and does not indicate that the reversal has been approved or sent to the relevant card
association. If the time period of 25 minutes is over and no reversal request has been initiated,
the transaction data is pulled into the batch file maintained by First Data. In this case, any
adjustment or reconciliation has to be made through return/refund during settlement. Thus a
reversal must occur within 25 minutes of the original authorization request. If it doesn’t, the
approved transaction amount captured at First Data will not be adjusted.
Capture Only: For merchants supporting capture only transactions, if they submit the same
transaction twice, they must go out for a refund of the duplicate transaction and not a reversal.
For more information, refer to Appendix K on page 6-55.


Financial Void Request–Debit/EBT (ISO Message Type 0400)

Transaction used to fully cancel a previously approved Debit or EBT Card transaction A Partial void is not
supported. With the following exceptions, the 0400 Message must provide the data sent in the original
0200 message to comply with Debit/EBT Network Provider requirements. Exceptions: Bit 7 (can be actual
transmission Date/Time); Bit 37 (can be new Retrieval Reference Number); Bit 52 (original Cryptogram
data is not required, but if unavailable send Hex ‘0000000000000000’).
A Void is used to correct an error or to accommodate the customer’s change of mind at the point of sale
following approval of the original transaction.
All Debit/EBT voids must be submitted within 25 minutes of the original request. On receiving a void
request, First Data sends back a response to the merchant. The response is just an acknowledgement of
the receipt of the void request. It does not indicate that the void is being processed. For more information,
refer to Appendix L on page 6-61.
Test Message (ISO Message Type 0800)

Network Administrative Message used to do the following:
Transaction used to test the communications link or application readiness. Other variations of this
message can be used to log on to the First Data Network.
New key request used to receive a new working key
Authorization Response Message (ISO Message Type 0110)

This message is sent to the merchant from First Data to respond to 0100 request message. It is
generated as a result of processing the following types of transactions:
Authorization Request — ISO Message Type 0100

Check Guarantee/Verification Request — ISO Message Type 0100
Prepaid Card Activation Request — ISO Message Type 0100
Prepaid Card Load Request — ISO Message Type 0100
Financial Transaction (Debit/EBT) Response (ISO Message Type 0210)

Transaction currently used to transmit the response to a Debit card or EBT Card transaction.


Reversal Response Message (ISO Message Type 0410)

Transaction used to transmit the response to a reversal request.
Test Message Response (ISO Message Type 0810)

Transaction used to test the communications link or application readiness. Other variations of this
message can be used to log on to the First Data Network. New key response used to receive a new
working key.


Chapter 3. Understand the Message
Flow Sequence
A card based transaction typically travels from a merchant’s point-of-sale terminal,
through a series of networks such as processor and Card Associations, to an issuer for
authorization against the cardholder’s account. The card issuer either approves or
declines the transaction and this response is communicated to the merchant on a timely
basis.
This chapter provides a high-level description of the sequence of transaction message
flow through different entities of card processing.


Figure 1 describes the workflow for merchants having a hosting facility (frame connection to First Data):
Figure 1


Chapter 4. ISO 8583 Bitmap Definitions
 Data Element Index (see page 4-2)

 Message Type ID [see page 4-3]
 Bitmap (Bitmap Position-None) [see page 4-3]
 Hexadecimal Equivalent of Binary Bitmap Layout (see page 4-4)
 Binary Bitmap Layout (see page 4-4]
 Bitmap Definitions (see page 4-5)

November 11, 2008 to First data

First Data ISO 8583 Global Specification ISO 8583 Bitmap Definitions
4.1. Data Element Index

Bit # Data Element Name Page
Message Type 2-7
Bitmap 4-5
2 Primary Account Number 4-5
3 Processing Code 4-6
4 Amount of Transaction 4-8
7 Transmission Date/Time 4-8
11 System Trace/Debit Reg E Receipt Number 4-9
12 Time, Local Transmission 4-9
13 Date, Local Transmission (Debit)/Sales Date (Credit) 4-11
14 Expiration Date 4-11
18 Merchant Category Code 4-12
22 POS Entry Mode + PIN Capability 4-12
24 Network International ID (NII) 4-13
25 Point of Service (POS) Condition Code 4-14
31 Acquirer Reference Data 4-14
32 Acquiring ID 4-15
35 Track 2 Data 4-16
37 Retrieval Reference Number 4-17
38 Authorization Identification Response 4-18
39 Response Code 4-18
41 Terminal ID 4-18
42 Merchant ID 4-19
43 Alternative Merchant Name/Location 4-20
44 Additional Response Data 4-21
45 Track 1 Data 4-23
48 First Data Private Use Data Element (Check Verification, AVS) 4-23
49 Transaction Currency Code 4-23
52 Encrypted PIN Data 4-24
54 Additional Amounts 4-24
59 Merchant ZIP/Postal Code 4-25
60 Additional POS Information 4-25
62 First Data Private Use Data Element 4-25
63 First Data Private Use Data Element 4-26
70 Network Management Information Code 4-13
93 Response Indicator 4-26
100 Receiving Institution Code 4-27
Version 2008-3 Confidential and Proprietary to First data 4-2

November 11, 2008

4.2. Message Type ID

Field Name Description
Attributes Numeric, BCD
Size 2 bytes, 4 digits
Req Mandatory
Comments A code that defines the message type. The message types and their associated
codes are as follows:
Authorization Messages
0100 Authorization Request
0110 Authorization Request Response
Financial Transaction Messages (Debit only)
0200 Authorization/Financial Transaction Request
0210 Authorization/Financial Transaction Request Response
Reversal Messages
0400 Reversal Request
0410 Reversal Request Response
Network Management Messages
0800 Network Management Request
0810 Network Management Request Response
4.3. Bitmap
Attributes Binary, Hexadecimal Representation
Size 64 bits; 8 bytes [or 128 bits, 16 bytes (for the extended bitmap)]
Req Mandatory-All message types
Comments Each bit in this field specifies the presence or absence of a field in a message type.
The bitmap indicates those fields that are being used in a message, since it is
neither necessary nor desirable to “activate” every available field in a particular
message type.
For fields that are activated or “on,” you must set the corresponding bitmap position
to a value of 1. These include mandatory fields, optional fields that you wish to
activate, and conditional fields (that meet those conditions making them mandatory).
If a field is optional and you elect not to activate it, its assigned bitmap position must
contain a value of 0.
In the following example, the extended bitmap (65-128) is not turned on.
Therefore, bit 1 (of 64) is set to binary 0 to disable the extended bitmap.



Hexadecimal Equivalent of Binary Bitmap Layout

(30 20 05 80 00 C8 00 00)
The following fields are activated in this bitmap: 3, 4, 11, 22, 24, 25, 41, 42, and 45.
Position 1-8 Position 17-24 Position 33-40 Position 49-56

0011 = 3 0000 = 0 0000 = 0 0000 = 0
0000 = 0 0101 = 5 0000 = 0 0000 = 0

Position 9-16 Position 25-32 Position 41-48 Position 57-64
0010 = 2 1000 = 8 1100 = C 0000 = 0
0000 = 0 0000 = 0 1000 = 8 0000 = 0
Binary Bitmap Layout (Bytes 1 through 8)

3 0 (Byte 1) 2 0 (Byte 2)
Bit Setting 0 0 1 1 0 0 0 0 0 0 1 0 0 0 0 0
Bit # 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
0 5 (Byte 3) 8 0 (Byte 4)
Bit Setting 0 0 0 0 0 1 0 1 1 0 0 0 0 0 0 0
Bit # 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32
0 0(Byte 5) C 8(Byte 6)
Bit Setting 0 0 0 0 0 0 0 0 1 1 0 0 1 0 0 0
Bit # 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48
0 0 (Byte 7) 0 0 (Byte 8)
Bit Setting 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
Bit # 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64


4.4. Bitmap Definitions

4.4.1. Secondary Bitmap

Attributes Binary
Size 64 bits; 8 bytes
Req Optional
Comments The secondary bitmap is a series of 64 bits that identifies the presence
(1) or absence (0) of each data element in the second segment of a
message.
4.4.2. Bitmap 2 — Primary Account Number

Size Variable to 10 bytes; 19 digits (if needed, last ½ byte padded-binary zero), preceded
by 1-byte Length Indicator.
Req Conditional — Mandatory for manual credit card authorizations, authorization and
capture, and capture only for all transactions, irrespective of manual/swiped entry
mode used during original authorization. Also, mandatory for EBT Voucher Clear
Transactions. Not included for check transactions.
On the 0200 Financial Transactions for EBT Card message, this field is mandatory
for Food Stamp transactions if the Track 2 Data cannot be read.
Comments This field identifies the card member’s account number. Unlike most numeric fields,
the Primary Account Number is left-justified. In this case, the rightmost byte is
padded with a ½ byte binary zero (e.g., a three-position field, X ’03 12 30’).


ISO 8583 Bitmap Definitions First Data ISO 8583 Global Specification
4.4.3. Bitmap 3 — Processing Code

Req Mandatory
Comments: A required code is used in conjunction with the message type to define the type
of transaction that is by the terminal to the host. Examples of relevant codes are
displayed in the table given below:
Code Message Type
000000 Credit Card Purchase/Pre-Authorization/
300000 Credit Card Balance Inquiry only
000000 New Key Request
500000 Bill Payment/Recurring
200000 Return/Refund (Debit and Credit Host Capture)
Partial reversal (Credit only)
009000 Debit Card Purchase Default Account
209000 Debit Card Return Default Account
009000 Debit Reversal
009800 EBT Food Stamp Purchase
209800 EBT Food Stamp Refund
280000 Visa Prepaid Card Load
720000 Visa Prepaid Card Activation/Activation and Load
099600 EBT Cash Benefits Purchase with Cash Back
990000 Echo Test
001000 Sale — Savings account — Canada Debit
002000 Sale — Checking account — Canada Debit
200010 Refund — Savings account — Canada Debit
200020 Refund — checking account — Canada Debit
021000 Adjustment of Return — Savings Account — Canada
Debit
022000 Adjustment of Return — Checking Account — Canada
Debit
220010 Adjustment of Sale — Savings Account — Canada Debit
220020 Adjustment of Sale — Checking Account — Canada
Debit
301000 Balance Inquiry — Savings Account — Canada Debit
302000 Balance Inquiry — Checking Account — Canada Debit
Format of the processing Codes:
Position 1-2 Transaction Type
Position 3–4 From Account
Position 5–6 To Account
Position 1-2
The first two digits Transaction Type
00 Goods and Services (Authorizations and Full
Reversals)/Pre-Authorization
01 Withdrawal/cash advance
02 Adjustment of a return (Debit only)
04 Check verification

09 Purchase with Cash Back

20 Return/Refund (Debit and Credit Host Capture)
Partial reversal (Credit only)
21 Payment (only specified private label formats)
22 Payment Reversal (only specified private label formats)
22 Adjustment of a Sale (Debit only)
28 Load or Load/Activate Prepaid Card Account (Visa Only)
30 Available Funds Inquiry (non-captured)
31 Balance Inquiry on EBT cards
45 Force Post Transaction (Host Draft Capture Merchants
Only)
50 Bill Payment
72 Activate Prepaid Card Account (Visa Only)
90 Signature Capture Data Present or Debit Key Exchange
99 Test transaction (0800 — Network Admin)
Position 3-4
The 3rd and 4th digits Account Type
00 Default Account (Credit only)
10 Savings Account (Debit — Canada only)
20 Checking Account (Debit — Canada only)
90 Default Account (Debit only)
96 Cash Benefits Account (EBT Only)
98 Food Stamps Account (EBT Only)
Position 5-6
th th
The 5 and 6 digits Account Type
00 Default Account (Credit, Debit, and EBT)
10 Savings Account (Debit — Canada only)
20 Checking Account (Debit — Canada only)
46 Force Post Transaction (logged to Billing File, not
switched to Association) for debit only


4.4.4. Bitmap 4 — Amount of Transaction

Attributes: Numeric, BCD
Size: 6 bytes, 12 digits: However, for settling through North, only 8 bytes (999,999.99) of
transaction amount are supported.
Req: Mandatory
Comments: This field specifies the transaction amount, in the acquirer’s currency. The applicable
currency code is entered in Field 49 (Transaction Currency Code).
Following are the important points on Amount of Transaction:
1. The number of implied decimals associated with the transaction amount depends
on the currency code. Refer to Appendix E (Currency Codes) for additional
information.
2. For Address Verification Only and Account Balance Inquiry type messages, the
transaction amount value must be ‘0’.
3. In most instances, the Transaction Amount value from the request message is
“echoed” back to the merchant in the host response messages (0110s, 0210s,
and 0410).
4. In the case of partially approved transaction responses (message 0110, in which
Field 39 contains a value of ‘10’), this field will contain the total amount approved
by the card issuer, and this amount should be used for reconciliation purposes.
5. Field 63, Table 68 — Additional Account/Amount Information will contain the total
transaction amount from the initial request, and it is provided for informational
purposes only.
6. For cash-back on a credit card, this field must contain the total transaction
amount. Field 63, Table 68 — Additional Account/Amount Information Data, must
also be included and must contain the cash-back amount portion of the
transaction.
7. On a 0400 (Debit/EBT) reversal message, this field must match the original 0200
(Debit/EBT) request.
8. On 0400 Partial Reversal message, this field represents Replacement Amount
and not the reduced amount.
9. On 0400 Full reversal message, this field represents the amount authorized.
10. On Incremental authorization, this field represents the incremental amount to be
authorized.


4.4.5. Bitmap 7 — Transmission Date/Time

Attributes Numeric; BCD
Req Optional
Comments This code identifies the month, day, hour, minute, and second a transaction is sent
(MMDDhhmmss). This must be represented in GMT or Universal time.
4.4.6. Bitmap 11 — System Trace/Debit Reg E Recipient Number

Req Mandatory
Comments A system-generated number is provided by the merchant and it uniquely
identifies a transaction. It is “echoed” back to the merchant in the host response
messages. This number needs to be a unique number per Merchant and
Terminal ID. If multiple terminals are used at a merchant’s location, the system
trace number must be different for each terminal. The system trace number must
increment from 000001 to 999999 and not reset until it reaches 999999. The
system trace number should never have a value of 000000. Every transaction
received by First Data must have a different system trace number, even if the
previous transaction was unsuccessful. For example, Split Tender and re-entry
of transaction (i.e. Invalid PIN-55 is received and PIN is re-entered or any other
reason of resubmission).
In 0200 Financial (Debit/EBT) Transaction requests and 0400 (Debit/EBT Card)

Reversals, this number is the “receipt” to comply with Debit Network Provider
requirements.
The System Trace entered on 0100 Incremental Authorization Request must be

identical to the System Trace of the original 0100 Authorization Request.
The System Trace entered on the 0400 Reversal Request must be identical to
the System Trace of the 0100 Authorization Request and 0200 Debit Request
being reversed.
System Trace Number can not be repeated for another Terminal ID of

the same merchant for the same day.
4.4.7. Bitmap 12 — Time, Local Transmission



Size 3 bytes, 6 digits; hhmmss
Req Conditional — Mandatory for Debit and EBT.
Not included for check transactions

Comments: For Point-of-Service (POS) terminals sending credit card transactions identifies
the hour, minute and second a transaction is sent. It must be POS terminal time
and match the printed receipt.
It is always recommended that merchants must submit relevant Time, Local

Transmission (Bitmap 12) value for Amex and Discover transactions. However, if
Bitmap 12 is not populated, First Data will submit Eastern Time (ET) as the time
for local transmission. It should be however, taken into consideration that not all
merchants are based out of East Coast of United States.
This is the time stamp of the transaction, and as a Regulation E requirement it

should be printed on the Debit Receipt given to a customer. It does not change
on subsequent transactions (i.e., on debit reversals).
For any merchant sending Debit/EBT card transactions, this field must be sent
with the request. It is assigned by the terminal.
On 0400 (Debit/EBT) reversal message the time of the transaction must match
the Transmission Date/Time in the original 0200 (Debit/EBT) request.


4.4.8. Bitmap 13 — Date, Local Trans. (Debit/EBT)/Sales Date (Credit)

Size 2 bytes, 4 digits-Fixed length; MMDD
Req Conditional — Mandatory for Debit and EBT
Not included for check transactions

Comments For POS terminals sending credit card transactions, this code identifies the month
and day a transaction is sent. It must be POS terminal time and match the printed
receipt.
This is the date stamp of the transaction and, as a REG-E requirement; it should be
printed on the Debit/EBT Receipt given to a customer. It does not change on
subsequent transactions (i.e., debit reversal).
For any merchant sending Debit/EBT card transactions, this field must be sent with
the request. It is assigned by the terminal or system originating the message.
On a 0400 (Debit/EBT) reversal message, this field must match the original 0200
4.4.9. Bitmap 14 — Card Expiration Date

Size 2 bytes, 4 digits-Fixed length; YYMM
Req Conditional — Mandatory for manual entry; optional for card-swiped transactions
(YYMM).
Comments This code indicates the year and month the Primary Account Number (PAN) expires.
It is included in both Track 1 and Track 2 data. The terminal does not store the track
information in the journal, so the PAN is sent on all advice messages (i.e., adjust,
off-line, etc.).
Transactions associated with an expired card must be settled within four days,
or the batch will be rejected.
For Discover Recurring and Installment transactions the transaction must
include a valid expiration date for the card being used in the recurring
agreement with the merchant.


4.4.10. Bitmap 18 — Merchant Category Code

Req Mandatory
Comments A code that identifies the type of business or services conducted by the service
establishment.
4.4.11. Bitmap 22 — POS Entry Mode+ Pin Capability

Req Mandatory
Comments This field specifies how the Primary Account Number was entered into the terminal.
The code is comprised of the POS Entry Mode Value and the PIN Capability Value:
POS Entry Mode

Value Description
00 Unknown
*
01 Manual/Key Entry
**
04 OCR code read
05 Integrated circuit card read — CVV data reliable
07 Contactless M/Chip or Visa Smart Card read
82 Contactless Mobile Commerce device
90 Magnetic Stripe–CVV/CVC certified, unaltered Track Data (1 or 2);
included in Authorization Request. Required to participate in PS/2000
or CPS/2000
***
91 Contactless chip magnetic stripe read
95 Integrated circuit card read — CVV data unreliable
*
For Check Guarantee/Verification, this value applies when check data is entered
manually, including manually entered MICR data.
Value also applies to E-Commerce for Visa and MasterCard.
Value also applies to Transponder transactions (Table 50).
**
For Check Guarantee/Verification, this value applies when an electronic device of


any kind is used during processing of the check (e.g., check reader or MICR
device).
***
Contactless chip magnetic stripe read is supported for Visa, MasterCard, Amex,
Discover and Debit cards only
PIN Capability
Value Description
0 Unknown
1 Can accept PIN
2 Cannot accept PIN (Valid Value for Transponders)
8 PIN Pad is down

9 PIN verified by terminal device
For example: 0012 consists of the following:
0 (Precedes the 3-digit code to make 2 full bytes)

01 (POS Entry Mode value=Manual/key entry)
2 (PIN Capability value=Terminal can not accept PIN)
4.4.12. Bitmap 24 — Network International ID (NII)

Req Mandatory
Comments This field identifies the acquiring host. This code will be returned on the host
response.
It consists of the following:
0 — Precedes the 3-digit code to make 2 full bytes

001 — First Data NII excluding Canadian Debit (appears as 0001 with added
0)
047 — Canadian Debit (appears as 0047 with an added 0)


4.4.13. Bitmap 25 — Point of Service (POS) Condition Code

Size 1 byte, 2 digits
Req Mandatory (Mandatory on Request, but Optional on Response)
Comments This field describes the conditions at the POS location for a particular transaction.
The possible values are as follows
POS Condition
Value Description
00 Normal Presentment (i.e., customer is present with card)
01 Customer Not Present
03 Merchant Suspicious of cardholder
*
04 Customer Not Present, Standing Order/Recurring and Visa Bill
Payment Transactions
**
05 Customer Present, Card Not
08 Mail/Phone Order
10 Customer ID Verified (Checks)
51 Card Verification Request
52 Address Verification only Request (Bit 4, zero filled)
***
59 E-Commerce
****
71 Card Present — Magnetic Stripe Cannot be Read
*
Recurring transactions supported for Visa, MasterCard, Amex and Discover
cards only
**
Valid value for Transponder transactions (Table 50)
***
Required for Visa, MasterCard and Amex E-commerce transactions. POS
Condition Code value of “08” should be used for all other card types.
****
Supported for Visa and Discover only. The card is present, the magnetic stripe
could not be read and the card number was key-entered. Visa requires Address
Verification (AVS) must be included within the authorization request message.
However, for Discover, AVS is optional.
On a 0400 reversal message, this field must match the original 0100/0200
request.

When performing E-Commerce Recurring transactions for MasterCard, the POS Condition
code must be 04 and the MOTO/ECI value in Field 63 Table 60 must be 05, 06, 07, or 08.



4.4.14. Bitmap 31 — Acquirer Reference Data

Attributes Alphanumeric, ASCII or EBCDIC
Size Variable to 99 bytes, preceded by 1-byte BCD length indicator
Req: Conditional - Required if the merchant is established as host capture.
This should only be used for host capture merchants. If this field is present for other
merchants, the transaction could be rejected.
Comments Contains values to be used by the “Acquirer” (First Data) to determine how to
process the transaction. Currently only the first byte in the field is being used. The
remaining positions are reserved for future use and should not be sent.
Position Type Length Description

1 AN 1 Capture Type Flag
Values
0 — Authorization Only
1 — Authorization/Capture
2 — Capture Only
If field 31 is not present in the Message, then a Capture Type of ‘0’ (Auth Only) will

be assumed.
2 …99 TBD TBD Reserved for Future Use
On a 0400 reversal message, this field must match the original 0100/0200 request.
4.4.15. Bitmap 32 — Acquiring ID

Size Variable to 6 bytes (12 digits) preceded by 1-byte BCD length indicator
Req Optional - This is no longer required. Existing merchants can discontinue sending
out bit 32 in their request messages. However, if they are sending up bit 32, they
can continue sending the same value that is currently in use. Default value is
000000000012.
Comments This code identifies the party processing the request (i.e., the “Acquirer,” which is
First Data).


4.4.16. Bitmap 35 — Track 2 Data

Attributes Z (Numeric + X ’D’ (BCD, ½ byte representation of D [1101] as a field separator
between Primary Account Number and Expiration Date), BCD — When an odd
number of digits, pack right-most half byte to ‘0’.
Size Variable to 37, preceded by a one-byte, BCD length indicator
Req Conditional — Present only if communicating Track 2 data
Comments This field contains the information encoded from a valid Track 2 magnetic stripe
read. It includes information such as the Primary Account Number and Expiration
Date. Entire Track Data must be forwarded intact (excludes Start Sentinel, End
Sentinel and Longitudinal Redundancy Check).
1. On Debit Card transactions, this field is mandatory.

2. On EBT Cash Benefit transactions, this field should be sent if available.
3. On EBT Food Stamp transactions, this field should be sent if available (If not
available, manual entry is allowed).
4. On EBT Voucher Clear transactions, this field is not available.
5. On Debit and EBT Card transactions, Bit 45 (Track 1) should be off.
7. On a Credit Card 0400 reversal message, Track Data should not be included in
the reversal message as Card Associations forbid the storage of track data.


4.4.17. Bitmap 37 — Retrieval Reference Number

Size 12 bytes, 12 Characters
Req Mandatory
Comments Authorization only — For Credit and debit transactions (excluding Canadian Debit)
the retrieval reference number can be any value based on the merchant’s choosing
(e.g. sequential tracking of transactions, fixed value etc.). The value submitted in the
request message is then echoed back in response. For example the value of
000000000001 for all transactions can be used. If the merchant leaves the retrieval
reference number blank in the request, First Data will assign a unique 12-byte
retrieval reference number and the assigned value will be returned in the response.
Authorization with capture — For Credit and debit transactions (excluding

Canadian Debit), this is a unique 12-byte reference number assigned to a transaction
by the merchant and returned in the response message. The retrieval reference
number should increment from …..001 to ….999 and should not be reset on a daily
basis until it reaches ….999.
Capture Only – For Credit transactions the retrieval reference number must be the
same value that was submitted in the original authorization request.
Canadian Debit — The POS terminal at the merchant’s location generates the

retrieval reference number and includes it in the transaction request. The host
echoes the value back in the response. The terminal must ensure that the number is
unique. The following formula is used to create the reference number.
Positions 1–4 0000
Positions 5–6 Last two digits of the terminal ID (Bit 41)
Positions 7–12 The terminal generated system trace number (Bit 11)
For example, if the Terminal ID (Bit 41) is ‘00123456’ and the System Trace Number
(Bit 11) is ‘004567’, the retrieval reference number (Bit 37) would be
‘000056004567’.
Reversals — In a 0400 (Debit/Credit) reversal request message, the retrieval

reference number must match the original 0100 (Credit) and 0200 (Debit) request.
This is applicable for Authorization with Capture for Credit and Debit, and Canadian
Debit only.


4.4.18. Bitmap 38 — Authorization Identification Response

Size 6 bytes, 6 characters
Req Conditional — Present in host response if the transaction is approved. Mandatory
for reversals and incremental.
Comments The Authorization ID Response is the approval code assigned by the association,
issuing bank, or Debit/EBT network.
On 0200 Financial Transaction (Debit/EBT Card), required for EBT Voucher Clear
transactions only.
On 0100 Authorization (VRU), required if Stand-in Processing was provided by

VRU.
Required on 0400 Debit voids, Credit Card reversals and on EBT Voucher Clear
transaction reversals if an approved 0210 authorization response was received.
For host capture merchants, this field is mandatory for Capture only (Bit 31 value of
2) and when the transaction is a Sale.
4.4.19. Bitmap 39 — Response Code

Req Conditional – Present in host response and mandatory for capture only transaction
request.
Comments The host response to a message to indicate the status of the transaction. The value
returned in the authorization response is submitted in the capture only transaction
request. Refer to Appendix A (Response Codes in Sequence By Text for Credit
Cards (page 6-2), Response code sequence by Code for Debit Cards (page 6-2),
Check Guarantee/Verification Related messages (page 6-35), Debit/EBT card
related messages (page 6-57) for the complete list (page 6-57). Most-common
responses are as follows:
Code Response Text
00 Approved (for capture)
76 Approved (non-capture)
01 Referral
51 Decline
For Partial Authorization reversals, the 0400 response must receive a
value of “10” in this field.



4.4.20. Bitmap 41 — Terminal ID

Req Mandatory
Comments This field contains a code that identifies a merchant terminal. A unique code must
be assigned to each terminal/POS device (e.g., a register) in a merchant location.
This code will be returned on the host response. In certain instances, the Terminal
ID may be assigned by the merchant; in other instances, First Data assigns it.
Please check with your First Data representative for details.
The Terminal ID does not conform to the standard definition of alphanumeric fields:
it is right justified and zero-filled on the left.
4.4.21. Bitmap 42 — Merchant ID

Req Mandatory
Comments This field contains a code assigned to a merchant location. Merchants must use
the First Data-assigned Merchant ID (see note below). The Merchant ID does not
conform to the standard definition of alphanumeric fields: it is right-justified and
zero-filled on the left.
On a 0100 VRU Authorization only (page 2-9), the Merchant ID can be the First
Data internal number or a merchant external number.


4.4.22. Bitmap 43 — Alternative Merchant Name/Location

Req Optional
Comments This field contains a number of sub-fields identifying the merchant’s name,
location and service entitlement number.
Must be in upper-case letters.

The purpose of this field is to override information that is stored for the
merchant on First Data’s Merchant Master. Merchant name, City and
State must be completely entered; otherwise the legal name in First
Data’s Merchant Master will be used. It is recommended for American
Express and Debit transactions that the Street Address also be
provided.
Field Name Attribute Req Value

Merchant AN 30 C Must be present if alternative Merchant Location data
Name should be used.
For Third Party Aggregators or Oil Companies processing

American Express Cards should provide unique processing
ids in this field. The Oil Companies should provide unique
station location code in the format “S#nnnnnnnnnnn”. The
Third Party Aggregators a unique, merchant-assigned, 16-
byte (max.), alphanumeric, seller/vendor code in the format
“S#nnnnnnnnnnnnnnn”.
Street Address AN 25 C If alternative location is provided for American Express or
Debit transactions, this must be present.
City AN 20 C Must be present if alternative Merchant Location data
should be used.
Alphabetic AN 2 C Must be present if alternative Merchant Location data
State should be used.
County AN 3 O Space filled
Zip Code AN 9 O Space filled, if not provided.
Country Code AN 3 O Needs to state numeric Country code. For more
information, refer to Appendix C on page 6-12.
Service AN 15 O If alternative Service Entitlement number needs to be used
Entitlement for non-bank cards, this information should be provided.
Number


4.4.23. Bitmap 44 — Additional Response Data

Size 1, preceded by 2-byte, BCD length indicator
Req Conditional — If Bit 48 is used in the request message (0100, 0200), this field is
returned in the response message (0110, 0210). For Host Capture merchants, if
the transaction is a Capture only transaction (Bit 31 value of 2) and address
verification was processed on the original authorization, the Address Verification
Response Code must be presented in the 0100 message.
Comments This field contains the response to an Address Verification Only (AVS) request:
Message Type Response Type Length Description

0110/0210) AVS 1 See AVS
Responses
AVS Result Code One character code indicating the result of the Address Verification process.
The different AVS result codes are listed in the following table.
Visa
Value Description
Y Yes: Address and ZIP Match
A Address: Address Matches ZIP Does Not Match
Z Zip: ZIP Matches, Address Does Not Match
N No: Address and ZIP Do Not Match
U Address Information not Verified for International Transaction or Service is not
supported
G Address Information not verified for international transaction
R Retry: System Unavailable or Timeout
E Error: Transaction ineligible for address verification or edit error found in the
message that prevents AVS from being performed
B Street Match: Street addresses match for international trans, but postal code
doesn’t
C Street Address: Street address and postal code not verified for international
transaction
D Match: Street addresses and postal codes match for international transaction
F Match: Street addresses and postal codes match for international transaction (for
UK only)
I Not Verified: Address information not verified for international transaction
M Match: Street Addresses and postal codes match for international transaction
P Postal Match: Postal codes match for international trans., but street address
doesn’t


MasterCard
Value Description
X Exact: Address and 9-digit ZIP Match
Y Yes: Address and 5-digit ZIP Match
A Address: Address Matches ZIP Does Not Match
W Whole Zip: 9-digit ZIP Matches, Address Does Not Match
Z Zip: 5-digit ZIP Matches, Address Does Not Match
N No: Address and ZIP Do Not Match
U Address Info is Unavailable
R Retry: System Unavailable or Timeout
E Error: Transaction ineligible for address verification or edit error found in the
message that prevents AVS from being performed
S Service Not Supported: Issuer does not support address verification
American Express
Value Description
Y Address and ZIP Match
A Address Matches ZIP Does Not Match
Z 9 or 5 digit ZIP Matches, Address Does Not Match
N Address and ZIP Do Not Match
U Address Information Is Unavailable
R System Unavailable or Timeout
S Issuer Does Not Support Address Verification
Discover
Value Description
X All digits match (9-digit Zip Code)
Y All digits match (5-digit Zip Code)
A Address matches, Zip Code does not
W 9-digit Zip matches, address does not
Z 5-digit Zip matches, address does not
N Nothing matches
U No Data from Issuer/Auth System
R Retry, system unable to process
S AVS not supported at this time


4.4.24. Bitmap 45 — Track 1 Data

Size Variable to 76, preceded by 1-byte, BCD length indicator
Req Conditional — Present only if communicating Track 1 data
Comments This field contains the information encoded from a valid Track 1 magnetic stripe
read, excluding the Start Sentinel, End Sentinel, and Longitudinal Record
Check (LRC). It includes information such as the Primary Account Number and
Expiration Date. Entire Track Data must be forwarded intact.
On a 0400 credit card reversal messages, Track Data should not be
included in the reversal message as Card Associations forbid the
storage of track data.
4.4.25. Bitmap 48 — First Data Private Use Data Element

First Data uses field 48 to communicate elements not included in the ISO 8583 specification. Refer to
page 4-27 in the First Data Private Use Data Elements for the specifications for this field.
Merchants certified to use the Debit Void functionality should include the ‘Message Reason
Code for Debit Reversals’ table. In this field and on all 0400 Debit Reversal Requests.

4.4.26. Bitmap 49 — Transaction Currency Code

Size 2 bytes, 4 digits (3-digit code, zero-filled to the left [e.g., 0840])
Req Conditional — Mandatory for “multi-currency” merchants, but optional for
merchants who use U.S. currency only.
Comments This field can be used to specify the currency type associated with a transaction
(e.g., 840=U.S. Dollar). Refer to Appendix D (Currency Codes) on page 6-17 for the
complete list of codes.


4.4.27. Bitmap 52 — Encrypted PIN Data

Attributes Binary, Hexadecimal Representation
Size 64 bit (compacted to 8 bytes)
Req Conditional — Mandatory for Debit Card transactions, EBT Cash Benefit
transactions, and all EBT Food Stamp transactions except for EBT Voucher Clear
transactions.
Comments Personal Identification Number (PIN) data as received from the PIN pad. The
terminal is not itself a secure device, so it doesn’t process the PIN data. The
terminal simply passes the encrypted PIN data (cryptogram) as received from the
PIN pad. If the original cryptogram is available, on a 0200 message and if the
original cryptogram is not available, on a 0400 message send eight bytes of Hex
‘0’s.
All new applications supporting Debit and EBT are required to use Derived Unique
Key Per Transactions (DUKPT) key management between the point-of-sale and
the first link where the PIN block is decrypted and re-encrypted at a Host Security
Module. This means that in most situations Leased Line merchants will be required
to use DUKPT key management, since the PIN block will be passed from the point-
of-sale to the corporate host to the First Data host, where the First Data Host
Security Module decrypts it. For DUKPT, Field 63 (Table 33) is required in addition
to Field 52. Refer to page 4-65 for details concerning this table.
For any corporation that has its own Host Security Module, Debit/EBT transactions
are required to use DUKPT key management between the point-of-sale and the
corporate host to which the Host Security Module is attached. These transactions
can then be transmitted to the First Data host during Master/Session Key
management.
4.4.28. Bitmap 54 — Additional Amounts

Attributes Numeric, ASCII or EBCDIC
Size Variable to 12 bytes, preceded by 2-byte Length Indictor; right justified and contains
leading zeroes
Req Optional
Comments This field contains amounts associated with the transaction. For Debit card and
EBT Cash benefit transactions, this field represents the “cash back” amount. On a
0400 (Debit/EBT) reversal message, this field must match the original 0200
The number of implied decimals associated with the transaction amount
depends on the currency code. Refer to Appendix D (Currency Codes) on
page 6-17 for additional information.


4.4.29. Bitmap 59 — Merchant Zip/Postal Code

Size 9 bytes (Zip/Postal Code), preceded by 1-byte BCD, Length Indictor (always X ‘09’)
Req Mandatory
Comments The merchant’s postal/zip code. Left-justify and zero-fill if less than 9 bytes.
Addresses outside the United States may vary in length and can include
alphanumeric character content. Some addresses outside the United
States do not contain postal codes; in this case the zip code must be
space filled.
4.4.30. Bitmap 60 — Additional POS Information

Size 1 byte, 2 digits
Req Conditional (Required for any card-present transaction)
Comments This field is comprised of the POS Type (first four bits) and the POS Capability
(last four bits) data elements. The POS Type describes the general category of
terminal used for the transaction. POS Capability describes the data entry
methods available at the POS location.
POS Type
Value Description
0 Unspecified
1 Limited-Amount Terminal
2 Unattended Terminal (ATM)
3 Unattended Terminal – Self-Service Terminal
4 Electronic Cash Register
7 Dial Terminal/Register Device
POS (Terminal) Capability
Value Description
0 Unknown
1 Terminal Not Used
2 Magnetic Stripe Read Capability
5 Integrated Circuit Card Read Capability
6 Contactless Chip Read Capability
7 Contactless Magnetic Stripe Read Capability
9 Terminal Does Not Read Card Data



First Data uses Field 62 to communicate elements not included in the ISO 8583 specification. Refer to
page 4-26 in the First Data Private Use Data Elements for the specifications for this field (see note
associated with Bitmap Position 63).
The information present in Bit 62 messages table is for existing merchants (as of 2003) and should not be
implemented in transactions carried out by future business engagements (merchants processing
transactions through First Data). The above table is documented in First Data ISO 8583 Global
Specification for future reference only to be used by First Data.

First Data uses Field 63 to communicate elements not included in the ISO 8583 specification. Refer to
page 4-50 in the First Data Private Use Data Elements for the specifications for this field.
New merchants/VARS are required to use Bitmap Position 63. Existing merchants are
advised to switch from Bitmap Position 62 to 63 as well, since Bit 63 provides access to

additional tables supporting required/optional services.
4.4.33. Bitmap 70 — Network Management Information Code

Size 2 Bytes, 3 digits (Preceded by a ‘0’ to make two complete bytes)
Req Mandatory for 0800/0810 message types
Comments Indicates the function of a particular 0800 Test Message.
Value Description
0811 New Key Request
0301 Keep Alive Message
0001 Log-on Message
4.4.34. Bitmap 93 — Response Indicator

Size 5 Bytes
Req Mandatory for 0810 message type.
Comments The following five-digit code is sent back on the 0810 (Log-On Response) to
acknowledge that the 0800 (Log-On Message) has been received and processed:
‘00002’


4.4.35. Bitmap 96 — Key Management Data

Attributes Binary
Size Variable to 18 bytes preceded by a 1-byte Length Indictor
Req Optional
Comments This data element is used in Network Management requests to transmit encryption
key data or key validation information.
4.4.36. Bitmap 100 — Receiving Institution ID Code

Size Variable to 11 bytes, preceded by 1-byte BCD Length Indictor
Req Conditional
Comments A code that identifies the institution receiving the request. This ID is used when it is
not possible to route a message using the Account Number field. When this field is
included, it takes precedence over all account number fields for routing.
Reserved for future use.

4.4.37. Private Data Bitmaps

First Data uses the Private Data Fields to communicate data elements not included in the ISO 8583
specification. Use of these fields is described here and can also be referenced in the message format
section.
Field Name Message Purpose

48 0100 Address Verification Services processing
48 0100 Check Guarantee/Verification processing
48 0400 Debit Reversal Reason
62 0100 PS/2000 Indicator
62 0110 PS/2000 Response
62 0200 PS/2000 Indicator
62 0210 PS/2000 Response
63 0110 Display information (e.g. APPROVED)
63 0110 Display information from a Check Processor
63 0210 Display information (e.g. APPROVED)
63 0100 Extended Data Table Information


4.4.37.1. Bit 48 Message Data for Address Verification (AVS)

0100 message
Length Attribute N ...31 M 00 31Length of data to follow
Tran Code AN 2 M 99
Cardholder Zip/Postal AN 9 M Nine-digit ZIP Code; (Billing
Code Address)*
Cardholder Street AN 20 M Street address; left justify, space fill
Address (Billing Address)
*
First 9 = zip code, if only 5-digit ZIP is available, left justify and ‘space’ fill remaining 4 bytes.
For cardholders outside of the U.S., this field contains any alphanumeric postal code, which must be left
justified, and any remaining positions should be space filled.
4.4.37.2. Bit 48 Message Reason Code for Debit and EBT Reversals/Void
0400 message
Length Attribute N ...06 M 00 06 — Length of data to follow
Transaction Code AN 2 M 25
Message Reason AN 4 M Specific reason this particular reversal was
Code generated
Value Description
4000 Transaction voided by cashier or
customer
4021 System generated reversal due to a
timeout


4.4.37.3. Bit 48 MICR or Driver’s License for Check Authorizations

0100 message
Length Attribute N ...47 M 00 47-Length of data to follow
Transaction Code AN 2 M See breakdown on next page
State Code AN 2 M State Code for Tran Codes 11, 30 and 50 (D.
or Zeros License);
00 for all MICR or if not applicable. For list of

TeleCheck codes, refer to page 6-39 in Appendix J.
Date of Birth or AN 6 M DOB MMDDYY for Tran Codes 11, 30 and 50 (D.
Zeros License);
000000 for MICR or if not applicable

Check. Acct # or AN 37 M Checking Acct # or
D. License or Drivers License or
MICR MICR
Transaction Codes
Fidelity TeleCheck ICS (NPC) Definitions
(Certegy)
11 30 unsupported For merchants who authorize checks by keying in
the driver’s license.
*
10 31 41 or 12 For merchants who authorize checks by always
keying in the checking account number (Short
MICR). Code 12 is used by existing merchants.
New merchants use 41.
14 32 42 or 13 For merchants who authorize checks by using an
electronic check reader (Full MICR). Code 13 is
used by existing merchants. New merchants use
42.
5 33 43 For merchants who normally use an electronic
check reader but have to key in the checking
account information because the check reader is
broken, the check is wrinkled, or won’t work in the
check reader (Full MICR).


Definitions
Short MICR — Only part of the MICR checking account information needs to be keyed in, usually part of
the account number. Fidelity (Certegy) or First Data provides a small plastic device for the clerk to place
over the check to show which digits to key.
Full MICR — All the information on the MICR line (the bank transit/routing ABA number, the entire
checking account number, and the check sequence number) is required and must be provided by either
using an electronic check reader to read this information or keying it in manually.
* Existing merchants utilizing TeleCheck for authorizations that currently only submit the account number
in the MICR data are being requested to support full MICR data to improve the validation. For new
merchants or vendor applications that submit authorization to TeleCheck via First Data account number
only will no longer be supported for format validation.
Electronic Check MICR Reader

First Data supports check readers for all of the check processors it supports. The three major brands can
be used but they must be set up with the proper format:
ABA (Bank) number, “T”, Account number, “A”, Sequence number.
This can be a maximum of 39 bytes in length, including the “T” and “A” delimiters. The configurations for

the certified manufacturers are as follows:
Make (Model) Format ID

IVI (MR1000) Format # 16
MAGTEK(Mini/Maxi) Format # 1118
Checkmate (CMR400M) First Data VeriFone Printer

If the check reader can’t read a check, the merchant must key in the information manually. The numbers
from the check must be entered as shown in the above format. To that end, First Data has programmed
its terminals to prompt for the “Bank Number” to allow the operator to enter the ABA (bank) number first
(8-9 digits). The terminal then prompts for the Account Number (4-18 digits), followed by the Check
Sequence Number (3-10 digits). Since the alpha separators “T” and “A” are inserted by the terminal
software, it’s unnecessary for the operator to key them.


4.4.37.4. Bit 62 PS/2000 Indicator

0100, 0200 messages
Field Attribute Req Value
Length Attribute N ..1 M 01-Length of data to follow
MC/Visa PS/2000 Indicator AN 1 M “Y" if PS/2000 merchant
This field is not present if the merchant is not a PS/2000 merchant of this document (including
CPS/2000).

The information present in Bit 62 PS/2000 Indicator (PS/2000, LEASED LINE ONLY) 0100,
0200 messages table is for existing merchants (as of 2003) and should not be implemented in
transactions carried out by future business engagements (merchants processing transactions
through First Data). The above table is documented in First Data ISO 8583 Global
Specification for future reference only to be used by First Data.
4.4.37.5. Bit 62 PS/2000 Response

0110, 0210 messages
MC/Visa AN 20 M If “Y” was present in request message:
nn = length + 'A', 'E', 'C' = Approved
+ 15-digit Tran ID *
+ 4-digit Validation Code **
or . . .
nn = length + 'N' = Declined
MasterCard
*Transaction ID= BankNET Date (4 bytes) +
BankNET Reference (9 bytes) +
Blanks (2 bytes)
**Validation Code= CVC Error (1 byte) +
POS Entry Mode Change (1 byte) +
Transaction Edit Error Code +
Blank (1 byte)
The information present in Bit 62 PS/2000 Response (PS/2000, LEASED LINE ONLY)) 0110,
0410 messages table is for existing merchants (as of 2003) and should not be implemented

for transactions carried out by future business engagements (merchants processing
transactions through First Data). The above table is documented in First Data ISO 8583
Global Specification for future reference only to be used by First Data.


4.4.38. Bit 63 Private Data Field
0100, 0200 messages

Field Name Attribute ReqValue
Length Attribute N ...999 M 00 nn-Lengths of data in field 63 —This appears
at the beginning of field 63, not beginning of
each table.
Table Length N ...999 M BCD length of the table
Table ID AN 2 M Table Identifier
Table Data Elements Data content of table; see individual table
formats
Table Length, ID and Data Elements are repeated for each of the included tables
4.4.38.1. Bitmap 63 Private Data Field Tables

Supplemental request data can be submitted in one or more of the following tables, which reside in Bit 63.
Each table has its own length indicator and ID (i.e., the Table Length and Table ID fields, respectively).
When more than one table is included in Bit 63, the Table Length and Table ID fields are used to specify
where one table ends and the next begins. The Length Attribute field, appearing at the beginning of Bit
63, indicates the entire length of the data presented in Bit 63; therefore, the Length Attribute field appears
just once at the beginning of Bit 63, not at the beginning of each table. The host bypasses those fields
that it doesn’t recognize and processes any subsequent fields that it recognizes. Please note that when a
table is included, all of its fields must be present, even if there is no data contained in one or more of its
fields.

New merchants/VARS are required to use Bitmap Position 63. Existing merchants are
advised to switch from Bitmap Position 62 to 63 as well, since it provides access to additional

tables supporting required/optional services.


4.4.38.2. Summary of Defined Tables

Table Product Applied to Applied to Applied to Applied to Applied to Applied to Page
ID Auth only Auth Only Auth-Cap Auth-Cap Cap Only Cap Only
Request Response Request Response Request Response
14 CPS/2000 Additional Visa 0100 0110 0100 0110 0100 0110 4-38
Data
0400 0410 0400 0410
14 Additional MasterCard Data 0100 0110 0100 0110 0100 0110 4-50
0400 0410 0400 0410
14 Discover Partial Reversal 0400 0410 0400 0410 4-57
Data
14 American Express CAPN 0100 0110 0100 0110 0100 0110 4-58
Data
20 Additional Data (Lodging 0100 4-59
Information)
22 Host Response Text 0110 0110 0110 4-59
0210 0210 0210
0410 0410 0410
24 Fleet Card Data (Applicable 0100 0110 0100 0110 4-60
for M/C only)
*
25 Fleet Card Data — New 0100 4-61
Functionality
31 Network Response 0210 4-62
Code/Canadian
*
Transactions — New
Functionality
32 Canadian MAC and Check 0810 0200 0210 4-64
*
Digits — New Functionality 0400 0410
33 Derived Unique Key Per 0200 0200 4-65
Transaction (DUKPT) 0400 0400
34 Canadian Debit Keys 0810 0210 4-66
35 Additional Data (Car Rental) 0100 4-67
36 Additional Addendum Data 0100 0100 4-67
— For Host Capture
Settlement Only
37 Canadian Debit Encrypted 0210 4-68



Balance — *New
Functionality
38 Canadian Reversal Reason 0400 4-69
Code – *New Functionality
48 Terminal Prompting — for 0100 0110 0100 0110 4-70
Visa
49 Card Code Value 0100 0100 4-71
Information
49 Card Code Response 0110 0110 0100 4-71
Information for Capture only
Transactions
50 Transponder Transaction 0100 0100 4-73
Information
51 Existing Debt Indicator 0100 0100 4-74
54 Deferred Billing Indicator 0100 0100 0100 4-75
55 Merchant Advice Code 0100 0110 0100 0110 4-76
Indicator (MasterCard and
Visa Recurring transactions
only)
56 Reg E Data 0200 0200 4-78
57 Old Visa Payer 0100 0100 4-79
Authentication Service
(VPAS)-DEFUNCT
58 Additional Transaction 0100 0100 4-80
Information (Foreign
Currency MasterCard)
59 Universal Cardholder 0100 0100 0100 4-82
Authentication Field (UCAF)
Information
60 MOTO/Bill 0100 0100 0100 4-84
Payment/Electronic
Commerce Additional POS 0400 0400
Info.
62 Electronic Benefits Transfer 0200 0210 0200 0210 4-85
(EBT) Data


65 Visa Payer Authentication 0100 0110 0100 0110 0100 4-87
Service (VPAS) Response
68 Additional Account/Amount 0100 0110 0100 0110 0100 4-90
Information Data
69 Agent Identification Service 0100 0100 4-95
(AUAR/TPP ID)
70 Dual Event Settlement 0100 4-97
Table
L1 Loyalty Card Action 0100 0100 4-99
Request —*New 0200 0200
Functionality 0400 0400
L2 Loyalty Card File Update 0100 4-104
Request *New Functionality
L3 Loyalty Card Action 0110 0110 4-106
*
Response New 0210 0210
Functionality 0410 0410
L4 Loyalty Card File Update 0110 4-107
*
Response New
Functionality
L5 Loyalty Display Response 0110 0110 4-108
*
— New Functionality 0210 0210
0410 0410
**
VI Visa Compliance Field 0100 0110 0100 0110 0100 0110 4-109
Identifier Table
**
DS Discover Qualification Field 0100 0110 0100 0110 0100 0110 4-111
Identifier Table
**
PD Promotional Data Field 0100 0100 4-113
Identifier Table 0400 0400
**
PE Petroleum Field Identifier 0100 0100 4-114
Table
**
P2 Purchase Card Level 2 0100 0100 4-115
**
Field Identifier Table
**
These tables use the Field Identifier Table structure.


4.4.38.3. Table Requirements for Special Features:

Industry Special features Visa MasterCard AMEX DS JCB
+Diners ‘36’
Car Rental Common Tables 14, 35, 14, 35 14, 35 DS
69*, VI
Direct Common Tables 14, VI 14 14 DS
Marketing Partial/Full Reversal 14 14 14
Terminal Prompting 48
CVV2/CVC2/CID 49 49 49 49
Existing Debt Indicator 51
Deferred billing 54
Merchant Advise Code 55 55
(Recurring billing)
Single 60 60
Bill/Recurring/Installme
nt Payment
transactions
Agent Identification 69*
Service (only for
VAR/VAD/Gateway)
E-commerce Common Tables 14, VI 14 14 DS
Partial/Full Reversal 14, 60 14, 60 14
CVV2/CVC2/CID 49 49 49 49
Deferred billing 54
Merchant Advise Code 55 55
(Recurring billing)
Foreign Currency 58
MasterCard
UCAF 59
E-commerce Indicator 60 60
VPAS 65, 60
Single Bill Payment 60
transactions
Service (only for
VAR/VAD/Gateway)
Lodging Common Tables 14, 20, 14, 20 14, 20 DS
69*, VI
Retail Common Tables 14, VI 14 14 DS
CVV2/CVC2/CID 49 49 49 49
Deferred billing 54
Debit 33 33
EBT 62 62
Prepaid cards 68 68 68 68
Single Bill Payment 60
Transactions
Service (only for

to First data
November 11, 2008

Industry Special features Visa MasterCard AMEX DS JCB

+Diners ‘36’
VAR/VAD/Gateway)
Auto-Substantiate 14, 68 14, 68
Health Benefits
Auto-Substantiate 14, 68
Transit
Visa Compliance Table is mandatory for merchants who are responsible for matching. If
the matching is performed by First Data, this is an optional table.

Table 69 Agent Identification Service (AUAR/TPP ID) is only used for
VAR/VAD/Gateways.


4.4.38.4. Bit 63 — (Table 14) CPS/2000 Additional Visa Data

(Applicable to Authorization only, Authorization and Capture, and Capture
only)
0100, 0110, 0400, 0410 messages
Length Attribute N ...999 M 0n nn — Length of data to follow — (Appears at
beginning of field 63, not at beginning of each table)
Table Length N ...999 M 00 48 — Length of data in this table
Table ID AN 2 M X'31 34' — Table 14 — Visa CPS/2000 Data
ACI AN 1 M Authorization Characteristics Indicator. Refer the
(Authorization ACI table given below for specific values.
Character. Ind.) The value received in the 0110 response must be
submitted in the 0400 reversal message and
capture only transaction request message. For a
reversal of an incremental authorization, ACI value
capture only transaction message must be the
same value received in the 0110 response of the
initial authorization message. For ACI values, refer
to ACI table on Page 3-40.
Tran ID AN 15 M Terminal will send X’20’ (spaces) in initial
authorization message:
(Provided by
Issuer) The value received in the 0110 response must be
capture only transaction request message. In case
of incremental authorization, value received in the
0110 response of the initial authorization message
must be submitted in the 0400 reversal message
and capture only transaction request message. For
Visa Transactions, a 15-digit identifier assigned by
Visa used to uniquely identify and link together all
related messages and records used for
authorization and settlement through Visa. If the
merchant submits an authorization request that
qualifies for REPS and the transaction is approved,
Visa's authorization system will send the
Transaction Identifier back in the authorization
response.



Validation Code AN 4 M Space-filled for initial authorization message. The
Issuer response will be sent for incremental
(Provided by authorizations and reversals.
Issuer)
The value received in the 0110 response must be
capture only transaction request message.
In case of incremental authorization, value received
in the 0110 response of the initial authorization
message must be submitted in the 0400 reversal
message and capture only transaction request
message.
For Visa Transactions, a four-byte code assigned by
Visa’s Authorization System that is used later to
determine the accuracy of the authorization data
contained in the settlement record. If the
authorization request qualifies for REPS and the
transaction is approved, the Validation Code is
included in the authorization response.
Market Specific AN 1 M MSDI
Data Indicator
Value Description
Space None
filled
A Auto
B Bill Payment
H Hotel
M Healthcare (Medical)
T Transit
The value submitted for reversal and capture only
request must mirror the value that was submitted in
the 0100 initial authorization request.
RPS AN 1 M The Requested Payment Service Indicator (RPSI) is
no longer applicable; space fill
First Authorized AN 12 M Used for 0400 reversal messages- Fill in the
Amount Amount that was initially authorized
All other message types including incremental
authorization message – Zero fill
See example on next page for details

Total Authorized AN 12 M Used for 0400 reversal message – Fill in the total
Amount * authorized amount after all incremental and partial
reversals. This value reflects the total authorized
amount after all incremental authorizations.
For all other message types – Zero fill
See example on next page for details


Table 14 must be submitted with the original auth response values for all Capture only
transactions (Bit 31 value of 2).

Incremental authorization is only supported for Lodging and Car Rental only.
*
The Total Authorized Amount consists of the total value of all transactions with this Tran ID. This data
must be provided with Visa partial reversals as shown here:

Partial Reversal
Initial Authorization
+ Any Incrementals
= Total Amount
Amount values must always contain numeric characters (zero nine). Nulls and spaces are not
acceptable.



Authorization Characteristic Indicator (ACI) Table

Authorization Characteristic This field indicates the result of the Visa's evaluation of the
Indicator (ACI) authorization characteristics of a custom payment service
(Formerly Payment Service transaction.
Indicator)
Submitted Value Authorization Criteria Definition Returned
Value
Y The full contents of either Track 1 or Card present A
Track 2 of the magnetic stripe were
transmitted to allow card authentication
through Card Verification Value (CVV)
processing.
Y The full contents of either Track 1 or Card present E

Track 2 of the magnetic stripe were with merchant
transmitted to allow card authentication name and
through Card Verification Value (CVV) location data
processing. Additional merchant name
and location data were submitted in the
authorization request.
Y A request for address verification (AVS) Card-not- V

was submitted with the authorization present (AVS)
request.
*
Y A CPS/Retail Key Entry transaction (POS Key Entered K
Entry Mode MUST be 01 and POS Transaction.
Condition Code must be 71). MCC must A problem was
NOT be an Automated Fuel Dispenser, encountered
Direct Marketing, or Emerging Market during reading
Visa Only
code. of magnetic
stripe data.
* Address Verification is Required
Y A request for preferred customer Card-not- R
participation was submitted with the present (AVS
authorization request. not required)
Y A request for preferred customer Transaction T
participation was submitted with the cannot
authorization request. participate in
CPS programs


Submitted Value Authorization Criteria Definition Returned

Value
P A request for preferred customer Card-not- P
participation was submitted with the present
authorization request (preferred
customer
participation)
R Health Care and certain Select Card not R
Developing Market transactions will present address
qualify for CPS/ Card-Not-Present without verification not
AVS during Authorization. Not eligible for required
Electronic Commerce transactions.
Y A card not present, Electronic Commerce Card not S
transaction with 3D secure attempt present, 3-D
authorization data. secure attempt
I Original authorization was approved as a Incremental I
custom payment service transaction. authorization
Y A card not present, Electronic Commerce Card not F
account funding transaction with AVS present,
match and CVV2. Account
Funding
Y A card not present, Electronic Commerce Card not U
transaction with 3D secure authorization present, 3-D
data. secure
Y A card not present, Electronic Commerce Card not W

transaction with AVS. present, non-3-
D secure
Any The authorization did not qualify as a Not a custom N
custom payment service transaction, or payment service
transaction
The acquirer or the merchant is not
participating in a custom payment
service.


4.4.38.5. Visa Partial Reversal — Additional Explanation

— Example Based on U.S. Currency (i.e., 2 assumed decimal places) —
Visa-Partial Reversal with incremental authorization

Applicable for lodging and car rental industries only
Scenario:
Initially, a transaction of $100.00 is sent for authorization. In addition to that, another transaction of $50.00
(incremental), carried out by the same customer, is sent for authorization. The total authorized amount is
now $ 150.00. However, the final settlement/replacement amount for this transaction is $125.00. The
difference between the authorized amount and the replacement amount necessitates the merchant to
perform a partial reversal of $25.00. To initiate a reversal, the merchant must indicate the total
authorization amount ($ 150.00) and the final replacement amount ($ 125.00) in Bit 4 and Bit 63 (Table
14) of the 0400 reversal message.
The following section gives you an idea of the details that you must enter in Bit 4, as well as Bit 63 (Table
14).
Details of Transaction Messages:

1. 0100 message is sent out from the merchant’s terminal to authorize $100.00. The following bits in
the 0100 message display information that are relevant to the $100.00 Initial authorization
request:
Bit 4 — Displays the initial transaction amount requested for authorization, which is $100.00.
Bit 63, Table 14 — Displays the initial authorized amount and the total authorized amount for
reversal messages, which are both $0.00.
2. 0100 message is sent out from the merchant’s terminal to authorize $50.00 (incremental). The

following bits in the 0100 message display information that are relevant to the $50.00 incremental
authorization request:
Bit 4 — Displays incremental transaction amount requested for authorization, which is $50.00.
Bit 63, Table 14 — Displays the incremental authorized amount and the total authorized
amount for reversal messages, which are both $0.00.
3. 0400 Reversal message is sent out by the merchant to First Data for reversing $25.00. To initiate
the reversal request, the merchant must specify the total authorized amount ($150.00) and final
replacement amount ($125.00) in the 0400 message. The following bits in the 0400 message
display information that are relevant to the transaction:
Bit 4 — Displays the final authorization transaction amount, which is $125.00. This amount is
the final replacement amount.
Bit 63, Table 14 — Displays the first authorization amount and the total authorized amount for
reversal messages. In this scenario, the first authorized amount is $100.00 and the total
authorized amount is $150.00.
The table below displays the details of the transaction messages with the transaction amounts used in the
scenario described above.



Transaction Type Message Type Amount of Private Data Private Data Field
Transaction Field (Bit 63, Table 14)
(Bit 63, Table Total Auth Amount
(Bit 4) 14)
First
Authorized
amount
Initial 0100 100.00 0.00 0.00
Authorization (Authorization (This is the first
Request — ISO authorized amount)

Message)
Incremental 0100 50.00 0.00 0.00
Authorization (Authorization (This is the
Request — ISO incremental
Message) authorized amount)
Partial Reversal 0400 125.00 100.00 150.00
(Authorization (This reflects the (This is the first (This is the total
Reversal final replacement authorized authorized amount)
Request-ISO amount) amount)
Message)
The reversal must be performed before replacement. The following details are captured for replacement:
Transaction Type Replacement Amount Initial Authorization Total Authorization

Amount Amount
Replacement 125.00 100.00 125.00


Visa-Partial Reversal without incremental authorization

Scenario:
A transaction of $100.00 is sent for authorization. However, the final replacement amount for this
transaction is $25.00. The difference between the authorized amount and the replacement amount
necessitates the merchant to perform a partial reversal of $75.00. To initiate a reversal, the merchant
must indicate the total authorization amount ($ 100.00) and the final replacement amount ($ 50.00) in Bit
4 and Bit 63 (Table 14) of 0400 reversal message respectively.
14).

the 0100 message display information that are relevant to the $100.00 initial authorization
request:
Bit 4 — Displays the transaction amount requested for authorization, which is $100.00.
Bit 4 — Displays the final authorization transaction amount, which is $25.00. This amount is the
final replacement amount.
Bit 63, Table 14 — Displays the initial authorization amount and total authorized amount for


Transaction Type Message Type Amount of Private Data Field Private Data Field
Transaction (Bit 63 Table 14) (Bit 63, Table 14)
(Bit 4) First Authorized Total Auth
Amount Amount
Authorization 0100 100.00 0.00 0.00
(Authorization (This is the first
Request — ISO and the only
Message) authorized
amount)
Partial Reversal 0400 25.00 100.00 100.00
(Authorization (This reflects the (This is the first (This is the total
Reversal final replacement and the only authorized
Request — ISO amount) authorized amount)
Message) amount)
Transaction Type Replacement Initial Authorization Amount Total Authorization

Amount Amount
Replacement 25.00 100.00 0.00


4.4.38.6. Visa Full Reversal — Additional Explanation

The reversal request should reflect the same data element values that were provided in the original
authorization request (0100). In addition, the reversal request message (0400 — Credit Card) must
contain the approval code that was provided in response to the original authorization request.
Please note that the amounts entered in the Transaction Amount, First Authorized Amount, and the Total
Authorized Amount fields should be the same. For additional details, refer to the Appendix M Additional
Processing Options — Reversal Processing.
— Example Based on U.S. Currency (i.e., 2 assumed decimal places) — on next page
Visa-Full Reversal without incremental authorization

Scenario
A transaction of $100.00 is sent for authorization. However, the sale is cancelled and the replacement is
never performed. This necessitates the merchant to perform a full reversal of $100.00. To initiate a
reversal, the merchant must indicate the full reversal amount ($100.00) and the total authorization amount
($100.00) in Bit 4 and Bit 63 (Table 14) of 0400 reversal message respectively. Besides that, the 0400
reversal request message must contain the approval code that was provided in response to the original
14).
request:
2. 0400 Reversal message is sent out by the merchant to First Data for reversing the total
authorized amount, which is $100.00. To initiate the reversal request, the merchant must specify
the total authorized amount ($100.00) and full reversal amount ($100.00) in the 0400 message.
The following bits in the 0400 message display information that are relevant to the transaction:
Bit 4 — Displays the full reversal amount, which is $100.00.




Transaction Message Amount of Private Data Field Private Data Field
Type Type Transaction (Bit 63, Table 14) (Bit 63, Table 14)
(Bit 4) First Authorized Total Auth Amount
Amount
Authorization 0100 100.00 0.00 0.00
(Authorizati (This is the first
on Request and the only
— ISO authorized
Message) amount)
Full Reversal 0400 100.00 100.00 100.00
(Authorizati (This reflects the (This is the first and (This is the total
on Reversal total authorized the only authorized authorized amount)
Request — amount which is amount)
ISO to be reversed.
Message)
Visa-Full Reversal with incremental authorization

Scenario:
Initially, a transaction of $100.00 is sent for authorization. In addition to that, another transaction of $50.00
(incremental), carried out by the same customer, is sent for authorization. The total authorized amount is
now $ 150.00. However, the sale is cancelled and the replacement is never performed. This necessitates
the merchant to perform a full reversal of $150.00. To initiate a reversal, the merchant must indicate the
total reversal amount ($ 150.00) and the total authorization amount ($ 150.00) in Bit 4 and Bit 63 (Table
14) of the 0400 message respectively. The following section gives you an idea of the details that you
must enter in Bit 4, as well as Bit 63 (Table 14).
request:
Bit 4 — Displays the initial transaction amount requested for authorization, which is $100.00.
2. 0100 message is sent out from the merchant’s terminal to authorize $50.00 (incremental). The
following bits in the 0100 message display information that are relevant to the $50.00 incremental
authorization request:
Bit 4 — Displays incremental transaction amount requested for authorization, which is $50.00.
Bit 63, Table 14 — Displays the incremental authorized amount and the total authorized
amount for reversal messages, which are both $0.00.
3. 0400 Reversal message is sent out by the merchant to First Data for reversing $150.00. To
initiate the reversal request, the merchant must specify the total reversal amount ($150.00) and
total authorized amount ($150.00) in the 0400 message. The following bits in the 0400 message
Bit 4 — Displays the total reversal amount, which is $150.00.


Bit 63, Table 14 — Displays the incremental authorization amount and the total authorized
amount for reversal messages. In this scenario, the first authorized amount is $100.00 and the
total authorized amount is $150.00.
Transaction Message Type Amount of Private Data Field Private Data

Type Transaction (Bit 63, Table 14) Field
(Bit 4) First Authorized (Bit 63, Table
Amount 14)
Total Auth
Amount
Initial 0100 100.00 0.00 0.00
Authorization (Authorization (This is the first
Request — ISO authorized
Message) amount)
Incremental 0100 50.00 0.00 0.00
Authorization (Authorization (This is the
Request — ISO incremental
Message) authorized
amount)
Full Reversal 0400 150.00 100.00 150.00
(Authorization (This reflects the (This is the first (This is the
Reversal Request total authorized authorized amount) total
— ISO Message) amount which is authorized
to be reversed.) amount)


4.4.38.7. Bit 63 — (Table 14) Additional MasterCard Data

only)
0100, 0110, 0400, 0410 messages
Length N …999 M 0n nn-Length of data to follow — (This only appears at the
Attribute beginning of field 63, not preceding each table.)
Table length N …999 M 00 48 — Length of data in this table
Table ID AN 2 M X'31 34' — Table 14 — MasterCard
ACI AN 1 M Authorization request message:
P = Preferred Customer Status (Lodging/Car Rental)
Y = All other authorization request messages
Authorization response message:

P = Preferred Customer Status (Lodging/Car Rental)
A = Normal Response all others (default value)
The value received in the 0110 response must be submitted

in the 0400 reversal message and capture only transaction
request message.
BankNET AN 4 M Space-fill in authorization request message. The value
Date received in the 0110 response must be submitted in the
0400 reversal message and capture only transaction
request message. The Issuer will respond with the 4-byte
BankNET Date (MMDD).
BankNET AN 9 M Space-fill in authorization request message. The value
Reference received in the 0110 response must be submitted in the
0400 reversal message and capture only transaction
request message. The Issuer will respond with the 9-byte
BankNET Reference.
Filler AN 2 M Space-fill
CVC Error AN 1 M Space-fill in authorization request message.
Code CVC Incorrect Indicator. An indicator, provided by the Issuer
in the authorization response, to identify the presence of an
invalid card verification code (CVC). If there is an error, the
Issuer will respond with the 1-byte CVC Error Code (Y).
request message.
POS Entry AN 1 M Space-fill in authorization request message. If the entry
Mode mode has changed, the Issuer will respond with the 1-byte
Change POS Entry Mode Change (Y).

request message.



Transaction AN 1 M Space-fill in authorization request message. If there is an
Edit Error error, the Issuer will respond with the 1-byte Transaction
Code Edit Error Code. MasterCard's BankNET system will provide
track data validation and POS validation. If the track data
contains an edit error, a single one-position alphabetic error
code is provided. The error codes are described as follows:
Error Description
Code
A Track 1 or Track 2 not
present in the message.
B Track 1 and Track 2 present
in the message.
C Primary Account Number
not equal in track data.
D Expiration date not equal in
track data.
E Card type invalid in track
data.
F Field separator(s) invalid in
track data.
G A field within the track data
exceeds maximum length.
H The transaction category
code is "T".
I POS customer presence
indicator is "1".
J POS card presence indicator
is "1".
Market AN 1 M The Market Specific Data Indicator:
Specific Data Value Description
Indicator
M Medical/Healthcare: Only valid for merchants
participating in Healthcare Substantiation. For
more information, refer to Appendix K on Page 6-
45.
Space all others
The value submitted for reversal and capture only request
must mirror the value that was submitted in the 0100
Total AN 12 M Used to submit the Total Authorized Amount in 0400
Authorization reversal request message.
Amount
For all other message types – Zero fill
See example on next page for details.


Table 14 must be submitted with the original auth response values for all Capture only
transactions (Bit 31 value of 2).

The Total Authorized Amount consists of the total value of all transactions with this
Tran ID. This data must be provided with MasterCard partial reversals as well.
Amount values must always contain numeric characters (zero-nine). Nulls and spaces
are not acceptable.


4.4.38.8. MasterCard Partial Reversal — Additional Explanation

Example Based on U.S. Currency (i.e., 2 assumed decimal places)
MasterCard-Partial Reversal
Scenario
A transaction of $100.00 is sent for authorization. However, the final replacement amount for this
transaction is $25.00. The difference between the authorized amount and the replacement amount
necessitates the merchant to perform a partial reversal of $75.00. To initiate a reversal, the merchant
must indicate the total authorization amount ($ 100.00) and the final replacement amount ($ 50.00) in Bit
4 and Bit 63 (Table 14) of 0400 reversal message respectively.
14).
request:
Bit 63, Table 14 — Displays the total authorized amount for reversal messages. In this
scenario, the total authorized amount is $0.00.
Bit 4 — Displays the final authorization transaction amount, which is $25.00. This amount is the
final replacement amount.
Bit 63, Table 14 – Displays the total authorized amount for reversal messages. In this scenario,
the total authorized amount is $100.00.


Transaction Message Type Amount of Transaction Private Data Field

Type (Bit 4) (Bit 63, Table 14)
Total Auth Amount
Authorization 0100 100.00 0.00
(Authorization (This is the first and the
Request — ISO only authorized amount)
Message)
Partial Reversal 0400 25.00 100.00
(Authorization (This reflects the final (This is the total
Reversal Request — replacement amount) authorized amount)
ISO Message)
Transaction Replacement Initial authorization Total authorization amount

Type amount amount
Replacement 25.00 100.00 0.00


MasterCard Full Reversal

The reversal request should reflect the same data element values that were provided in the original
authorization request (0100). In addition, the reversal request message (0400 — Credit Card) must
contain the approval code that was provided in response to the original authorization request.
Please note that the amounts entered in the Transaction Amount and the Total Authorized Amount fields
should be the same. For additional details, refer to the Reversal Processing explanation, beginning on
page 6-57.
MasterCard-Full Reversal
Scenario
A transaction of $100.00 is sent for authorization. However, the sale is cancelled and the replacement is
never performed. This necessitates the merchant to perform a full reversal of $100.00. To initiate a
reversal, the merchant must indicate the full reversal amount ($ 100.00) and the total authorization
amount ($ 100.00) in Bit 4 and Bit 63 (Table 14) of 0400 reversal message respectively. Besides that, the
0400 reversal request message must contain the approval code that was provided in response to the
original authorization request.
The following section gives you an idea of the details that you must enter in Bit 4 as well as Bit 63 (Table
14).
request:
2. 0400 Reversal message is sent out by the merchant to First Data for reversing the total
authorized amount, which is $100.00. To initiate the reversal request, the merchant must specify
the total authorized amount ($100.00) and full reversal amount ($100.00) in the 0400 message.
The following bits in the 0400 message display information that are relevant to the transaction:
Bit 4 — Displays the full reversal amount, which is $100.00.

Transaction Type Message Type Amount of Transaction Private Data Field

(Bit 4) (Bit 63, Table 14)
Total Auth Amount
Authorization 0100 100.00 0.00
(Authorization (This is the first and the
Request — ISO only authorized amount)
Message)


Full Reversal 0400 100.00 100.00

(Authorization (This reflects the full (This is the total
Reversal Request — reversal amount) authorized amount)
ISO Message)


4.4.38.9. Bit 63 — (Table 14) Discover NRID Data

only)
0100, 0110 messages
Length Attribute N ...999 M 0n nn-Length of data to follow — (Appears at the
beginning of field 63, not at the beginning of each
table)
Table Length N ...999 M 00 48-Length of data in this table
Table ID AN 2 M X'31 34' — Table 14 — Discover Compliance data
Discover AN 1 M Discover Indicator - In the 0100 message the
Indicator indicator needs to be set to “X” in order to receive the
Discover NRID in the response message (0110).
The Discover NRID received in the 0110 response
message needs to be provided in the 0100 capture
only message.
NRID / AN 15 M Space-fill in the authorization request message.
Transaction ID The Discover NRID will only be provided in the 0110
(Provided by authorization response if the 0100 authorization
Issuer) request message contained a “X” in the Discover
Indicator. Otherwise it should be zero-filled.
Filler AN 6 M Space-filled
Filler AN 12 M Zero filled
Filler AN 12 M Zero-filled
4.4.38.10. Bit 63 — (Table 14) Discover Partial Reversal Data

only)
0400, 0410 messages
Length Attribute N …999 M 0n nn — Length of data to follow — (Appears at
beginning of field 63, not at beginning of each table)
Table Length N ..999 M 00 48-Length of data in this table
Table ID AN 2 M X'31 34' — Table 14 — Discover Partial Reversal

Discover Indicator AN 1 M Discover Indicator.
Value Description
Space No Additional Data Required
Total Authorized AN 12 M Used to submit the Total Authorized Amount after all
Amount incrementals and partial reversals. This value
replaces the original amount. For all other message
types — Zero fill


4.4.38.11. Bit 63 — (Table 14) American Express CAPN Data

only)
0100, 0110 messages
Length Attribute N ...999 M 0n nn-Length of data to follow — (Appears at
beginning of field 63, not at beginning of each
table)
Table Length N ...999 M 00 48-Length of data in this table
Table ID AN 2 M X'31 34' — Table 14 — Amex CAPN Data
American Express AN 1 M American Express Indicator; On 0100 message
Indicator needs to be set to “X” to receive Amex CAPN
response message (0110)
On a 0100 capture only transaction, the value

from Amex CAPN response message (0110)
needs to be sent.
Tran ID AN 15 M Space-fill in authorization request message.
(Provided by Only if the American Express Indicator on the

Issuer) authorization request message (0100) is an “X”,
the Amex CAPN Transaction ID will be returned in
the response (0110), otherwise zero-filled
POS Data AN 12 M Space-fill in authorization request message.
Only if the American Express Indicator on the

authorization request message (0100) is an “X”,
Amex CAPN POS Data field will be returned in the
response (0110), otherwise zero-filled.
On a 0100 capture only transaction,

value that corresponds to the transaction
Identifier received in 0110 message needs to be
sent.
Filler AN 12 M Zero-fill or Space-fill


4.4.38.12. Bit 63 — (Table 20) Additional Data (Lodging Information)

(Applicable to Authorization only – Visa only)
0100 message
Length Attribute N …999 M 0n nn — Length of data to follow — (This
appears at the beginning of field 63, not
preceding each table.)
Table length N ..999 M 00 86 — Length of data in this table
Table ID AN 2 M X'32 30' — Table 20 — Lodging Details
Folio Number AN 12 O Space filled; Reserved for future use.
Room Number AN 6 O Space filled; Reserved for future use.
Reference Number AN 9 O Space filled; Reserved for future use.
Program Indicator AN 1 C Space filled; Reserved for future use.
Arrival Date AN 4 O Space filled; Reserved for future use.

Departure Date AN 4 O Space filled; Reserved for future use.
Room Rate AN 12 O Space filled; Reserved for future use.
(Whole $ amount)
Cardholder Name AN 26 O Space filled; Reserved for future use.
Duration AN 2 M Length of Hotel Stay — Numeric characters
only, right justified, zero filled
Prestigious Property AN 1 O Space filled; Reserved for future use.
Indicator (PPI)
Extra Charges AN 6 O Space filled; Reserved for future use.
Visa No Show AN 1 O Space filled; Reserved for future use.
4.4.38.13. Bit 63 — (Table 22) Host Response Text

only)
0110, 0210, and 0410 messages
If the originating message contains Bit 63, the host will place any response text in a table (Table 22). If
the originating message does not contain Bit 63, any host response will be sent 'freeform' in Bit 63 (i.e.,
not inside a table). Text displayed on the terminal is based on the table submitted in the request message
(Bit 39).
Length N …999 M 0n nn-Length of data in Field 63 — (This
Attribute appears at the beginning of field 63, not at the
beginning of each table.)
Table length N ..999 M 00 nn — length of data in this table
Table ID AN 2 M X'32 32' —Table 22 — Response Text
Response AN Variable to M Example: APPROVED
Data 16


4.4.38.14. Bit 63 — (Table 24) Fleet Card Data

(Applicable to Authorization only, and Authorization and Capture)
0100, 0110 messages
Length Attribute N …999 M 0n nn-Length of data to follow — (This appears at the
table.)
Table Length N …999 M 00 14-Length of data in this field
Table ID AN 2 M X'32 34' — Table 24 — Fleet Card Data
Driver’s Number N 6 M Driver Number (Zero fill if not present) — Either a
Driver’s Number or Vehicle Number is mandatory.
Vehicle Number N 6 M Vehicle Number (Zero fill if not present) — Either a
Driver’s Number or Vehicle Number is mandatory.
Association Compliance (Fleet Card Authorization Tables)

**
This is new functionality; please check with your First Data Client Certification and Implementation
representative for availability, and certification procedures.
The table-25 has been developed to comply with MasterCard, and Visa Association mandates concerning
Fleet Card Authorization. Please check with First Data first for availability.
The MasterCard Corporate Fleet Card is part of MasterCard’s Corporate Products family. The Corporate

Fleet Card is an extension of the Purchasing Card and significantly leverages that infrastructure. The
MasterCard Corporate Fleet Card BIN range is a subset of the Purchasing Card BIN range. This allows
the Corporate Fleet Card to behave like a fleet card at petroleum locations, yet function exactly like a
purchasing card at all other Merchant Category Codes (MCCs). This functionality makes the MasterCard
Corporate Fleet Card ideally suited for use as a fully featured fleet card or a fleet plus T and E card. The
fleet functionality is completely dependent on the BIN range. Therefore, only cards within the Fleet BIN
range can provide this full functionality.
Visa Fleet is a part of the Visa Commercial Card Product and Services. Mid-to-large sized companies and
government entities use Visa Fleet as a payment tool for fuel and maintenance expenses for company
vehicles, or fleets. Fleet functionality includes a set of enhanced authorization and clearing capabilities for
participating Fleet merchants in the United States. These new capabilities are known as the Visa Fleet.
To support the Visa Fleet product, oil merchants have initially provided enhanced data, but maintenance
and repair sectors will be the logical next participants.
Participants from Visa and MasterCard come from the maintenance and repair sections of the fleet
industry.


4.4.38.15. Bit 63 — (Table 25) Fleet Card Data

**
(Applicable to Authorization only)

0100 message
Table 25 is used for MasterCard Fleet, and Visa Fleet transactions.
Length Attribute N ...999 M 0n nn — - Length of data in Field 63 (This appears
at the beginning of field 63, not at the beginning of
each table.)
Table length N ...999 M 00 11-Length of data in this table
Table ID AN 2 M X'32 35' — Table 25 — Fleet Card Data
Table Version AN 2 M “01”
ID Indicator AN 1 M Lengt Description
h
V Vehicle ID
D Driver ID
G Generic ID
ID Number N 6 M Zero filled if not entered at terminal


4.4.38.16. Bit 63 — (Table 31) Canadian Network Response Code

**
(Applicable to Authorization and Capture)

0210 message
The native network response code is mapped to ISO Bit Field 39 Response Code values and both values
are returned to the merchant in the Canadian Debit authorization response. Field 63, Table 31 contains
the native code and can be used to display or print descriptive error text at the point-of-sale.
Currently network codes are defined only for the Canadian Debit (EverLink) network — see
below.

Field Name Attribute Comment

Table Length N4 ‘0nnn’ – BCD length of data to follow
Table ID AN 2 X ‘33 31’
Network Response Code AN 2 Native network response code
EverLink Code Response Fault Allocation

00 Approved or completed successfully Approved
05 Do not honor Policy
06 Edit error Policy
11 Invalid processing code Policy
13 Invalid amount (edit error in amount) Policy
14 Invalid card number (edit error in PAN) Policy
19 RFI Error. Re-enter transaction System
23 Invalid Transaction Fee (future) Policy
40 Requested function not supported Policy
51 Not sufficient funds Policy
52 No checking account Policy
53 No savings account Policy
54 Expired card Policy
55 Incorrect PIN Policy
56 No card record (PAN not on authorizer’s database) Policy
57 Transaction not permitted to cardholder Policy
58 Transaction not permitted to terminal Policy
61 Exceeds withdrawal amount limit Policy
62 Restricted card-temporarily disallowed from Policy
interchange
63 MAC security failure System
65 Exceeds withdrawal frequency limit Policy
68 Response received too late (timeout) System
75 Allowable number of PIN entry tries exceeded Policy
77 Invalid capture date System
81 Invalid PIN block System
82 PIN length error System
85 No keys available System
86 KME synch error System
87 KPE synch error System

EverLink Code Response Fault Allocation

88 KMAC synch error System
91 Issuer or switch is inoperative System
92 Financial institution or intermediate network facility System
cannot be found for routing
94 Duplicate transmission System
96 System malfunction System
Q0 Edit error on capture date System
Q7 Exceeds RFI limit System
Response received that was not listed above System


4.4.38.17. Bit 63 — (Table 32) Canadian MAC and Check Digits

**

0200, 0210, 0400, 0410 and 0810 messages
The MAC is used to validate selected fields in a message. Currently, only the first 8 bytes are used and
the last 8 bytes are always zeroes. Field 63, Table 32 is included in Canadian Debit authorization
request/response; reversal request/response, balance inquiry request/response, and key update
response messages.

Table Length N4 ‘0022’ — BCD length of data to follow
Message Authentication AN 16 MAC authentication is bypassed if the Field 63, Table 32
Code (MAC) MAC in the response message is all spaces. The
message authentication code is created using the
message authentication working key.
Message Authentication AN 4 The check digits are validation characters associated
Working Key Check with the message authentication working key. The check
Digits digits are used to distinguish a MAC synch (31) reversal
error from a MAC verification (30) reversal error when
MAC authentication fails. If the MAC authentication fails
for a transaction and the check digits received in Field
63, Table 32 for the transaction do not match the check
digits stored in the terminal from the last key update,
then the Canadian Debit Reversal Code (Field 63, Table
38) is set to ‘31’ for synch error; otherwise, the Reversal
Code is set to ‘30’ for verification failure.


4.4.38.18. Bit 63 — (Table 33) DUKPT

Derived Unique Key per Transaction - DUKPT
(Applicable to Authorization only, and Authorization and Capture only)
0200, 0400 messages
Length Attribute N …999 M 0n nn — Length of data to follow — (This only
appears at the beginning of field 63 not at the
Table Length N …999 M 00 22 — Length of data in this table
Table ID AN 2 M X '33 33' — (Table 33 — Derived Unique Key Per
Trans.)
Key Serial AN 20 M DUKPT Encryption Key Data — includes the
Number Data (or following fields:
SMID – Security Length Description
Management
1 Pad Character (“F”)
Information Data)
9 Base Derivation Key ID (BDK ID) (If
fewer than nine positions, pad on
LEFT with ‘F’s.)
5 Device ID
5 Transaction Counter
For corporations that have their
own Host Security Module,

Debit/EBT transactions are
required to use DUKPT key
management between the point-
of-sale and the corporate host to
which the Host Security Module
is attached. Debit/EBT
transactions would then be
transmitted to the First Data
host using Master/Session key
management, and this field
would NOT be sent.
Do not send Table 33 with EBT
Voucher Clear transactions.


4.4.38.19. Bit 63 — (Table 34) Canadian Debit Keys

0210, 0810 messages
This table holds the Canadian Debit master session keys and is included with the Canadian key update
response (Message Type 0810; Processing Codes 000000) and optionally included with other Canadian
Debit ‘0210’ responses. The table defines values for the message authentication working key (TMAC),
the PIN encryption working key (TKPE) and the message/balance encryption working key (TKME).
If the terminal receives new keys on a transaction response, the new keys must be used for
that response and for all subsequent processing until new keys are received.


Message AN 16 Ignore if spaces — do not overwrite existing key.
Authentication
Working Key (TMAC)
PIN Encryption AN 16 Ignore if spaces — do not overwrite existing key.
Working Key (TKPE)
Message Encryption AN 16 Ignore if spaces — do not overwrite existing key.
Working Key (TKME)


4.4.38.20. Bit 63 — (Table 35) Additional Data (Car Rental)

0100 message
Length Attribute N …999 M 0n nn-Length of data to follow — (This appears
at the beginning of field 63, not at the
Table ID AN 2 M Table 35 — Car Rental Details
Rental City AN 18 O Space filled; Reserved for future use.
Rental State AN 2 O Space filled; Reserved for future use.
Rental Time AN 4 O Space filled; Reserved for future use.
Return City AN 18 O Space filled; Reserved for future use.
Return State AN 2 O Space filled; Reserved for future use.
Return Time AN 4 O Space filled; Reserved for future use.
Auto Audit Adj. AN 8 O Space filled; Reserved for future use.
Audit Adj. Ind. AN 1 O Space filled; Reserved for future use.
Renter Name AN 20 O Space filled; Reserved for future use.
Car Rental Agree. AN 12 O Space filled; Reserved for future use.
#
Rental Date AN 4 O Space filled; Reserved for future use.
Return Date AN 4 O Space filled; Reserved for future use.
Duration AN 2 M Length of car rental
Extra Charges AN 6 O Space filled; Reserved for future use.
Visa No Show AN 1 O Space filled; Reserved for future use.
4.4.38.21. Bit 63 — (Table 36) Additional Addendum Data

(Applicable to Authorization and Capture, and Capture only)
0100 message
Length Attribute N …999 M 0n nn — Length of data to follow — (Appears
at the beginning of field 63, not at the
beginning of each table)
Table ID AN 2 M X'33 36' — Table 36
Version # AN 1 M X ‘31’ — Version 1
Customer Service# AN 10 M Customer Service Phone #
Order # AN 15 M Order #
E-com URL AN 32 M Visa (13 Bytes)
MC (32 Bytes)


4.4.38.22. Bit 63 — (Table 37) Canadian Debit Encrypted Balance

**

0210 message
The encrypted debit account balance must be sent to the PIN pad along with the Message Encryption
Key (TKME) to obtain the decrypted account balance for display on the PIN pad.
Encrypted Debit AN 16 Encrypted debit account balance for Canadian processing.
Account Balance See the decrypted debit account balance format below.
Decrypted Debit Account Balance:

Balance Block: [sign] [balance]
[sign]: 'D' = Debit (minus amount)
'C' = Credit (positive amount)
[balance]: 9(15), amount in cents, padded with leading zeros
Examples (64 bit hex data block):
C000000000129959: $1,299.59
D000000000013952: -$139.52


4.4.38.23. Bit 63 — (Table 38) Canadian Reversal Reason Code

0400 message
This field may be included on 0400 reversal requests to indicate the reason for the reversal. This field is
required for Canadian Debit reversals and for partial approval transactions where the transaction was
voided by the cashier or customer.

Reversal AN 2 Mandatory for all Canadian Debit reversals and when the
Reason Code cardholder rejects a partial approval at the POS (‘00’ below).
Values are:
‘00’ – Transaction voided by cashier or customer

‘01’-Timeout (no response received at the terminal)
‘06’-Edit error (parse error at the terminal)
‘30’-MAC Verification Error (terminal MAC is invalid or data
used to verify the MAC is incorrect)
‘31’-MAC Synch Error (terminal MAC is out of synch with
host MAC)
‘86’-Message Encryption Error (terminal message encryption
key is out of synch with host message encryption key or
there is an error with the input data)
‘96’-System Error (all other errors such as communication
errors between the terminal and PIN pad).


4.4.38.24. Bit 63 — (Table 48) Terminal Prompting — for Visa

(Applicable to Authorization only, and Authorization and Capture only)
0100, 0110, messages
Length Attribute N …999 M 0n nn — Length of data to follow — (This appears at
the beginning of field 63, not at the beginning of each
table.)
Table ID AN 2 M X'34 38' — Table 48 — Terminal Prompting
Tax Amount AN 1 M On the 0100 (see explanation below), the terminal
Capable indicates whether it is “tax prompt capable.” If so, the
terminal will prompt for the sales tax when Visa
indicates that the card is a commercial card.
Business, corporate and purchasing cards are all a

subset of commercial cards; therefore, the terminal
should prompt for sales tax when it receives B, R, or S
in the 0110 response (see below). A “T” response
indicates that First Data received no response from
Visa; however, the terminal should still prompt for tax
if the transaction is approved since the card could be
commercial.
With the exception of the Fuel Industry,
Commercial card transactions must include

tax amounts to receive the highest rate.
0100 Request Message:

Value Description
T Terminal is tax prompt capable
0110 Response Message:
Value Description
B Visa Business Card
R Visa Corporate Card
S Visa Purchasing Card
T Unable to Obtain Info. from Visa (prompt
for Sales Tax)
Space Card is not one listed above


4.4.38.25. Bit 63 — (Table 49) Card Code Value Information

The Card Verification Value 2 (CVV2 — Visa), Card Verification Code 2 (CVC2 — MasterCard), Card
Identifier (CID — Discover) and Card Identifier (CID – American Express) are card verification tools
designed to reduce fraud losses, primarily on transactions during which the card is not present. These
values are collectively referred to as “Card Code Values”. Issuers are required to print the Card Code
Value on the back of all Visa/MasterCard/Discover credit, debit, consumer and commercial cards and on
the front of all such American Express cards. Participation in this program is optional. Participating
*
merchants must manually enter the Card Code values to use the tool.

0100 message (Request)
Field Attribute Req Value
Name
Length N …999 M 0n nn — Length of data to follow — (This appears at the
Attribute beginning of field 63, not at the beginning of each table.)
Table N …999 M 00 07-Length of data in this table
Length
Table ID AN 2 M X'34 39' — Table 49 — Card Code Value Information
Presence AN 1 M Code used to indicate the existence of the Card Code Value:
Indicator Value Description Card Types
0 Value is deliberately Visa, and Discover

bypassed or not provided
1 Value is present Visa, MasterCard,
Amex, and Discover
2 Value is present, but Visa, and Discover
illegible
9 Cardholder states that the Visa, and Discover
card has no value imprint
Card AN 4 M A 3- or 4-digit card verification code printed on the front or back

Code of the card, depending on the card product. American Express
Value uses a 4-digit code printed on the front of the card. Visa,
MasterCard, and Discover use a 3-digit code printed on the
back of the card. (Currently, only Visa, MasterCard, Discover
and American Express are supported, but other card products
will eventually be supported, too.) This field is right justified and
blank-filled.

*
The American Express Card Code Value Verification Program must be initiated through the merchant’s
written agreement with American Express.
*
For Discover Recurring Payments the merchant must use the Card Identification Data (CID) on the first
transaction, if submitting a Card Not Present transaction. Merchants must not store CID, and must not
submit CID on subsequent transactions.



0110 message (Response)
Attribute beginning of field 63, not at the beginning of each table.)
Table ID AN 2 M X'34 39' — Table 49 — Card Code Value Information
Response AN 1 M A Card Verification Value (Visa), Card Validation Code
Value (MasterCard), Card Identifier (Discover), and another
identically named Card Identifier (American Express)
returned on the Authorization Response Message in
response to the Card Code Value information entered on
the request. For example, the Card Code Response
Value “M” indicates that there is a Card Code Value
Match, whereas the Card Code Response Value “U”
indicates that the Card Code Value is unknown or that
the Issuer does not participate.
Value that corresponds to the Card Code Presence

Indicator value submitted on the 0100 message are as
follows:
Value Description Card Types
M CVV2/CVC2/CID Visa, MasterCard,

Match Amex, and Discover
N CVV2/CVC2/CID No Visa, MasterCard,
Match Amex, and Discover
P Not Processed Visa, MasterCard,
Amex, and Discover
S CVV2 should be on Visa, and Discover
the card, but
merchant indicated
that it was not
U Unknown/Issuer Visa, MasterCard,
does not participate and Discover
X Server provider did Visa, MasterCard,
not respond (Default) Amex, and Discover


Table 49: Card Code Response Information for Capture only Transactions
(Using Bit 31 value 2)
0100 message–“Capture only” Transaction
Length Attribute N ...999 M 0n nn — Length of data to follow — (This appears
each table.)
Table ID AN 2 M X'34 39' — Table 49 — Card Code Response
Information
Response Value AN 1 M Value that corresponds to the Card Code
Response Value received in the 110 message
4.4.38.26. Bit 63 — (Table 50) Transponder Transaction Indicator

0100 message
The transaction is/was submitted for payment using Transponder. If the Indicator value is not ‘1’, do not
use/transmit the table.
Length Attribute N …999 M 0n nn – Length of data to follow-(This only
Table Length N ..999 M 00 05 – Length of data in this table
Table ID AN 2 M X'35 30' - (Table 50 – Additional Transaction
Information)
Reserved AN 2 M X ‘30 30’
Transponder AN 1 M Transponder authorizations are non face-to-face
Transaction transactions where the card is not present, and a
Indicator transponder device is used to activate the
transaction.
Value Description
0 Not a transponder transaction
1 Transponder transaction


4.4.38.27. Bit 63 — (Table 51) Existing Debt Indicator

(Applicable to Authorization only, and Authorization and Capture for Visa Only)
0100 message
The transaction is/was submitted for the payment of an existing debt obligation. If indictor value is not ‘9’,
do not use/transmit table.

Length Attribute N 999 M 0n nn – Length of data to follow-(This only appears at
the beginning of field 63 not at the beginning of each
table.)
Table Length N 999 M 00 03 – Length of data in this table
Table ID AN 2 M X '35 31' - (Table 51 – Existing Debt indicator)
Indicator AN 1 M Value Description
0 Default value
9 Payment on existing debt


4.4.38.28. Bit 63 — (Table 54) Deferred Billing Indicator

(Applicable to Authorization only, Authorization and Capture, and Capture for Visa only)
0100 message
The transaction is/was submitted for payment of a deferred billing obligation. If the Indicator value is not
‘1’, do not use/transmit the table. For more information, refer to Appendix K (page 6-41).

Length Attribute N …999 M 0n nn–Length of data to follow-(This only appears at
the beginning of field 63 not at the beginning of each
table.)
Table Length N …999 M 00 03–Length of data in this table
Table ID AN 2 M X '35 34'-(Table 54 – Deferred Billing Indicator)

Indicator AN 1 M Value Description
0 Not a Deferred Billing transaction
1 Indicates that Deferred Billing was used
at the Point of Service


4.4.38.29. Bit 63 — (Table 55) Merchant Advice Code

(Applicable to Authorization only, and Authorization and Capture for MasterCard and
Visa recurring transactions only)
0100, 0110 messages
This table supports the use of Merchant Advice Codes (M/C), also known as Recurring Payment
Cancellation (Visa), for issuers to clearly communicate to merchants the reason for declining a
MasterCard and Visa recurring payment transaction and the actions merchants can take to continue to
serve their recurring payment customers. In order to receive this table on a declined transaction, the
merchants must indicate that they are able to accept the Merchant advice code at the Point of Service by
setting the Flag value as 1 in the request message. If the MasterCard or Visa returns an advice code in
their response, then this table will be present. However, even if the merchant has set the flag as 1 and the
relevant card association doesn’t return any advice code, this table will not be present. This is specific to
recurring transaction.
If the merchants send out a request, selecting the default value of 0 in the flag, they will
receive 00 as an advice code in the response message.

Length Attribute N 999 M 0n nn — Length of data to follow — (This only
Table Length N 999 M 00 05 — Length of data in this table
Table ID AN 2 M X '35 35' — (Table 55 — Merchant Advice Code
Indicator)
Flag AN 1 M 0100 Request Message:
Value Description
0 Not provided
1 Indicates that the merchant is able
to accept the Merchant Advice
Code at the Point of Service
Indicator AN 2 M 0110 Request Message:

Value Description Card Type
00 Not provided Visa and
MasterCard
01 New account MasterCard
information only
available
02 Try again later Visa and
MasterCard
03 Do not try again Visa and
MasterCard
21 Do not honor Visa and
MasterCard
The following tables based on card types (Visa and MasterCard) provide detail information on advice
codes, reasons for decline, and suggested action to be taken by merchant.


This table is specific to Visa:

Value Description
02 Cardholder only wishes to stop one specific payment in the recurring payment
relationship.
03 Cardholder has requested to stop all recurring payment transactions for a
specific merchant.
21 All recurring payments have been cancelled for the card number requested.

This table is specific to MasterCard:

Value Description Advice Code supported by Card
Type
01 Expired Card Obtain New Account Information
Account upgrade before next billing cycle.
Portfolio Sale
Conversion
02 Over Credit Limit. Insufficient Funds Recycle transaction 72 hours later.
03 Account Closed Fraudulent Obtain another type of payment from
customer.
21 Cardholder has been unsuccessful at Stop recurring payment requests.
canceling recurring payment through
merchant.


4.4.38.30. Bit 63 — (Table 56) Reg E Data

0200 Debit Card Authorization Message
The information in this table is printed on the cardholder’s Bank statement and shows the location of the
store where the debit card transaction was performed. If the merchant elects not to send in this
information during the authorization of an ‘on-line’ debit card request; First Data will populate these fields
from data stored in the merchant database, based on the Merchant ID received with the authorization
request.

Length Attribute N …999 M 0n nn — Length of data to follow —
(Appears at the beginning of field 63, not at
the beginning of each table.)
Table Length N …999 M 00 86 — Length of data in this field
Table ID AN 2 M X'35 36' — Table 56 — Debit Reg E Data
Merchant Name AN 30 M Name of Merchant — This field is left
justified, with trailing spaces.
Merchant Street AN 23 M Street address of Merchant — This field is
Address left justified, with trailing spaces.
Merchant City AN 13 M City of Merchant — This field is left
justified, with trailing spaces.
Merchant State Code N 2 M Numeric State Code of Merchant (i.e., ‘47’
for Tennessee)
Merchant State Code A 2 M Alpha Code for State of Merchant (i.e., ‘TN’
for Tennessee)
Merchant Country AN 3 M Numeric Country Code of Merchant (i.e.,
‘840’ for US). For more information, refer to
Appendix C on page 6-12.
Merchant Country AN 2 M Alpha Code for Country of Merchant (i.e.,
‘US’). For more information, refer to
Appendix C on page 6-12.
Merchant ZIP/Postal AN 9 M Merchant ZIP/Postal Code — This field is
Code left justified, with trailing spaces.


4.4.38.31. Bit 63 — (Table 57) Old VPAS

(Visa Payer Authentication Service (VPAS) – DEFUNCT)
(Applicable to Authorization only and Capture only)
0100 message
Visa has instituted a new cardholder authentication process to combat fraudulent transactions originating
from Electronic commerce transactions. This authentication process applies to Visa magnetic swipe cards
and Visa issued chip cards. Optional fields were introduced into the Visa documentation during the June
1998 release called CAVV (Cardholder Authentication Verification Value)/VPAS 1 and XID (Transaction
ID)/VPAS 2. These fields are hash values resulting from the verification of a digital certificate and are 20
bytes binary, fixed length. They are now required as part of the Verified by Visa (VBV) program. * This
table should be used for 3-D Secure Protocol Version 1.0.0.
The following table will remain in effect for all existing merchants/VARs. New merchants/VARs are
required to use Table 65 (see page 4-87). Existing merchants/VARs are advised to switch to that table
also, since use of Version 1.0.0 will eventually result in a downgrade of their transactions. Please first
check with First Data for availability, however.

Length Attribute N ...999 M 0n nn — Length of data to follow — (This
only appears at the beginning of field 63 not
at the beginning of each table.)
Table ID AN 2 M X '35 37' — (Table 57 — Visa VPAS
Indicator)
CAVV/VPAS 1 HB 40 M This is the VPAS 1 field from the merchant to
be passed to Visa (20 bytes of binary data
converted to 40 bytes of hex data by the
merchant). (Refer to the Hex Binary [HB]
section for additional details [Page 4-4].
XID/VPAS 2 HB 40 M This is the VPAS 2 field from the merchant to
be passed to Visa (20 bytes of binary data
section for additional details [Page 4-4])


4.4.38.32. Bit 63 — (Table 58) Additional Transaction Information

0100 message
This table specifies the data required for processing MasterCard foreign currency going to “Europay.”
Length Attribute N ...999 M 0n nn — Length of data to follow — (This only
Table Length N ...999 M ’00 09’ — Length of data in this table
Table ID AN 2 M '35 38' — (Table 58 — Foreign Currency
MasterCard Additional Information)
POS Terminal AN 1 M Indicates whether the POS terminal accepting the
Attendance card was attended or unattended:
Indicator Value Description
0 Attended terminal — position 1-2 of
POS Entry NOT equal 01 or 02
1 Unattended terminal (cardholder
activated terminal)
2 No terminal used
POS Terminal AN 1 M Indicates the location of the POS Terminal
Location Indicator Value Description
0 On premises card acceptor facility
1 Off premises card acceptor facility
2 On premises of cardholder
3 No terminal used
POS Cardholder AN 1 M Indicates whether the cardholder was present at
Presence Indicator the POS terminal, or explains the condition if the
cardholder was not present
Value Description
0 Cardholder present
1 Cardholder not present, unspecified
2 Cardholder not present, mail/facsimile
order
3 Cardholder not present, telephone/ARU
order
4 Cardholder not present standing
order/recurring transactions
5 Electronic order
POS Card AN 1 M Indicates if the card was present at the POS
Presence Indicator terminal
Value Description
0 Card present
1 Card not present
POS Card Capture AN 1 M Indicates whether the POS terminal has card
Capabilities capture capability
0 Terminal/operator has no card capture
capabilities
1 Terminal/operator has card capture
capabilities


CAT Level Indicator AN 1 M Indicates whether the terminal was activated by
the cardholder using his or her card; and for such
terminals, indicates the security level of the
terminal
Value Description
0 Not a CAT transaction
1 Authorized level 1 CAT: Automated
dispensing machine with PIN
2 Authorized level 2 CAT: Self-service
terminal
3 Authorized 3 CAT: Limited amount
terminal
4 Authorized level 4 CAT: In-flight
commerce
5 Reserved
6 Authorized Level 6 CAT: Electronic
Commerce
7 Authorized Level 7 CAT: Transponder
transaction
POS Card Data AN 1 M Indicates the POS terminal capabilities for
Terminal Input obtaining the data stored on the card
Capability Indicator Value Description
0 Unknown or unspecified
1 No terminal used
2 Magnetic stripe reader
3 Bar code (for future use)
4 Optical character recognition (for future
use)
5 Magnetic stripe reader and EMV-
compatible ICC reader
6 Key entry only
7 Magnetic stripe reader, key entry, and
EMV-compatible ICC
8 EMV-compatible ICC reader


4.4.38.33. Bit 63 — (Table 59) UCAF

(Universal Cardholder Authentication Field – UCAF)
Applicable to Authorization only, and Authorization and Capture)
0100 message
MasterCard provides members with the Universal Cardholder Authentication Field (UCAF) for
standardizing the transport of cardholder authentication data for Electronic commerce transactions,
including mobile commerce, within authorization messages.
The UCAF is a universal, multi-purpose date transport infrastructure that MasterCard uses to
communicate authentication information between the cardholder, merchant, issuer, and acquirer
communities. The UCAF is a 32-byte binary field with a flexible data structure that MasterCard can tailor
to support the needs of various issuer security and authentication approaches, including the Secure
Payment Application (SPA) and other future security solutions.
Refer to the explanation on the following page for further details involving this process.

Table ID AN 2 M X '35 39' — (Table 59 — UCAF Table Indicator)
UCAF Collection AN 1 M Value Description
Indicator 0 UCAF data collection is not supported at
the merchant’s Web site
1 The merchant supports UCAF data
collection, but the field was not
populated.
2 The merchant supports UCAF data
collection, and the data field was
populated.
UCAF Data HB 64 C Unique tracking number sent by the client: The
client converts the binary data provided by
MasterCard (variable length up to 32 bytes) to 64
bytes of hex data (right padded with zeroes as
required to equal 64 bytes) in either ASCII or
EBCDIC format (corresponding to the client's
character set for all alphanumeric fields). Refer to
conversion examples on following page and to Hex
Binary (HB) section for additional details, refer to
page 4-4
This field must be present if the UCAF
Collection Indicator (above) is equal to a

value of 2; for any other value, it must not
be present.
In Table 60 (Electronic Commerce Indicator [Page 4-84]), the Electronic Commerce Indicator
field value must be set to ’07, 06 or 05’ for the corresponding UCAF Collection Indicator

values 0, 1 and 2 (above).


UCAF Information for Capture only Transactions

(Applicable to Capture only)
0100 message
beginning of each table)
Table ID AN 2 M X '35 39' — (Table 59 — UCAF Table Indicator)
UCAF Collection AN 1 M Corresponds to the value of the UCAF collection
Indicator Indicator in the auth request 0100 message
The Universal Cardholder Authentication Field (UCAF) Conversion Process

Binary to Hex Conversion
MasterCard provides binary data (variable-length up to 32 bytes) to the merchant/VAR. [Refer to an
example of such binary data (in a textual format) immediately following the Base64 Data heading, below].
The merchant/VAR must then convert the binary data to hexadecimal (hex). The hex data must equal 64
bytes; however, since the binary data supplied by MasterCard is variable-length, the converted data may
need to be padded to equal 64 bytes. (Refer to an example immediately following the Hex Conversion
heading, below, in which the padded zeroes are highlighted in red).
Base64 Data – assuming ASCII format
hpqlETCoVYR1CAAAiX8HBjAAAAA=
Hex Conversion
6870716C4554436F565952314341414169583848426A41414141413D00000000
For example, in the conversion from binary to hex above, the binary ‘h’ is represented by ‘68’ in hex. The
binary ‘p’ is represented by hex ‘70’; the ‘q’ is represented by ‘71’, and so on.


4.4.38.34. Bit 63 — (Table 60) MOTO/Bill Payment / Electronic Commerce

Additional POS Info.
Only)
0100, 0400 messages - U.S. Merchants and Acquirers Only
The Electronic Commerce Type Indicator field value must be set to ‘05’ for VPAS for full authentication or
‘06’ for merchant-attempted cardholder authentication using 3-D secure.
Visa also requires that a MOTO/Bill Payment/E-Commerce Type indicator be included in all bill payment
transactions including retail bill payments. For E-Commerce based bill payments, valid MOTO/Bill
Payment/E-Commerce type values are 05, 06, 07, or 08.
Attribute beginning of field 63 not at the beginning of each table.)
Table N …999 M 00 04-Length of data in this table
Length
Table ID AN 2 M X'36 30' – (Table 60-Additional POS information)
MOTO/Bill AN 2 M MOTO/Bill payment indicator
Payment/
Electronic Value Description Card Types
Commerce
Type 1 Single Payment Transaction (non E- Visa
Indicator commerce) for Retail and face-to-face
Bill Payment transaction
2 Recurring Transaction (non E- Visa and
commerce) Discover
3 Installment Payment (non E- Visa and
commerce) Discover
Visa Electronic Commerce indicator

5 The cardholder was authenticated using a Visa-
approved authentication methodology. The
authorization message was successfully authenticated
using Verified by Visa. Or
6 The merchant is capable of and attempted to
authenticate the cardholder using Verified by Visa, but
the cardholder did not participate.
7 The cardholder’s payment card was protected with a
form of internet security, such as SSL, but
authentication was not performed.
8 A non-secure transaction in which the cardholder’s
payment card data was transmitted with no security
method.
MasterCard Electronic Commerce indicator

5, 6, Channel encryption; cardholder certificate not used
or 7
8 No security protocol; cardholder certificate not used


4.4.38.35. Bit 63 — (Table 62) Electronic Benefits Transfer (EBT) Data

0200 message (Request)
Length Attribute N ...999 M 0n nn — Length of data to follow —
(Appears at beginning of field 63 not
Table Length N ...24 M 00 24 — Length of data in this field
Table ID AN 2 M X'36 32' — (Table 62 — EBT
information)
Merchant FNS Number AN 7 O If not supplied, space-fill so number can
be obtained from First Data Terminal
Control file (FNS: Food and Nutrition
Service).
Voucher Number AN 15 C Conditional — Mandatory for Voucher
Clear Transactions; Space-fill if not
used.


Electronic Benefits Transfer (EBT) Data Response

0210 message
Length Attribute N 999 M 0n nn — Length of data to follow — (This only
Table Length N 999 M 0014 — Minimum length
0069 — Maximum length

Table ID AN 2 M X'36 32' — (Table 62 — EBT information)
Num of Acct Balances N 1 M This number indicates the number of account
balances that are being returned (from one [1]
to six [6]). Each “set” of 11 bytes comprises a
single account balance record.
Account Type N 1 M Value Description

96 Cash Benefit
98 Food Stamp
Amount Type N 1 M Value Description
01 Ending Balance
02 Available Balance
18 Beginning Balance
40 Amount Cash
57 Pre-authorized Amount
Currency Type N 2 M Currently 0840 (U.S. Dollars)
+/- Amount A 1 M Value Description
C or 0 Positive Amount
D Negative Amount
Balance Amount N 6 M Twelve digits with 2 decimal places implied
Account Type N 1 O Same as Account Type field (above), but for
Account 2
Amount Type N 1 O Same as Amount Type field (above), but for
Account 2
Currency Type N 2 O Same as Currency Type field (above), but for
Account 2
+- Amount A 1 O Same as +- Amount field (above), but for
Account 2
Balance Amount N 6 O Same as Amount Type field (above), but for
Account 2
- Account Type Balance Amount (above), but
Account 3

Account 4
Account 5
- Account Type Balance Amount, but
Account 6


4.4.38.36. Bit 63 — (Table 65) Visa Payer Authentication Service (VPAS)

0100 message
Visa has instituted a new cardholder authentication process to combat fraudulent transactions originating
from Electronic Commerce transactions. This authentication process applies to Visa magnetic swipe
cards and Visa issued chip cards. They are now required as part of Verified by Visa (VBV) program. This
table should be used for 3-D Secure Protocol Version 1.0.2.
In Table 60 [Electronic Commerce Indicator (Page 4-84)], the Electronic Commerce Indicator
field value must be set to ‘05’ for VPAS for full authentication or ‘06’ for merchant-attempted

cardholder authentication using 3-D secure.

Length Attribute N ...999 M 0n nn — Length of data to follow —
(Appears at the beginning of field 63, not at
the beginning of each table)
Table ID AN 2 M X '36 35' — (Table 65 — Visa VPAS
Indicator)
Version AN 1 M Value Description
1 Protocol 1.0.2
CAVV HB 40 M The CAVV is a cryptographic value that is
generated during the 3-D Secure
authentication process by the issuer’s
Access Control Server (ACS) to verify the
cardholder (20 bytes of binary data
section for additional details [Refer to page
4-4])


Visa Payer Authentication Service (VPAS) Response

0110 message
This table should be used for 3-D Secure Protocol Version 1.0.2.

Length Attribute N …999 M 0n nn — Length of data to follow — (This appears at
table.)
Table ID AN 2 M X '36 35' — (Table 65 — Visa VPAS Indicator)
VPAS AN 1 M Value Description
Response 0 CAVV failed validation — authentication
Value 1 CAVV failed validation — authentication
2 CAVV passed validation — authentication
3 CAVV passed validation — attempt (A 3-D
Secure authentication value of 7 from the
issuer’s ACS indicates authentication was
attempted.)
4 CAVV failed validation — attempt (A 3-D
Secure authentication value of 7 from the
issuer’s ACS indicates that authentication
was attempted.)
5 Reserved for future use — not used
6 CAVV not validated, issuer not participating
in CAVV Validation

Secure authentication value of 7 from Visa’s
ACS indicates that an authentication
attempt was performed.)
8 CAVV passed validation — attempt (A 3-D
Secure authentication value of 7 from Visa’s
attempt was performed. [Determined that
Visa generated this value from the use of
Visa CAVV key(s).]
Secure authentication value of 8 from Visa
attempt was performed when the issuer’s
ACS was not available. [Determined that
Visa CAVV key(s).]
VPAS AN 1 M Value Description



Response A CAVV passed validation — attempt (A 3-D
Value Secure authentication value of 8 from Visa’s
(Continued) ACS indicates that an authentication
attempt was performed when the issuer’s
ACS was not available. [Determined that
Visa’s CAVV key(s).]
B CAVV passed validation —information only,

no liability shift. (When the ECI equals 7
and CAVV is present, the CAVV will be
validated but no liability shift will occur. Visa
will generate this value for card or
transaction types that are not eligible for the
3-D Secure service.)
C CAVV was not validated — attempt (Issuer
did not return a CAVV results code in the
authorization response.)
D CAVV was not validated — authentication
(Issuer did not return a CAVV results code
in the authorization response.)


VPAS Response for Capture only Transactions

0100 message
Length Attribute N …999 M 0n nn — Length of data to follow — (Appears at the
table)
Table ID AN 2 M X '36 35' — (Table 65 — Visa VPAS Indicator)
VPAS Response AN 1 M Value that corresponds to the VPAS response value
Value on the 0110 message
4.4.38.37. Bit 63 — (Table 68) Additional Account/Amount Information

0100/0110 messages
There are two versions of Table 68 Additional Account/Amount Information Data (Request). They are as
follows:
Version 1 — Prepaid Product Balance Information Support Only

Version 2 — Additional Account / Amount Information Support
The description of the two versions is given on the next page.

Version 1 Usage — Prepaid Product Balance Information Support Only
First Data uses this table as an indicator that the requestor is capable of receiving account balance
information.
The following table is for Balance Inquiry only. It should not be used for balance with
authorization.

Length Attribute N …999 M 0n nn — Length of data to follow (Appears at the
table)
Table Length N …999 M 00 03 — Length of data in this field
Table ID AN 2 M X'36 38' — (Table 68 — Additional
Account/Amount Information Data)
Version AN 1 M X’31’ — Version 1


Version 2 Usage — Additional Account/Amount Information Support

First Data uses this table to determine the requestor’s various capabilities with regard to sending and/or
receiving account information records. These account information records are currently used in support of
various prepaid product processing.
The requestor should use Version 2 of this table in request messages to indicate any or all of the
following:
The ability to accept balance information in response messages.

The ability to accept partial authorization approval responses (mandatory for petroleum).
Request for auto-substantiation (i.e., verification of a qualified amount) against a Flexible
Spending Account (FSA) or Healthcare Reimbursement Arrangement (HRA).
**
Request for cash-back amount on a credit card purchase (Discover-only, scheduled Oct. 06)
**
This is new functionality; please check with your Client Certification & Implementation representative for
availability, and certification procedures.
For Partial Authorizations a “10” response code will be returned in the 0110 message
(Bitmap Position 39).

If the transaction is only partially approved, the amount approved will be returned in Field 4
of the 0110 message.
Length N …999 M 0n nn — Length of data to follow (Appears at the
Attribute beginning of field 63, not at the beginning of each table).
Table Length N …999 M 00 nn — Length of data in this table. Valid lengths are:
00 05 — Table length for Non Auto-Substantiation type

transactions
00 34 — Table length for Auto-Substantiated type

transactions, with 1 account information record. Add 20
bytes for each additional account information record as
applicable.
Table ID AN 2 M X'36 38'-(Table 68 – Additional Account / Amount Info)
Version AN 1 M X’32’ — Version 2
Balance AN 1 M POS device’s capability to handle balance information in
Information response messages. Valid values are:
Capability
0 — Balance information not supported in responses
1 — Balance information is supported in responses
Partial AN 1 M POS device’s capability to accept response messages in
Authorization which only a portion of the requested amount was
Approval approved. Valid values are:
Capability 0 — Partial authorization approvals are not supported
1 — Partial authorization approvals are supported.
Table 68 should end here when included in transaction requests that are NOT Auto-Substantiations or
Cash Disbursements. The Following Fields Are Mandatory in Table 68 for Auto-Substantiation and
Cash Disbursements Type Requests. These fields must only be present in the transaction request
messages, if the card type is FSA/HRA only.



Filler AN 8 C Space fill if including Account Information Record Data
for Auto-Substantiated Healthcare or Transit amount.
Number of AN 1 C This value indicates the number of account information
Account records being provided. A single account information
Information record is comprised of 20 bytes, as broken down below
Records and on the following page. Currently, the inclusion of
account information records is only supported on
Healthcare Auto-Substantiation, Transit Auto-
Substantiation, and Cash Disbursement Requests.
Applications can send in a minimum of one (1) and a
maximum of six (6) information records.
Account Information Record Fields:

Account Type AN 2 C Value Account Type
00 Not specified
30 Credit Card Account — used for cash
disbursement.
Amount Type AN 2 C Value Amount Type Description
4S Healthcare Qualified medical
(Visa/MC only) expenses (i.e. over-the-
counter qualified medical
items)
4T Transit (Visa only) Transit fare media such
as commuter and parking
passes, and mass transit
vouchers and tickets.
4O Cash Amount of cash back
Disbursement being requested
(Discover Only)
4U RX (Visa/MC Sub-Total of Prescription
only) RX
4V Vision (Visa only) Sub-Total of
Vision/Optical
4W Clinical (Visa Sub-Total of Clinical
only)
4X Dental (Visa only Sub-Total of Dental
Currency Code AN 3 C The 3-digit code defines the currency used in the amount
field.
Sign Amount AN 1 C Value Description
C Positive Amount
D Negative Amount
Amount AN 12 C 12 digits, with implied decimal relative to the currency code.
In Auto-Substantiation transactions, this value reflects the
qualified amount of the total purchase. For Discover credit
card cash disbursement transactions, this value reflects the
cash portion of the total purchase amount.
For Discover, cash over amount cannot be greater than $100.00 and the cash over amount
must be less than the card transaction amount.



Additional Account / Amount Information Data (Response)

0110 message
Table 68 will only be returned to the requestor in the response message if Table 68 was included in the
request message.
Requesters submit Table 68 to indicate the POS device is capable of accepting:
Balance information (for Visa, and MasterCard Pre-paid cards)If the POS device is identified as
capable of receiving balance information and account balance information is available from the
issuer, Table 68 will be included in the response message to the POS device.
Partial authorization approvals (for Visa, MasterCard, Amex, and Discover Pre-paid cards)If the
POS device is identified as capable of accepting partially approved authorizations and the issuer
approves only a portion of the requested amount, Table 68 will be included in the response
message.
**
Cash disbursement totals on Discover credit card (for Discover credit only) If the POS device
**
sent an amount of cash disbursement in the request, Table 68 will return the cash disbursement
amount that was approved.

Length N 999 M 0n nn — Length of data to follow (Appears at the beginning
Attribute of field 63, not at the beginning of each table)
Table Length N 999 M 00 24 — Minimum length; 01 24-Maximum length
Table ID AN 2 M X'36 38' — (Table 68 — Additional Account/Amount
Information Data)
Version N 1 M X’31’ — Version 1 or X’32’ Version 2
Number of N 1 M This value indicates the number of account information
Account records being provided. A single account information record
Information is comprised of 20 bytes as broken down below. Although
Records only 1 information record is currently being included in
response messages, applications MUST be prepared to
accept a minimum of one [1] and maximum of six [6]
information records.
Account N 2 M Value Description Value Description
Type 00 Not specified 30 Credit Card
Account
10 Savings account 40 Universal
Account
20 Checking 64 Spending Power
account
28 Load (Prepaid) 72 Activate
(Prepaid)
Amount Type N 2 M Value Account Type Description
00 Load or Activate Prepaid card
balance
01 Deposit Accounts Current ledger
balance
Credit Card Accounts Open-to-buy


02 Deposit Accounts Current available
balance
Credit Card Accounts Customer’s credit
limit
Spending Power Accts Current
remaining
preauthorization
amount
40 Cash Disbursement Amount of cash
disbursement
57 Not Specified Total transaction
amount of the
original request
Currency N 3 M The 3-digit code defines the currency used in the amount
Code field.
Sign Amount A 1 M Value Description
C Positive Amount
D Negative Amount
Amount N 12 M 12 digits, with implied decimal relative to the currency code
Account N 2 O Same as Account Type field (above), but for Account 2
Type
Amount Type N 2 O Same as Amount Type field (above), but for Account 2
Currency N 3 O Same as Currency Type field (above), but for Account 2
Code
Sign Amount A 1 O Same as Amount field (above), but for Account 2
Amount N 12 O Same as Amount field (above), but for Account 2
- Account Type Amount (above), but Account 3


4.4.38.38. Bit 63 — (Table 69) AUAR/TPP ID

AUAR/TPP ID - Agent Identification Service
0100 message (only for VAR/VAD/Gateways)
Visa’s Trusted Agent Program (TAP) – In conjunction with Visa’s regulatory change(s), First Data will
require the Agent Identification Service from all the Third Party Servicers (TPS) or Merchant Servicers
(MS). The AUAR Data composed of the Visa Business Identifier (BID) and Agent Unique Account Result
(AUAR), is required for all Visa transactions that are processed through a Third-Party Servicer (TPS) or
Merchant Servicer (MS) agent. The TPS or MS Agent is required to register with Visa to obtain the BID
and the algorithm to calculate the AUAR. The AUAR is unique to every account number. FDMS can
support a maximum of 3 occurrences of AUAR Data if multiple servicers are used during the transaction
process. Currently Visa will be supporting the acceptance of 1 registered servicer with a future
enhancement to accept up to 3 servicers. If multiple servicers are used, the first entry should always be
the servicer that sends the transaction to First Data. Each subsequent servicer should be identified where
they are in the chain.
First Data requires the Third Party Processor (TPP) identifier, which is a unique 6 byte identifier, assigned
by FDMS to all certified Third Party Processors and software vendors. To identify merchant processing
using a Third Party Processor or software vendor application the TPP ID is required for all credit card and
travel and entertainment card type (Visa, MasterCard, Diners, American Express, Discover and JCB).
FDMS can support a maximum of 3 occurrences of First Data TPP ID if multiple Third Party Processors or
software vendor applications are used during the transaction process. If multiple Third Party Processor or
software vendor applications are used the first entry should always be the TPP ID/software Vendor that
sends the transaction to First Data. Each subsequent TPP ID/software vendor should be identified where
they are in the chain.

Length Attribute N …999 M 0n nn — Length of data to follow (Appears at the
beginning of field 63, not at the beginning of each table)
Table Length N …999 M 00 23 — Length of data in this field (if 1 AUAR is
present)
Table ID AN 2 M X'36 39' — (Table 69 — Additional Account/Amount
Information Data)
Version AN 2 M X’30 31’ — Version 01
Number of Entries AN 1 M Number of Servicers contained in the table.
Valid values are 1, 2 or 3.
Visa ID Hex 1-byte M Constant value of Hex “0B” for all card types
(First Occurrence) (2 hex
digits)
Visa BID AN 5 M Visa Business Identifier (BID)
(First Occurrence) However, If a BID has not been provided to the TPS by
Visa or the card type is not a Visa; spaces should be
submitted in this field.
Visa AUAR Hex 6 M Visa’s Agent Unique Account Result (AUAR).
(First Occurrence) bytes Note: 6byte (12 digit hex) Visa AUAR
(12 ID. Example: 12 34 56 78 90 12
hex However, if the AUAR is not present, 6 bytes
digits) (12digits) of Hex 0 should be submitted.
Example: 00 00 00 00 00 00
This applies to all the card types.



TPP ID AN 6 M Provided by First Data to all TPP and vendors.
(First Occurrence)
(Second (2 hex
Occurrence, if digits)
applicable)

(Second However, If a BID has not been provided to the TPS by
Occurrence, if Visa or the card type is not a Visa; spaces should be
applicable) submitted in this field.

(Second bytes Note: 6byte (12 digit hex) Visa AUAR
Occurrence, if (12 ID. Example: 12 34 56 78 90 12
applicable) hex However, if the AUAR is not present, 6 bytes
Example: 00 00 00 00 00 00
(Second
Occurrence, if
applicable)
(Third Occurrence, (2 hex
if applicable) digits)
(Third Occurrence, However, If a BID has not been provided to the TPS by
if applicable) Visa or the card type is not a Visa; spaces should be
submitted in this field.
(Third Occurrence, bytes Note: 6byte (12 digit hex) Visa AUAR
if applicable) (12 ID. Example: 12 34 56 78 90 12
hex However, if the AUAR is not present, 6 bytes
Example: 00 00 00 00 00 00
(Third Occurrence,
if applicable)
*
Required for Visa transactions. Space filled for other card types.


4.4.38.39. Bit 63 — (Table 70) Dual Event Settlement Table

0100 message
Developers should check with Client Certification and Implementation (CC&I Group)
representative/Certification Analyst for availability, and certification procedures.
This table should be supplied only if the following conditions exist:
The merchant is set-up for Host Capture Settlement.

Bit 4 — Transaction Amount contains the amount to be settled.
Bit 31 — Acquirer Reference Data must be set to “2” capture only.
If amount to be settled is less than the original amount.

Length N 999 M 0n nn — Length of data to follow (Appears at the
Attribute beginning of field 63, not at the beginning of each
table)
Table Length N 999 M 00 16 — Length of data in this field
Table ID AN 2 M X'37 30' — (Table 70 — Dual-Event Settlement
Table)
Version AN 2 M X’30 31’ — Version 01
Original Auth N 12 M This is the sum of the original authorization amount
Amount and any incremental requests.
The decimal placement for the amount is based on

the transaction currency code (bit 49).


4.4.38.40. Loyalty Processing

First Data is implementing a new universal loyalty solution for its merchants. The Electronic and Rewards
Network (EARN) offers merchants a system that enables consumers to accumulate rewards in real-time,
based on point-of-sale transactions.

Figure 2 on the next page describes the flow of Loyalty processing.
1 2
3
POS
Loyalty Host
4
6
FDMS6000 5
1- POS Request
Associations
2- Loyalty Request
3- Loyalty Response
4- Association Request
5- Association Response
6- POS Response
Figure 2
Loyalty requests will include credit/debit authorizations, financial transactions, and card file transactions.
Credit/debit authorization requests will be processed through Loyalty and then sent, with a possible
transactions amount adjustment, to the appropriate association for authorization. The financial
transactions are Loyalty cash transactions that require Loyalty processing only. Both the credit/debit and
financial transactions will support reversal processing. The card file transactions are Loyalty card member
management messages and will only be sent to the Loyalty host.


Bit 63-Private Data Field-(Table L1) Loyalty Card Action Request

**
0100, 0200, 0400 messages
There are three versions of this table. Version 1 includes Message Types 9324, 9400, and 9604. Version
2 (next page) excludes Message Type 9604 because it is incompatible with the External Account
Reference field. Version 3 (next page) includes the LAN Track Data field and Tender Type field. However,
it excludes Message Type 9604 because it is incompatible with the External Account Reference field.
Version 1
Length Attribute N …999 M 0n nn — Length of data in Field 63 (appears at the
beginning of field 63 not at the beginning of each
table).
Table length N ..39 M 00 nn length of data in this table.
Table ID AN 2 M X'4C 31' — Table L1 — Loyalty Card Action Request
Table Version AN 1 M “1” – Version 1
Message Type NN 4 M Loyalty Transaction Request Message Type
Value Description
9324 Card Action Request
9400 Card Reversal Request
9604 Totals Review Request
Response Limit NN 1 M Loyalty Response Message Limit Indicator
Value Description
0 No response message size limit
1 Limit response message to 800 bytes
LAN NN .19 O Loyalty Account Number
Present for credit/debit transactions that include a

separate Loyalty card. Set length to zero if data not
present. (Zero length for 9604.)
Transaction NN 2 O Code describing the reason for the request. Default to
Request Code 01 for 9604 and 09 for 9400 messages.
Value Description
01 Sale/Terminal Report Request for 9604
05 Points redemption
09 Merchant Initiated Reversal (9400 only)
Loyalty Points NN .8 O The number of points to be redeemed from the
Amount account. Will be present if Loyalty Transaction
Request Code is 05.
LID NN .19 C Loyalty Transaction ID should be sent only on 9400
messages and should be the ID from the original
9334 message. On 9324 and 9604 messages the
length will be zero.



**
0100, 0200, 0400 messages
Version 2
This table may include the LAN field and/or the External Account Reference field. Refer to those fields
below for details.

table).
Table ID AN 2 M X'4C 31' — Table L1 — Loyalty Card Action
Request

Message Type NN 4 Loyalty Transaction Request Message Type
Value Description
Value Description
LAN NN 19 O Loyalty Account Number

separate Loyalty card. Set length to zero if data not
present.
External Account NN 15 O First 5 digits of street address number, plus 10 digit
Reference telephone number (area code plus number). Street
address is right-justified and zero filled if less than 5
digits. Zero length for 9604.
Transaction NN 2 O Code describing the reason for the request. Default
Request Code to 09 for 9400 messages
Value Description
01 Sale
09 Merchant Initiated Reversal (9400
only)
Loyalty Points NN 8 O The number of points to be redeemed from the

Amount account. Will be present if Loyalty Transaction
Request Code is 05.
LID NN 19 C Loyalty Transaction ID should be sent only on 9400



messages and should be the ID from the original
9334 message. On 9324 message the length will
be zero.



**
0100, 0200, 0400 messages
Version 3
Two new fields have been added to Version 3 of the L1 Table. These new fields include the LAN Track
Data field and Tender Type field. Refer to the table below for details.

table).
Table ID AN 2 M X'4C 31' — Table L1 — Loyalty Card Action Request
Value Description
Value Description
separate Loyalty card. Set length to zero if data is not
present.
LAN Track Data Z ..37 O LAN Magnetic Stripe Track Data
Present in transactions that include a separate swiped
Loyalty card. Set length to zero if data is not present.
External Account NN .15 O First 5 digits of street address number, plus 10 digit
digits. Zero length for 9604.
Transaction NN 2 O Code describing the reason for the request. Default to
Request Code 09 for 9400 messages
Value Description
01 Sale
09 Merchant Initiated Reversal (9400 only)
Loyalty Points NN 8 O The number of points to be redeemed from the
Amount account. Will be present if Loyalty Transaction Request
Code is 05.
LID NN 19 C Loyalty Transaction ID should be sent only on 9400
messages and should be the ID from the original 9334
message. On 9324 message the length will be zero.
Tender Type AN 3 O Tender Type denoting the method of payment at the
Point-of-Sale. This field is optionally included in the


9324 request.
Set length to zero if data is not present. This field
should be left justified and space filled.
Possible values are as follows:
MC MasterCard
VS Visa
AX American Express
DN Diners
DS Discover
DB Debit
PR Proprietary
FL Fleet
CK Check
CS Cash
GC Gift Card
PC Phone Card
EB EBT Food
EC EBT Cash


Field 63 (Table L2) Loyalty Card File Update Request

**
0100 message
Version 1
There are two versions. Version 1 includes Message Types 9304. Besides that, Version 2 includes a new
field that has the LAN Track Data.

Length Attribute N 999 M 0n nn — Length of data in Field 63 (appears at the
beginning of field 63 not at the beginning of each table).
Table length N 46 M 00 nn length of data in this table.
Table ID AN 2 M X'4C 32' — Table L2 — Loyalty Card File Update
Request
Value Description
9304 Card File Update Request
Value Description
Set length to zero if data not present.

External Account NN 15 M First 5 digits of street address number, plus 10 digit
digits.
Account NN 3 M Indicates what action is to be taken on the account
Management
Code Value Description
001 Add
002 Update
003 Delete
004 Inquiry


Field 63 (Table L2) Loyalty Card File Update Request

**
0100 message
Version 2
A new field has been added to Version 2 of the L2 Table. This new field includes the LAN Track Data.
Refer to the table below for details.

Length Attribute N ...999 M 0n nn — Length of data in Field 63 (appears at the
table).
Request
Value Description
9304 Card File Update Request
Value Description
LAN NN 19 O Loyalty Account Number
Set length to zero if data is not present.
LAN Track Data Z ..37 O LAN Magnetic Stripe Track Data
Present in transactions that include a separate swiped
Loyalty card. Set length to zero if data is not present
External Account NN 15 M First 5 digits of street address number, plus 10 digit
digits.
Account NN 3 M Indicates what action is to be taken on the account
Management Value Description
Code 001 Add
002 Update
003 Delete
004 Inquiry


Field 63 (Table L3) Loyalty Card Action Response

**
0110, 0210, 0410 message

Length N …999 M 0n nn — Length of data in Field 63 (appears at the
Attribute beginning of field 63 not at the beginning of each table).
Table length N ..56 M 00 nn length of data in this Table.
Table ID AN 2 M X'4C 33 — Table L3 — Loyalty Card Action Response
Table Version AN 1 M “1” — Version 1
Message Type NN 4 M Loyalty Transaction Response Message Type
Value Description
9334 Card Action Response
9410 Card Reversal Response
9614 Totals Review Response
Loyalty Result NN 1 M Loyalty Host status for the transaction
Value Description
4 Non Loyalty Account
1 Loyalty Host Unavailable
2 Loyalty Host Success Response
3 Loyalty Host Failed Response
Loyalty NN 3 C Response code from the Loyalty Host system. (Refer to
Response the Loyalty Processing Response Codes [Page 4-108]).
Code
LID NN 19 M Loyalty Transaction ID. This field uniquely identifies the
transactions to the Loyalty system.
Loyalty Amount NN 12 C Adjusted/revised authorization amount after any

discount(s) — zero for 9614 message.
Loyalty Points NN .8 C The number of points to be redeemed from the account.
Amount Will be present if Loyalty Transaction Request Code
was 05.
Loyalty Points NN .8 C Provides the balance in the designated points program
Remaining for the Loyalty member after the action taken by this
Balance transaction (zero length for 9614 message).


Field 63 (Table L4) Loyalty Card File Update Response

**
(Applicable to Authorization only) 0110 message
Length N …999 M 0n nn — Length of data in Field 63 (appears at the
Attribute beginning of field 63 not at the beginning of each table).
Table length N 30 M 00 nn length of data in this Table
Response
Message Type NN 4 M Loyalty Transaction Response Message Type
9314 — Card File Update Response
Loyalty Result NN 1 M Loyalty Host status for the transaction
Value Description
4 Non Loyalty Account
1 Loyalty Host Unavailable
2 Loyalty Host Success Response
3 Loyalty Host Failed Response
Loyalty NN 3 C Response code from the Loyalty Host system. [Refer to
Response the Loyalty Processing Response Codes (Page 4-108)].
Code
LID NN 19 M Loyalty Transaction ID —This field uniquely identifies
the transactions to the Loyalty system.


Field 63 (Table L5) Loyalty Display Response

**
0110, 0210, 0410 messages

Length N ….9999 M nn nn — Length of data in Field 63 (appears at the
Attribute beginning of field 63 not at the beginning of each
table).
Table length N ….1111 M nn nn length of data in this Table
Table ID AN 2 M X'4C 34' — Table L5 — Loyalty Display Response
Offer Lines NN 3 M Number lines of text to be printed
Line Length NN 3 M Width of each line to be printed
Loyalty ANS ….1000 M This information can be printed on the receipt and can
Response be multiple lines. There are no printer control
Message characters in this message. The size of this message
can be limited by setting the appropriate limit value in
the L1 table.
Loyalty Processing Response Codes

**
Code Description
000 Success
010 Failed
100 Account not found
110 Account add failed
120 Duplicate card
130 Account already exists
140 Loyalty card is expired
150 Invalid Loyalty Request
160 Invalid Merchant
200 Loyalty processing failed
210 Insufficient points in account
300 Transaction not found
310 Transaction already reversed
320 Transaction found, but data doesn’t match
330 Reversal failed
900 System failure


4.4.38.41. Field Identifier Tables

The construction of Field Identifier tables has two parts, a fixed and a variable part. The first part is a fixed
portion providing the total table length and the table identifier. The second part is variable, where fields
are provided using the Field Identifier (FID), the data, and a field separator (FS). The fields provided are
dependent on the type of transactions being processed.
The Field Separator used for these tables is a hexadecimal ‘1C’.
Table Length [Table ID] [FID] [Data] [FS] [FID] [Data] [FS]
Fixed Portion Variable Portion

It is important to note this table is subject to change. Additional Field Identifiers may be added due to
regulation changes. If a Field Identifier is not recognized, it should be ignored. By coding in this manner it
will allow processing changes to be introduced and allow the merchant to comply at a later date without
major re-work.
Table ID Table Name Page

VI Visa Compliance Table 4-109
DS Discover Compliance Table 4-111
PD Promotional Data Table 4-113
PE Petroleum Table 4-114
P2 Purchase Card Level 2 Table 4-115
Field 63 (Table VI) Visa Compliance Field Identifier Table

(Applicable to Authorization only, Authorization and Capture, and Capture only)
The Card Level Response Code field is required to be included in the Settlement records for Visa sale
transactions that were electronically authorized. The Visa Compliance Table is sent in on the request
message as a trigger to receive the Visa Compliance table in the response message.
0100 message (Authorization only, and Authorization with Capture)

Length Attribute N …999 M 0n nn — Length of data to follow — (This only appears
at the beginning of field 63 not at the beginning of each
table.)
Table Length N …999 M 0n nn — Length of data in this table, included table ID
Table ID AN 2 M X ‘56 49’ — (Table VI — Visa Compliance Table)


The VI table below will be returned in the 0110 authorization response. For Capture only transactions the
VI table received in the 0110 authorization response must be submitted in the 0100 capture only request.
0110 (Authorization Response), 0100 (Capture Only Request)
Table VI – Visa Compliance – Fixed Portion
Length N …999 M 0n nn — Length of data to follow — (This only
Attribute appears at the beginning of field 63 not at the
Table Length N …999 M 0n nn — Length of data in this table, included table
ID
Table ID AN 2 M X ’56 49’ — (Table VI — Visa Compliance Table)
Table VI – Visa Compliance - Variable Portion

FID Field Name Attribute Req Value
CR Card Level Response Code AN 2 M Visa Card Level Response


Field 63 (Table DS) Discover Qualification Field Identifier Table

(Applicable to Authorization only, Authorization and Capture, and Capture only)
The following table has been developed to comply with Discover mandates concerning qualification for
Full Service processing. If this table is sent in the request (0100) message where the fixed portion of the
table is sent, the qualification fields will be returned in the response (0110) message.
0100 Message (Authorization only, and Authorization and Capture)
The Auth message will contain the fixed portion of the Table
Table DS — Discover Compliance — Fixed Portion
Length Attribute N …999 M 0n nn — Length of data to follow — (This only
Table Length N …999 M 0n nn — Length of data in this table, included
table ID
Table ID AN 2 M X ’44 53’ — (Table DS–Discover Qualification
Table)

The DS table below will be returned in the 0110 authorization response. For Capture only transactions the
DS table received in the 0110 authorization response must be submitted in the 0100 capture only
request.
0110 (Authorization Response), 0100 (Capture Only Request)
Table DS – Discover Compliance – Fixed Portion
Length N …999 M 0n nn — Length of data to follow—(This only
Attribute appears at the beginning of field 63 not at the
Table Length N …999 M 0n nn — Length of data in this table, included
table ID
Table ID AN 2 M X ‘44 53’ — (Table DS – Discover Qualification
Table)


Table DS — Discover Compliance — Variable Portion

01 Processing AN 6 O Identifies the type of Card Transaction sent
Code to Card Acceptor
02 System Trace N 6 O The System Trace Audit Number is assigned
Audit Number by a transaction originator to assist in
(STAN) identifying a Card Transaction. The trace
number remains unchanged for the life of the
Card Transaction.
03 POS Entry N 4 O The POS Entry Mode provided to Discover
Mode for the authorization
Bytes 1-2: Discover POS Entry Mode
Byte 3: Discover Pin Entry Capability
Byte 4: RFU (Always zero)
Note: Only the first 3 bytes are required for

settlement processing
04 Local Tran N 6 O Local time at which the Card Transaction
Time took place. Format HHMMSS.
05 Local Tran Date N 4 O Local month and day on which the Card
Transaction took place. Format MMDD
06 Discover AN 2 O Discover Response Code which indicates the
Response Code status of the transaction
07 Discover POS AN 13 O This field indicates the specific Card
data Information Capture Conditions present at
the time a Card Transaction took place at
POS.
08 Discover AN 2 O This field is used to indicate the magnetic
Transaction stripe condition and the vulnerability to fraud
Qualifier / Track in Discover Network Card Transactions.
Data Condition
Code
09 Discover AN 1 O If at the time of the authorization consumer
Address address verification was requested, this field
Verification will contain an address verification response
Result as defined by Discover. This field should be
used for qualification, since it may differ from
the standard address verification (a mapped
value).
10 Discover NRID AN 15 O NRID returned if available


Field 63 (Table PD) Promotional Data Field Identifier Table

0100, 0400 message
The following table has been developed in order for merchants to provide promotional data required for
NTIA coupons. Currently, this table is provided on the request message, either the 0100 or 0400
message type.
0100 Auth Message
Table PD — Promotional Data — Fixed Portion
Length Attribute N …999 M 0n nn — Length of data to follow— (This only appears
each table.)
Table Length N …999 M 0n nn — Length of data in this table, including Table
ID.
Table ID AN 2 M X ’50 44’ — (Table PD — Promotional Data Table)
Table PD — Promotional Data — Variable Portion
01 UPC/SKU AN 34 O This field is to be used to provide the SKU or
UPC number of the converter box for NTIA
Coupon Processing.
This field is variable length and can be up to
34 bytes in length.
Please refer to the overview at the beginning
of this specification for details about
processing the NTIA Coupons See page 6-45.


Field 63 (Table PE) Petroleum Field Identifier Table**

0100 message
The following table has been developed for host capture merchants processing petroleum transactions.
This table provides data required for settling the transaction properly and should be provided when the
Acquirer Reference Data is either set to a value of “1” Authorization/Capture or “2” Capture only.
0100 Auth Message

Table PE — Petroleum — Fixed Fields
Length Attribute N …999 M 0n nn – Length of data to follow-(This only appears at
table)
Table Length N …999 M 0n nn — Length of data in this table, including table ID
Table ID A 2 M X ‘50 45’ — (Table PE — Petroleum Field Identifier
N Table)
Table PE — Petroleum — Variable Portion
01 Product Description AN ..30 M Product Description


Field 63 (Table P2) Purchase Card Level 2 Field Identifier Table **

0100 message
**
The following table has been developed for host capture merchants processing Purchase Card
transactions. This table provides data required for settling the transaction properly and should be
provided when the Acquirer Reference Data is either set to a value of “1” Authorization/Capture or “2”
Capture only.
0100 Auth Message
Table P2 — Basic Purchase Card Level 2 — Fixed Fields
Length Attribute N …999 M 0n nn — Length of data to follow— (This only appears at
table)
Table Length N …999 M 0n nn — Length of data in this table, included table ID
Table ID AN 2 M X ‘50 32’ — (Table P2 — Purchase Card Level 2 Field
Identifier Table)
Variable Portion
Table P2 — Basic Purchase Card Level 2 — Variable Fields
Fid Field Name Attribute Req Value
01 Order Date N 6 O For Visa the date on which the order is received by the
merchant. Format is YYMMDD
02 Tax N 9 C For Visa the amount of state or provincial tax included in
Amount to the transaction amount. The tax amount must be within 0.1
12 % and 22% of the transaction amount. Two (2) decimal
places are implied and size can be 12 bytes.
For MasterCard the total amount of sales tax or VAT on
the total purchase must be between 0.1% and 30 % of the
total transaction amount; zeroes indicate that the card
acceptor is capable of transmitting the tax amount and the
tax amount is zero. Right justified and zero filled. Size can
be 9 bytes maximum.
For American Express the amount of tax calculated or
entered for the transaction. Two (2) decimal places are
implied and size can be 12 bytes.
**Refer to Conditional Requirement Matrix for further
detail.
03 Tax N 1 C Mandatory for Visa and MasterCard.
0 No tax information provided.
1 Local tax amount is provided.
2 Item is tax exempt or non taxable (The Local
Tax Amount [above] must be zero).
For MasterCard — an indicator used to reflect sales tax
capture and reporting:
Value Description


Y Sales tax included in total purchase amount
N Merchant has ability to provide tax amount, but
goods/services were not taxable
Space Sales tax not provided
04 Purchase AN 25 M For Visa the information in the field used by the merchant
Identifier to identify the purchase (e.g., SKU number).
For MasterCard the code that the cardholder supplied to
the merchant.
For American Express the customer reference number.
05 Order AN 12 O For Visa the Customer Code/Customer Reference
Number or to Identifier — Used by the customer to identify the purchase
Customer 17 (e.g., the invoice number).
Reference For MasterCard and American Express the code that
Identifier facilitates merchant/corporation communication and record
(CRI) keeping.
For MasterCard Electronic Payment Transactions this
value should represent the Invoice Number.
**Refer to Conditional Requirement Matrix for further
detail.
06 Discount N 12 O Optional for Visa only. Not applicable for MasterCard or
Amount American Express.
Total amount of discount applied to the transaction by the

merchant. Used by the merchant when a discount is given
on the entire transaction rather than on unit prices.
Typically shown as credit on a detailed invoice. Two (2)
decimal places are implied.
07 Freight N 12 O Optional for Visa and MasterCard. Not applicable for
Total for freight or shipping and handling charges. Two

decimal places are implied.
08 Duty N 12 O Optional for Visa and MasterCard. Not applicable for
Total charges for any import/export duties included in the

transaction. Two (2) decimal places are implied.
09 Destination AN 10 C Optional for Visa and MasterCard. Mandatory for American
Postal Express.
Code
The postal or Zip code of the “ship to” location. This is
equal to the Ship from Postal/Zip Code when the customer
takes possession of the items at the merchant location.
10 Ship from AN 10 O Optional for Visa and MasterCard. Not applicable for
Postal/Zip American Express.
Code
The postal or Zip code of the location from which goods
were shipped.
11 Destination AN 3 O Optional for Visa and MasterCard. Not applicable for
Country American Express.
Code The ISO assigned code of the country to which goods



were shipped.
12 Merchant AN 15 C Mandatory for MasterCard. Not applicable for Visa or
Tax ID American Express. The merchant’s federal tax
identification number.
The table listed below associates the FID to a specific card type in order to qualify for Purchase Card
Level 2, if applicable.
FID Visa MasterCard American Express
01 O N/A N/A
02 O M M
03 M M N/A
04 M M M
05 O O O
06 O N/A N/A
07 O O N/A
08 O O N/A
09 O O M
10 O O N/A
11 O O N/A
12 N/A M N/A

Conditional Requirement Matrix

VISA
The below matrix should be used in determining when the tax amount and customer code is required to
be present or optional. If the tax amount is required it must be within 0.01% and 22% of the transaction
amount. Tax exempt or non taxable transactions no longer qualify for Corporate, Business or Purchasing
card programs.
All industries, including Fuel Industry (MCC’s 4468, 5499, 5541, 5542, and 5983) for non fuel
transactions.
Date Element Corporate and Business Card Level II Purchasing Card Level II
Tax Amount Required Required
Customer Code Optional Optional
GSA Purchase Cards and Large Ticket Programs; Registration is required in order to participating in any
of the GSA Purchase Card or Large Ticket Programs. For further qualification or registration
requirements please contact your Relationship Manager.
Date Element Purchasing Card Level II
Tax Amount Required
Customer Code Required
MasterCard
The below matrix should be used in determining when the tax amount and customer code is required to
be present or optional. If the tax amount is required it must be within 0.01% and 30% of the transaction
amount. If the cardholder is charged tax the tax amount is required.
All industries excluding Fuel Industry:
Date Element Corporate Data Rate Level II Purchasing Card Level II
Tax Amount Required Required
Customer Code Required Required


Chapter 5. Sample Message Format
 Table Layout (see page 5-2)

 Messages (see page 5-2)
 Sample Messages (EBCDIC and ASCII) (see page 5-54)


Sample Message Format First Data ISO 8583 Global Specification
5.1. Table Layout

The table and field formats for the various message types contain the following information:
BIT Position within the bitmap indicating the presence of the field
FIELD NAME Name of the Field as used by First Data
ATTRIBUTE Data attributes of the field
REQ Whether the field is required (see table below)
COMMENTS Description of field as used by First Data
5.2. 0100 Message Authorization only, and Authorization &

Capture
Bit Field Name Attribute Req Comments
Message Type N 4 0100 See field details on page 2-7
Bitmap b 64 M See field details on page 4-3
Secondary b 64 C Must be present if any bit from 65 through
Bitmap 128 is used (see field details on page 4-5)
2 Primary N ..19 C Identifies the card member’s account number
Account (see field details on page 4-5)
Number
3 Processing N 6 M Code used in conjunction with the message
Code type to define the transaction being sent
from the terminal to the host (see field details
on page 4-6)
4 Amount of N 12 M See field details on page 4-8
Transaction
7 Transmission N 10 O See field details on page 4-8
Date/Time
11 System Trace N 6 M A system-generated number provided by the
merchant, the System Trace Number
uniquely identifies a transaction. (See field
details on page 4-9)
12 Time, Local N 4 C See field details on page 4-9
transaction
13 Date, Local N 4 C See field details on page 4-11
transaction
14 Card Expiration N 4 C See field details on page 4-11
Date
18 MCC N 4 M Merchant Category Code (see field details
on page 4-12)
22 POS Entry N 3 M See field details on page 4-12
Mode + PIN
Capability
24 Network Int'l ID N 3 C Identifies the acquiring host (see field details

on page 4-13)
25 POS Condition N 2 M Describes the conditions at the POS location
Code for a particular transaction (see field details
on page 4-14)


First Data ISO 8583 Global Specification Sample Message Format

31 Acquirer AN 1 C Values used by the “Acquirer” to determine
Reference Data how to process the transaction. (see field
32 Acquiring ID N ..12 O This code identifies the party (First Data)
processing the request (see field details on
page 4-15)
35 * Track 2 Data Z ..37 C Information such as the Expiration Date,
Primary Account Number, etc. encoded on a
magnetic stripe (see field details on page 4-
16)
37 Retrieval AN 12 M See field details on page 4-17
Reference #
41 Terminal ID AN 8 M First Data-assigned code that identifies the
merchant’s terminal (see field details on
page 4-19)
42 Merchant ID AN 15 M First Data-assigned code that identifies the
merchant’s location (see field details on
page 4-19)
43 Alternative AN 107 O The purpose of this field is to override
Merchant Name information stored for the merchant on First
/ Location Data Merchant master.
For American Express and Debit, it is

recommended that the Street Address also
be provided.
45 * Track 1 Data AN 76 C Information such as the Expiration Date,
Primary Account Number, etc. encoded on a
23)
48 Additional Data AN 31 O Billing (cardholder) address information for
-Private Data Address Verification Services. For details,
Field refer to Bit 48 Message Data for AVS only
and AVS + Authorization Transaction.
49 Transaction N 3 O Transaction Currency Code indicating the
Currency Code currency type used during the transaction
(see complete list on page 4-23)
59 Merchant AN ..9 M See field details on page 4-25

ZIP/Postal Code
60 Additional POS N 1 C See field details on page 4-25
Information
62 PS/2000 AN ..1 O PS/2000 Indicator legacy information only.
Indicator
63 Private Data AN ..999 O The response returned is based on the
Field tables that are submitted in the request
messages (Bit 39).
100 Receiving N ...11 C Code identifying the institution to receive
Institution ID request message (see field details on page
Code 4-27)
*
One of these must be communicated if the card is swiped.


**
Bit 62 or Bit 63 but not both.


5.3. 0100 Message Capture Only

Secondary b 64 C Must be present if any bit from 65 through
Bitmap 128 is used (see field details on page 4-5)
2 Primary Account N ..19 C Identifies the card member’s account
Number number (see field details on page 4-5)
3 Processing Code N 6 M Code used in conjunction with the
message type to define the transaction
being sent from the terminal to the host
(see field details on page 4-6)
Transaction
Date/Time
11 System Trace N 6 M A system-generated number provided by
the merchant, the System Trace Number
uniquely identifies a transaction (see field
details page 4-9)
12 Time, Local N 4 C See field details on page 4-9
transaction
13 Date, Local N 4 C See field details on page 4-11
transaction
Date
18 MCC N 4 M Merchant Category Code (see field details
on page 4-12)
22 POS Entry Mode N 3 M See field details on page 4-12
+ PIN Capability
24 Network Int'l ID N 3 C Identifies the acquiring host (see field

25 POS Condition N 2 M Describes the conditions at the POS
Code location for a particular transaction (see
field details on page 4-14)
31 Acquirer AN 1 C Values used by the “Acquirer” to
Reference Data determine how to process the transaction
processing the request (see field details
on page 4-15).
Reference #
38 Authorization AN 6 C Mandatory for Capture only (Bit 31, value
Code of 2) transactions
41 Terminal ID AN 8 M First Data-assigned code that identifies
the merchant’s terminal (see field details
on page 4-19).
42 Merchant ID AN 15 M First Data assigned code that identifies


the merchant’s location (see field details
on page 4-19).
Merchant Name / information stored for the merchant on
Location First Data Merchant master.
recommended that the Street Address
also be provided
44 Additional AN 1 C AVS response from auth — mandatory for
Response data Capture only (Bit 31, value of 2)
(AVS) transactions
49 Transaction N 3 O Transaction Currency Code indicating the
Currency Code currency type used during the transaction
59 Merchant AN 9 M See field details on page 4-25
ZIP/Postal Code
Information
62* PS/2000 AN ..1 O PS/2000 Indicator legacy information only
Indicator
63* Private Data AN …999 O The response returned is based on the
messages (Bit 39) – see page 4-32.
100 Receiving N ...11 C Code identifying the institution to receive
Institution ID request message (see field details on
Code page 4-27)
* Bit 62 or Bit 63 but not both.


5.4. 0100 Balance Inquiry for Prepaid Cards

2 Primary Account N ..19 C Identifies the card member’s account number
Number (see field details on page 4-5)
Code type to define the transaction being sent from
the terminal to the host (see field details on
page 4-6)
Transaction
merchant, the System Trace Number uniquely
identifies a transaction (see field details on
page 4-9).
12 Time, Local N 4 M See field details on page 4-9
transaction
13 Date, Local N 4 M See field details on page 4-11
transaction
Date
18 MCC N 4 C Merchant Category Code (see field details on
page 4-12)
Mode + PIN
Capability
on page 4-13)
Code for a particular transaction (see field details on
page 4-14)
35 Track 2 Data Z ..37 C Information such as the Expiration Date,
Primary Account Number, etc., encoded on a
16).
37 Retrieval Ref. # AN 12 C See field details on page 4-17
merchant’s terminal (see field details on page
4-19).
merchant’s location (see field details on page
4-19).
43 Alternative AN 107 O This field contains a number of sub-fields
Merchant Name identifying the merchant’s name, location and
/ Location service entitlement.
45 Track 1 Data AN ..76 C Information such as the Longitudinal Record
Check, etc., encoded on a magnetic stripe
63 Private Data AN …999 C The response returned is based on the tables


Field that are submitted in the request messages
(Bit 39).
The following tables are applicable here:
Table 68 (Additional Account/Amount
Information Data Request)


5.5. 0110 Authorization Host Response

0110 Identifies the message as a response to the 0100 request transaction
3 Processing Code N 6 M See field details on page 4-6
Transaction
Date/Time
the merchant, the System Trace Number
details on page 4-9).
25 POS Condition N 2 O Describes the conditions at the POS
32 Acquiring ID N ..12 O See field details on page 4-15
37 Retrieval Ref. # AN 12 M See field details on page 4-17
38 Authorization Code AN 6 C This field is provided only if the
authorization was approved by the issuer.
39 Response Code AN 2 M Indicates the status of the transaction. For
details, refer to Bitmap 39 — Response
Code on page 4-18.
41 Terminal ID AN 8 M First Data assigned code that identifies
the merchant’s terminal (see field details
on page 4-19)
Merchant information stored for the merchant on
Name/Location First Data Merchant master.

also be provided.
44 AVS Response AN 1 C Address Verification Response (see page
Code 4-21).
62 MC / Visa PS/2000 AN 20 O Refer to Field 62 (PS/2000 Indicator)
Response table (see page 4-31)
63 Private Data Field AN 16 C The response returned is based on the
tables that are submitted in the request
messages (Bit 39).


5.6. 0100 Check Guarantee/Verification

the terminal to the host (see field details on
page 4-6)
Transaction
page 4-9).
18 Merchant N 4 M Merchant Category Code (see field details on
Category Code page 4-12)
Mode+ PIN
Capability
24 Network Int'l ID N 3 O Identifies the acquiring host (see field details
on page 4-13)
25 POS Condition N 2 M This field describes the conditions at the POS
Code location for a particular transaction.
processing the request (see field details on
page 4-15).
37 Card Echo/ N 12 M See field details on page 4-17
Retrieval Ref.
#
41 Terminal ID A 8 M First Data assigned code that identifies the
N merchant’s terminal (see field details on page
4-19)
42 Merchant ID A 15 M First Data assigned code that identifies the
N merchant’s location (see field details on page
4-19)
43 Alternative A 107 O This field contains a number of sub-fields
Merchant N identifying the merchant’s name, location and
Name / service entitlement (see field details on page
Location 4-20)
48 Additional Data A ...47 M For details on check processing information,

— Private Data N refer to Bit 48 — MICR or Driver’s License
Field Data for Check Authorization/Guarantee 0100
message (see page 4-23)
59 Merchant A ..9 O See field details on page 4-25
ZIP/Postal N
Code



60 Additional POS N 2 O Not required for Check Verification
Information


5.7. 0110 Check Verification — Host Response

from the terminal to the host (see field details
on page 4-6)
4 Amount of N 12 M Echo from 0100 message (see field details
Transaction on page 4-8
7 Trans. N 10 O See field details on page 4-8
Date/Time
uniquely identifies a transaction. (see field
12 Time, Local N 6 M From First Data (see field details on page 4-
Trans. 9)
13 Date, Local N 4 M MMDD From First Data (see field details on
Trans. page 4-11)
on page 4-13)
25 POS Condition N 2 O Describes the conditions at the POS location
on page 4-14)
Reference
Number
38 Authorization AN 6 C This field is provided only if the authorization
Code was approved by the issuer (see field details
on page 4-18).
39* Response Code AN 2 M Indicates the status of the transaction
(Check-specific Response Code details on
page 4-18)
41 Terminal ID AN 8 M First Data assigned code that identifies the
page 4-19).
63* Private Data AN ...16 M The response returned is based on the
messages (Bit 39).

*
For check verification/guarantee, this text should always be used to display a response on the terminal.
Under certain conditions it will contain the ABA/Name supplied by the Check Verification Provider.
Occasionally, when Bit 39=00 (Approved), additional information must be displayed. Additional
information must be displayed for almost all Referrals (Bit 39=01).


5.8. 0100 Prepaid Card Activation (Visa Only)

2 Primary N 19 C Identifies the card member’s account number
Number
the terminal to the host. For prepaid card
activations, use the value “720000” (see field
4 Amount of N 12 M Amount to activate $0.00. See field details on
Transaction page 4-8.
page 4-9).
page 4-12)
Mode + PIN
Capability
24 Network Int'l ID N 3 C Identifies the acquiring host (see field details on
page 4-13)
25 POS Condition N 2 M Describes the conditions at the POS location for
Code a particular transaction (see field details on
page 4-14)
magnetic stripe (see field details on page 4-16)
37 Retrieval Ref. AN 12 C See field details on page 4-17
#
4-19)
merchant’s location (see field details on page 4-
19)
59 Merchant Zip AN 9 M See field details on page 4-25
Code

Information


5.9. 0110 Prepaid Card Activation Response

Message Type N 4 0110 see field details on page 2-7
Transaction
Date/Time
on page 4-13)
on page 4-14)
38 Authorization AN 6 C This field is provided only if the authorization
Code was approved by the issuer.
39 Response Code AN 2 M Indicates the status of the transaction (see
4-19)
63 Private Data AN .999 C Table 14 (CPS/2000 Additional Visa Data) —
Field Here the first authorized amount and total
authorized amount would both be zero.
Table 22 (Host Response Text) — Text
displayed on the terminal corresponds to the
response code (Bit 39)


5.10. 0100 Prepaid Card Load (Visa Only)

Bitmap b 64 M see field details on page 4-3
from the terminal to the host. For prepaid
card loads, use the value “280000” (see
field details on page 4-6).
4 Amount of N 12 M Amount to load (see field details on page 4-
Transaction 8)
the merchant. The system Trace Number
18 MCC N 4 C Merchant Category Code (see field details
on page 4-12)
Mode + PIN
Capability
Code location for a particular transaction (see field
Primary Account Number, etc., encoded on
a magnetic stripe (see field details on page
4-16)
37 Retrieval Ref. # AN 12 C See field details on page 4-17
page 4-19)
42 Merchant ID AN 15 M First Data assigned code that identifies the
merchant’s location (see field details on
page 4-19)
Code

Information



63 Private Data AN .999 C Table 68 (Additional Account/Amount
Field Information)
The values for specific fields in Table 68 for
Prepaid Card Load are as follows:
Version Number: 2
Balance Info Capable: 1
Partial Auth Capable): 0


5.11. 0110 Prepaid Card Load Response

Transaction
Date/Time
the merchant. The System Trace Number
25 POS Condition N 2 O Describes the conditions at the POS
32 Acquiring ID N 12 O See field details on page 4-15
authorization was approved by the issuer.
39 Response Code AN 2 M Indicates the status of the transaction (see
field details page complete list on page 4-
18)
page 4-19)
63 Private Data Field AN 999 C The following tables are returned:
Table 14 (CPS/2000 Additional

Visa Data) — Here the first
authorized amount and total
authorized amount would both be
zero.
Table 22 (Host Response Text) —
Text displayed on the terminal
corresponds to the response code
(Bit 39)
Table 68 (Additional
Account/Amount Information) —
Displays the account balance after
Load


5.12. 0100 Prepaid Card Activation with Load (Visa Only)

Bitmap b 64 M See field details on page. 4-3
2 Primary N 19 C Identifies the card member’s account number
Number
the terminal to the host. (see field details on
page 4-6)
4 Amount of N 12 M Amount to activate and Load (see field details
Transaction on page 4-8)
merchant. The System Trace Number
page 4-12)
Mode + PIN
Capability
on page 4-13)
page 4-14)
32 Acquiring ID N 12 O See field details on page 4-15
35 Track 2 Data Z 37 C Information such as the Expiration Date,
16)
37 Retrieval Ref. AN 12 C See field details on page 4-17
#
4-19)
42 Merchant ID AN 15 M First Data assigned code that identifies the
merchant’s location (see field details on page
4-19)
Code
60 Additional N 2 C See field details on page 4-25
POS
Information



63 Private Data AN …999 C Table 68 (Additional Account/Amount
Field Information) - The values for specific fields in
Table 68 for Prepaid Card Load are as
follows:
Version Number: 2
Balance Info Capable: 1
Partial Auth Capable: 0


5.13. 0110 Prepaid Card Activation and Load Response

Transaction
Date/Time
merchant. The System Trace Number
on page 4-13)
page 4-14)
38 Authorization AN 6 C This field is provided only if the issuer
Code approves the authorization (see field details
on page 4-18)
39 Response Code AN 2 M Indicates the status of the transaction
complete list (see field details on page 4-18)
4-19)
63 Private Data AN ..999 C The following tables are returned:
Field
Table 14 (CPS/2000 Additional Visa
Data) — Here the first authorized
amount and total authorized
amount would both be zero.
Table 22 (Host Response Text) —
Text displayed on the terminal
corresponds to response code (Bit 39)
Table 68 (Additional
Account/Amount
Information) — Displays the account
balance after Load


5.14. 0100 Authorization (VRU Only)

Bitmap b 64 M See field details on page. 4-3
Secondary Bitmap b 64 C see field details on page 4-5
Transaction
Date / Time
11 System Trace N 6 M A system-generated number provided
by the merchant, the System Trace
Number uniquely identifies a transaction
(see field details on page 4-9).
transaction
transaction
Date
+ PIN Capability

Reference #
38 Authorization AN 6 C See field details on page 4-18
Code
39 Response Code AN 2 C The host response to a message to
indicate the status of the transaction
42 Merchant ID AN 16 M First Data assigned code that identifies
on page 4-19)
43 Alternative AN 107 O This field contains a number of sub-
Merchant Name / fields identifying the merchant’s name,
Location location and service entitlement (see
field details page 4-20)



48 Additional Data — AN ...31 O Billing (cardholder) address information
Private Data Field for Address Verification Services. For
details, refer to Bit 48 – Message data
for AVS only and AVS + Authorization
Transactions 0100 message on page 4-
23.
49 Transaction N 3 O Transaction Currency Code indicating
Currency Code the currency type used during the
transaction (see field details on page 4-
23)
Information


5.15. 0200 Financial Transaction (Debit) — Excluding Canadian

Processing
Track 2 data must be present for all Debit transactions. However, Track 1 data is not allowed for any type
of Debit Card transaction.

Bitmap binar 64 M See field details on page 4-3
y
being sent from the terminal to the
host (see field details on page 4-6)
Transaction
7 Transmission N 10 C Bit 7 is mandatory for Debit host
Date/Time capture. See field details on page 4-8.
Number uniquely identifies a
transaction and is also considered the
debit “receipt” number by First Data
(see field details on page 4-9).
Transaction
Transaction
14 Card Expiry Date N 4 C See field details on page 4-11
18 Merchant Category N 4 M See field details on page 4-12
Code
22 POS Entry Mode + N 3 M See field details on page 4-12
PIN Capability
25 POS Condition Code N 2 M Describes the conditions at the POS
location for a particular transaction
31 Acquirer Reference AN 1 C Values used by the “Acquirer” to
Data determine how to process the
transaction (see field details on page
4-14 )
32 Acquiring ID N ..12 O This code identifies the party (First
Data) processing the request. (see



35 Track-2 Data Z ..37 C Information such as the Expiration
Date, Primary Account Number, etc.,
encoded on a magnetic stripe (see
37 Retrieval Reference # AN 12 M See field details on page 4-17
41 Terminal ID AN 8 M First Data-assigned code that
identifies the merchant’s terminal (see
42 Merchant ID AN 15 M First Data-assigned code that
identifies the merchant’s location (see
43 Alternative Merchant AN 107 O The purpose of this field is to override
Name/Location information stored for the merchant on
First Data Merchant master.

also be provided
52 Encrypted Pin AN 8 C See field details page 4-24
Number
54 Cash Back Amount AN ...999 O See field details on page 4-24
63 Private Data Field AN ...999 C The response returned is based on the
tables that are submitted in the
request messages (Bit 39).
The following tables are applicable
here:
Table 33 (Derived Unique Key

Per Transaction [DUKPT])
Mandatory for DUKPT for PIN
Based debit
Not required for Master session
(see page 4-65 for table details)
Field 63 should be excluded if

no data is present.



5.16. 0210 Financial Transaction (Debit) — Host Response

'0210' identifies the message as a response to the 0200 Financial Trans
(Debit).
message type to define the
transaction being sent from the
terminal to the host (see field
4 Amount of Transaction N 12 M See field details on page 4-8
Date/Time
11 System Trace N 6 M A system-generated number
provided by the merchant, the
System Trace Number uniquely
identifies a transaction (see field
Transaction
Transaction
24 Network Int'l ID N 3 C Identifies acquiring host (see field
25 POS Condition Code N 2 O Describes the conditions at the
POS location for a particular
transaction (see field details on
page 4-14)

authorization was approved by the
issuer (see page 4-18)
39 Response Code AN 2 M Indicates the status of the
page 4-18)
identifies the merchant’s terminal



43 Alternative Merchant AN 107 O The purpose of this field is to
Name/Location override information stored for the
merchant on First Data Merchant
master.
For American Express and Debit, it

is recommended that the Street
Address also be provided
63 Private Data Field AN …16 C The response returned is based on
the tables that are submitted in the
request messages (Bit 39)


5.17. 0200 Financial Transaction (Debit) — Canadian

Processing
Balance inquiry transactions are not captured for settlement process. However, all debit transactions
need to be captured for settlement. Track 2 data must be present for all Debit transactions.
Track 1 data is not allowed for any type of Debit Card transaction.

Bitmap binary 64 M See field details on page 4-3
Number number (see field details on page 4-
6)
Canadian Debit transaction being sent from the
Processing Codes: terminal to the host. (see field details
on page 4-6)
Sale ‘001000’ (savings)
‘002000’ (checking)
Refund ‘200010’ (savings)
Adjustment of
Adjustment of Sale
‘220010’ (savings)
Balance Inquiry
‘301000’ (savings)
Transaction
7 Transmission N 10 M See field details on page 4-8
Date/Time

transaction and is also considered
the debit “receipt” number by First
Data



Transaction
Transaction
14 Card Expiration Date N 4 C See field details on page 4-11
18 Standard Industry N 4 M See field details on page 4-12
Classification Code
PIN Capability
24 Network Int'l ID N 3 C Identifies the acquiring host, “047” for
Canadian merchants
31 Acquirer Reference AN 1 C Values used by “Acquirer” to
transaction. See field details on page
4-15.
Data) processing the request
35 Track-2 Data Z ..37 C Information such as the Expiration
Date, Primary Account Number etc.,
encoded on a magnetic stripe.
37 Retrieval Reference AN 12 M See field details on page 4-17
Number
identifies the merchant’s location
49 Transaction N 3 M Transaction Currency Code indicating

Currency Code the currency type used during the
transaction
52 Encrypted Pin Data AN 8 C See field details on page 4-24
54 Cash Back Amount AN ..12 O
63 Private Data Field AN …999 M The response returned is based on
The following table is applicable here:
Table 32 – Canadian MAC and
Check Digits – ** New Functionality:
Debit Message Authentication
Code/Check Digit
Mandatory for Canadian Debit sales,
refunds adjust/voids and balance
inquiries. The MAC is calculated
using the three working keys (TMAC,
TKPE, and TKME) and the following
fields:

Primary Account Number (from

Track II)
Processing Code (Bit 3)
Amount Transaction (Bit 4)
System Trace (Bit 11)
Terminal RRN (Bit 37)
Three working keys – These working

keys are assigned by the host and
sent back in the 210 or 810 response


5.18. 0210 Financial Transaction (Debit) Response — Canadian

Processing
Canadian Debit being sent from the terminal to the host
Processing Codes:
‘001000’ (savings)
Sale ‘002000’ (checking)
Adjust/Void of
Adjust/Void Sale
‘220010’ (savings)
Balance Inquiry ‘220020’ (checking)
‘301000’ (savings)
Transaction
7 Transmission N 10 M Bit 7 is mandatory for Debit host
Date/Time capture (see field details on page 4-8)
transaction and is also considered the
debit “receipt” number by First Data
Transaction
Transaction
24 Network Int'l ID N 3 C Identifies the acquiring host, “047” for
Canadian merchants
Code location for a particular transaction
Data) processing the request
Number
issuer (see field details on page 4-18)



(see field details on page 4-18 —
complete list page 4-18)
the merchant’s terminal.
63 Private Data Field AN ...999 M The response returned is based on the
messages (Bit 39).
The following tables are applicable
here:
Table 22 (Host Response Text)

– Text displayed on the terminal
corresponds to the response
code (Bit 39)
Table 31 – Network Response
Code: The native network
response code returned is
mapped to the response code in
Bit 39.<For more details refer to
>
Table 32 – Canadian MAC and
Check digits — Authentication
should use MAC from field 63
Table 34 – Canadian Debit
Keys. Three new working keys
are assigned by the host, if the
transaction is declined.


5.19. 0200 Financial Transaction (EBT Card)

Track 2 data must be present for all EBT Cash Benefit transactions. For EBT Food Stamp transactions,
track 2 data should be sent if available. If track 2 cannot be read, manual entry is allowed. EBT Voucher
Clear transactions do not require track 2 data and should not use Track 2 Data.
Track 1 Data is not allowed for any type of EBT transaction.

3 Processing N 6 M Code used in conjunction with the
Code message type to define the transaction
Transaction
Date/Time
Number uniquely identifies a transaction
Transaction
Transaction
14 Card Expiry N 4 C See field details on page 4-11
Date
18 Merchant N 4 M see field details on page 4-12
Category Code
Mode+PIN
Capability
31 Acquirer AN 1 C Values used by the “Acquirer” to
Reference Data determine how to process the
transaction (see field details on page 4-
14).
Data) processing the request (see field



35 Track-2 Data Z ..37 M Information such as the Expiration Date,
Primary Account Number, etc., encoded
on a magnetic stripe (see field details
on page 4-16)
Reference #
38 Authorization AN 6 C Mandatory for all EBT Voucher Clear
Code transactions. The authorization number
from the voice authorization process is
sent in this field (see field details on
page 4-18).
the merchant’s terminal (see field
42 Merchant ID AN 15 M First Data-assigned code that identifies
on page 4-19)
43 Alternative AN 107 O This field contains a number of sub-
Merchant fields identifying the merchant’s name;
Name/Location location and service entitlement (see
52 Encrypted Pin AN 8 C See field details on page 4-24
Data
54 Cash Back AN ..12 O For EBT Cash Benefit transactions only
Amount (see field details on page 4-24)
63 Private Data AN …999 C The response returned is based
Field on the tables that are submitted
in the request messages (Bit 39).
The following tables are
applicable here:
Per Transaction [DUKPT]):
Mandatory for DUKPT. Not
required for Master session (see
page 4-65 for table details)
Table 62 (Electronics Benefits
Transfer (EBT) data): Mandatory
for Electronic Benefits Transfer
(EBT) transactions (see page 4-
85 for table details.)


5.20. 0210 Financial Transaction (EBT) — Host Response

'0210' identifies the message as a response to the 0200 Financial Trans.
(EBT)
terminal to the host (see field details
on page 4-6)
Date/Time
12 Time, Local Transaction N 6 M See field details on page 4-9
13 Date, Local Transaction N 4 M See field details on page 4-11
24 Network Int'l ID N 3 C Identifies acquiring host (see field
25 POS Condition Code N 2 O Describes the conditions at the POS
37 Retrieval Ref. # AN 12 M For more details, please refer to field
details on page 4-17
issuer.
(see field details on page 4-18 —
complete list on page 4-18)
63 Private Data Field AN …999 C The response returned is based on


5.21. 0400 Reversal — Credit Card

A 0400 reversal message must contain all of the fields from the original authorization request. In addition,
Fields 7 (Transmission Date/Time) and 24 (Network International ID) must also be included. Finally, if the
original transaction is qualified for Visa CPS/2000 or MasterCard, then Tran-ID and Validation Code from
Visa and BankNet Settlement Date and Reference number from MC original response must be included
in Field 63, Table 14.

Primary Bitmap b 64 M See field details on page 4-3
2 Primary Account N 19 M Identifies the card member’s account
Number number (see field details on page 4-
5)
terminal to the host (see field details
on page 4-6)
7 Transmission N 10 O See field details page 4-8
Date/Time
4-9).
transmission
transmission
14 Card Expiration Date N 4 C See field details on page 4-11
18 MCC N 4 M Merchant Category Code (see field
22 POS Entry Mode+ PIN N 3 M See field details on page 4-12
Capability
31 Acquirer Reference AN 1 C Values used by the “Acquirer” to
4-14).
Data) processing the request (see
37 Retrieval Ref. Number AN 12 M See field details on page 4-17.
38 Auth Code AN 6 C See field details page 4-18.



39 Response Code AN 2 C See field details on page 4-18.
Required for Partial Authorization
reversals (pre-paid cards)
41 Terminal ID AN 8 M Code that identifies the merchant’s
terminal (see field details on page 4-
19)
identifies the merchant’s location (see
43 Alternative Merchant AN 107 O The purpose of this field is to override
Name/Location information stored for the merchant
on First Data Merchant master.
For American Express and Debit it is

recommended that the Street
Address also be provided
48 Additional Data Private AN ...31 O Billing (cardholder) address
Data Field information for Address Verification
Services. For details, refer to Bit 48
Additional Data – Private Data Field
(Message Data for AVS Only and
AVS + Authorization Transaction) on
page 4-23
49 Transaction Currency N 2 C See field details on page 4-23
Code
59 Merchant ZIP/Postal AN ..9 M See field details on page 4-19
Code
Information
62* PS/2000 Indicator AN ..1 O See table details page 4-27
63* Private Data Field AN ..999 O The response returned is based on
reversal messages relevant to Credit
Cards (Bit 39).
* Bit 62 or Bit 63 but not both.


5.22. 0410 Credit Card Reversal — Host Response

Identifies the message as a response to the 0400 Credit Card Reversal
message type to define transaction
host (see field details on page 4-6)
Transactions
Date/Time
4-9).
25 POS Condition Code N 2 O Describes the conditions at the POS
37 Retrieval Reference # AN 12 M For more details refer to field details
on page 4-17.
38 Authorization Code AN 6 C See field details on page 4-18
identifies the merchant’s terminal (see
field details on page 4-19 — complete
list on page 4-19)
63 Private Data Field AN ...16 The response returned is based on

request messages.
Non-CPS/2000 – Text displayed on
terminal that corresponds to the
Response Code (Bit 39, above)
AN ..999 O CPS/2000 and MC data (For details,
refer to page 4-27)


5.23. 0400 Debit Card Reversal

With the following exceptions, the 0400 Message must provide the data sent in the original 0200
message to comply with Debit Network Provider requirements. Exceptions: Bit 7 (can be actual

Secondary Bitmap b 64 C Must be present if any bit from
65 to 128 is used. See field
details on page 4-5
3 Processing Code N 6 M Code used in conjunction with
the message type to define the
Transaction
Date/Time
identifies a transaction (see
Transmission
Transaction
18 Merchant Category N 4 M See field details on page 4-12
Code
22 POS Entry Mode + N 3 M See field details on page 4-12
PIN Capability
24 Network Int'l ID N 3 C Identifies the acquiring host

25 POS Condition Code N 2 M Describes the conditions at the
page 4-14)
31 Acquirer Reference AN 1 C Values used by the “Acquirer”
Data to determine how to process
the transaction (see field details
on page 4-14).



32 Acquiring ID N ..12 O This code identifies the party
(First Data) processing the
request (see field details on
page 4-15).
35 Track-2 Data N ..37 C See field details on page 4-16
37 Retrieval Reference # AN 12 M See field details on page 4-17
identifies the merchant’s
terminal (see field details on
page 4-19)
location (see field details on
page 4-19)
43 Alternative Merchant AN 107 O The purpose of this field is to
Name/Location override information stored for
the merchant on First Data
Merchant master.
For American Express and

Debit it is recommended that
the Street Address also be
provided
48 Message Reason AN …06 O Specific reason the Debit
Code Reversal is being generated.
For details, refer to `Bit 48 –
Additional Data-Private Data
Field (Message Reason Code
for Debit Reversals).
52 Encrypted Pin Data AN 8 C See field details on page 4-24
54 Cash Back Amount AN ..12 O See field details on page 4-24
63 Table 18 (Debit AN ...999 C Table 18 (Debit Resubmission
Resubmission Data Data Elements) is mandatory
Elements) on Reversals of Debit
Resubmission requests. On all
Table 33 (DUKPT) other types of Debit Reversals,
Table 18 should be excluded
(see page 4-58 for table
details).

Per Transaction [DUKPT]).
Mandatory for DUKPT
Not required for Master session

(see page 4-65 for table
details).
Field 63 should be
excluded if no data is

present.


5.24. 0410 Financial Transaction (Debit) Reversal — Host

Response
Identifies the message as a response to the 0400 Financial Reversal Trans.
(Debit/EBT)
message type to define
4 Amount of Transaction. N 12 M See field details on page 4-8
7 Trans. Date/Time N 10 O See field details on page 4-8
12 Time, Local Trans. N 6 M See field details on page 4-9
13 Date, Local Trans. N 4 M See field details on page 4-11
24 Network Int'l ID N 3 C Identifies the acquiring host (see
field details page 4-13)
25 POS Condition Code N 2 O Describes the conditions at the
page 4-14)
37 Retrieval Ref. # AN 12 M For more details please refer to
field details on page 4-17
38 Authorization Code AN 6 C See field details on page 4-18
Always 868686 in 0410 message

page 4-18 – complete list on page
4-18)
63 Private Data Field AN ...16 The response returned is based
on the tables that are submitted in
the request messages Bit 39.


5.25. 0400 EBT Card Reversal

With the following exceptions, the 0400 Message must provide the data sent in the original 0200
message to comply with EBT Network Provider requirements. Exceptions: Bit 7 (can be actual

3 Processing Code N 6 M Code used in conjunction
with the message type to
define the transaction being
sent from the terminal to the
host (see field details on
page 4-6)
Transaction
Date/Time
provided by the merchant,
the System Trace Number
uniquely identifies a
transaction (see field details
on page 4-9).
Transmission
13 Date, Local N 4 M See field details on page 4-
Transmission 11
18 Merchant Category N 4 M See field details on page 4-
Code 12
22 POS Entry N 3 M See field details on page 4-
Mode+PIN Capability 12
24 Network Int'l ID N 3 C Identifies the acquiring host

(see field details on page 4-
13)
25 POS Condition Code N 2 M Describes the conditions at
the POS location for a
particular transaction (see
31 Acquirer Reference AN 1 C Values used by the
Data “Acquirer” to determine how
to process the transaction
(see field details on page 4-
14).



32 Acquiring ID N ..12 O This code identifies the party
(First Data) processing the
request (see field details on
page 4-15).
35 Track-2 Data Z ..37 C See field details on page 4-
16
37 Retrieval Reference AN 12 M See field details on page 4-
# 17
page 4-19)
location (see field details on
page 4-19)
43 Alternative Merchant AN 107 O This field contains a number
Name/Location of sub-fields identifying the
merchant’s name, location
and service entitlement (see
48 Additional Data — AN ..99 O This field contains the
Private Data Field message reason code for
Debit and EBT reversal/Void.
For details, see page 4-23.
52 Encrypted Pin Data AN 8 C See field details on page 4-
24
54 Cash Back Amount AN ..12 O See field details on page 4-
24


5.26. 0410 Financial Transaction (EBT) Reversal — Host

Response
Identifies the message as a response to the 0400 Financial Reversal Trans.
(Debit/EBT)
message type to define
Transaction.
7 Trans. Date/Time N 10 O See field details on page 4-8
12 Time , Local N 6 M See field details on page 4-9
Trans.
13 Date, Local Trans. N 4 M See field details on page 4-11
24 Network Int'l ID N 3 C Identifies the acquiring host (see
25 POS Condition N 2 O Describes the conditions at the
Code POS location for a particular
page 4-14)
37 Retrieval Ref. # AN 12 M For more details please refer to
38 Authorization AN 6 C See field details on page 4-18.
Code
Always 868686 in 0410 message
page 4-18 — complete list on
page )
63 Private Data Field AN …16 The response returned is based
on the tables that are submitted in
the request messages Bit 39.


5.27. 0800 Log-On Message

Primary Bitmap b 64 M See field details on page4-4
Secondary Bitmap b 64 M see field details on page 4-5
7 Trans. Date/Time N 10 O see field details on page 4-8
4-9).
#
70 Network N 4 M See field details on page 4-13
Management Info
Code X’00 01’


5.28. 0810 Log-On Response

Secondary Bitmap b 64 M See field details on page 4-5
7 Transmission N 10 O See field details on page 4-8. Leased
Date/Time Line Only
37 Retrieval Reference # AN 12 M For more details please refer to field
details on page 4-17
70 Network Management N 3 M X’00 01’ (see field details on page 4-
Information Code 13)
93 Response Indicator AN 5 M see field details on page 4-26


5.29. 0800 Echo Test-First Data Standard Format

0810 Message will be returned from the Host
being sent from the terminal to the host.
In this case the processing code is
990000 (see field details on page 4-6).
transaction. (Field details on page 4-9)
41 First Data Terminal AN 8 M First Data-assigned code that identifies
ID the merchant’s terminal (see field details
on page 4-19)
42 First Data Merchant AN 15 M First Data-assigned code that identifies
Number the merchant’s location (see field details
on page 4-19)


5.30. 0810 Echo Test (First Data Standard Format) — Response

message type to define transaction
host. In the case, the processing
code is 990000 (see field details on
page 4-6).
12 Local Time N 6 M See field details on page 4-9
13 Local Date N 4 M See field details on page 4-11
24 Network Int'l ID N 3 M Identifies the acquiring host (see
page 4-18— complete list on page
4-18)
41 First Data Terminal ID AN 8 M First Data-assigned code that
42 First Data Merchant ID AN 15 M First Data-assigned code that
identifies the merchant (For more
details refer to page 4-19)
63 Private Data Field AN 999 M Text displayed on terminal that
corresponds to the Response Code
(Bit 39, above)
The response returned is based on

request messages.


5.31. 0800 Echo Test — Visa Standard Format

'0810' Message will be returned from the Host
Date/Time
#
48 Additional Data – AN ..99 O Message text will be echoed
Private Data Field back on the response. For
example, HEARTBEAT.
Management Info.
Code X’03 01’


5.32. 0810 Echo Test (Visa Standard Format) — Response

Bit Field Attribute Req Comments
7 Transmission N 10 O See field details on page 4-8-
Date/Time
37 Retrieval Reference # AN 12 M For more details please refer to
48 Message Text AN ..99 O Message text will be echoed back
if provided on input.
70 Network N 3 M X’03 01’ (see field details on page
Management 4-13)
Information Code


5.33. 0800 New Key Request for Non Canadian Merchants using
a HSM
Secondary Bitmap b 64 M
Date/Time
Transaction
Transaction
41 First Data AN 8 M First Data-assigned code that
Terminal ID identifies the merchant’s terminal
42 First Data AN 15 M First Data-assigned code that
Merchant ID identifies the merchant (see field
70 Network N 4 M 811 (new key) — see field details
Management Info on page 4-13
Code


5.34. 0810 New Key Response

Date/Time
Transaction
Transaction
39 Response Code AN 2 M See field details on page 4-18
41 First Data Terminal AN 8 M First Data-assigned code that
ID identifies the merchant’s terminal
42 First Data Merchant AN 15 M First Data-assigned code that
ID identifies the merchant (see field
70 Network N 4 M 811 (new key) — Refer to page 4-
Management Info 13
Code
96 Key Management b ..18 O Contains a 1 byte BCD length
Data indicator followed by up to 16 bytes
of a merchant working key and 2
bytes of check digits.
If single DES, an 8 byte
merchant key followed
by a 2 byte check digit
will be sent. If triple
DES, a 16 bytes
merchant key followed
by a 2 byte check digit
will be sent.


5.35. 0800 New Key Request for Canadian Merchants using

MACing
3 Processing Code N 6 M Value = 000000
11 System Trace/Debit N 6 M A system-generated number
Receipt provided by the merchant, the
System Trace Number
uniquely identifies a
transaction (see field details
on page 4-9).
24 Network Int’l ID AN 3 M Value = 047 for Canadian
Merchant (see page 4-13)
31 Acquirer Reference AN 2 O Values used by “Acquirer” to
transaction. Value should be
“0” for key request message.
41 First Data Terminal AN 8 M First Data-assigned code that
ID identifies the merchant’s
page 4-19)
42 First Data Merchant AN 15 M First Data-assigned code that
ID identifies the merchant (see
Management Info
Code Value 811 for New Key
request


5.36. 0810 New Key Response — Canadian Merchants using

MACing
Secondary Bitmap b 64 M
3 Processing Code N 6 M Value = 000000
11 System Trace/Debit N 6 M A system-generated number provided by
Receipt the merchant, the System Trace Number
uniquely identifies a transaction. (Field
details page 4-9)
Transaction
Transaction
24 NII N 3 M Echoed from Request
39 Response Code AN 2 M See field details on page 4-18
41 First Data Terminal ID AN 8 M First Data-assigned code that identifies the
page 4-19)
42 First Data Merchant ID AN 15 M First Data-assigned code that identifies the
merchant (see field details on page 4-19)
63 Private Data Field The response returned is based on the
messages (Bit 39). The following tables
are applicable here:
AN 42 O Table 22 — Host response text: The text
displayed in the terminal corresponds to
the response code (in Bit 39)
AN 4 O Table 31 — Network Response Code: The
native network response code returned is
mapped to the response code in Bit 39.
For more details, refer to page 4-62.
AN 18 M Table 32 — Canadian MAC and Check
digits: Authentication should use MAC
from field 63 Table 34, if present in the
response message. No authentication
required if the MAC in the field 63 Table
32 is all spaces.
AN 50 M Table 34 — Canadian Debit Keys: New
Keys — Apply to authentication for
processing of this message as well as
subsequent processing.
70 Network Management N 4 M 811 (new key) Refer to page 4-13
Info Code


5.37. Sample Messages (EBCDIC and ASCII)

The following sections provide examples of ISO 8583 format request and response messages in both the EBCDIC and ASCII character sets. The
following sample messages do not include the only possible combinations of fields. Rather, these examples are intended to provide the reader
with an idea of how to interpret our specifications.
Since the Account Number used throughout these examples isn’t real, it may not pass MOD-10 checking.

Request Message (EBCDIC) — Example Based on U.S. Currency (i.e., 2 assumed decimal places)
01 00 72 24 45 81 08 C1 00 22 15 40 05 55 00 00 a.A........
00 01 90 00 00 00 00 00 00 00 22 25 10 23 15 59 r.........
30 23 35 19 98 05 59 60 00 12 00 01 53 12 99 82 q..-......rb
00 10 09 93 F3 F2 F3 F6 F9 F2 F3 F0 40 40 40 40 l32369230
E5 C3 C3 F1 F3 F5 F1 F9 F0 F0 F0 F1 F7 F4 F1 F6 VCC1351900017416
F4 F5 F1 F7 F9 F9 F0 00 31 F9 F9 F2 F6 F2 F6 F9 4517990..9926269
F0 F0 F0 F0 40 40 40 40 40 40 40 40 40 40 40 40 0000
40 40 40 40 40 40 40 40 09 F2 F0 F0 F7 F6 F0 F0 2007600
F0 F0 00 50 00 48 F1 F4 E8 40 40 40 40 40 40 40 00.and..14Y
40 40 40 40 40 40 40 40 40 40 40 40 40 F7 F0 F0 700
F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 0000000000000000
F0 F0 F0 F0 F0 F0 000000.

Message Bitmap Bit 2 Bit 3
Type ID 2, 3, 4, 7, 11, 14, 18, 22, 24, 25, 32, 37, 41, Length Acct. #Account Number Processing Code
42, 48, 59, 63
01 00 72 24 45 81 08 C1 00 22 15 40 05 55 00 00 00 00 19 00 00 00
N, 4 BCD B, 64 Binary N, 2 BCD N, 15 (up to 19 ) BCD N, 6 BCD


Bit 4 Bit 7 Bit 11 Bit 14 Bit 18 Bit 22
Dollar Amount Transmission Date / System Trace Card Expir. Date MCC POS Entry Mode
Time
00 00 00 00 10 00 10 23 15 59 30 23 35 19 99 11 59 60 00 12
N, 12 BCD N, 10 BCD N, 6 BCD N, 4 BCD N, 4 BCD N, 3 BCD (padded
½ byte of 0)
Bit 24 NII Bit 25 Bit 32
POS Condition Code Length of Acq. ID
Acquiring ID
0001 08 12 998200100993
N, 3 BCD (padded ½ byte of 0) N, 2 BCD N, 2 BCD N, 12 BCD
Bit 37 Bit 41
Retrieval Reference Number Terminal ID

3 2 3 6 9 2 3 0 b b b b V C C 1 3 5 1 9
F3 F2 F3 F6 F9 F2 F3 F0 40 40 40 40 E5 C3 C3 F1 F3 F5 F1 F9
AN, 12 EBCDIC AN, 8 EBCDIC
Bit 42
Merchant ID
0 0 0 1 7 4 1 6 4 5 1 7 9 9 0
F0 F0 F0 F1 F F4 F1 F6 F4 F F1 F7 F9 F9 F0
7 5
AN, 15 EBCDIC
Bit 48
Length of Cardholder B.A. Cardholder Billing Address
31 0 9 2 6 2 6 9 0 0 0 0 b (twenty b
spaces)
00 31 F F9 F2 F6 F2 F F9 F0 F0 F0 F0 40 <---> 40
0 6
N, 3 BCD (padded ½ byte of 0) AN, 31 EBCDIC


Bit 59 Field 63, Table 14

Length of Merch. Zip Merchant ZIP/Postal Code Length of Bit 63 Length of Table 14 Table ID
09 9 0 0 7 6 0 0 0 0 50 48 1 4
09 F9 F0 F0 F7 F F0 F0 F0 F0 00 50 00 48 F1 F4
6
N, 2 BCD AN, 9 EBCDIC N, 3 BCD (padded ← AN, 2 EBCDIC
½ byte of 0
Bit 63 (Continued), Table 14

ACI TRAN ID Validation Code MSDI RPSI First Amount Total Amount
Authorized Authorized
Y b (15 spaces) b b b b b B 07 0 (12 zeros) 0 0 (12 zeros) 0
E8 40 ----- 40 40 40 40 40 40 F7 F0 ---- F0 F0 ---- F0
AN, 1 EBCDIC AN, 15 EBCDIC AN, 4 EBCDIC AN, 1 EBCDIC ← AN, 12 EBCDIC AN, 12 EBCDIC
Response Message (EBCDIC) — Example Based on U.S. Currency (i.e., 2 assumed decimal places)
01 10 32 20 01 81 0E 90 00 02 00 00 00 00 00 00 ..a..........
00 22 25 10 23 15 57 40 23 35 19 00 01 53 12 99 ..r
82 00 10 09 93 F3 F2 F3 F6 F9 F2 F3 F0 40 40 40 b...l32369230
40 F1 F8 F9 F2 F9 F6 F0 F0 E5 C3 C3 F1 F3 F5 F1 18929600VCC1351
F9 00 01 E9 00 70 00 48 F1 F4 E5 F0 F2 F6 F2 F9 9..Z....14V02629
F7 F7 F1 F9 F7 F4 F8 F9 F7 F2 C4 D5 F5 F2 40 40 7719748972DN52
F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 F0 0000000000000000
F0 F0 F0 F0 F0 F0 F0 F0 00 18 F2 F2 C1 D7 D7 D9 00000000...22APPR
D6 E5 C1 D3 40 40 40 40 40 40 40 40 OVAL


Message Type ID Bitmap Bit 3 Bit 4
3, 4, 7, 11, 24, 25, 32, 37, 38, 39, 41, 44, 63 Processing Code Amount
01 10 32 20 01 81 0E 90 00 02 00 00 00 00 00 00 00 22 25
N, 4 BCD B, 64 Binary N, 6 BCD N, 12 BCD
Bit 7 Bit 11 Bit 24 Bit 25
Transmission Date / Time System Trace NII POS Condition Cod e

10 23 15 57 40 23 35 19 00 01 08
N, 10 BCD N, 6 BCD N, 3 BCD (padded ½ byte of 0) N, 2 BCD
Bit 32 Bit 37
Length of Acquiring ID Retrieval Reference Number

12 9 9 8 2 0 0 1 0 0 9 9 3 3 2 3 6 9 2 3 0 b b b B
12 9 9 8 2 0 0 1 0 0 9 9 3 F3 F2 F3 F6 F9 F2 F3 F0 40 40 40 40
N, 2 BCD N, 12 BCD AN, 12 EBCDIC
Bit 38 Bit 39 Bit 41
Authorization Code Response Code Terminal ID

1 8 9 2 9 6 0 0 V C C 1 3 5 1 9
F1 F8 F9 F2 F9 F6 F0 F0 E5 C3 C3 F1 F F5 F1 F9
3
AN, 6 EBCDIC AN, 2 EBCDIC AN, 8 EBCDIC
Bit 44 Bit 63, Table 14

Length of AVS Response Code Length of Bit 63 Length of Table 14
01 Z 50 48
00 01 E9 00 50 00 48
N, 3 BCD (padded ½ byte of 0) AN, 1 EBCDIC N, 3 BCD (padded ½ byte of 0) N, 3 BCD (padded ½ byte of 0)
Bit 63, Table 14 (Cont.)
Table ID ACI Response Transaction ID


1 4 V 0 2 6 2 9 7 7 1 9 7 4 8 9 7 2
F1 F4 E5 F0 F2 F6 F2 F9 F7 F7 F1 F9 F7 F4 F8 F9 F7 F2
Validation Code MSDI

D N 5 2 B
C4 D5 F5 F2 40
AN, 4 EBCDIC AN, 1 EBCDIC

RPSI First Authorized Amount Total Authorized Amount
b 0 (twelve zeros) 0 0 (twelve zeros) 0
40 F0<----> F0 F0<----> F0
Request Message (ASCII) — Example Based on U.S. Currency (i.e., 2 assumed decimal places)
01 00 72 24 45 81 08 C1 00 22 15 40 05 55 00 00 .a.A........
00 01 90 00 00 00 00 00 00 00 22 25 10 23 15 59 ..r.............
30 23 35 19 98 05 59 60 00 12 00 01 53 12 99 82 .q..-......rb
00 10 09 93 33 32 33 36 39 32 33 30 20 20 20 20 .l32369230
56 43 43 31 33 35 31 39 30 30 30 31 37 34 31 36 VCC1351900017416
34 35 31 37 39 39 30 00 31 39 39 32 36 32 36 39 4517990..9926269
30 30 30 30 20 20 20 20 20 20 20 20 20 20 20 20 0000
20 20 20 20 20 20 20 20 09 32 30 30 37 36 30 30 .2007600
30 30 00 50 00 48 31 34 59 20 20 20 20 20 20 20 00.and..14Y
20 20 20 20 20 20 20 20 20 20 20 20 20 37 30 30 700
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
30 30 30 30 30 30 000000.

Message Bitmap Bit 2

Type ID 2, 3, 4, 7, 11, 14, 18, 22, 24, 25, 32, 37, 41, 42, 48, 59, 63 Length of Account # Account Number
01 00 72 24 45 81 08 C1 00 22 15 400555000000190
N, 4 BCD B, 64 Binary N, 2 BCD N, 15 (up to 19) BCD

Processing Code Amount Transmission Date / Time System Trace
00 00 00 00 00 00 00 22 25 10 23 15 57 40 23 35 19
N, 6 BCD N, 12 BCD N, 10 BCD N, 6 BCD
Bit 14 Bit 18 Bit 22 Bit 24 Bit 25

Card Expiration Date MCC POS Entry Mode NII POS Condition
Code
98 05 59 60 00 12 00 01 08
N, 4 BCD N, 4 BCD N, 3 BCD (padded ½ byte of 0) N, 3 BCD (padded ½ byte of 0) N, 2 BCD
Bit 32 Bit 37
Length of Acquiring ID Retrieval Reference Number
1 2 9 9 8 2 0 0 1 0 0 9 9 3 3 2 3 6 9 2 3 0 b b b b
12 9 9 8 2 0 0 1 0 0 9 9 3 3 2 3 6 9 2 3 0 b b b b
Bit 41
Terminal ID
V C C 1 3 5 1 9
56 43 43 31 33 35 31 39
AN, 8 EBCDIC


Bit 42
Merchant ID
0 0 0 1 7 4 1 6 4 5 1 7 9 9 0
30 30 30 31 37 34 31 36 34 35 31 37 39 39 30
AN, 15 ASCII
Bit 48
Length of Cardholder Billing Address
31 9 9 2 6 2 6 9 0 0 0 0 b (twenty spaces) b
00 31 39 39 32 36 32 36 39 30 30 30 30 20 <---> 20
N, 3 BCD (padded ½ byte of 0) AN, 31 ASCII
Bit 59
Length of Merchant ZIP/Postal Code
09 2 0 0 7 6 0 0 0 0
09 32 30 30 37 36 30 30 30 30
N, 2 BCD AN, 9 ASCII
Bit 63, Table 14

Length of Bit 63 Length of Table 14 Table ID ACI Tran ID
74 48 1 4 59 b (fifteen spaces) b
00 74 00 48 31 34 Y 20 --------- 20
N, 3 BCD (padded ½ byte of 0) N, 3 BCD (padded ½ byte of 0) AN, 2 ASCII AN, 1 ASCII AN, 15 ASCII
Bit 63, Table 14

Validation Code MSDI RPSI First Authorized Amount Total Authorized Amount
B b b b b 7 0 (12 zeros) 0 0 (12 zeros) 0
20 20 20 20 20 37 30 ----- 30 30 ----- 30
AN, 4 ASCII AN, 1 ASCII AN, 1 ASCII AN, 12 ASCII AN, 12 ASCII

Bit 63 – Table 33 (DUKPT SMID)

Length of Table 33 Table ID
22 33 F F F F A B A B A B 0 (nine 0 1
zeros)
00 22 33 33 46 46 46 46 41 42 41 42 41 42 30 <---> 30 31
N, 3 BCD (padded ½ byte of 0) AN, 2 ASCII AN, 20 ASCII
Response Message (ASCII) — Example Based on U.S. Currency (i.e., 2 assumed decimal places)
01 10 32 20 01 81 0E 90 00 02 00 00 00 00 00 00 .....a..........
00 22 25 10 23 15 57 20 23 35 19 00 01 53 12 99 ...............r
82 00 10 09 93 33 32 33 36 39 32 33 30 20 20 20 b.l32369230
20 31 38 39 32 39 36 30 30 56 43 43 31 33 35 31 18929600VCC1351
39 00 01 5A 00 70 00 48 31 34 56 30 32 36 32 39 9..Z....14V02629
37 37 31 39 37 34 38 39 37 32 44 4E 35 32 20 20 7719748972DN52
30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 30 0000000000000000
30 30 30 30 30 30 30 30 00 18 32 32 41 50 50 52 00000000..22APPR
4F 56 41 4C 20 20 20 20 20 20 20 20 OVAL
Message Type ID Bitmap Bit 3 Bit 4

3, 4, 7, 11, 24, 25, 32, 37, 38, 39, 41, 44, 63 Processing Code Amount
01 10 32 20 01 81 0E 90 00 02 000000 000000002225
N, 4BCD B, 64 Binary N, 6 BCD N, 15 BCD

Transmission Date/Time System Trace NII POS Condition Code
10 23 15 57 40 23 35 19 00 01 08
N, 10 BCD N, 6 BCD N, 3 BCD (padded ½ byte of 0) N, 2 BCD


Bit 32 Length of Acquiring ID Bit 37 Retrieval Reference Number

12 9 9 8 2 0 0 1 0 0 9 9 3 3 2 3 6 9 2 3 0 b b b b
Bit 38 Authorization Code Bit 39Response Code Bit 41 Terminal ID

1 8 9 2 9 6 0 0 V C C 1 3 5 1 9
31 38 39 32 39 36 30 30 56 43 43 31 33 35 31 39
AN, 6 ASCII AN, 2 ASCII N, 8 ASCII
Bit 44 Length of AVS Response Code Bit 63, Table 14

Length of Field 63 Length of Table 14 Table ID ACI Response
0 0 0 1 Z 70 48 14 56
0 0 0 1 5A 0070 0048 31 34 V
N, 3 BCD (padded ½ byte of 0) AN, 1 ASCII N, 3 BCD (padded N, 3 BCD (padded ½ byte of 0) AN, 2 ASCII AN, 1 ASCII
½ byte of 0)
Validation Code Bit 63, Table 14 (Cont.) First Authorized Amount Total Authorized Amount
MDSI RPSI
D N 5 2 b b 0 (12 zeros) 0 0 (12 zeros) 0
44 4E 35 32 20 20 30 ----- 30 30 ----- 30
AN, 4 ASCII AN, 1 ASCII AN, 1 ASCII AN, 12 ASCII AN, 12 ASCII
Length of Table 22 Bit 63, Table 22 Table ID Displayed Text

18 22 A P P R O V A L b (8 spaces) b
0018 32 32 41 50 50 52 4F 56 41 4C 20 <-> 20
N, 3 BCD (padded ½ byte of 0) AN, 2 ASCII AN, 16 ASCII

Chapter 6. Appendix
 Appendix A — Response Codes (see page 6-2)

 Appendix B — State Codes (see page 6-11)
 Appendix C — Country Codes (see page 6-12)
 Appendix D — Currency Codes (see on page 6-17)
 Appendix E — Check Digit Logic/Card Type ID
 + Card type identification (see page 6-23)
 Appendix F — Magnetic Stripes Standards (see page 6-26)
 Appendix G — Glossary (see page 6-27)
 Appendix H — Escalation Procedures for Authorization Link Problems (see page 6-
33)
 Appendix I — Address Verification Service (AVS) [see page 6-34]
 Appendix J — Check Guarantee/Verification (see page 6-35)
 Appendix K — Additional Credit Card Processing (see page 6-39)
 Appendix L — General Information on Debit and EBT (see page 6-57)
 Appendix M — First Data Processing Environment (see page 6-70)
 Appendix N — Host Capture (see page 6-71)
 Appendix O — Canadian Debit Processing-Terminal MAC/EKME (see page 6-74)
 Appendix P — Frequently asked questions (see page 6-78)


First Data ISO 8583 Global Specification Appendix A
6.1. Appendix A — Response Codes

6.1.1. Response Codes in Sequence by Text
Response Codes in Sequence by Text

Code Corresponding Meaning
Displayed Text
61 Amt Exceeds Lmt Amount Exceeds Limit
00 Approval Approved for capture in batch
76 Approval Approved (non captured)
10 Apprv Lesser Amt Approved for a lesser amount than what was requested (i.e.
partial approval)
85 AVS Accepted AVS Request Accepted
NK Crypto Box Unav Crypto box is offline
C2 CVV2 Declined Association indicated the transaction was not approved due to
mismatch of the CVV2 value, but it would have been approved
had the CVV2 value matched
NP Dbtsw inv merid Network Response indicates that Merchant ID/SE is invalid
NS Dbtsw Pin Xl Err The authorizing network has a problem decrypting the
cryptogram in the request
NL Dbt Switch Unavl Communications link to debit/EBT network gateway is down or
responded with a "System Malfunction (96)" message
NL DBT T.O. Retry Communications link to debit/EBT network gateway is down or
03 Declined Invalid Merchant number or Subscriber doesn't exist or is
inactive
05 Declined Declined
57 Declined Tran not allowed
63 Declined For American Express transactions if the CID from the
transaction doesn't match the one on file then decline
transaction.
Transaction not permitted to acquirer or terminal
89 Declined Term record not found on First Data system
N3 Declined Invalid Effective Date
NU Declined Insufficient funds
05 DOB Error Data of Birth Error from check processing
14 Do not try again Applies to recurring authorizations only. The account number is
invalid
51 Do not honor Declined: Association’s payment cancellation advice code
provided
Applies to recurring authorizations only
51 Do not try again Declined: Association’s payment cancellation advice code
provided
Applies to recurring authorizations only. These are examples of
what may have occurred: the account has been closed, or
fraudulent
54 Do not try again Applies to recurring authorizations only. The card has expired
63 Do not try again Applies to recurring authorizations only. There was a security
violation
94 Duplicate Tran Duplicate Transaction


Appendix A First Data ISO 8583 Global Specification

Displayed Text
NH Enter Lesser Amt Enter lesser amount
54 Expired Card Expired Card
69 Host Key Error Host Key Error
14 Inv Acct Num Account or Checking Account Number not on file
13 Inv Amt Invalid amount
51 Inv Acct Num Invalid Checking Acct Num
N3 Invld Acct2 Invalid account/date or sales date in future
55 Incorrect Pin Incorrect Pin
NJ Inv Cashback Amt Cash back amount greater than total Transaction amount (bit 4)
03 Invld Mer ID Invalid Merchant number or Subscriber doesn't exist or is
inactive
12 Inv State Code Invalid State Code for Check Processing
25 Inv Terminal Terminal Not Found
89 Invalid Term ID Invalid Term ID
12 Inv tran Invalid Transaction
NM Issuer Unav Debit/EBT network gateway cannot get through to the ISSUER
60 Hold-Call Ctr Capture Card -- Call Center
00 New Account Note applies to recurring authorizations only. These are
information available examples of what may have occurred: Card has expired,
Account was upgraded, Portfolio sale, Conversion
14 New Account Applies to recurring authorizations only. These are examples of
information available what may have occurred: Card has expired, Account was
upgraded, Portfolio sale, Conversion
51 New Account Declined: Association’s payment cancellation advice code
information available provided
what may have occurred: Card has expired, Account was
information available what may have occurred: Card has expired
NI Pin Xlate Error Host Security module could not decrypt the PIN block.
Master Session: The master key is missing or incorrect in the
PIN pad, or the merchant record is set-up incorrectly at First
Data Host.
DUKPT: The Base Derivation key is missing or incorrect in the
PIN pad, or is set-up incorrectly in the Host Security Module.
75 Pin Retry Max Allowable number of PIN tries exceeded
75 Pin Try Exceeded Allowable number of PIN tries exceeded
28 Please Retry File is temporarily unavailable
91 Please Retry Reasons for this error are one of the following:
Format Error
Unable to route transaction
Switch or issuer unavailable
System Busy
Timeout
01 Referral Referral
12 Referrral - Inv TR1 More than 76 characters in Track 1 or Track 1 not formatted
correctly
NR Resub Excds Lmt Resubmission of transaction violates debit/EBT network
frequency



Displayed Text
NG Rev Rejected Reversal Rejected; cannot parse 400 message
63 Serv Not Allowed Service Not Allowed
CE System Problem System Problem
NQ Tran Ct Excd Lmt Debit/EBT transaction count exceeds pre-determined limit in
specified time/ Withdrawal limit exceeded
57 Tran Not Allowed Transaction Not Allowed
51 Try again later Applies to recurring authorizations only. These are examples of
what may have occurred: the account is over the credit limit try
again in 72 hours
54 Try again later Applies to recurring authorizations only. The card has expired.
Get the new expiration date and try again
NN Undefined Card Debit/EBT network gateway cannot route card based on
Merchant Entitlement
*** MasterCard or Check transactions may override standard display
for responses

6.1.2. Response Codes in Sequence by Code

Response Codes in Sequence by Code
Displayed Text
00 Approval Approved for capture in batch
Information what may have occurred: Card has expired, Account was
01 Referral Referral
03 Invld Mer ID Invalid Merchant number or Subscriber doesn't exist or is
inactive
03 Declined Invalid Merchant number or Subscriber doesn't exist or is
inactive
05 DOB Error Date of Birth Error for Check Processing
10 Apprv Lesser Amt Approved for a lesser amount than what was requested (i.e.
partial approval)
12 Inv tran Invalid Transaction
12 Inv State Code Invalid State Code for Check Processing
12 Referrral-Inv TR1 More than 76 characters in Track 1 or Track 1 not formatted
correctly
13 Inv Amt Invalid amount
14 Inv Acct Num Account Number not on file or Checking Account Number
Information what may have occurred: Card has expired, Account was
14 Do not try again Applies to recurring authorizations only. The account number is
invalid.
25 Inv Terminal Terminal Not Found
28 Please Retry File is temporarily unavailable
51 Inv Acct Num Invalid Checking Acct Num
51 Do not honor Declined: Association’s payment cancellation advice code
provided
Applies to recurring authorizations only
51 Do not try again Declined: Association’s payment cancellation advice code
provided
what may have occurred: the account was closed, or fraudulent.
51 New Account Declined: Association’s payment cancellation advice code
Information available provided
what may have occurred: Card has expired, Account was
upgraded, Portfolio sale, Conversion.
51 Try again later Declined: Association’s payment cancellation advice code
provided
what may have occurred: the account is over the credit limit try
again in 72 hours.



Displayed Text
54 Do not try again Applies to recurring authorizations only. The card has expired-
54 New Account Applies to recurring authorizations only. The card has expired.
Information
54 Try again later Applies to recurring authorizations only. The card has expired.
Get the new expiration date and try again.
54 Expired Card Expired Card
55 Incorrect Pin Incorrect Pin
57 Tran Not Allowed Transaction Not Allowed
60 Hold-Call Ctr Capture Card -- Call Center
61 Amt Excceds Lmt Amount Exceeds Limit
63 Serv Not Allowed Service Not Allowed
63 Declined For American Express transactions if the CID from the
transaction doesn't match the one on file then decline
transaction.
Transaction not permitted to acquirer or terminal
63 Do not try again Applies to recurring authorizations only. There was security
violation.
69 Host Key Error Host Key Error
75 Pin Retry Max Allowable number of PIN tries exceeded
75 Pin Try Exceeded Allowable number of PIN tries exceeded
76 Approval Approved (non captured)
85 AVS Accepted AVS Request Accepted
89 Invalid Term ID Invalid Term ID
89 Declined Term record not found on First Data system
91 Please Retry Reasons for this error are one of the following:
Format Error
Unable to route transaction
Switch or issuer unavailable
System Busy
Timeout
94 Duplicate Tran Duplicate Transaction
C2 CVV2 Declined Association indicated the transaction was not approved due to
mismatch of the CVV2 value, but it would have been approved
had the CVV2 value matched.
CE System Problem System Problem
N3 Invld Acct2 Invalid account/date or sales date in future
N3 Declined Invalid Effective Date
NG Rev Rejected Reversal Rejected cannot parse 400 message
NH Enter Lesser Amt Enter lesser amount
NI Pin Xlate Error Host Security module could not decrypt the PIN block.
Master Session: The master key is missing or incorrect in the

PIN pad, or the merchant record set-up incorrectly at First Data
Host.
DUKPT: The Base Derivation key is missing or incorrect in the

PIN pad, or is set-up incorrectly in the Host Security Module.
NJ Inv Cashback Amt Cash back amount greater than total Transaction amount (bit 4)

Displayed Text
NK Crypto Box Unav Crypto box is offline
NL Dbt Switch Unavl Communications link to debit/EBT network gateway is down or
NL DBT T.O. Retry Communications link to debit/EBT network gateway is down or
NM Issuer Unav Debit/EBT network gateway cannot get through to the ISSUER.
NN Undefined Card Debit/EBT network gateway cannot route card based on
Merchant Entitlement
NP Dbtsw inv merid Network Response indicates that Merchant ID / SE is invalid.
NQ Tran Ct Excd Lmt Debit/EBT transaction count exceeds pre-determined limit in
specified time/ Withdrawal limit exceeded.
NR Resub Excds Lmt Resubmission of transaction violates debit/EBT network
frequency
NS Dbtsw Pin Xl Err The authorizing network has a problem decrypting the
cryptogram in the request
NU Declined Insufficient funds
MasterCard or Check transactions may override standard
display for responses.


6.1.3. Check Guarantee/Verification — Related Messages

Check Guarantee/Verification-Related Messages
ISO Bit 39 2- 16-character Meaning
character Code Response Text in Bit 63
00 APPROVAL Check Processor approved transaction
01 Call Center Please call Check Processor
01 CALL JBS Please call JBS/NPC
01 CALL REF nnnn Please call JBS/NPC with the info given
01 CODE n Please call Check Processor with code #
given
01 CODE n check writer’s name Please call Check Processor with info
given
01 ERROR RETRY Please call Check Processor
01 INVLD ACCT NUM Invalid account number
01 REFERRAL Please call Check Processor
03 INVLD MER ID Subscriber is not active or does not exist
12 BAD PROC CODE Bad Procedure Code
13 INV AMT Invalid Amount
14 INVLD ACCT NUM Invalid account number
51 CHECK DECLINED Check Processor declined transaction
51 DECLINE xxxxxx Check Processor declined transaction for
account holder named xxxxxx
91 PLEASE RETRY Request was not completely processed-
Please try again
94 DUPLICATE TRAN Duplicate Transaction
VC VELOCITY ERROR Number of checks or monetary amount
exceeds limit
VB VELOCITY ERROR CALL Velocity error – please call the Check
Processor
VA DUPLICATE AUTH Duplicate Authorization

6.1.4. Debit/EBT Card — Related Messages

Debit/EBT Card-Related Messages
ISO Bit 39 16-character Response Meaning
Text in Bit 63
2 Character Code
12 INV TRAN Invalid transaction
13 INV AMT Invalid amount
14 INV ACCT Invalid card number
51 DECLINE Decline the transaction
55 INCORRECT PIN Incorrect PIN
57 TRAN NOT ALLOWED Transaction not allowed
61 AMT EXCEEDED LIMIT Amount exceeded limit
75 PIN RETRY EXCEEDED (maximum 3 times)
91 DBT T.O. RETRY Request was switched but no reply from
debit/EBT network gateway within the time
out period
91 PLEASE RETRY Generic system error – Please try again
94 DUPLICATE TRAN Duplicate System Trace/Receipt number
NG REV REJECTED Cannot parse 0400 message
NH ENTER LESSER AMOUNT
NI PIN XLATE ERROR Host Security Module could not decrypt the
PIN block.
Master Session: Either the master key is

missing or incorrect in the PIN pad, or the
merchant record is set up incorrectly at the
First Data Host.
DUKPT: Either the Base Derivation key is

missing or incorrect in the PIN pad, or the
Base Derivation Key is set up incorrectly at
the Host Security Module.
NJ INV CASHBACK AMT Cashback Amt greater than total in bit 4
NK CRYPTO BOX UNAV CRYPTO Box is off-line
NL DBT SWITCH UNAVL Communications link to debit/EBT network
gateway is down or responded with a
"System Malfunction (96)" message
NM ISSUER UNAV Debit/EBT network gateway cannot get
through to the ISSUER
NN UNDEFINED CARD Debit/EBT network gateway cannot route
card based on Merchant Entitlement
NP DBTSW INV MERID EDS response indicates that Merchant ID /
SE is invalid
NQ TRAN CT EXCD LMT Debit/EBT transaction count exceeds pre-
determined limit in specified time /
Withdrawal limit exceeded
NQ TRAN CT EXCD LMT Debit/EBT transaction count exceeds pre-
determined limit in specified time /
Withdrawal limit exceeded


Debit/EBT Card-Related Messages

ISO Bit 39 16-character Response Meaning
Text in Bit 63
2 Character Code
NR RESUB EXCDS LMT Resubmission of transaction violates
debit/EBT network frequency
NS DBTSW PIN XL ERR The authorizing network has a problem
decrypting the cryptogram in the request.
NU DECLINE Insufficient funds
69 HOST KEY ERROR The Host Security Module could not decrypt
the PIN block because of system error.
Master/Session: N/A
DUKPT: An error while processing the PIN

block that is not related to the point- of-sale
equipment. Contact the Help Desk for
assistance.

First Data ISO 8583 Global Specification Appendix B
6.2. Appendix B — State Codes

State Code Country Code
UNKNOWN 00 MISSOURI 29
ALABAMA 01 MONTANA 30
ALASKA 02 NEBRASKA 31
ARIZONA 04 NEVADA 32
ARKANSAS 05 NEW HAMPSHIRE 33
CALIFORNIA 06 NEW JERSEY 34
COLORADO 08 NEW MEXICO 35
CONNECTICUT 09 NEW YORK 36
DELAWARE 10 NORTH CAROLINA 37
DISTRICT OF COLUMBIA 11 NORTH DAKOTA 38
FLORIDA 12 OHIO 39
GEORGIA 13 OKLAHOMA 40
HAWAII 15 OREGON 41
IDAHO 16 PENNSYLVANIA 42
ILLINOIS 17 RHODE ISLAND 44
INDIANA 18 SOUTH CAROLINA 45
IOWA 19 SOUTH DAKOTA 46
KANSAS 20 TENNESSEE 47
KENTUCKY 21 TEXAS 48
LOUISIANA 22 UTAH 49
MAINE 23 VERMONT 50
MARYLAND 24 VIRGINIA 51
MASSACHUSETTS 25 WASHINGTON 53
MICHIGAN 26 WEST VIRGINIA 54
MINNESOTA 27 WISCONSIN 55
MISSISSIPPI 28 WYOMING 56


First Data ISO 8583 Global Specification Appendix C
6.3. Appendix C — Country Codes
Country Alpha Numeric Country Alpha Numeric

codes Code codes Code
AFGHANISTAN AF 004 BRITISH INDIAN IO 086
OCEAN
ALBANIA AL 008 TERRITORY
ALGERIA DZ 012 BRUNEI BN 096
DARUSSALAM
AMERICAN AS 016 BULGARIA BG 100
SAMOA
ANDORRA AD 020 BURKINA FASO BF 854
ANGOLA AO 024 BURUNDI BI 108
ANGUILLA AI 660 CAMBODIA KH 116
ANTARCTICA AQ 010 CAMEROON CM 120
ANTIGUA and AG 028 CANADA CA 124
BARBUDA
CAPE VERDE CV 132
ARGENTINA AR 032
CAYMAN ISLANDS KY 136
ARMENIA AM 051
CENTRAL CF 140
ARUBA AW 533
AFRICAN
AUSTRALIA AU 036 REPUBLIC
CHAD TD 148
AUSTRIA AT 040
CHILE CL 152
AZERBAIJAN AZ 031
CHINA CN 156
BAHAMAS BS 044
CHRISTMAS CX 162
BAHRAIN BH 048 ISLAND
COCOS (KEELING) CC 166
BANGLADESH BD 050
ISLANDS
BARBADOS BB 052 COLOMBIA CO 170
BELARUS BY 112 COMOROS KM 174
BELGIUM BE 056
CONGO CG 178
BELIZE BZ 084
COOK ISLANDS CK 184
BENIN BJ 204
COSTA RICA CR 188
BERMUDA BM 060
COTE D’IVOIRE CI 384
BHUTAN BT 064
CROATIA HR 191
BOLIVIA BO 068
CYPRUS CY 196
BOSNIA and BA 070
CZECH REPUBLIC CZ 203
HERZEGOVINA
BOTSWANA BW 072 DEMOCRATIC CD 180
REPUBLIC OF
BOUVET ISLAND BV 074
CONGO
BRAZIL BR 076 DENMARK DK 208



DJIBOUTI DJ 262 GUATEMALA GT 320
DOMINICA DM 212 GUINEA GN 324
DOMINICAN DO 214 GUINEA-BISSAU GW 624
REPUBLIC
GUYANA GY 328
EAST TIMOR TP 626
HAITI HT 332
ECUADOR EC 218
HEARD and HM 334
EGYPT EG 818
MCDONALD
EL SALVADOR SV 222 ISLANDS
HONDURAS HN 340
EQUATORIAL GQ 226
GUINEA HONG KONG HK 344
ERITREA ER 232
HUNGARY HU 348
ESTONIA EE 233
ICELAND IS 352
ETHIOPIA ET 230
INDIA IN 356
FALKLAND FK 238
INDONESIA ID 360
ISLANDS
(MALVINAS) IRAQ IQ 368
FAEROE ISLANDS FO 234
IRELAND IE 372
FIJI FJ 242
ISRAEL IL 376
FINLAND FI 246
ITALY IT 380
FRANCE FR 250
JAMAICA JM 388
FRENCH GUIANA GF 254
JAPAN JP 392
FRENCH PF 258
POLYNESIA JOHNSTON JT 396
ISLAND
FRENCH TF 260
SOUTHERN JORDAN JO 400
TERRITORIES KAZAKHSTAN KZ 398
GABON GA 266
KENYA KE 404
GAMBIA GM 270
KIRIBATI KI 296
GEORGIA GE 268
KOREA, DEM. KP 408
GERMANY, DE 280 PEOPLES'
REPUBLIC OF REPUBLIC OF
GHANA GH 288 KOREA, REPUBLIC KR 410
of
GIBRALTAR GI 292
KOSOVO, UNITED QZ 900
GREECE GR 300 NATIONS MISSION
IN KOSOVO
GREENLAND GL 304
(UNMIK)
GRENADA GD 308 KUWAIT KW 414
GUADELOUPE GP 312 KYRGYZSTAN KG 417
GUAM GU 316


Appendix C First Data ISO 8583 Global Specification

LAO PEOPLE'S LA 418 MOZAMBIQUE MZ 508
DEMOCRATIC
NAMIBIA NA 516
REPUBLIC
LATVIA LV 428 NAURU NR 520
LEBANON LB 422 NEPAL NP 524
LESOTHO LS 426 NETHERLANDS NL 528
LIBERIA LR 430 NETHERLANDS AN 530
ANTILLES
LIBYAN ARAB LY 434
JAMAHIRIYA NEW CALEDONIA NC 540
LIECHTENSTEIN LI 438 NEW ZEALAND NZ 554
LITHUANIA LT 440 NICARAGUA NI 558
LUXEMBOURG LU 442 NIGER NE 562
MACAU MO 446 NIGERIA NG 566
MACEDONIA MK 807 NIUE NU 570
MADAGASCAR MG 450 NORFOLK ISLAND NF 574
MALAWI MW 454 NORTHERN MP 580
MARIANA
MALAYSIA MY 458
ISLANDS
MALDIVES MV 462 NORWAY NO 578
MALI ML 466 OMAN OM 512
MALTA MT 470 PAKISTAN PK 586
MARSHALL MH 584 PALAU PW 585
ISLANDS
PALESTINE PS 275
MARTINIQUE MQ 474
PANAMA PA 591
MAURITANIA MR 478
PAPUA NEW PG 598
MAURITIUS MU 480
GUINEA
MEXICO MX 484 PARAGUAY PY 600
MICRONESIA FM 583 PERU PE 604
MIDWAY ISLANDS MI 488 PHILIPPINES PH 608
MOLDOVA, MD 498 PITCAIRN PN 612
REPUBLIC OF
POLAND PL 616
MONACO MC 492
PORTUGAL PT 620
MONGOLIA MN 496
PUERTO RICO PR 630
MONTENEGRO, ME 499
REPUBLIC OF QATAR QA 634
MONTSERRAT MS 500
REUNION RE 638
MOROCCO MA 504


ROMANIA RO 642 TAJIKISTAN TJ 762
RUSSIAN RU 643 TANZANIA, TZ 834
FEDERATION UNITED REPUBLIC
RWANDA RW 646 OF
THAILAND TH 764
SAMOA WS 882
TOGO TG 768
SAN MARINO SM 674
TOKELAU TK 772
SAO TOME and ST 678
PRINCIPE TONGA TO 776
SAUDI ARABIA SA 682
TRINIDAD and TT 780
SENEGAL SN 686 TOBAGO
TUNISIA TN 788
SERBIA, RS 688
REPUBLIC OF TURKEY TR 792
SEYCHELLES SC 690
TURKMENISTAN TM 795
SIERRA LEONE SL 694
TURKS and TC 796
SINGAPORE SG 702 CAICOS ISLANDS
TUVALU TV 798
SLOVAKIA SK 703
US MINOR UM 581
SLOVENIA SI 705
OUTLYING
SOLOMON SB 090 ISLANDS
ISLANDS UGANDA UG 800
SOMALIA SO 706
UKRAINE UA 804
SOUTH AFRICA ZA 710
UNITED ARAB AE 784
SPAIN ES 724 EMIRATES
UNITED KINGDOM GB 826
SRI LANKA LK 144
UNITED STATES US 840
ST. HELENA SH 654
URUGUAY UY 858
ST. KITTS-NEVIS KN 659
UZBEKISTAN UZ 860
ST. LUCIA LC 662
VANUATU VU 548
ST. PIERRE and PM 666
MIQUELON HOLY SEE VA 336
ST. VINCENT and VC 670 (VATICAN CITY
the GRENADINES STATE)
SURINAME SR 740 VENEZUELA VE 862
SVALBARD and SJ 744 VIET NAM VN 704
JAN MAYEN VIRGIN ISLANDS, VG 092
SWAZILAND SZ 748 BRITISH
SWEDEN SE 752 VIRGIN ISLANDS, VI 850
US
SWITZERLAND CH 756 WAKE ISLAND WK 872
SYRIAN ARAB SY 760 WALLIS AND WF 876
REPUBLIC FUTUNA
TAIWAN TW 158


Appendix C First Data ISO 8583 Global Specification
Country Alpha Numeric

codes Code
WESTERN EH 732
SAHARA
YEMEN YE 886
ZAMBIA ZM 894
ZIMBABWE ZW 716

First Data ISO 8583 Global Specification Appendix D
6.4. Appendix D — Currency Codes

6.4.1. Currency Name Order
Country Name(s) Decimal Code Currency Name

Places
AFGHANISTAN 2 971 NEW AFGHANI
ALBANIA 2 008 LEK
ALGERIA 2 012 ALGERIAN DINAR
AMERICAN SAMOA 2 840 US DOLLAR
ANDORRA 2 978 EURO
ANGOLA 2 024 NEW KWANZA
ANGUILLA 2 951 EAST CARRIBEAN DOLLAR
ANTARCTICA 2 578 NORWEGIAN KRONE
ANTIGUA AND BARBUDA 2 951 EAST CARRIBEAN DOLLAR
ARGENTINA 2 032 ARGENTINE PESO
ARMENIA 2 643 NEW RUBLE
ARUBA 2 533 GUILDER
AUSTRALIA 2 036 AUSTRALIAN DOLLAR
AUSTRIA 2 978 EURO
AZERBAIJAN 2 944 AZERBAIJANIAN MANAT
BAHAMAS 2 044 BAHAMIAN DOLLAR
BAHRAIN 3 048 BAHRAINI DINAR
BANGLADESH 2 050 TAKA
BARBADOS 2 052 BARBADOS DOLLAR
BELARUS 2 643 NEW RUBLE
BELGIUM 2 978 EURO
BELIZE 2 084 BELIZE DOLLAR
BENIN 0 952 CFA FRANC BCEAO2
BERMUDA 2 060 BERMUDIAN DOLLAR
BHUTAN 2 356 INDIAN RUPEE
BOLIVIA 2 068 BOLIVIANO
BOSNIA and HERZEGOVINA 2 977 CONVERTIBLE MARK
BOTSWANA 2 072 PULA
BOUVET ISLAND 2 578 NORWEGIAN KRONE
BRAZIL 2 986 BRAZILIAN REAL
BRITISH INDIAN OCEAN TERRITORY 2 840 US DOLLAR
BRUNEI DARUSSALAM 2 096 BRUNEI DOLLAR
BULGARIA 2 975 LEV
BURKINA FASO 0 952 CFA FRANC BCEAO2
BURUNDI 2 108 BURUNDI FRANC
CAMBODIA 2 116 RIEL
CAMEROON 0 950 CFA FRANC BEAC3
CANADA 2 124 CANADIAN DOLLAR
CAPE VERDE 2 132 CAPE VERDE ESCUDO
CAYMAN ISLANDS 2 136 CAYMAN ISLANDS DOLLAR
CENTRAL AFRICAN REPUBLIC 0 950 CFA FRANC BEAC3
CHAD 0 950 CFA FRANC BEAC3
CHILE 2 152 CHILEAN PESO



Places
CHINA 2 156 CHINESE RENMINBI
CHRISTMAS ISLAND 2 036 AUSTRALIAN DOLLAR
COCOS (KEELING) ISLANDS 2 036 AUSTRALIAN DOLLAR
COLOMBIA 2 170 COLOMBIAN PESO
COMOROS 0 174 COMORO FRANC
CONGO 0 950 CFA FRANC BEAC3
COOK ISLANDS 2 554 NEW ZEALAND DOLLAR
COSTA RICA 2 188 COSTA RICAN COLON
COTE D’IVOIRE 0 952 CFA FRANC BCEAO2
CROATIA 2 191 KUNA
CYPRUS 2 978 EURO
CZECH REPUBLIC 2 203 KORUNA
DEMOCRATIC REPUBLIC OF THE 2 976 CONGO FRANC
CONGO
DENMARK 2 208 DANISH KRONE
DJIBOUTI 0 262 DJIBOUTI FRANC
DOMINICA 2 951 EAST CARRIBEAN DOLLAR
DOMINICAN REPUBLIC 2 214 DOMINICAN PESO
EAST TIMOR 0 360 RUPIAH
ECUADOR 2 218 SUCRE
840 UNITED STATES DOLLAR
EGYPT 2 818 EGYPTIAN POUND
EL SALVADOR 2 222 EL SALVADOR COLON
EQUATORIAL GUINEA 0 950 CFA FRANC BEAC3
ERITREA 2 232 Eritean Nakfa
ESTONIA 2 233 KROON
ETHIOPIA 2 230 ETHIOPIAN BIRR
EUROPEAN UNION COUNTRIES 2 978 EURO
FALKLAND ISLANDS (MALVINAS) 2 238 FALKLAND ISLANDS POUND
FAROE ISLANDS 2 208 DANISH KRONE
FIJI 2 242 FIJI DOLLAR
FINLAND 2 978 EURO
FRANCE 2 978 EURO
FRENCH GUIANA 2 978 EURO
FRENCH POLYNESIA 0 953 C.F.A. FRANC
FRENCH SOUTHERN TERRITORIES 2 978 EURO
GABON 0 950 CFA FRANC BEAC3
GAMBIA 2 270 DALASI
GEORGIA 2 981 LARI
GERMANY, REPUBLIC OF 0 978 EURO
GHANA 2 936 CEDI
GIBRALTAR 2 292 GIBRALTAR POUND
GREECE 2 978 EURO
GREENLAND 2 208 DANISH KRONE
GRENADA 2 951 EAST CARRIBEAN DOLLAR
GUADELOUPE 2 978 EURO
GUAM 2 840 US DOLLAR
GUATEMALA 2 320 QUETZAL
GUINEA 0 324 GUINEA FRANC
Appendix D First Data ISO 8583 Global Specification

Places
GUINEA-BISSAU 2 624 GUINEA-BISSAU PESO
GUYANA 2 328 GUYANA DOLLAR
HAITI 2 332 GOURDE
HEARD and MCDONALD ISLANDS 2 036 AUSTRALIAN DOLLAR
HONDURUS 2 340 LEMPIRA
HONG KONG 2 344 HONG KONG DOLLAR
HUNGARY 2 348 FORINT
ICELAND 2 352 ICELAND KRONA
INDIA 2 356 INDIAN RUPEE
INDONESIA 0 360 RUPIAH
IRAQ 3 368 IRAQI DINAR
IRELAND 2 978 EURO
ISRAEL 2 376 ISRAELI SHEKEL
ITALY 2 978 EURO
JAMAICA 2 388 JAMAICAN DOLLAR
JAPAN 0 392 YEN
JOHNSTON ISLAND 2 840 US DOLLAR
JORDAN 3 400 JORDANIAN DINAR
KAZAKHSTAN 2 643 NEW RUBLE
KENYA 2 404 KENYAN SHILLING
KIRIBATI 2 036 AUSTRALIAN DOLLAR
KOREA, DEMOCRATIC PEOPLES' 2 408 NORTH KOREAN WON
REP. OF
KOREA, REPUBLIC OF 0 410 WON
KOSOVO, UNITED NATIONS MISSION 2 978 EURO
IN KOSOVO (UNMIK)
KUWAIT 3 414 KUWAITI DINAR
KYRGYZSTAN 2 643 NEW RUBLE
LAO PEOPLE'S DEMOCRATIC 2 418 KIP
REPUBLIC
LATVIA 2 428 LATVIAN LATS
LEBANON 2 422 LEBANESE POUND
LESOTHO 2 426 MALOTI
LIBERIA 2 430 LIBERIAN DOLLAR
LIBYAN ARAB JAMAHIRIYA 2 840 US DOLLAR
LIECHTENSTEIN 2 756 SWISS FRANC
LITHUANIA 2 440 LITHUANIAN LITAS
LUXEMBOURG 2 978 EURO
MACAU 2 446 PATACA
MACEDONIA 2 807 DENAR
MADAGASCAR 2 969 MALAGASY ARIARY
MALAWI 2 454 KWACHA
MALAYSIA 2 458 MALAYSIAN RINGGIT
MALDIVES 2 462 RUFIYAA
MALI 0 952 CFA FRANC BCEAO2
MALTA 2 978 EURO
MARSHALL ISLANDS 2 840 US DOLLAR
MARTINIQUE 2 978 EURO
MAURITANIA 2 478 OUGUIYA
MAURITIUS 2 480 MAURITIUS RUPEE



Places
MEXICO 2 484 MEXICAN PESO
MICRONESIA 2 840 US DOLLAR
MIDWAY ISLANDS 2 480 MAURITIUS RUPEE
MOLDOVA, REPUBLIC OF 2 643 NEW RUBLE
MONACO 2 978 EURO
MONGOLIA 2 496 TUGRIK
MONTENEGRO, REPUBLIC OF 2 978 EURO
MONTSERRAT 2 951 EAST CARRIBEAN DOLLAR
MOROCCO 2 504 MOROCCAN DIRHAM
MOZAMBIQUE 2 943 MOZAMBICAN METICAL
NAMIBIA 2 710 RAND
NAURU 2 036 AUSTRALIAN DOLLAR
NEPAL 2 524 NEPALESE RUPEE
NETHERLANDS 2 978 EURO
NETHERLANDS ANTILLES 2 532 NETHERLANDS ANTILLIAN
GUILDER
NEW CALEDONIA 0 953 C.F.A. FRANC
NEW ZEALAND 2 554 NEW ZEALAND DOLLAR
NICARAGUA 2 558 CORDOBA ORO
NIGER 0 952 CFA FRANC BCEAO2
NIGERIA 2 566 NAIRA
NIUE 2 554 NEW ZEALAND DOLLAR
NORFOLK ISLAND 2 036 AUSTRALIAN DOLLAR
NORTHERN MARIANA ISLANDS 2 840 US DOLLAR
NORWAY 2 578 NORWEGIAN KRONE
OMAN 3 512 RIAL OMANI
PAKISTAN 2 586 PAKISTAN RUPEE
PALAU 2 840 US DOLLAR
PALESTINE 2 840 US DOLLAR

PANAMA 2 590 BALBOA
PAPUA NEW GUINEA 2 598 KINA
PARAGUAY 0 600 GUARANI
PERU 2 604 NUEVO SOL
PHILIPPINES 2 608 PHILIPPINE PESO
PITCAIRN 2 554 NEW ZEALAND DOLLAR
POLAND 2 985 ZLOTY
PORTUGAL 2 978 EURO
PUERTO RICO 2 840 US DOLLAR
QATAR 2 634 QATARI RIAL
REUNION 2 978 EURO
ROMANIA 2 946 ROMANIAN LEU
RUSSIAN FEDERATION 2 643 RUSSIAN RUBLE
RWANDA 0 646 RWANDA FRANC
SAMOA 2 882 TALA
SAN MARINO 2 978 EURO
SAO TOME AND PRINCIPE 2 678 DOBRA
SAUDI ARABIA 2 682 SAUDI RIYAL

Appendix D First Data ISO 8583 Global Specification

Places
SENEGAL 0 952 CFA FRANC BCEAO2
SERBIA, REPUBLIC OF 2 941 SERBIAN DINAR
SEYCHELLES 2 690 SEYCHELLES RUPEE
SIERRA LEONE 2 694 LEONE
SINGAPORE 2 702 SINGAPORE DOLLAR
SLOVAKIA 2 703 SLOVAK KORUNA
SLOVENIA 2 978 EURO
SOLOMON ISLANDS 2 090 SOLOMON ISLANDS DOLLAR
SOMALIA 2 706 SOMALI SHILLING
SOUTH AFRICA 2 710 RAND
SPAIN 2 978 EURO
SRI LANKA 2 144 SRI LANKA RUPEE
ST. HELENA 2 654 ST. HELENA POUND
ST. KITTS-NEVIS 2 951 EAST CARRIBEAN DOLLAR
ST. LUCIA 2 951 EAST CARRIBEAN DOLLAR
ST. PIERRE and MIQUELON 2 978 EURO
ST. VINCENT AND THE GRENADINES 2 951 EAST CARRIBEAN DOLLAR
SURINAME 2 968 SURINAME DOLLAR
SVALBARD and JAN MAYEN 2 578 NORWEGIAN KRONE
SWAZILAND 2 748 LILANGENI
SWEDEN 2 752 SWEDISH KRONA
SWITZERLAND 2 756 SWISS FRANC
SYRIAN ARAB REPUBLIC 2 760 SYRIAN POUND
TAIWAN 2 901 NEW TAIWAN DOLLAR
TAJIKISTAN 2 972 TAJIKISTAN SOMONI
TANZANIA, UNITED REPUBLIC OF 2 834 TANZANIAN SHILLING
THAILAND 2 764 BAHT
TOGO 0 952 CFA FRANC BCEAO2
TOKELAU 2 554 NEW ZEALAND DOLLAR
TONGA 2 776 PA'ANGA
TRINIDAD AND TOBAGO 2 780 TRINIDAD AND TOBAGO
DOLLAR
TUNISIA 3 788 TUNISIAN DINAR
TURKEY 2 949 NEW TURKISH LIRA
TURKMENISTAN 2 643 RUSSIAN RUBLE
TURKS and CAICOS ISLANDS 2 840 US DOLLAR
TUVALU 2 036 AUSTRALIAN DOLLAR
US MINOR OUTLYING ISLANDS 2 840 US DOLLAR
UGANDA 2 800 UGANDAN SHILLING
UKRAINE 2 980 HRYVNIA
UNITED ARAB EMIRATES 2 784 UAE DIRHAM
UNITED KINGDOM 2 826 POUND STERLING
UNITED STATES 2 840 US DOLLAR
URUGUAY 2 858 PESO URUGUAYO
UZBEKISTAN 2 643 NEW RUBLE
VANUATU 0 548 VATU
HOLY SEE (VATICAN CITY STATE) 2 978 EURO
VENEZUELA 2 937 BOLIVAR FUERTE
VIET NAM 2 704 DONG
VIRGIN ISLANDS, BRITISH 2 840 US DOLLAR



Places
VIRGIN ISLANDS, US 2 840 US DOLLAR
WAKE ISLAND 2 840 US DOLLAR
WALLIS AND FUTUNA 0 953 C.F.A. FRANC
WESTERN SAHARA 2 504 MOROCCAN DIRHAM
YEMEN 2 886 YEMENI RIAL
ZAMBIA 2 894 KWACHA
ZIMBABWE 2 716 ZIMBABWE DOLLAR
2 CFA Franc BCEAO; Responsible authority:Banque Centrale des Etats de l’Afrique de l’Quest
3 CFA Franc BEAC; Responsible authority:Banque des Etats de l’Afrique Centrale

First Data ISO 8583 Global Specification Appendix E
6.5. Appendix E — Check Digit Logic/Card Type ID + 6.51 Card Type identification
The client should perform the Double-Add-Double MOD 10 Check Digit Routine for all credit card, off-line debit, and T and E cardholder account
numbers presented to First Data. This will reduce rejections for invalid cardholder account numbers caused by keying errors. This routine should
not be performed for on-line debit cards or EBT cards.
Cardholder account numbers are issued in various lengths but the same check-digit logic applies to all lengths and all issuers (Bankcard and T
and E). When the cardholder account number is less than 16 digits, right-justify and zero-fill and apply the same check-digit logic.
16-DIGIT ACCOUNT NUMBER

Account 4 1 2 3 6 5 1 4 7 9 1 1 6 5 4 7
Number
Weight 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
8+ 1+ 4+ 3+ 1+2+ 5+ 2+ 4+ 1+4+ 9+ 2+ 1+ 1+2+ 5+ 8+ 7= 70

70 divided by 10 = 7, remainder zero
The account number is valid because remainder is zero.
15-DIGIT ACCOUNT NUMBER

Account 0 3 7 1 4 4 9 6 3 5 3 9 8 4 3 1
Number
Weight 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
0+ 3+ 1+4 1+ 8+ 4+ 1+8 6+ 6+ 5+ 6+ 9+ 1+6+ 4+ 6+ 1= 80
80 divided by 10 = 8, remainder zero

The account number is valid because remainder is zero.


Appendix E First Data ISO 8583 Global Specification
INVALID 16-DIGIT ACCOUNT NUMBER
Account 4 1 2 3 6 5 1 4 7 9 1 1 6 5 4 8
Number
Weight 2 1 2 1 2 1 2 1 2 1 2 1 2 1 2 1
8+ 1+ 4+ 3+ 1+2+ 5+ 2+ 4+ 1+4+ 9+ 2+ 1+ 1+2+ 5+ 8+ 8= 71

71 divided by 10 = 7.1, remainder is not zero.
The account number is not valid because remainder is not zero.

First Data ISO 8583 Global Specification Appendix E
6.5.1. Card Type Identification (BIN Ranges)

The standards organizations, which determine and publish the account numbering schemes, assign
ranges of numbers to various card issuers to facilitate the identification of the type of card represented by
any given card account number. In addition, the issuers themselves follow certain conventions that allow
for further edit checks on the validity of a number.
Listed below is an overview of the rules (current as this document is being published) for validating cards
generally supported within the First Data system. Please check with a Client Certification and
Implementation (CC&I) Group representative / Certification Analyst for additional details.
For a fuller description please refer to the ‘BIN Range Reference Document’, located on the First data
specification website (www.fdms.com/specs).
Card Type Length When in Card Begins With

production
Visa 16 Now 4
MasterCard 16 Now 5
14 Now 36** (Effective November 8, 2004, MasterCard will
begin processing the Diners Club International
cards with a 14 digit account number beginning
with a BIN prefix of ‘36’ as a MasterCard
International transaction for U.S. and Canadian
merchant locations.)
AMERICAN 15 Now 37, 34
EXPRESS
DINERS CLUB 14 Now 36, 38
Diners Club International cards issued in
the United States and Canada with a BIN

prefix of ‘38’ has been reissued and
processed as co-branded MasterCard
cards with a 16-digit MasterCard account
number in the range of 510000-559999.
Discover 16 see Bin range 6011
reference For specific Bins in the 6011 range,
document
refer to section 2 of the BIN Range
Reference Document**
Start End
62212600 62292599
64400000 64999999
65000000 65999999
JCB 16 Now 352800-358999


First Data ISO 8583 Global Specification Appendix F
6.6. Appendix F — Magnetic Stripe Standards

Card Data Format
Recording Density (Bits Character Configuration (Including Information
Per Inch) Parity Bit) Content
Track 1 210 bpi 7 bits per character 79 alphanumeric
characters
Track 2 75 bpi 5 bits per character 40 numeric
characters
Track 1
SS F Pan FS Name FS Additional Data ES LRC
C
Primary Account Name Expiration Date 4
Number (26 Restriction or Type

alphanumeri 3
(19 digits max.) c characters
max.) Offset or PVN
5
Discretionary Data
TRACK 2
SS FC Pan FS Additional Data ES LRC
Primary Account Expiration Date 4
Number Restriction or Type 3
(19 digits max.) Offset or PVN 5
Discretionary Data
3. This field may contain embedded spaces that are not counted as part of the 19 account number
digits.
4. TRACK-2 may never contain spaces.
Notes
Notes Track 1 Track 2
Size limitations (including Start Sentinel, End 79 Characters 40 Characters
Sentinel and LRC)
Control Characters: EBCDIC EBCDIC HEX
SS (Start Sentinel) % ; B
FS (Field Separator) ^ = D
ES ( End Sentinel) ? ? F
FC (Format Code)
LRC (Longitudinal Redundancy Check)


Appendix G First Data ISO 8583 Global Specification
6.7. Appendix G — Glossary

Appendix G-Glossary
Term Definition
Acquiring Bank A bank that maintains the merchant relationship and receives all transactions.
Activation Notification to an issuer that a prepaid card has been purchased and should
be activated for cardholder usage.
ASCII Standard digital code used extensively in microcomputers, minicomputers and
communications; ASCII is a 7-bit code allowing 128 possible character
combinations. ASCII is often stored in bytes, where the 8th bit may be used as
the parity bit. ASCII stands for American Standard Code for Information
Interchange.
Asynchronous A character at a time; asynchronous communications is the transmission and
Communication recognition of a single character at a time and is also called “Start/Stop
Transmission.” Contrast with synchronous transmission, where characters are
transmitted in groups.
Attenuation Deterioration of signals as they pass through a transmission medium;
generally, attenuation increases (signal level decreases) with both frequency
and cable length. Measured in terms of levels or decibels.
Authorization Code Alphanumeric value assigned by the bank to a merchant sale or cash advance
that has received specific approval. The code is used as proof that the
transaction has been properly approved.
Auto-Substantiation The process of verifying that purchase transactions are for expenses
permitted and eligible under Internal Revenue Service regulations for Flexible
Spending Accounts (FSAs) and Healthcare Reimbursement Arrangements
(HRAs).
Available Credit The difference between the credit limit assigned to a cardholder account and
the present balance (including authorization outstanding) on that account.
Synonymous with open-to-buy.
Bank Card A group of institutions formed for the purpose of sponsoring a bank card
Association program and/or using a common processing and administrative center.
BankNET Date Identifies the date, in MMDD format, the authorization record was captured by
the MasterCard's telecommunications network.
BankNET Unique data element, assigned by MasterCard, which identifies an
Reference Number authorization transaction.
BIN - Bank A number assigned to banks and other financial institutions that are VISA
Identification members; it identifies them and distinguishes their card issuing and acquiring
Number programs. A BIN may also be assigned to non-member processors for
identification purposes.
BISYNC Binary Synchronous - Category of synchronous communications protocols.
Cardholder A person to whom a card has been issued or a person authorized to use such
a card by the person to whom it was issued.
Cardholder Bank The bank that has issued a bank card to an individual. The term is frequently
used in conjunction with interchange arrangements to identify the card-issuing
bank.
Cardholder Account Actual Cardholder Account Number or Checking Account Number (encoded
on bottom of check) for Check Verification / Guarantee request.
Cardholder Street At least twenty characters of the cardholder's billing address that was used in
Address the Address Verification request. The merchant must convert spelled numbers
to numeric values (e.g., Fourth Street becomes 4TH Street prior to sending
the address verification request).

First Data ISO 8583 Global Specification Appendix G
Appendix G-Glossary
Term Definition
Cardholder Five or nine digit zip code of the cardholder's billing address that was used in
Zip/Postal Code the Address Verification request. When the cardholder is from out of the U.S.,
this field contains any alphanumeric postal code.
Card Code Value A code used to indicate the presence of a Card Verification Value (Visa), a
Presence Indicator Card Validation Code (MasterCard), a Card Identifier (Discover), and another
identically named Card Identifier (American Express) printed on the front or
back of a credit card; used to reduce fraud losses.
Card Code A Card Verification Value (Visa), Card Validation Code (MasterCard), Card
Response Value Identifier (Discover), and another identically named Card Identifier (American
Express) returned on the Authorization Response Message in response to the
Card Code Value information entered on the request. For example, the Card
Code Response Value “M” indicates that there is a Card Code Value Match,
whereas the Card Code Response Value “U” indicates that the Card Code
Value is unknown or that the Issuer does not participate.
Card Code Value A 3- or 4-digit Card Value printed on the back of a credit card.
Cash Advance A transaction in which a cardholder obtains cash in person at a branch of a
member financial institution and which is posted against the cardholder's bank
card account.
Charge-Back A transaction that is challenged by a cardholder or merchant bank and sent
back through interchange to the bank of account (cardholder or merchant) for
resolution.
Check Digit The last digit of an account number that is calculated according to a
predetermined formula and used to validate an account number.
"Code 10" A merchant's or member's request for a "code 10" authorization is the
Authorization merchant's or member's means of alerting its Authorizing Member that a
suspicious transaction is occurring.
Common Carrier Government regulated organization that provides telecommunications services
for public use such as ATandT, GTandE, ITT, MCI, SBS and Western Union.
Conditioning The "tuning" or addition of equipment to improve the transmission
characteristics or quality of a leased voice-grade line so that it meets
specifications for data transmission.
County Code Three digit number identifying the U.S. county (as defined in FIPS Pub. 6.3,
1979) where the transaction occurred. (FIPS stands for the Federal
Information Processing Standards Publication-Counties and County
Equivalents of the States of the United States.) This optional field may be zero
filled.
Credit Card A plastic card used to purchase goods and services and to obtain cash
advances on credit for which the cardholder is subsequently billed by the
issuing member for repayment of credit extended.
Credit Line The monetary amount of credit extended to a cardholder.
DBA (Doing Refers to the specific name and location of the merchant's store where a bank
business as) card purchase is made.
Decline A response to a request for authorization in which approval is refused. A
merchant receiving a decline should not complete the transaction.
Debit Function Indicates the specific purpose of the message within its message class.
Code
Debit Network The code that specifies the actual result provided by the debit network in
Response Code response to the request message.
Debit Network A 6-digit value identifying the specific debit network providing the response to
Appendix G-Glossary
Term Definition
Routing ID the request message.
Debt Indicator Identifies the transaction as payment of an existing debt obligation, such as a
car loan payment.
Deferred Billing Identifies transactions where the merchandise billing occurred after the
Indicator merchandise was delivered to the cardholder. Available for Visa only.
Derived Unique Key Allows the encryption of a PIN via the use of a unique key for each
Per Transaction transaction.
Discretionary Data Any valid information that the issuer uses for “on-us” transactions and wishes
to have transmitted through the authorization process for inquiries on
interchange transactions.
Driver's License Driver's license number of consumer, for Check Verification / Guarantee
Number requests. When requesting verification with Driver's License Number, you
must use the State Code field to indicate the state in which the driver's license
was issued.
Duration Duration field is the anticipated length of the hotel stay or auto rental and is
required in hotel and auto rental custom payment service transactions.
DUKPT see “Derived Unique Key Per Transaction.”
EBCDIC Extended Binary Coded Decimal Interchange Code-Standard digital code
used extensively in mainframes; EBCDIC is a code allowing 256 possible
character combinations.
EBT Electronic Benefits Transfer – A payment card used at the point of sale to
access a government account for Food Stamps or Cash Benefits.
Echo The return of transmitted data.
Expiration Date The date embossed on the card beyond which the card must not be honored.
Month and Year that the cardholder's account expires. If unknown, zero fill.
End Sentinel The character that follows the final character of data recorded on the track of
the card's magnetic stripe.
Financial Institution Any commercial bank, federal or state savings and loan association; federal or
state savings bank; or any federal or state chartered credit union.
FNS NUMBER A seven-digit merchant number issued by the US Department of Agriculture
Food and Nutrition Service that is used in EBT Food Stamps.
Foreign Currency The three-digit code, assigned by Visa, to designate the type of currency (non-
Code U.S. dollars) of the transaction.
Foreign Currency The local currency (non-U.S. dollars) transaction amount. The decimal
Transaction Amount position is assumed, based upon the type of currencies.
Front End Communications computer-The front end processor is a computer that
Processor (FEP) connects to the communications channels on one end and the main computer
on the other. Software in the FEP directs the transmitting and receiving of
messages according to the rules of the communications protocol used in the
network. The communications software, executing in the FEP, detects and
corrects transmission errors, assembles and disassembles messages, etc., so
that only "pure" data is transferred to and from the main computer (stripped of
all codes that are attached for transmission through the network). A FEP is
also called a communications control unit.
Full-Duplex A communications channel that transmits in both directions at the same time.
Half-Duplex A communications channel that transmits in both directions, but in only one
direction at a time.
Host Main computer-The host is generally the central or controlling computer in a

Appendix G-Glossary
Term Definition
distributed system.
Hot Card A card being used on an account on which excessive purchasing, indicative of
unauthorized purchasing, is taking place. Usually a lost or stolen card.
Interchange Fees Compensation paid by the acquiring member to an issuing member for
particular expenses incurred in the process of interchange transactions.
Issuer A member that issues bank cards.
Leased Line Dedicated communications channel leased from a common carrier; leased
lines usually can handle greater transmission speeds than the dial-up
telephone system. Leased lines from the telephone company can be
"conditioned" (electronically fine tuned), which can reduce transmission error
rates.
Load Notification to an issuer of an amount to be loaded to a prepaid account’s
available balance.
Local Area Network Communications network within an organization; local area networks connect
various hardware devices together within a building or plant via a continuous
cable or through the use of an in-house voice/data telephone system. Local
networks do not rely on external public or private communications services,
although they may connect to them in order to transfer information across long
distances.
Longitudinal A verification value that ensures that no data have been lost in the stripe
Redundancy Check reading process. The LRC is equivalent to a check digit of the entire track,
(LRC) including the control characters.
Lost Card A bank card that has been reported to the credit issuer as lost or misplaced by
the cardholder of record.
Magnetic Stripe A stripe of magnetic information affixed to the back of a plastic credit (or
debit/EBT) card. The magnetic stripe contains essential customer and account
information.
Mail/Telephone The purchase of goods or services where the cardholder is not present at the
Order Transaction point of sale.
Market Specific This entry is used to indicate that market-specific authorization data was
Authorization present in the authorization request to Visa’s VIP system.
Market-Specific Information supplied in the authorization request to assist the issuer in making
Authorization Data better authorization decisions.
Merchant Category Four-digit Merchant Category Code which identifies the type of business
Code(MCC) conducted by the merchant. Also known as Merchant Category Code (MCC).
It is used in the warning bulletin, authorization and settlement systems to
identify the type of merchant (formerly SIC)
Merchant Advice A code associated with the reason a recurring payment transaction has been
Code declined.
Merchant Country Three-digit code identifying the country (outlet location) where the transaction
occurred.
Merchant Number This field must contain the Account Number assigned by First Data for the
specific outlet.
Merchant ZIP/Postal Five- or nine-digit U.S. Postal Service Zip Code of the merchant outlet where
Code the transaction occurred. When merchant is outside the U.S., this field
contains any alphanumeric postal code.
Merchandise Return A “credit” to the cardholder’s account for merchandise previously purchased.
Returns are typically processed a day (or days) after the cardholder performed
the original purchase.
Appendix G-Glossary
Term Definition
Merchant Bank The bank that has entered into an agreement with a merchant to accept
deposits generated by bank card transactions.
Merchant Floor A maximum monetary amount above which a particular transaction requires
Limit authorization.
Message A communications transmission; regardless of the nature of the
data/information, it is considered a message as it travels from the terminal to
the computer or from computer to computer over a communications channel.
Modem A modulation/demodulation device that provides compatibility between
input/output equipment and communications facilities by conditioning data
signals for transmission.
Multiple In the hotel and auto rental industries, multiple or incremental authorizations
Authorizations and a single partial reversal are often obtained after the initial authorization.
Multi-Dropped A communication line system having more than one terminal connected to the
same line.
National MasterCard International or Visa International, which are licensing and
Association regulatory agencies for bank card activities.
Negative File A file containing all accounts for which charge privileges have been revoked
by the card issuer.
Network Retrieval A reference number supplied by the debit network providing the response. It is
Reference Number used to help locate the transaction.
Network Response Ancillary data, obtained in the authorization process, which is used internally
by First Data.
On-Us Transaction A transaction in which both the cardholder and the merchant are signed by the
same member.
Open-To-Buy Available credit.
Original Auth Code Reflects the Authorization Code of the transaction to be reversed.
Packet Switching A technique for handling information traffic over a communications network;
packet switching breaks apart all information to be transmitted into fixed length
units called "packets." This method optimizes the transmission of variable
information traffic in the network. Messages of different lengths and priorities
can be handled efficiently on a packet switching network.
Partial Authorization An authorization response with an approval for a portion of the total amount
requested.
Port Communications channel hardware interface; the number of ports in the
computer or communications control unit determines the number of
communications channels that can be connected.
POS Terminal A device placed at the point-of-sale, connected to a system via
telecommunication lines, designed to authorize, record, and/or forward sales
transactions electronically.
Positive File A file containing, at minimum, the current balance for each active cardholder
account. A positive file may also include PIN and other cardholder information.
Private Label Cards Private label, or retail cards, are those issued by a single store or chain of
stores. These cards are used only in those establishments.
Preferred Customer In the hotel and auto rental industries, customers can apply for and be
accepted into a preferred customer service. These customers receive
preferential treatment, such as being taken directly to their hotel rooms or to
their rental cars without having to present their card and sign a rental
agreement.
Protocol The scheme of operating procedures and control signals by which a
telecommunications system is controlled.
Quasi-Cash "Quasi-Cash" refers to transactions that can be interpreted as purchase or

Appendix G-Glossary
Term Definition
Transactions cash, such as wire transfer money orders or alimony payments. When
authorized through Visa's Base I system they are treated as cash transactions,
but are handled as purchases when they are cleared through Visa's Base II
clearing and settlement system.
Referral A referral is neither a decline nor an approval; instead it indicates that
authorization can be obtained only through direct telephone or telex contact
with the issuer center.
Response Echo Additional data provided by the merchant that is echoed back by First Data for
Data the merchant’s internal matching purposes.
Return see Merchandise Return.
Reversal A request to cancel part or all of a previously approved card transaction.
SDLC Synchronous Data Link Control-IBM communications protocol; SDLC is the
primary protocol supported under SNA.
S.E. Number The Service Establishment number for non-bankcard transactions which
identifies the merchant entity requesting the authorization.
SNA Systems Network Architecture-IBM network architecture.
Standard Industrial See Merchant Category Code.
Classification (SIC)
Stand-In- A service offered by the Associations that provides transaction processing
Processing (STIP) services on behalf of an unavailable or timed-out issuer.
Start Sentinel The character that indicates the initial data position on the track of the card's
magnetic stripe.
State Code Two-digit code identifying the U.S. state where the transaction occurred. For
Check Verification / Guarantee requests with Driver's License Number, the
State Code field must be used to indicate the state where the driver's license
was issued. This field is used only when the Country Code is "840" (U. S.).
see Appendix C, beginning on page 11.
Synchronous High-speed transmission; synchronous communications is the transmission
Communications and recognition of long groups of characters at a time. Both the sending and
receiving devices are set to the same synchronization of pulses (BITS).
Voice Authorization The authorization procedure in which a merchant uses a standard telephone
to request authorization from an acquirer center.
Void A type of transaction meant to correct an error or to accommodate a
customer’s change of mind after the approval of the original transaction.
Note: Voids are currently supported for debit transactions only.

X.25 International communications protocol-X.25 defines a public switching
network.

First Data ISO 8583 Global Specification Appendix H
6.8. Appendix H — Escalation Procedures for Authorization

Link Problems
Step 1:
1. Call the Network Control Center at 1-800-555-9966.
2. Identify yourself and your company.
3. Provide any pertinent information that may assist the Operator in resolving the problem.
4. The Network Operator will perform preliminary diagnostics with you to identify the source of the
problem, and will involve any technical/vendors, as needed.
Step 2:
1. If, after thirty minutes, you are not satisfied with the progress, ask the Operator for escalation to
the Shift Supervisor.
Step 3:
1. If, after one hour, you are not satisfied with the progress, ask the Shift Supervisor for escalation to
the Network Operations Manager. During off-hours, the merchant will receive a response from the
Network Operations Manager within one half hour.
Step 4:
1. If after two hours you are not satisfied with the progress, ask the Operator to escalate the problem
to the Director of the Control Center, who will respond promptly.


First Data ISO 8583 Global Specification Appendix I
6.9. Appendix I — Address Verification Service (AVS)

6.9.1. AVS Overview
Address verification, an optional merchant service offered by Visa, Discover, MasterCard and American
Express, is designed to reduce the fraudulent use of card numbers for mail and telephone orders, where
a card is not present and merchandise is to be shipped/mailed. The information provided by this service is
intended to help merchants make more informed decisions about transactions and thereby reduce the
number of fraudulent transactions, charge-backs, and cardholder/merchant disputes. It should be noted
that Address Verification Service is supported for domestic U.S. cardholder addresses only.
When mail or phone-order customers charge their purchases to a credit card, merchants have no
opportunity to compare signatures or confirm possession of the card. Thieves who use victim's credit card
numbers to place fraudulent orders typically think that the account number is the only item checked
during the authorization procedure. In most instances, they don't have access to the cardholder's
accurate billing address when they place the order.
While an authorization indicates to the merchant that an account is valid and in good standing, AVS
provides a means to quickly check that the person placing the order is probably the same person
responsible for payment on the account. If AVS indicates that the billing address provided with the order
doesn't match the address on file with the card issuer, the merchant may have reason to suspect a
fraudulent transaction and therefore choose to delay fulfillment until the customer's identity is confirmed.
Merchants should use AVS in conjunction with their other efforts to verify a customer's identity. A "match"
response from AVS alone cannot provide an unconditional guarantee.
6.9.2. AVS Basic Features

The following are the program's basic features:
Merchants may utilize AVS in combination with an authorization request or they have the option to
submit AVS requests separately. When performing a stand-alone address verification, the
merchant provides the address information and zero-fills the Transaction Amount field within the
request message.
The cardholder billing address (the zip code plus 20 characters of the street address for up to 29
characters total) must be included in the request message. Any street name that is numeric in
nature should be converted to numeric form. For example, One Main Street would be presented
as 1 Main Street.
Verification will be provided by the issuer's processor or by Visa, MasterCard or American Express
in a stand-in-mode as designated by the issuer.
The merchant receives an address verification "result" code that reflects the validity of the
cardholder's address when compared to data maintained by the issuer. The AVS Result Code
does not affect the authorization, approval, or decline. The merchant may use the AVS code to
decide how to process the order from that point forward, depending upon individual business
policies. The valid responses are listed in the Data Dictionary
The response message also indicates whether the result was provided directly from the issuer or
by the Association in a stand-in mode. A Stand-in Processing (STIP) Code of “5” is generated if
the response was provided by the issuer's processor.


Appendix J First Data ISO 8583 Global Specification
6.10. Appendix J — Check Guarantee/Verification

6.10.1. Check Guarantee/Verification Overview
In an effort to help protect merchants from the risk involved in accepting checks, First Data acts as an
interface for a variety of Check Verification and Check Guarantee services. Both Check Verification and
Check Guarantee processing will enable a merchant to make an informed decision as to whether to
accept a check from a specific consumer.
6.10.2. Check Verification

When a check verification transaction is requested, First Data will route the request to the entity specified
by the merchant. That entity will verify that the consumer does not have a history of passing fraudulent
checks.
6.10.3. Check Guarantee

When a check guarantee transaction is requested, First Data will route the request to the entity specified
by the merchant. That entity will verify that the consumer does not have a history of passing fraudulent
checks. In addition to performing the verification, the provider will guarantee payment. The level of
guarantee is specified in the contract between the merchant and the provider.
6.10.4. Check Guarantee/Verification Support

First Data Merchant Services interfaces with three major Check Verification / Guarantee processors:
 NPC (JBS)
 Fidelity (Certegy)
 TeleCheck
Merchants must establish an affiliation with a given Check processor and obtain appropriate
identification/entitlement numbers from that institution prior to commencing live processing. The
data elements required for processing these transactions varies depending on the provider
selected by the merchant.
Merchants using any of the Check processors listed above can perform check verification and/or
guarantee using either full MICR (ABA number, checking account number, and check sequence
number) or the short MICR * (checking account number only) information number. In addition,
merchants who key in Driver’s License numbers (DL) can perform check verification and/or
guarantee using Fidelity (Certegy), or TeleCheck.
Driver’s License support is not currently available through NPC (JBS). The DL or MICR is sent to
First Data in field 48 of the Check Guarantee/Verification Authorization Request Message (see
page 5-10). Responses are returned in the Check Guarantee/Verification Response Message (see
page 5-12).
* MICR stands for Magnetic Ink Character Recognition.
For verification performed using DL, the state code is required in the fifth and sixth bytes of Field
48. The date of birth is required in bytes 5-10 of Field 48 for Fidelity (Certegy) and TeleCheck.


First Data ISO 8583 Global Specification Appendix J
For verification performed using short MICR, the full checking account number (up to 18 digits) is
required. A plastic check guide is provided by First Data for the sales clerk to use when keying the
account number field.
A unique situation can occur when merchants verify with short MICR (i.e., checking account
number only): Two separate banks might issue the same checking account number to two people.
When a merchant transmits an account number to First Data that also resides on the Check
processor’s negative file*, it is necessary to determine whether the account number on file actually
belongs to the person who is submitting the check to the merchant. Once First Data relays this
information back to the Check processor, a referral is typically generated and sent back to the
merchant. The sales clerk will need to call the Check processor and compare the ABA number on
the check in question with the ABA of the checking account on the Check processor’s negative
file. If they match, the merchant should decline the check. If they do not match, the clerk accepts
the check.
* Existing merchants utilizing Tele Check for authorizations that currently only submit the account number
in the MICR data are being requested to support full MICR data to improve the validation. For new
merchants or vendor applications that submit authorization to Tele Check via First Data, account number
only will no longer be supported for format validation.
First Data can accept input from check MICR readers. In this case, the contents of Field 48 of the
authorization request, starting at the 11th byte, would consist of the following:
 ABA (Bank Routing) Number "T" Checking Account Number “A” Check Sequence Number

6.10.4.1. NCP (JBS) Response Values

The possible responses from JBS are listed below (by First Data response code). The Displayed
Message column shows the format of text returned in Field 63 of the Response Message.
Response Code Authorization Code Displayed Message

00 123456 APPROVAL
00 000000 # of Checks = 99
01 N/A CALL JBS
01 N/A CALL REF # 1234
01 N/A INVLD ACCT NUM
51 N/A CHECK DECLINED
51 N/A DECLINE XXXXXX
91 N/A PLEASE RETRY
* The negative file contains a list of account numbers associated with individuals who have passed bad
checks
6.10.4.2. NPC (JBS) Display Messages and Their Meanings

Displayed Message Meaning
APPROVAL Check was approved-authorization code 123456.
# of Checks = 99 Velocity message-with number of checks written in the last 5 days.
CALL JBS Call JBS (used with Check Guarantee only).
CALL REF # 1234 Call JBS and specify the referral number 1234.
INVLD ACCT NUM An invalid account number was used. This error may indicate non-
numeric values entered in the MICR data or an account number that
was either too long or too short. For full MICR data, this error could
indicate an ABA # or a check sequence number that was either too long
or too short.
CHECK DECLINED Check was declined.
DECLINE XXXXXX Check was declined. “XXXXXX” represents the first 6 characters of the
checking account holder’s last name, such as “JOHNSO” for
JOHNSON.
PLEASE RETRY Transaction failed to be completely processed. Resubmit transaction.
The name, velocity, and decline messages apply only to check verification. Merchants may
select different options, and those options determine which verification responses JBS will

send. Programmers should provide for all messages in case a merchant changes the
selected options with JBS.


6.10.4.3. Fidelity (Certegy) Response Values

The possible responses from Fidelity (Certegy) are listed below (by First Data response code). The
Displayed Message column shows the format of the text returned in Field 63 of the Response Message.

00 123456 APPROVAL
01 N/A REFERRAL
14 N/A INV ACCT NUM
91 N/A PLEASE RETRY
6.10.4.4. Fidelity (Certegy) Display Messages and Their Meanings

APPROVAL Self-Explanatory
REFERRAL Call Fidelity (Certegy).
INVLD ACCT NUM An invalid account number was used. These type errors may indicate
non-numeric values entered in the MICR data or an account number that
was either too long or too short. For full MICR data, this error could
indicate an ABA number or a check sequence number that was either
too long or too short.
PLEASE RETRY The transaction failed to be completely processed. Resubmit the
transaction.
6.10.4.5. TeleCheck Response Values
The possible responses from TeleCheck are listed below (by First Data response code). The Displayed
Message column shows the format of the text returned in Field 63 of the Response Message.

00 123456 APPROVAL
01 N/A Call Center
01 N/A Error Retry
01 N/A CODE 3
01 N/A CODE 3 Smith John
03 N/A INVLD MER ID
91 N/A PLEASE RETRY

6.10.4.6. TeleCheck Display Messages and Their Meanings

APPROVAL Check was approved, authorization code 123456.
Call Center Call TeleCheck.
Error Retry The transaction failed to be completely processed. Resubmit the
transaction.
INVLD MER ID The subscriber is not active or does not exist.
CODE 3 The check was not approved. Call TeleCheck and specify that the reason
given for the non-approval was CODE 3.
CODE 3 Smith John The check was not approved. Call TeleCheck and specify that the reason
given for the non-approval was CODE 3 Smith John.
PLEASE RETRY The transaction failed to be completely processed. Resubmit the
transaction.
6.10.4.7. TeleCheck State Codes

State Code Country Code
Northwest Territories 01 Saskatchewan 58
British Columbia 11 Kentucky 59
Saskatchewan 12 Ohio 60
New Brunswick 13 Manitoba 61
Virgin Islands 16 Nebraska 63
Arizonia ID 20 Minnesota 64
Alberta 21 Oklahoma 65
California 23 Missouri 66
Alabama 25 Oregon 67
Colorado 26 Montana 68
Arkansas 27 New York 69
Connecticut 28 Puerto Rico 70
New Foundland 31 Quebec 71
Delaware 33 South Carolina 72
Florida 35 South Dakota 73
North Dakota 36 Rhode Island 74
Northwest Territories 37 North Carolina 75
Nevada 38 Mississippi 77
New Mexico 39 Pennsylvania 78


Michigan 40 Maryland 79
Nova Scotia 41 Prince Edward Island 81
Georgia 42 Virginia 82
Idaho 43 Vermont 83
Hawaii 44 Tennessee 86
Illinois 45 Massachusetts 87
Indiana 46 Utah 88
New Hampshire 47 Texas 89
Iowa 49 Yukon Territory 91
Ontario 51 Washington 92
Louisiana 52 Washington DC 93
New Jersey 53 Wisconsin 94
British Columbia 54 New Brunswick 95
Alaska 55 Military Card 97
Maine 56 West Virginia 98
Kansas 57 Wyoming 99

First Data ISO 8583 Global Specification Appendix K
6.11. Appendix K — Additional Credit Card Processing Options

6.11.1. Foreign Currency Authorization
The On-line Multi-currency Conversion feature of the VisaNet Integrated Payment (V.I.P.) System allows
authorization of bankcard transactions in any transaction currency supported by Visa. Using the foreign-
currency-related fields within the First Data authorization request message, the non-U.S. merchant can
designate the appropriate currency code (see Appendix E, beginning on page Error! Bookmark not
defined.) and foreign currency transaction amount. First Data will, in turn, route the transaction to Visa for
authorization. Visa's authorization system (Base) determines the currency based upon the card issuer,
applies the appropriate conversion rate, and converts the transaction amount to the issuer's posting
currency.
6.11.2. Miscellaneous Processing
FEATURES SUPPORTED FOR CARDS TYPE

Visa MasterCard Amex Discover Other
Contactless Transactions Y Y Y
Cash Back Y
Recurring Transactions Y Y Y Y
Recurring Payment Y Y
Cancellations (Merchant Advice
Code Indicator)
Deferred Billing Indicator Y
Installment Bill Payment Y Y
NTIA Program Y
6.11.3. Contactless Transactions

Contactless Payment Cards are similar to traditional credit / debit cards except that they have a
contactless chip and radio frequency (RF) antenna configuration embedded within the plastic. After you
tap or wave your Contactless Payment Card at a merchant terminal equipped with an RFID (Radio
Frequency Identification) reader, the card wirelessly transmits Track 2 and / or Track 1 payment details to
the terminal.
If the Visa, MasterCard or Discover Card is read via the chip using a RFID reader the appropriate entry
mode (see BIT 22, value = 91) in the authorization and settlement records must be present. The
appropriate entry mode is used to identify the type of RFID terminal used. American Express does not
require a special indicator identifying the card as contactless read.
For Visa transactions, if the merchant has a RF reader at the point of sale, the Terminal Capability value
(see BIT 60, POS Terminal Capability value = 7) must indicate a contactless reader is available.
Visa Contactless Payment Program requirement - In order for merchants to participate in the Visa
Contactless Payment Program; the merchants must be registered with Visa. The merchants must contact
their Relationship Manager to pursue the registration process.


6.11.4. Cash Back

At this time only the Discover association is offering Cash Disbursement Over (Cash Back) Purchase
Processing functionality. Some merchants will allow for the purchase of a good or service with additional
cash received from the purchase. For Discover cardholders, the consumer can ask for a cash
disbursement on a prepaid card purchase or a credit card purchase. See BIT 63, Table 68 (Version 2) to
indicate Discover Cash Disbursement.
6.11.5. Recurring Transactions

Recurring Payment (MasterCard, American Express and Discover) and Recurring Bill Payment (Visa)
Indicator is supported for Visa, MasterCard, Discover and American Express only.
A recurring transaction is a transaction for which a cardholder provides written permission to a merchant
to periodically charge his/her account number for recurring goods or services. These may include
payment of charges such as insurance premiums, subscriptions, membership fees, tuition or utility
charges. The recurring transaction indicator (see Bit 3 (Processing Code = 500000), Bit 25 (POS
Condition value = 04) and BIT 63 (Table 60 value = 02 for Visa and Discover only)) must be present in
the authorization and settlement message formats.
Visa requires that the initial authorization and settlement transaction must indicate how the merchant
obtained the card holder number (I.e. card present; mail/telephone order; internet etc). The initial
authorization and settlement request should not contain the recurring transaction indicator, only the
subsequent transactions will contain the recurring transaction indicator. Address verification must be
obtained with the initial authorization request and is not required in the subsequent recurring transactions
that contain the recurring indicator. Address verification is however required to be obtained yearly.
MasterCard and American Express require that both the initial and subsequent authorization and
settlement transactions contain the recurring transaction indicator as well as how the card information
was obtained from the card holder (i.e. face to face, internet, mail order etc.). When performing E-
Commerce Recurring transactions for MasterCard, the POS Condition code must be 04 and the
MOTO/ECI value in Field 63 Table 60 must be 05, 06, 07, or 08.
The recurring indicator is not required on refunds. The indicator is required on voice authorized
transactions. Visa Bill Payment (Recurring, Installment & Single Bill Payment) is only supported for US
Acquirers and US Domiciled Merchants. For Non US Acquirers and non US Domiciled merchants, if any
of the Visa Bill Payment Indicators are present First Data will ignore the indicator and not pass it to Visa.
6.11.5.1. Merchant Advice Code
MasterCard implemented the recurring payment transaction Indicator and Advice Code on 4/6/01. First
Data implemented the Visa Recurring Cancellation Service on 8/03/07.
An additional response ‘Merchant Advice Code Indicator’ (see BIT 63, Table 55) may be returned to

assist the merchant with the reason for declining a recurring transaction when the appropriate Recurring
indicators (see Recurring Transactions) are present in the authorization request message i.e.
Recurring/Recurring Bill Payment (Visa and MasterCard). This documentation provides actions a
merchant can take to continue to serve their customers.

Appendix K First Data ISO 8583 Global Specification
Response Values and Definitions for MasterCard:
01 = New Account Information

02 = Try Again Later
03 = Do Not Try Again. Obtain another type of payment from customer due to account closed or
fraud.
21 = Do not try again. Cardholder has canceled recurring charge.
Response Example Reason For Decline Suggested Merchant Action

01 Expired Card Obtain New Account Information
Account upgrade before next billing cycle.
Portfolio Sale
Conversion
02 Over Credit Limit Recycle transaction 72 hours later.
Insufficient Funds
03 Account Closed Obtain another type of payment
Fraudulent from customer.
21 Cardholder has been unsuccessful at Stop recurring payment requests.
canceling recurring payment through
merchant.
Response values and definitions for Visa:
02 = Stop a specific payment

03 = Revoke authorization for further payments
21 = Cancel all recurring payments for the card number in the request.
Response Example Reason For Decline Suggested Merchant Action

02 Cardholder only wishes to stop one The merchant must NOT resubmit the
specific payment in the recurring SAME transaction. The merchant may,
payment relationship. however, continue the billing process in the
subsequent billing period.
03 Cardholder has requested to stop all Stop recurring payment requests.
recurring payment transactions for a
specific merchant.
21 All recurring payments have been Stop recurring payment requests.
cancelled for the card number
requested.


6.11.6. Deferred Billing Indicator

The Deferred billing transaction indicators is supported for Visa only. It identifies transactions that the
billing occurred after delivery. The transaction is being submitted to bill the cardholder for merchandise
that was received within the past 90 days. The indicator will allow issuers to identify these unique types of
requests and will provide information to assist customer service representatives in addressing issues
related to disputes, charge backs and authorization holds. The indicator is required in the authorization
and settlement messages.
6.11.7. Installment Bill Payment

The Installment Bill Payment transaction indicator is supported for Visa and Discover only. It is a
transaction for which a cardholder provides permission for the merchant to charge his/her account for a
specified amount over a certain period of time. Example: If you were to purchase goods or services for a
total of $75.00 and you make 3 easy payments of $25.00.
The initial authorization and settlement request will not contain the installment transaction indicator. The
initial transaction must indicate how the merchant obtained the cardholder's information (i.e. card present,
mail/telephone order, internet, etc.). The sequential transactions will contain the installment transaction
indicator (see BIT 63, Table 60 value = 03) at the time of authorization and settlement.
Installment transactions are card not present transactions but Address Verification is only required to be
obtained yearly. The installment indicator is not required on credit returns. The indicator is required for off-
line (voice authorized) transactions. Visa Bill Payment (Recurring, Installment & Single Bill Payment) is
only supported for US Acquirers and US Domiciled Merchants. For Non US Acquirers and non US
Domiciled merchants, if any of the Visa Bill Payment Indicators are present First Data will ignore the
indicator and not pass it to Visa.

6.11.8. NTIA Coupon Program
Background on the NTIA Coupon Program

In order to continue to receive television programming after February 17, 2009, consumers must have a
digital-to-analog converter box, a digital television, or cable/satellite television service. Between January
1, 2008 and March 31, 2009, all U.S. households will be eligible to request up to two coupons, worth $40
each, to be used toward the purchase of up to two digital-to-analog converter boxes, from the Department
of Commerce’s National Telecommunications and Information Administration (NTIA).
Retailers choosing to participate in the sale of these digital-to-analog converter boxes may want to accept
and redeem these coupons, which will be issued in the form of a non-branded plastic magnetic-stripe
card. These cards cannot be used once the amount loaded onto the card is depleted.
Optional Retailer Participation

The NTIA encourages the voluntary participation of consumer electronics retailers to ensure the success
of the Coupon Program.
CLC Services (CLC) will directly solicit merchants who sell consumer electronics to participate and accept
the coupon. Retailers wishing to participate need to undergo a retailer certification process administered
by CLC. During the certification process, retailers will be required to complete a Central Contractor
Registration (CCR). CCR validates the registrant information and electronically shares the secure and
encrypted data with the U.S. Treasury, which will facilitate paperless payments through electronic funds
transfer (EFT).
Coupon Authorization Method

There are two components to the coupon authorization process:
Coupon Authorization — performing an authorization to confirm that the coupon is valid. This is
provided as card information in the authorization request. The bin range for these non-branded plastic
magnetic-stripe cards is 589732. The CVV2 value is present on the card and can be submitted for
validation during the UPC and coupon authorization request for card not present transaction types.
Merchants could receive decline authorization responses if the CVV2 value is invalid. Address Verification
is not supported and must not be present in the authorization request.
UPC Validation — verifying that the product being purchased with the coupon is an eligible digital-to-
analog converter box. The UPC is provided in bit 63 Table PD (Promotional Data) Tag 01.


Coupon Settlement Method

Transactions performed by using NTIA coupons cannot be submitted to First Data for settlement
processing. Any questions regarding settlement and funding processing should be directed to CLS.
First Data will support the following methods:
UPC and Coupon Authorization validation. In this process, authorization of the coupon and UPC is
performed at the POS using the 0100 Authorization Request message. The BIT 31 value of ‘0’
indicating Authorization Only and the UPC is provided in BIT 63 Table PD (Promotional Data) Tag
01. (First Data will route the transaction out to Visa.
Reversals (time-out and clerk initiated) are supported. In this process, the coupon and UPC are
provided using the 0400 Reversal request message. CLC requires that the reversal be submitted
within 15 minutes of the approved UPC and coupon authorization response (clerk initiated
reversal) or if no response is received (time-out reversal). The merchants must initiate a reversal
within 14 minutes of the approved UPC and Coupon Authorization response. The approved
reversal response is just an acknowledgement to the receipt of the reversal request and does not
indicate that the reversal has been processed and submitted to Visa. First Data will perform a
match of the approved UPC and Coupon Authorization response with the reversal request. If a
match is found the reversal request will be sent to Visa.
Once the transaction is authorized, the coupon is deactivated. Depending upon the final retail price of the
converter box, the retailer may need to collect an additional form of payment for any residual amount due
for the total purchase price.
Next Steps/Additional Information:

Merchants interested in participating in the coupon program must apply for certification by contacting
NTIA between June 1, 2007 and March 31, 2008. Certification requirements include:
Having been engaged in the consumer electronics retail business for at least one year.
Having completed a Central Contractor Registration (www.ccr.gov).
Having in place systems that can be easily audited.
Agreeing to have coupon-eligible converter box sales audited.
Providing redemption information and payment receipts to NTIA for coupon-eligible converter
boxes.
Agreeing to accept only coupons for, and receive payment resulting from, authorized purchases
made for coupon-eligible converter boxes.
 A list of coupon-eligible converter boxes will be made available to retailers and consumers.
Retailer certification may be revoked by NTIA if a certified retailer fails to comply with the Final Rule.
Certification will not be revoked for unintentional noncompliance or error.
Continued

Retailer questions should be directed to:

DTV Converter Box Coupon Program
U.S. Department of Commerce
National Telecommunications and Information Administration
Phone Number: 1-866-296-1107
Web Site: www.ntiadtv.com


6.11.9. Prepaid Card Processing Functionality

Prepaid products provide consumers with the flexibility to pay in advance. Visa MasterCard, American
Express and Discover recognize that prepaid products represent unique opportunities for both merchants
and consumers. Several transaction options are available in support of these card types.
Visa Pre Paid Gift Card is limited to U.S Merchant’s accepting domestic transactions only.
Several transaction options are available in support of these card types. The table below identifies the
transaction options that are available for each card type:
FUNCTIONALITY SUPPORTED FOR CARDS TYPE

Amex Discover MasterCard Visa
Balance Inquiry Only request Y Y Y
Balance receptive with an Y
Y
authorization request
Partial Authorization Capable Y *Y Y Y
Partial Auth capable and balance Y
receptive concurrently
Activate Y
Load & Activate Y
Reversal of Activation Y
Reversal of Load Y
Health Care/Transit Auto Y
Y
Substantiation
Discover supports Partial Authorization on Prepaid Gift cards and credit cards.


6.11.9.1. Account Balance Information

Two processing options are available for receiving cardholders’ account balance information at merchant
locations. They are as follows:
Balance information that is returned as part Bit 63 (Table 68 – version 2) of the balance inquiry
with authorization purchase response. (Visa Pre-paid cards only). Merchant have to indicate the
POS device’s capability to handle balance information in response messages by setting the
Balance information Capability value as 1 in the request message.
Stand-alone balance inquiry initiated by the cardholder. This option is designed to allow
cardholders to request account balance or available credit prior to the initiation of a purchase
transaction. Transactions identified as stand-alone balance inquiries must also contain a
processing code (Bit 3) of 300000 and a transaction amount (Bit 4) of $0.00. These transactions
should not be captured for settlement processing. (Visa and MasterCard Pre-paid cards). Balance
information is returned as part Bit 63 (Table 68 – version 1) of the balance inquiry only response.
To receive balance information, the requestor must first indicate that they are capable of receiving
such information. First Data uses the information provided in the Additional Account / Amount
Information request table (BIT 63, Table 68) to determine the requestor’s ability to support the
inclusion of account balance information in response messages. If an issuer includes account
balance information in their authorization response and the requestor indicates their ability to
receive such information, the account balance data will be returned to the POS device in the
Additional Account / Amount Information table of the response message.


6.11.9.2. Partial Authorization Capable
Partial Authorizations is supported for Visa, MasterCard, American Express and Discover Prepaid card
products such as gift, Flexible Spending Account (FSA) or Healthcare Reimbursement Account (HRA)
cards. In addition Discover supports partial authorization on their consumer credit card. Effective 4/5/08
Partial Authorization is required for Automated Fuel Dispenser (AFD). For Automated Fuel Dispenser
(AFD), the partially approved amount may be greater than the requested amount. The Automated Fuel
Dispensers (AFD) must not allow the card holder to pump in fuel of an amount that is greater than the
partially approved amount.
It is often difficult for the consumer to spend the exact amount available on the prepaid account, as the
purchase can be for amounts greater than the value available. This can result in unnecessary declines.
Visa, MasterCard, American Express and Discover recognize that the prepaid products represent unique
opportunities for both merchants and consumers.
With Partial Authorizations issuers may approve a portion of the amount requested. This will enable the
residual transaction amount to be paid by other means.
The introduction of the partial authorization capability will reduce decline frequency and enhance the
consumer and merchant experience at the point of sale. Merchants will now have the ability to accept
partial authorizations rather than having the sale declined.
Since all Prepaid Cards can not be identified by the BIN range the Partial Authorization Capable
transaction request is supported for all Visa, MasterCard, and American Express and Discover
authorization requests.
For merchants that support partial authorizations, real time reversal processing is required.
Refer to General Information/Reversal of an Authorization for further information.

For merchants that support partial authorizations, real time reversal processing is required. Refer to
General Information/Reversal of an Authorization for further information.
Along with participating in the Partial Authorization Capable program merchants may also request to
receive the remaining balance of the Visa Prepaid Card if the transaction is not partially approved, this
feature is not available for Visa Flexible Spending Account (FSA) or Healthcare Reimbursement Account
(HRA) cards. The remaining balance may be returned if the issuer returns the balance and the
transaction amount is less than or equal to the remaining balance of the card. American Express supports
either Balance Receptive with a sale or Partial Authorization Capable, but does not support requesting
the balance with Partial Authorization Capable. MasterCard does not support providing balances during
an authorization request. Discover does not support or provide balances.
When balance information is returned by the Issuer on a Visa Prepaid Gift Card as part of the approved
authorization response, merchants are required to print balance information on the Cardholder receipt.
The balance that is returned may not reflect the actual funds available due to pending authorization(s)
that have not been processed. Not all issuers return balances for all the Visa Prepaid products.
To perform a Partial Authorization Capable Request, the requestor must set the flag as 1 in Bit 63 (Table
68-version2) to indicate that they are partial authorization capable.

Partial Authorization Capable Response

If the issuer identifies the card type as a prepaid card, accepts partial authorization and approves the
transaction as a partial authorization, the Bit 4 (Transaction Amount) and Bit 63 (Table 68 – version 2)
Additional Account/ Amount Information field will be returned.
The transaction amount in Bit 4 will reflect the approved transaction amount.
Additional Account/ Amount Information Data Information Response (Bit 63 Table 68):
 The Account Type will contain a value of 57 indicating the total transaction amount of the original
request.
 The Amount will reflect the amount submitted in Bit 4 (Transaction Amount) within the 0100
The merchant will need to subtract the Additional Amount from the Transaction Amount to determine the
remaining amount due for the purchases of goods or services and request the cardholder pay the
remaining balance.
Effective 4/5/08 Partial Authorization is required for Automated Fuel Dispenser (AFD). For Automated
Fuel Dispenser (AFD), the partially approved amount may be greater than the requested amount. .
Example: Consumer is using a prepaid card with a balance of $25. For Visa the AFD submits an
authorization request for $1.00. The issuer partially approves the transaction for $25.00. The AFD must
stop the dispensing of fuel when the amount reaches the partially approved amount, in this case $25.00.
The settlement amount for transaction processing can not be greater than the partially approved
transaction amount. If the partially approved amount does not equal the settlement amount the merchant
is required to submit a reversal for the difference. The AFD is not required to submit a reversal when the
approved amount does not equal the settlement amount when fuel is dispensed. For AFD if the
transaction is partially approved a reversal of the approved amount is required if the cardholder abandons
the sale and fuel is not dispensed.
For partially authorized transactions the remaining balance of the card will not be returned.


6.11.9.3. Healthcare/Transit Auto-Substantiation Processing

The Healthcare/Transit Auto-Substantiation is supported for Visa and MasterCard FSA and HRA cards.
Effective December 31, 2006, the IRS has revised rules for Healthcare Flexible Spending Account (FSA)
and Healthcare Reimbursement Account (HRA) card acceptance. The new rules limit the use of the cards
to merchants and service providers that have merchant category codes related to healthcare, such as
physicians, pharmacies, dentists, vision care offices, hospitals and other medical care providers.
The requirements for Healthcare Auto-Substantiation transaction are for implementation by non-medical
merchants, such as supermarkets, grocery and discount stores, wholesale clubs, mail order, web-based
prescription drug providers, and other merchants that sell over-the-counter qualified medical items. These
are the merchants that the IRS requires to have a compliant Inventory Information Approval System (IIAS)
in place as of January 1, 2008 in order for issuer processors of FSA/HRA cards to approve cardholder
purchases. Pharmacy and drug stores are required by the IRS to have a compliant IIAS by January 1,
2009 for acceptance of FSA/HRA cards. Medical merchants such as doctors, dentists, optometrists,
optical goods, hospitals, etc., do not need to support Healthcare Auto-Substantiation transactions.
It is the sole obligation of the merchant to qualify the eligibility of any and all FSA/HRA-related items,
using an approved Inventory Information Approval System (IIAS) at the point of sale and in real time. First
Data does not indemnify, warrant, or validate, in any form or by any means, the merchant’s liability
regarding this obligation.
The healthcare segment is rapidly moving toward the use of payment cards for Flexible Spending
Accounts (FSA) and Healthcare Reimbursement Accounts (HRA) so that such funds can be conveniently
accessed in these types of healthcare reimbursement accounts. Benefit administrators and companies
that provide healthcare services want more cost-effective means of substantiating purchases of qualified
medical items using FSA or HRA Debit cards. Electronic substantiation at the point of sale will reduce the
need for consumers to pay for medical purchases and subsequently submit sales receipts to obtain
reimbursement from their employer. The healthcare auto-substantiation enhancement will permit
employers and their third-party service providers to approve qualified medical expenses at the time of
purchase at the point of sale for participating retailers.
In addition, participating retailers who sell transit fare media, such as commuter passes, parking passes,
and mass transit vouchers and tickets, may also use the auto-substantiation Process to support
purchases with transit cards.
Like other prepaid or pre-funded cards, it is difficult for the consumer to spend the exact amount available
in the FSA or HRA account. Therefore, merchants are encouraged, but not required, to develop support
for partial authorization for healthcare auto substantiation (partial authorization support is required for
Transit auto substantiation). Support for partial authorization is expected to reduce declines due to non-
sufficient funds. Refer to General Information/Partial Authorization Capable for further information on this
optional feature. If partial authorization option is selected, it is required by the card associations to support
Reversal of Authorization, refer to General Information/Reversal of Authorization for further information.
To perform auto-substantiation processing, the requestor must include the following information in the
request message:
The total amount of the transaction.

The auto-substantiated amount of the transaction. This data must be included in Bit 63 (Table 68,
version2) with an Amount Type of 4S (Healthcare) or 4T (Transit), and must be housed in the
Additional Account / Amount Information table of the request message.
Optionally, in Bit 63 (Table 68, version2) of the request message, subtotals of 4U

(Prescriptions/RX), 4V (Vision / Optical), 4W (Clinical) and/or 4X (Dental) can be provided.
Bit 63, Table 14 for Visa and MasterCard must identify that the transaction has been substantiated
by sending a value of “M” in the Market Specific Data Indicator. If the Market Specific indicator is
set to a value of 'M', the additional account/account information table (field 63/table 68) must be
supplied.
The requestor must also support partial authorization approval responses. This capability must be
identified based on the value of Partial Authorization Capability set by the requestor in Bit 63
(Table 68, version 2) of the request message. If the value of Partial Authorization Capability in Bit
63 (Table 68, version 2) is set as 1 in the request message, it indicates that the merchant is partial
authorization capable.
For Settlement processing any auto-substantiated transactions must be identified.
Table 14 for Visa and MasterCard must identify that the transaction has been substantiated by
sending a value of “M” in the Market Specific Data Indicator.
The Transaction amount must be equal to or less than the approved authorized amount.
In order to process Health Benefit transactions with Visa the merchant must have a valid Merchant
Verification Value. The Merchant Verification Value is assigned by Visa and is used to identify merchants
that are participating in this program. First Data will store the Merchant Verification Value on behalf of the
merchant and enrich the authorization message. The merchant should contact their Relationship
Manager on this subject. If the authorization response message contains “N” in the Market Specific
Indicator, this could indicate a problem with the Merchant Verification Value. In this case, the merchant
should contact their Relationship Manager.
The merchants must use the Bin File Management to identify FSA/HRA cards. Refer to
Bit 63 (Table 68 Version 2) for the specific fields that must be present in the transaction

request message, if the card type is FSA/HRA only.
Values associated with Activation and Load transactions must be immediately posted
to the prepaid card accounts and be available for potential cardholder access.


6.11.9.4. Activation and Load of Prepaid Cards

The Activation and Load of Prepaid Cards is supported for Visa prepaid gift card products.
Activation of a Visa prepaid card notifies the issuer that a card has been purchased and should be
activated for cardholder usage on the Issuer Processor system. Refer to Processing code - Bit 3 on page
4-6 and Bit 63 table 68 on page 4-90 for appropriate values.
Load of a Visa prepaid card notifies the issuer of the dollar amount to be loaded to the card account. For
an existing card account, the load amount should be added to the available balance on file. Note: Load
transactions do not require Activation. Load transactions can be independent of Activation transactions.
For a new card account, the card should be activated for usage and the amount added as the initial load
to the card account. This is an unlinked load transaction in which the source of funds for the load value is
provided from either one or the other of the following:
Cash,
or
Another negotiable instrument (such as check, money order or travelers check) or debit or credit
card that may or may not be issued by the prepaid card Issuer.
Values associated with Activation and Load transactions must be immediately posted to the prepaid card
accounts and be available for potential cardholder access.
Settlement of Activation and Load transactions is carried out directly between the merchant and the card
Issuer. These transaction types should not be included in the settlement file submitted to First Data.
Adjustment or charge backs are not allowed for Activation and Load transactions.

6.11.10. Reversal Processing
FEATURES SUPPORTED FOR CARDS TYPE

Visa MasterCard Amex Discover NTIA
Full Reversal —Credit Y Y Y Y
Cards
Partial Reversal —Credit Y Y Y
Cards
6.11.10.1. Full Reversals — Credit Cards Only

A credit card reversal transaction cancels the processing associated with a previously approved
authorization. If a merchant or customer elects not to complete a transaction for which an authorization
has been made and approved, a reversal message is used to cancel that authorization. The following
facts are critical when performing reversal processing.
Reversal requests are currently supported for Visa, MasterCard and Discover.
Any reversals against a Pre-Paid card where a “partial” authorization approval was received will
need to send in field 39 with a value of “10” (Partial Authorization approval).
Visa and MasterCard require field 63 table 14. Tran-ID and Validation Code from Visa and
BankNet Settlement Date and Reference number from MC original response are required.
Reversal requests are limited to Visa, MasterCard and Discover** transactions only.
Only approved card-based transactions can be reversed. A reversal should not be used to cancel
a decline, a referral, or a verification request.
The reversal request should reflect the same data element values that were provided in the
original authorization request, with the exception of track data which Card Associations do not
allow to be stored. In addition, the reversal request message must contain the approval code that
was provided in response to the original authorization request.
When an issuer center receives a reversal request, it attempts to adjust the cardholder's available
balance and returns a reversal response to the acquiring center. This response acknowledges
receipt of the reversal.
The reversal request is then either "accepted" or "not accepted." An accepted response indicates
that the request has been successfully forwarded to the issuer. A not accepted response indicates
either that a reversal has been requested for a card type not supported by this service or that
there was some problem at the issuer's center.


6.11.10.2. Partial Reversals and Incremental Auth – Credit Cards Only

Authorizations initiated by certain merchants sometimes include estimated amounts which may vary
significantly from the final transaction amount. To effect more complete control over its cardholders' open-
to-buy balances and to limit over-authorizations, Visa's interchange pricing structure imposes tolerance
limits on the difference between the total amount authorized and the total amount cleared. When the
authorization to clearing amount tolerance threshold has been exceeded, a merchant can utilize a partial
authorization reversal transaction or an incremental authorization to adjust the original authorization
amount. MasterCard and Discover support partial reversals as well.
As with a full reversal, the partial reversal should reflect the same data element values that were provided
in the original authorization request. An additional field called the Replacement Amount field is used to
reflect the corrected total amount of the authorization, and the Transaction Identifier (only for Visa)
generated in the first authorization is used to link the partial reversal to the first authorization.
An incremental authorization (Visa only) is used to increase the amount authorized and is identified by
sending an "I" as the Authorizations Characteristics Indicator value. In incremental authorizations, the
Transaction Amount field reflects the additional amount, and the Transaction Identifier from the original
authorization is used to link the incremental authorization to the first amount.

First Data ISO 8583 Global Specification Appendix L
6.12. Appendix L — General Information on Debit and EBT

6.12.1. Debit card functionality/feature
Card SUPPORTED FUNCTIONALITIES

Cash back Debit cards Return Void Full Reversal
Debit Y Y Y Y
6.12.2. Debit card number/PAN length

Debit card account numbers range from 12 to 19 digits in length. It is required that all merchants that
accept Debit cards must be able to accept and process Debit card number lengths from 12 to 19 digits.
6.12.3. Debit edit checks

Unlike credit cards you will not be able to perform all edit checks on Debit Cards. Debit ATM cards are not
required to follow industry standards. Validation of expiration date, card range and mod 10 checks can
not be performed on Debit Cards. Debit card lengths should be checked.
6.12.4. Debit personal identification numbers

The length of the personal identification number (PIN) is determined by the cardholder's issuing bank.
The minimum length of a PIN is 4 digits and the maximum length is 12 digits.
6.12.5. Key management

Key management functionality is designed to periodically change the key that encrypts cardholder PIN's.
There are two basic methodologies: “Master Session” and “DUKPT” (Derived Unique Key per
Transaction). DUKPT derives a new key with every debit authorization request and is only used in PIN
pads. Master Session requires a periodic working (session) key request transaction. The new working key
is transmitted encrypted under the static master key. For new merchant implementations, Master Session
is restricted to host-to-host links, i.e. merchant configurations that include a Host Security Module (HSM).
In addition, effective January 2005 Master Session implementations using a HSM must use Triple DES
(TDES) encryption with double-length keys. First Data will be converting merchants utilizing an HSM from
Single DES to TDES.
PIN pad Master Session key management is not acceptable for debit processing. All PIN pad devices
must utilize DUKPT key management.
The Derived Unique Key per Transaction (DUKPT) System of “derived” keys is used in a point-of-sale
(POS) environment where the Host can accept transactions from a large number of unique PIN entry
devices. This technique involves the use of a non-secret “key serial number” and a secret “base
derivation key”. On each transaction, the PIN pad uses a unique key based on a previous key and the key
serial number, which contains a transaction counter. It encrypts the PIN with this key, and then sends
both the encrypted PIN and the key serial number to the Host. The Host, either First Data or a merchant
system incorporating an HSM, has the responsibility for maintaining the base derivation keys.

First Data currently supports TDES DUKPT.


Appendix L First Data ISO 8583 Global Specification
6.12.5.1. Triple DES Requirement

Merchants are required to comply with ANSI and Debit Network mandates regarding Triple DES (TDES)
encryption of the transmitted PIN. The encryption method is Triple Electronic Code Book (TECB) as
defined in sections 6 and 7 of ANSI X9.52-1998. First Data supports double-length working keys and
requires that these be randomly generated, i.e. key halves are unique.
Triple DEA with Double-Length Keys as the Suggested Remedy
The recommended remedy to [the weakness of DEA] has been in use since 1976: triple-DEA with double-
length keys (“two-key-triple-DEA”). In this approach, presented in ANSI X9.52 as “TECB”, the “encrypt”
operation requires three DEA operations. First, the clear text is encrypted using a first key. Second, the
resulting cipher text is decrypted using a second key. Third, the result of this second DEA operation is
encrypted using (again) the first key. Decryption is the inverse operation, namely decrypt/encrypt/decrypt.
Several networks have required Triple DES (TDES) encryption, and Visa is the only one at this time with
a stated deadline: by July 1, 2010, all PIN entry devices must be using Triple DES encryption.
Projects are underway to support TDES on First Data hosts and at the point of sale, with the intention of
deploying TDES PIN pads to new merchants as soon as possible, and of providing the longest possible
lead-time for existing merchants to make the conversion to TDES.

6.12.5.2. Working Key Request: Dynamic Key Exchange

The 0800 working key request instructs the First Data Host to generate and return a random working
(session) key. The minimum recommended key change frequency is every 24 hours or every 50,000
transactions, whichever occurs first. Frequent key changes offer some protection against electronic fraud
intended to determine cardholder PIN’s.
Merchants incorporating a Host Security Module (HSM) into their system use the 0800 transaction. The
merchant HSM will accept DUKPT output from PIN pads at the point-of-sale (POS) and translate the
encrypted PIN to the current working key shared with First Data. A master key (KEK: key exchange key or
ZMK: zone master key) must be established in coordination with the First Data Key Management office
prior to the start of processing. Upon receipt of a 0800 message, the First Data host returns the initial or
new working key in Bit 63 of the 0810 response. The working key check value is ALSO returned in Bit 96.
This value can be compared with the check value provided by the merchant HSM when new key is
translated for storage on the merchant host.
For merchants that have multiple hosting facilities they must be able to propagate the working key
between their systems prior to submitting the next transaction. To assist with transactions in flight First
Data will hold the previous key for a maximum of 30 seconds and will accept the previous and new key.
After 30 seconds the previous key will not be accepted.
6.12.6. Debit Authorization Request

Debit authorization request messages are submitted on behalf of a request for authorization on purchase
of goods or services for a specified amount.
At the time of the approved authorization response the funds are depleted from the cardholder account by
the issuing bank. The merchant’s terminal application software must wait a minimum of 40 seconds for
the 0210 debit response message.
6.12.7. Debit Authorization Request with Cash Back

Debit authorization request messages with cash back are submitted on behalf of a request for
authorization on purchase of goods or services for a specified amount in addition to a cash back amount.
The amount of cash requested by the cardholder is submitted in the *Additional Amount field (Bit 54). The
Transaction Amount (Bit 04) must equal the total amount of the purchase or services and cash back
amount. The appropriate Processing Code (Bit 03) must be provided to indicate that cash back is
included within the authorization request. At the time of the approved authorization response, the funds
are depleted from the cardholder account by the issuing bank.


6.12.8. Debit Return

A return “credits” the cardholder’s account for goods or services previously purchased using the same
debit card account number. Returns are typically processed a day (or days) after the cardholder
performed the original purchase. The networks require that the cardholder be present and they swipe
their card and enter their PIN.
Returns are supported only for merchants that have a host based system with a frame relay or lease line
interface to First Data, availability of returns for dial up interfaces may be approved on a case by case
basis.
For a merchant to support returns they must have a contractual agreement and understand liability with
their bank alliance prior to testing and implementation. Software vendors should not promote or
implement returns as a universal or global offering.
A return is submitted to First Data in a 0200 message type with a processing code 200040 merchandise
return to default account. Return transaction types do not support cash back amounts.
Not all networks support return transactions. When a return is received, First Data will evaluate which
networks support returns and submit the transaction to the network. If First Data is unable to route the
return to the network, a response code of G39 will be returned in BIT 39. First Data will only generate an
approval if an approved response is returned from the network. First Data will not perform a match
against the original authorization request and does not verify for duplications prior to transmitting the
request to the Network.
The funds may not be credited back to the card holders’ account immediately. This is dependant upon the
Network and card issuer.
The merchant’s terminal application software must wait a minimum of 40 seconds for the 0210 debit

response message. Refer to REVERSALS if a response is not received.
The merchant will need to follow their corporate policy if they are unable to support return transactions.
First Data suggestions are to issue a store credit, cash refund or follow merchants’ corporate policies.
Any settlement discrepancies will be identified in the reconciliation processes done at First Data.

6.12.9. Void Processing for Debit

A void “credits” the cardholder’s account for a transaction being performed while the customer is at the
point of sale. This transaction is meant to correct an error or to accommodate a customer’s change of
mind after the original 0200 authorization request was approved. A void is a clerk-initiated transaction.
The networks require that the cardholder be present and the void must be the next financial transaction.
Each debit network has various and changing time frames allowed for void processing (I.e. 25 minutes to
24 hours). To better insure that the reversal request is processed as well as First Data’s ability to catch
duplicate voids the void request must be sent within 25 minutes of the authorization request (0200/0100).
Voids are supported only for merchants that have a host based system with a frame relay or lease line
interface to First Data.
For a merchant to support voids they must have a contractual agreement and understand liability with
their bank alliance prior to testing and implementation. Software vendors should not promote or
implement voids as a universal or global offering.
A Void must never be submitted in lieu of a reversal. A void of a 0400/0410 (reversal) or (void of a void)
are not supported for 0400 void transactions.
A void is only supported if the original message type was a 0200 authorization request and the
transaction was approved. Voids are supported on sales and returns. The merchant will need to follow
their corporate policy if they are unable to perform the transaction. First Data suggestions are to issue a
store credit, cash refund or 0200 return (refer to Debit Returns for procedures and policies).
A void is submitted to First Data in a 0400 message type with the same merchant Id, terminal Id and
processing code that was submitted in the original 0200 authorization request. A value of 18 must be
present in field ID 25 (Transaction Code) to indicate a clerk-initiated void. Partial voids are not supported.
The amount, including cash back (if applicable) must be the same amount(s) as the original 0200
Once a void is received from a merchant, First Data will attempt to match the void to the original
authorization request. A response code of A02 will be returned in BIT 39 (Transaction Not Allowed) if a
match is not found.
The funds may not be credited back to the card holders’ account immediately. This is dependant upon the

Networks ability to match the transaction request along with the individual card issuing banks policies and
procedures of processing the void/correction.
Please note that a response code (BIT 39) of ’00 or ‘79’ does not denote the processing of the void but

the acknowledgement of the request. It does not necessarily mean the approval of the request. It confirms
that First Data has matched the original authorization request with the void and First Data will submit the
void request to the network.


Any settlement discrepancies will be identified in the reconciliation processes done at First Data.
The debit networks require that a void must immediately follow the original 0200 authorization request
and its 0210 response which was approved.
Example:
A 0200 authorization request is submitted and approved.
A 0400 void request is submitted against the previous authorization request.
A merchant can attempt a return if the last 0200 authorization request is not the transaction to be voided
(Refer to Returns within this document for procedures, requirements and processes).
The void must occur prior to the batch settlement cycle. For merchants that are set-up for host capture,
First Data creates settlement batches at different intervals through out the day. If established as host
capture the void must occur within 25 minutes of the authorization request. If they are not submitted
within 25 minutes the transaction will not be adjusted.
The merchant’s terminal application software must wait a minimum of 50 seconds for the 0410 debit
response message.
If a 0410 Void Response is not received, First Data suggests that the 0400 Void Request be sent again,
up to 3 attempts. If the 0410 Void Response is still not received then the transaction will need to be
reconciled during the off-line back office process if there is a discrepancy.
If First Data receives multiple void requests for the same transaction (merchant ID, terminal ID, card
number, dollar amount(s) and receipt number) and a match is found First Data will return an ‘00’ response
in BIT 39. First Data will identify a duplicate void and not transmit the duplicate void request to the
network as long as the close batch processing has not been performed and First Data has not received
more than 5,000 reversals or voids in the past 24 hours. The transaction totals and time frames are a
combined total for all merchants that perform reversal and void transaction types to First Data.

Scenario–Original 0200 have been approved and the customer changes his or her mind or a
transaction error needs to be corrected. (Void)
Merchant sends a 0200 Debit authorization request message to First Data and waits for the
approval response. Note: Only approved transactions can be voided.
The customer changes his or her mind about performing the transaction, or an error in the
transaction is discovered that needs to be corrected (i.e., incorrect transaction amount, cash
back inadvertently requested, etc).
The merchant sends a Void transaction to First Data using original 0200 message. Merchant
must change message type from 0200 to 0400. In addition, the merchant must include Field 48
– Message Reason Code for Debit Reversals. The value supplied in the Message Reason
Code sub-field of Field 48 should be 4000, signifying that the reversal is being generated as
the result of a clerk-initiated Void. All other field values must remain exactly the same as they
were in the original transaction (e.g., Bit 3 [Processing Code], Bit 11 [Receipt Number], Bit 12
and 13 [Local Date/Time], Bit 35 [Track 2 Data], etc.).
First Data will acknowledge receipt of reversal by sending a 0410 response. First Data will
always send an Approval Code of 888888 or 868686 on a 0410, and Bit 39 equals "76." First
Data will not check whether original transaction occurred or not. First Data will not approve the
reversal if the 0400 could not be parsed as described in these specifications.
Merchant should check Bit 39 and verify that the Result-Code equals "76." If so, the terminal
should continue with next transaction; otherwise, the merchant should continue to send the
0400 to First Data until the merchant receives a 0410 from First Data with a Result-Code of
“76.” This guarantees a reversal of transaction at First Data.
If the response for Debit Void is not received, you may try the request again (up to 3 attempts)
after waiting the appropriate time-out considerations.


6.12.10. Reversal Processing for Debit And EBT

First Data supports merchant-generated Debit/EBT card reversals (also referred to as time-out reversals).
A merchant is responsible for generating the reversal transaction if no response is received from First
Data or the transaction did not successfully complete at the point of sale register. The merchant may not
receive any response from First Data if the merchant loses the communication link during response
processing.
0400 Debit reversal messages may be sent to cancel out the effect of a previous 0110 and 0210
authorization response message. A card processor removes the hold on funds when it receives an
authorization reversal message. The funds may not be reversed back to the card holders’ account
immediately. This is dependant upon First Data and the Network Gateway’s ability to match the
transaction request along with the individual card issuing banks policies and procedures of processing the
reversal.
The reversal message is only supported for 0100/0110 pre-authorization and 0200/0210 (sales and
returns) Debit Authorization. A 0400 reversal is not supported for 0400 void request messages. A reversal
request should not be generated in lieu of a refund or void.
The reversal request (0400) can not be generated prior to the minimum 40 second timeout of the
0200/0100 authorization request. The reversal request must be sent to First Data immediately after
waiting a minimum of 40 seconds for the authorization (0200/0100) request due to various and changing
timeframes allowed by the Networks.
Each debit network has various and changing time frames allowed for reversal processing (I.e. 25
minutes to 24 hours). To better insure that the reversal request is processed as well as First Data’s ability
to catch duplicate reversals the reversal request must be sent within 25 minutes of the authorization
request (0200/0100). First Data will identify a duplicate reversal and not transmit the duplicate reversal
request to the network as long as the close batch processing has not been performed and First Data has
not received more than 5,000 reversals or voids in the past 24 hours. The transaction totals and time
frames are a combined total for all merchants that perform reversal and void transaction types to First
Data.
The reversal must occur prior to the batch settlement cycle. For merchants that are set-up for host
capture, First Data creates settlement batches at different intervals through out the day. If established as
host capture the reversal must occur within 25 minutes of the authorization request. If they are not
submitted within 25 minutes the transaction will not be adjusted.
If the 0410 reversal response is not received you must retry the 0400 reversal request again after waiting
40 seconds for the 0410 response. A "PLEASE RETRY" response within 40 seconds is a legitimate
response, and the merchant should not generate any reversal transaction. First Data will automatically
generate a reversal transaction whenever a transaction exceeds our own time-out limit. If the 0410
reversal response is not received you must retry the 0400 reversal request up to 3 attempts.

First Data suggests that the 1st reversal (0400) attempt be submitted 60 seconds after the timeout of the
0200/0100 authorization request. If no response is received (50 second timeout) from the 1st 0400
reversal request wait 2 minutes or until network/application issues have been resolved (if applicable) then
retry the reversal request. If the 2nd reversal request is not responded to within 50 seconds wait 5
minutes or until network/application issues have been resolved (if applicable), then retry the 3rd reversal
request.
You can not generate a queue of reversal attempts at one time without waiting for the response. The
requests must be single threaded at the location level (First Data merchant number).
Once the 0410 response is received the transaction is complete and the reversal retry attempts must
cease.
Please note that a response code (BIT 39) of approved (00 for authorization with capture or 76 for
authorization without capture) does not denote the processing of the reversal, but the receipt of the
request. Any settlement discrepancies will be identified in the reconciliation processes done at First Data.

Scenario – Merchant does not receive response to the 0200 from First Data
The sequence of events in which a merchant should send a reversal transaction to First Data is described
below:
Merchant sends a 0200 Debit authorization message to First Data.

Merchant does not receive any response from First Data within 40 seconds or the transaction
did not successfully complete at the point of sale register. Merchant sends reversal transaction
to First Data using original 0200 message. Merchant should change message type from 0200
to 0400. All other field values should remain exactly the same as they were in the original
transaction (e.g., Bit 3 [Processing Code], Bit 11 [Receipt Number], Bit 12 and 13 [Local
Date/Time], Bit 35 [Track 2 Data], etc.).
First Data will acknowledge receipt of reversal by sending a 0410 response. First Data will
always send an Approval Code of 888888 or 868686 on a 0410, and Bit 39 equals "76." First
Data will not check whether original transaction occurred or not. First Data will not approve the
reversal if the 0400 could not be parsed as described in these specifications.
Merchant should check Bit 39 and verify that the Result-Code equals "76." If so, the terminal
should continue with next transaction; otherwise, the merchant should continue to send the
0400 to First Data until the merchant receives a 0410 from First Data with a Result-Code of
“76.” This guarantees a reversal of transaction at First Data.
A "PLEASE RETRY" response within 40 seconds is a legitimate response, and the merchant
should not generate any reversal transaction. First Data will automatically generate a reversal
transaction whenever a transaction exceeds our own time-out limit.
If the response for Debit Reversal is not received, you may try the Reversal request again (up
to 3 attempts) after waiting the appropriate time-out considerations.
Debit Reversal functionality must be programmed very carefully. After the merchant completes the
reversal, a new receipt number must be generated for the next transaction.


6.12.11. Electronic Benefits Transfer (EBT)

Electronic Benefits Transfer (EBT) is the electronic distribution of government benefits through point-of-
sale terminals and ATMs. These transactions are initiated with a plastic mag stripe EBT card issued by
individual states or local jurisdictions.

Although EBT processing is very similar to on-line debit processing, there are some important
differences, especially related to Food Stamp transactions. This document emphasizes these
differences and provides separate examples of EBT requirements.

There are two types of EBT programs: Food Stamps and Cash Benefits. Each has a different transaction
set.
Food Stamp Transactions

FNS Number
The United States Department of Agriculture, Food and Nutrition Service (FNS) must authorize merchants
who wish to accept food stamp. A merchant applies directly to this agency. If the necessary requirements
are met, the merchant is issued a certificate with a seven-digit number for each participating merchant
location. This number, referred to as the FNS number, uniquely identifies the merchant location to the
state EBT processor system. In the First Data system, this number must be set up in the Cross-Reference
File (XREF) under usage indicator I. The number is pulled from the XREF file and inserted into each
transaction request before the request is passed on from the front end. This number is used only for Food
Stamp transactions.
Food Stamp Cardholders
Under the EBT system, food stamp clients apply for their benefits in the usual way, by filling out a form at
their local food stamp office. Once eligibility and the level of benefits have been determined, an account is
established in the client’s name, and food stamp benefits are deposited electronically into the account
each month. A plastic card similar to a debit card is issued, and a personal identification number (PIN) is
assigned or chosen by the client to provide access to the account.
When a food stamp client is ready to purchase groceries, the client's card is run through an electronic
reader or a POS (point-of-sale) terminal, and the client enters the secret PIN number to access the food
stamp account. A transaction request is transmitted to the processor for the issuing state. The processor
electronically verifies the PIN and account balance and sends either an authorization or a denial back to
the retailer. The client's account is debited for the amount of the purchase, and the retailer's account is
credited. No money or food stamps change hands.

Transaction Set
The following food stamp transactions are supported by First Data EBT processing and are required to be
in each application.
Food Stamp Purchase:

The remaining balance transmitted from the processor must be printed on the receipt. Cash back is not
allowed on Food Stamp transactions. Manual entry of account number is allowed if Track 2 cannot be
read. PIN entry is required. Cash Back is not allowed.
Food Stamp Merchandise Refund:

Manual entry of account number is allowed if Track 2 cannot be read. PIN entry is required.


Voucher Clear:
This is an online force-post entry of a previously voice-authorized food stamp transaction. Entry of the
authorization number and the voucher number is required, and the Account Number is manually entered
without PIN data.
If any aspect of the EBT system is down, the merchant may call the issuing state’s processor for a voice
authorization for Food Stamp transactions only. The merchant must complete a Manual Voucher form
(provided by First Data or state EBT contractor) to obtain the authorization number, the voucher number
and the client’s signature. This puts a hold on the funds in the client’s account for the amount of the voice
authorization. To receive payment for the transaction, the merchant must process a Voucher Clear
transaction within ten days of the voice authorization for electronic auth response. Only electronic auth
response thus received should be used for settlement.
Balance Inquiry from Food Stamp Account varies by state. PIN entry is required.
Cash Benefit Transactions
Various state and county agencies issue cash benefits for various needs; the most familiar is Temporary
Assistance to Needy Families (TANF). If the benefit is issued electronically, it can be spent like cash
wherever EBT payments are accepted.
The following are valid cash benefit transactions:
Purchase only from cash account:
The remaining available balance is not required, but should be printed on the receipt if the
processor returns it. Track 2 should be sent if available; and PIN entry is required.
Purchase with cash back from cash account. Track 2 and PIN entry are required.
Balance inquiry from cash account:
Track 2 and PIN entry are required for Cash only from cash account. The amount is not to be
limited and client is permitted to access the remaining available balance in the account. Track 2
should be sent if available; and PIN entry is required.
The following transactions are NOT ALLOWED for cash accounts:
Electronic refund to a cash account.

Voice authorizations with a voucher clear (i.e., if the network is down, no cash benefits may be
administered).

Receipt Requirements
Upon completion of an authorized transaction, other than a Balance Inquiry, each POS Terminal must
make a receipt available to the Cardholder.
In addition to the usual receipt elements, an EBT receipt must include the printed account balance(s), as
returned from the issuer. The account accessed, i.e., Food Stamp or Cash Benefit, should be indicated.
Only the last four digits of the cardholder’s number are to be printed on the receipt.
Once a Food Stamp purchase has been successfully authorized or a Food Stamp transaction has been
declined for insufficient funds, the POS terminal operator must print the Available Balance communicated
by the Cardholder Authorization System on the receipt. The reason a declined transaction has been
denied, as returned by First Data, must be printed on the receipt.


First Data ISO 8583 Global Specification Appendix M
6.13. Appendix M — First Data Processing Environment

6.13.1. First Data Processing Environment Overview
First Data accepts authorization requests in the standard First Data implementation of the ISO 8583
format.
6.13.2. FDCS/6000 Front — End Processing Support

The primary First Data Authorization Data Centers are located in Denver, Omaha, Hagerstown (MD), and
Melville (NY). Within each Data Center are multiple systems handling electronic communications of client
interface systems and host-level interfaces in an authorization environment. Each mini-computer is a
logical equivalent of the other with fully duplexed links for Visa, MasterCard, AMEX, Diners, Discover,
JCB, NPC (JBS), Fidelity (Certegy), or TeleCheck. Each Data Center operates in both a primary and
secondary role, with each one providing a complete back-up site to the other.
The major elements consist of the following:
Interactive processing
The line protocols, which First Data has found to serve the industry well, consist of the following:
 TCP/IP–This protocol is widely used within the industry and throughout the world. TCP/IP is
accepted across most hardware and operating system platforms. It provides ease of
configuration, optimal throughput and maximum flexibility. It is currently the protocol of choice.
 X25–X 25 is an international packet switching standard used in many networks, worldwide. It is
packet oriented with a variable block size and supports either Switched Virtual Circuits (SVC) or
Permanent Virtual Circuits (PVC). Supported for legacy clients only.
 SNA–SNA networks have been in existence for many years and provide packet-oriented data
transmission. LU Type 0 and 2 are supported on the First Data/6000 platform. First Data can
emulate a primary or secondary LU type 0 station and a secondary LU Type 2 station.
Supported for legacy clients only.
Credit card authorizations.

Financial transactions (DEBIT and EBT).
Check guarantee/verification authorizations.
Address verification processing.
Fully duplexed systems are attached to an uninterrupted power supply with diesel generator back-
up.
Uptime level of 99+%.


First Data ISO 8583 Global Specification Appendix N
6.14. Appendix N — Host Capture

The host system of First Data captures those authorization requests that are electronically approved and
maintains them in a data capture file. This information is later used for settlement. The settlement batches
are created at different intervals through out the day.
In order to support host capture, the merchant may require additional communication arrangements to
access First Data front-end systems that support host capture. First Data will also require configuring the
appropriate back office system to support host capture for the merchant. Once the merchant is
established to support host capture transactions, they must indicate how First Data should process the
transaction, in Bit 31 (Acquirer Reference Data) in the transaction messages. A zero, one, and two in Bit
31 indicates an authorization only, authorization and capture, and capture only transaction respectively.
For Canadian domiciled merchants, availability of host capture for credit and debit is dependant on
merchant’s sponsorship with the acquirer. Please refer to your Certification Analyst or Project Managers
for the availability.
The table below describes each type of transactions supported in a host capture system:
Value in Bit Type of Transaction Descriptions

31
0 Authorization Only (for credit A transaction used to transmit an
and debit) authorization request to First Data where it
is not captured on the First Data host for
settlement processing. The examples of
these transactions are:
Dual Event
Address Verification Services only
Balance Enquiry only
Check Authorization
1 Authorization and Capture (for A transaction used to transmit an
credit and debit) authorization request to First Data where
the approved transaction is captured on the
First Data host for settlement processing.
This is supported for Electronic Commerce,
MOTO, and Retail.
2 Settlement Capture (for credit A transaction that was previously authorized
only) and is submitted to First Data’s host to be
captured for settlement processing only.
For example, a merchant may decide to

initially submit the transaction as an
Authorization Only request. A subsequent
transaction is then submitted to First Data’s
host to be captured for settlement
processing. In this case, the merchant
must retain additional records from the
authorization and must send that
information when submitting the
transaction for settlement.


Appendix N First Data ISO 8583 Global Specification
Value in Bit Type of Transaction Descriptions

31
Other examples of capture only
transactions include:
Voice Authorization-If the

Authorization Only or Authorization
and Capture request receives a
response code of '01', it means
referral, call for authorization. In this
case, the authorization is obtained
from the authorization response unit.
The capture only transaction is then
submitted to First Data’s host to be
captured for settlement processing
only.
Return/Refund – Transaction that is
never submitted to First Data for
authorization. However, it is
submitted to First Data’s host to be
captured for settlement processing.
The reversal must occur within 25 minutes of the original auth request. If received within this timeframe,
the transaction will be removed from the data capture file and will not be included in the settlement
process. If it doesn’t, the approved transaction amount captured at First Data will not be adjusted.
Another stipulation is that the merchant must supply a unique number for each transaction in the Retrieval
Reference Number field (Bit 37). This is necessary for reversal and reconcilement processing.

First Data ISO 8583 Global Specification Appendix N
6.14.1. Dual Event Settlement

Dual Event Settlement is only available for merchants processing with First Data using Host
Capture.
A single authorization may contain multiple items. However, the merchant may fail to ship all the items, or
render all the services. Thus the total authorized amount cannot be settled. Dual -Event Settlement
process is applicable to the above scenario where the total authorized amount cannot be settled. This
specifically applies to ecommerce and direct marketing industries. Under association rules, a cardholder
can not be billed for items that have not been shipped or services have not been rendered.
Dual Event Settlement will stream line the process of the transaction flow when the merchant fails to
determine, before authorization, whether all the items can be shipped; and all the services can be
rendered. During the initial authorization request the merchant must flag the transaction as Authorization
only, so that First Data will not capture the transaction for settlement processing. The approved
authorization transaction will be captured by the merchant. The merchant will only need to send the
settled amount for the shipped items and identify the total amount previously authorized in the Capture
Only request. The FDC host will capture the transaction for settlement processing and initiate the Partial
Reversal on the merchant’s behalf. Upon subsequent shipments of that order, the merchant must obtain
another authorization and then settle that authorization.
Described below is an example of the sequence of events and the critical fields to invoke this processing:
Initial Authorization Request
Bit 4-Transaction Amount is the Authorization Amount for two items ordered by the consumer.
Bit 31-The Acquirer Reference Data must be set to “0” (authorization only)
Initial Authorization Response
Bit 38-Authorization Code must be retained for settlement and interchange qualification.
Bit 63 – Table 14 – Compliance Data varies depending on the association. Compliance. Data must
be retained for settlement and interchange qualification.
First Shipment/Settlement Request
Bit 4-Transaction Amount is the settled amount for the item being shipped.
Bit 31-The Acquirer Reference Data must be set to “2” (capture only)
Bit 38-Authorization Code from the Initial Authorization.
Bit 63 -- Table 14 – Compliance Data from the Initial Authorization.
Bit 63 – Table 70 – Dual Event Settlement Table contains the Total Authorization Amount.
Subsequent Shipment/Settlement Request
Bit 4-Transaction Amount is the settled amount for the item being shipped.
Bit 31-The Acquirer Reference Data must be set to “1” (authorization and capture


First Data ISO 8583 Global Specification Appendix O
6.15. Appendix O — Canadian Debit Processing — Terminal

MAC/EKME
A message authentication code (‘MAC’) is an authentication tag (sometimes called a checksum) derived
by applying an authentication scheme, together with a secret key, to a given message. MACs are
computed and verified with the same key, so that verification is restricted to the intended recipient. This
section covers the methodology used to generate or verify a ‘MAC’ block and the verification involved in
the Encrypted Available Balance (‘EKME’) block at the terminal. The terminal MAC discussed in this
document applies to block cipher-based MAC.
The MAC is a value derived using an algorithm on certain data elements in a message, and the terminal
includes the resulting value in the message when sending. The receiver calculates the MAC using the
same data elements. If the receiver-calculated value matches that in the message, it is relatively certain
that the message has not been tampered with or damaged during the transmission.
A 16 byte MAC block, with the first 8 bytes containing valid data, and the remaining 8 bytes being zero
filled will be generated for each message originating from the terminal except for Canadian Debit key
updates (Message 0800/0810, Processing Code 000000).
Responses received by the terminal may or may not have a MAC block, depending upon the response
code received. For example, if the transaction didn’t make it to the host, or encountered a host system
error host (such as the key server or encryption box being unavailable), then the MAC block returned to
the terminal will be blanks. But if there is a valid MAC block present in the MAC field in the response, the
terminal does the verification on the MAC.
The encrypted data block that has the balance amount for the card is called the EKME block, and is also
16 bytes in length. Unlike the MAC block, the terminal will always be receiving and never sending an
EKME, so the only operation it will perform on it is decryption, never encryption. All balance Inquiry
transactions will have a MAC block in the response even if the transaction was declined. If the request
was approved, the terminal formats the response information and sends it to the PIN pad. The PIN pad
decrypts the EKME block and displays the balance amount on the PIN pad display. Only the customer
who does the Balance Inquiry using his/her card is supposed to view the balance amount displayed on
the PIN pad.
The encryption/decryption process depends upon three secret keys stored within the terminal known as
the working keys, and one permanent key stored in the PIN pad. The working keys are:
TMAC–Terminal Message Authentication Code (MAC) working key. A MAC Key is used to
authenticate selected data elements in messages.
TKPE–Terminal PIN Encryption working key. A PIN Encryption Key is a used to protect PINs as
they are transmitted.
TKME–Terminal Message Encryption working key. A Message Encryption Key is used to encrypt
and decrypt selected message elements, excluding PINs.
These working keys can be changed at any time based on rules and regulations for the Key changes
specific to that merchant or client.



The PIN pad is injected with a permanent Terminal Key Encryption Key (TKEK), which is used to encrypt
and decrypt the working keys that are exchanged between the Host and the terminal. This key must also
be stored on the host encrypted under the host Master Key.

Canadian Debit key update MAC process (Message 0800/0810, Processing

Code ‘000000’)
Once the terminal has been loaded with the software application, it is ready to request its 3 working keys.
Performing a parameter download sends a request to the host to generate 3 working keys (TMAC, TKPE,
and TKME) and the 4 byte check digit associated with the message authentication working key (TMAC).
The Canadian Debit Key Update request should be sent to the host as soon as the terminal has
successfully completed a parameter update (init) session but before the line is dropped for dial terminals.
The key update request is only sent for terminal applications that support Canadian Debit and when
Canadian Debit is enabled during the parameter update (init).
The response for the key update request, if successful, will contain the new terminal working keys, the
MAC check digit and a MAC block. When the terminal receives the response, it sends a message to the
PIN pad to verify the MAC block. The PIN pad expects a MAC verification request to have a specific
format, as shown below, including data elements not present in the host response message. Therefore,
the terminal application will create a message that includes the host response information in the
appropriate fields, as well as all of the additional data fields expected by the PIN pad, filled with zeros.
The terminal sends this new message to the PIN pad, requesting MAC verification. The pin pad sends a
message back to the terminal indicating success or failure of the MAC verification. If the PIN pad
successfully verifies the MAC block, the new keys and the MAC check digit are stored in the terminal. If
the MAC block fails verification at the PIN pad, then the terminal displays the message “MAC Verification
Failed”.
Below is the format in which the terminal sends the data to the PIN pad for the MAC verification on a
successful parameter download response. The fields are separated by a space character.
1. Account number (PAN)–19 bytes. All zeroes.
2. Processing code–6 bytes. All zeroes.
3. Transaction amount – 12 bytes. All zeroes
4. Trace number–6 bytes.
5. Terminal RRN–12 bytes. All zeroes
6. Response code–2 bytes.
7. Terminal MAC working key–16 bytes.
8. Terminal KME working key–16 bytes.
9. Terminal KPE working key–16 bytes.

The 8 bytes of the MAC block that contain valid data are also sent to the PIN pad.
Authorization/Reversal request MAC process (Message 0200/0210 and

Message 0400/0410)
The terminal generates a MAC block for an authorization/reversal request by sending the following data
elements to the PIN pad.
1. Account number (PAN)
2. Processing code
3. Transaction amount
4. Trace number
5. Terminal RRN

Appendix O First Data ISO 8583 Global Specification

The above space-separated fields will be sent, along with the TMAC working key, to the PIN pad in a
request to generate an encrypted MAC block. The PIN pad uses this TMAC working key to generate an
encrypted MAC block based on the data elements provided. The terminal receives the MAC block,
includes the MAC block in the request message and sends it to the host.
Authorization/Reversal response MAC process

When the terminal receives the authorization/reversal response from the host, the MAC block, the TMAC
working key, and the appropriate additional data elements as noted below, are sent to the PIN pad in a
MAC verification request. The TMAC working key will be used by the PIN pad to verify the MAC block
received. The data elements sent to the pin pad are space separated.
The following are the mandated data elements that are used for the MAC verification by the PIN pad:
1. Account number (PAN). This is a variable length field and the maximum length is 19 bytes
2. Processing code
3. Transaction amount
4. System trace number
5. Terminal RRN
6. Response code. (Values: Approval – 00, Decline – 57)

Apart from the above mentioned data elements; there are 3 other optional data elements. If any of these
are present in the response message it will be included in the MAC verification.
TMAC working key.

TKME working key.
TKPE working key.
The 8 byte MAC block is also sent to the pin pad.
If the MAC verification fails at the PIN pad, the terminal will display or print “MAC Verification Failed".
Subsequently, a reversal will be generated and stored in the terminal with a reason code of 30. If the
MAC verification failed due to TMAC sync error, then a reversal will be generated with a reason code of
31. This reversal will be transmitted to the host, the next time a transaction is attempted. For any
transaction to be processed, the stored reversal has to be processed first. If the host declines the
reversal, or if the reversal response fails MAC verification, the reversal will be retransmitted up to 2
additional times. After the third unsuccessful attempt, the reversal will be deleted. New keys may be
received on any reversal attempt and should be used to process the response in which they were
received.
For 0400 Canadian Debit reversals, the MAC check digit is used during Canadian Debit Processing to
distinguish a MAC synch error from a MAC (TMAC) verification error when MAC verification fails. If the
MAC authentication fails for a transaction and the MAC Check Digit received in the transaction response
does not match the MAC Check Digit stored when the MAC working key was last received from the host,
then the 0400 Canadian Debit Reversal Code is set to ‘31’ for synch error; otherwise, the Reversal Code
is set to ‘30’ for verification failure.

EKME/Data Block (Encrypted available balance).
The EKME block is an encrypted data block containing the balance amount of the customer’s account.
This encrypted block will be decrypted at the PIN pad and the balance amount will be displayed at the pin
pad display for a few seconds.
EKME block is 16 bytes long. The host sends the encrypted EKME block on a Balance Inquiry approval
response. The terminal sends this block along with the TKME working key (Message encryption key) to
the PIN pad. The PIN pad decrypts the EKME/Data block and displays the balance amount on the pin
pad.
If pin pad fails to decrypt the data block, the terminal will display/print ‘Decryption Failure’. Message
decryption failure can only occur on balance inquiry messages returned to the terminal where balance
data is present.
There are 2 types of failures that can happen.
Message Decryption Failure

Message Encryption Key synchronization error.
In both of these circumstances a reversal will be generated with the appropriate reversal reason code of
86.


First Data ISO 8583 Global Specification Appendix P
6.16. Appendix P — Frequently Asked Questions

Debit
What is a Financial Transaction (Debit/EBT) Reversal?
A financial transaction reversal is a transaction that corrects a financial transaction authorization in
progress because of a communications failure or a time-out in the transaction flow.
A financial transaction reversal is not used by the merchant as a means of crediting a customer for
returned merchandise.

What is a Financial Transaction (Debit) Void?
A Void is a specialized financial transaction that corrects the impact of an approved financial transaction
because an error was discovered in the transaction or the customer changed his or her mind.

A financial transaction Void is not used by the merchant as a means of crediting a customer for returned
merchandise.

When does a Debit Void Occur?
A financial transaction Void is needed when the 0200 transaction has been approved and either an error
is discovered in the transaction or the customer changes his or her mind.

When does a Debit/EBT Reversal Occur?
A financial transaction reversal is needed when a merchant initiates a financial authorization transaction
to First Data, but First Data fails to send a response back to the merchant. The failure of First Data to
respond to the merchant's authorization request can occur for a variety of reasons.
A financial transaction reversal is also needed whenever a merchant receives an approval but is unable
to complete the transaction on the merchant system.

How does First Data Handle Reversals?
First Data always accepts a reversal from the merchant, even if the original transaction was never
received by First Data. Once First Data receives the reversal request, it sends an acknowledgment
message to the merchant indicating the reversal was received and that the merchant can continue with
other transactions.
The onus is on the merchant to make sure that First Data responds affirmatively that it has received the
reversal. It is also the merchant’s responsibility to continue to send the reversal transaction to First Data
until it receives appropriate acknowledgment from First Data that the reversal was received.
The only situations in which the merchant should not receive an acknowledgment from First Data are as
follows: the First Data system is down; a communications line cut has been cut; or, there is an in-store
problem, and the store is unable to communicate with First Data.

What is a Visa and MasterCard Check/Debit Card?


Appendix P First Data ISO 8583 Global Specification
As an alternative to writing checks and using a credit card, most major banks have teamed up with major
credit-card companies to issue check cards.
Displayed on the face of the check card will be the card issuing banks logo, card number, cardholders’
name, both a Visa or MasterCard logo and the words “Check Card”. On the back of the check card you
there will be a signature line, magnetic stripe and the participating Debit Networks. The card numbers will
be 16 digits in length and fall within the Visa and MasterCard bin ranges. Visa card numbers start with a 4
and MasterCard starts with a 5.
Check cards are different from straight ATM cards. Check cards are also known as debit cards because
of how they work -- instead of getting credit for your purchase and receiving a monthly bill, like you do
with a credit card, a Visa and MasterCard check/debit card deducts money from your checking or savings
account.
You can use your check card as either a credit card or a debit card -- either way; it comes out of your
account.
A credit card transaction also known as an “off-line transaction” can either be swipe read through a card
reader or the card number and expiration date can be manually entered. The card holders’ signature is
required for card present transactions.
A debit card transaction also known as an “on-line transaction” must be swipe read and the PIN number
must be entered using a PIN pad. The cardholder signature is not requested.
A check card has your name, "credit" account number, the Credit Company’s logo (Visa or MasterCard),
the bank's logo and "Check Card" printed across the front of the card.
Check card companies, such as Visa and MasterCard, have agreements with banks to issue what looks
like a Visa or MasterCard credit card. A Visa or MasterCard check card can be used at any retailer that
accepts Visa or MasterCard credit cards and at ATMs worldwide.

What are ATM CARDS?
Banks issue ATM cards. The face of the ATM card includes the card holders name, account number and
bank's logo on the front of it. On the back of the ATM card there will be a signature line, magnetic stripe
and the participating Debit Networks. The card numbers can range from 12 – 19 digits in length can begin
with any number, expiration dates may not be valid and the card numbers may not be mod 10 calculated.
For this reason you can not perform edit checks of the card.
ATM cards are also known as debit cards because of how they work. A debit card transaction is also
known as an “on-line transaction”. When a cardholder uses their card for a purchase, cash back or cash
withdraw the money is ducted from the cardholders checking or savings account.
ATM cards are different from check cards. An ATM card must be swipe read and the PIN number must be
entered using a PIN pad. The cardholder signature is not requested. An ATM can be used at any retailer
that accepts PIN based debit transactions and at ATMs worldwide.



Can both savings and checking accounts be accessed using a check card or ATM card?
Whether the customer has access to their savings account is totally up to the issuing bank. Both check
cards and ATM cards can possibly have access to savings accounts – the type of card doesn’t matter. It’s
based on whether the issuer allows a customer to attach their savings account to the check card or the
ATM card when the card is used at the point of sale. The reason savings accounts are not typically
allowed point of sale access is that the rules governing how many electronic transactions can be made
are much more restrictive than for checking accounts. The very structure of a checking account is to allow
a cardholder unlimited accesses to their funds. Savings accounts are meant to be more restrictive, so the
Federal Government places limits on the types of activity that is allowed. Hence issuers many times don’t
allow a savings account to be attached to a check card or ATM card when used at the point of sale.
By far the majority of consumers only access their checking account when they’re paying at the point of
sale. Savings account access is usually only for ATM use, when the consumer would want to make a
savings deposit or withdrawal or transfer between accounts.
If a cardholder purchases goods or services using a Debit Card and returns the goods how do I
reimburse the cardholder?
A debit transaction “on-line transaction” is considered same as cash. At the time of authorization the
funds are removed from the card holders’ account. The merchant may issue a cash refund, check or store
credit. For a merchant to support returns using this message format they must have a contractual
agreement and understand liability with the bank alliance prior to support debit returns. Due to Card
Association and other regulatory restrictions, the merchant can not issue a refund on a credit card if the
initial transaction was processed as a debit. Even if the cardholders card was a check card.
Healthcare (FSA/HRA)
How do you identify whether it is a FSA/HRA card?
First Data provides the merchants with the relevant Bin Ranges which they can use to identify the
FSA/HRA cards. These Bin Ranges are included in the relevant Bin File.

How often are the Bin Files updated?
The Bin Files are updated on a daily basis.

Where do you obtain the list of eligible healthcare items?
For processing IIAS transactions you need to be a member of SIGIS. In order to be listed as a member of
SIGIS you need to visit www.sigis.com. The benefit of being listed with SIGIS is that you can obtain the
list of eligible healthcare items directly to code your products. You will be listed as a SIGIS member in
their website as well. Eventually, SIGIS will be providing you with a logo decal to post it at the entrance
just like Visa/MasterCard logos.
How often is the list of healthcare eligible items (IIAS Compliant) updated?
The list of healthcare eligible items is updated on a monthly basis.
Can a FSA/HRA card be used in a card present as well as card-not-present scenario?

Appendix P First Data ISO 8583 Global Specification
Yes FSA/HRA cards can be used in both the scenarios – card present and card not present.
Can Address Verification (AVS) CVV2/CVC2 be performed on a FSA/HRA card?

Yes CVV2/CVC2 can be performed on a FSA/HRA card. Address Verification (AVS) can be performed on
FSA/HRA cards as well.

Is partial authorization a requirement or an option?
This is an option. However if the total purchase includes non-eligible items the chances of receiving a
decline is greater if partial authorization is not supported by the merchant.
Can voice authorization be performed on a FSA/HRA card?

There is no voice authorization on FSA/HRA cards.

Can you return an item purchased by a FSA/HRA card?
Merchandise return/refund for health care cards is handled exactly the same way as it is handled for non
healthcare cards.
Will issuers return account balance as part of NSF?

Returning of card holder balances is not supported on FSA/HRA cards.
What are the requirements for voids/reversals?
Card Association requires that the merchants who are partial authorization capable must support
reversal of authorization.
Reversal of Authorization is required if the card holder does not have alternate means to pay for
the remaining balance on a partially approved transaction. The partially approved transaction
amount can not be altered for capture and settlement processing that is void/remove an item
intended to be purchased due to the full amount not being approved.
Partial Authorization Reversals are not permitted on Health Benefit Card transactions. However,
only full reversals of the approved transaction amount are supported on Health care benefit card.
Are there different response codes for FSA/HRA authorizations?

There are no new response codes for FSA/HRA authorizations.


Address Verification Service

When performing address verification what values must be present in the zip code field?
Valid characters are A-Z (upper case only) and 0-9 including spaces while embedded spaces are not
allowed. For a United States address the zip codes can either be 5 or 9 digits in length. Addresses
outside the United States may vary in length and can include alphanumeric character content. For
example Canadian zip codes are 6 characters in length and consist of numeric and alpha values. Some
addresses outside the United States do not contain zip codes, in this case the zip code must be space
filled.
Is Address Verification (AVS) required in order to achieve a better interchange rate?

In case of Visa, the merchant must attempt Address Verification (AVS) to qualify for CPS/Card-Not-
Present or CPS/Retail key Entry interchange rate.
Could there be any impact in sending default values of the card holder’s zip code such as zero
filling?
First Data will pass the zip code out to the card association. The card association will pass to the issuer
for validation. If the issuer identifies that a merchant is sending in default values they could impose fines
to the merchant.
When performing Address Verification (AVS) does the address have to match in order to qualify
for the best interchange rate?
The only instance where the Zip Code must match is if the merchant is attempting to qualify at Visa
CPS/Retail Key-Entry rate.


ISO Global 2008 3

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

ISO Global 2008 3

Uploaded by

Copyright:

Available Formats

Changes made to this document in the last eighteen months

Version 2008-3 Confidential and Proprietary ii

Changes made to this document in the last eighteen months

0100 Capture Only

Changes made to this document in the last eighteen months

Private Data section

Changes made to this document in the last eighteen months

Version 2008-3 Confidential and Proprietary v

Changes made to this document in the last eighteen months

Version 2008-3 Confidential and Proprietary vi

5.1. Table Layout .....................................................................................................................................5-2

Version 2008-3 Confidential and Proprietary ii

6.10.1. Check Guarantee/Verification Overview ............................................................................................... 6-35

Version 2008-3 Confidential and Proprietary iii

Chapter 1. New Features

Version 2008-3 Confidential and Proprietary to 1-1

List of New Features:

Version 2008-3 Confidential and Proprietary 1-2

This chapter consists of:

 Target Audience (see page 2-2)

Version 2008-3 Confidential and Proprietary 2-1

2.1. Target Audience

Transaction Types Description

For this type of transaction, settlement processing is supported through

Merchants may require additional communication changes to be made

Authorization with capture is supported for electronic commerce,

Version 2008-3 Confidential and Proprietary 2-2

Transaction Types Description

For instance, a merchant may initially decide to submit the transaction

Other examples of capture only transactions include Voice

2.3. ISO 8583 Global Specification

Version 2008-3 Confidential and Proprietary 2-3

2.4. Basic Message Format

2.5. Programming Considerations

Version 2008-3 Confidential and Proprietary 2-4

2.6. Legend of Attribute Abbreviations

125 Variable field of up to 125 characters. The ‘…’ is a three-digit length indicator (2

Version 2008-3 Confidential and Proprietary 2-5

2.7. Default Field Format

Alphanumeric Data Elements (AN)

Binary Coded Decimal (BCD)

Hex Binary (HB)

Legend of Field Requirements

Version 2008-3 Confidential and Proprietary 2-6

2.8. Message Type Identifier

Message Identifiers Description

Types of Message Identifiers used by First Data

First Data does not support partial reversals for Debit.

Network Management Messages

2.9. Standard Message Types

Version 2008-3 Confidential and Proprietary 2-8

Check Guarantee/Verification Request (ISO Message Type 0100)

Version 2008-3 Confidential and Proprietary 2-9

Financial Transaction (Debit/EBT) Request (ISO Message Type 0200)*

Version 2008-3 Confidential and Proprietary 2-10

Authorization Reversal Request Format–(ISO Message Type 0400)

For more information, refer to Appendix K on page 6-55.

Version 2008-3 Confidential and Proprietary 2-11

Financial Void Request–Debit/EBT (ISO Message Type 0400)

Test Message (ISO Message Type 0800)

Authorization Response Message (ISO Message Type 0110)

Authorization Request — ISO Message Type 0100

Financial Transaction (Debit/EBT) Response (ISO Message Type 0210)