Яяяяяя Amex Pip-Iso Oct2010

PLURAL INTERFACE PROCESSING (PIP)
TERMINAL INTERFACE SPECIFICATION

(ISO 8583 FORMAT) OCTOBER 2010
GLOBAL MERCHANT SERVICES

POS020055, v3.1, October 22, 2010
Copyright 2006-2010 American Express Travel Related Services Company, Inc. All rights reserved. This document contains sensitive, confidential and trade secret information; and no part
of it shall be disclosed to third parties or reproduced in any form or by any electronic or mechanical means, including without limitation information storage and retrieval systems, without
the express prior written consent of American Express Travel Related Services Company, Inc.
American Express Proprietary & Confidential
PIP Terminal Interface Spec (ISO 8583)
Revision Log
Version Date | Content Owner | Prepared By | Description
3.1
10/22/10 | J. Cheney | R. Wong | See Below

Added new cover and modified format of Revision Log.
Page 63: Added paragraph beginning American Express limits the maximum value that can be approved in
this field.
Page 77: Changed last five digits in Expresspay Pseudo-Magnetic Stripe example from 00200 to 12345.
Page 92: In ISO 7813 Format explanatory text, changed VLI from 60 to 76 bytes, changed total length
from 61 to 77 and appended 6789012345678901 (16 bytes) to end of example in diagram.
Page 93: Changed Expresspay Pseudo-Magnetic Stripe Format example, relative positions 40-44 from
~~012 to 12345.
Page 153, ISO 7813 Standard, Track 1: Changed Discretionary Data from 5 to 21 bytes, and deleted Unused
subfield, which was 16 bytes. Total (length) unchanged.
Pages 155-168: Appended 6789012345678901 (16 bytes) to end of sample data in diagrams.
Pages 162, 174: Changed text, as indicated, Currently, American Express has no definite plans to require
USA does not expect Merchants to interrogate
Page 166: Changed Length of Field from 5 bytes to 5 bytes ANSI X4.16 and 21 bytes ISO 7813.
Also changed ISO 7813 Approximate Position from 57-61 to 57-77.
Page 167: Changed ISO 7813 Approximate Position from 62 to 78.
Page 168: Changed ISO 7813 Approximate Position from 63 to 79.
Page 169: Deleted references to ISO 7813 (3 places), added Note: This field applies only to ANSI X4.16
Standard Track 1 and is not applicable to ISO 7813 and deleted diagram containing sample data.
Pages 183-184: Revised Expresspay Pseudo-Magnetic Stripe Formats explanatory text and Track 1 & Track 2
Subfields, as follows: Changed ATC to Application Transaction Counter (ATC). Changed Track 1, Cardmember Name length from 23 to 21 bytes. Changed Track 1 and Track 2 ATC lengths from 3 to 5 bytes. And,
deleted Track 2 Language Code subfield.
Pages 196-201: Added Notes 3 and 4, inserted Maximum Value column in Currency Code tables and added
000999999999 for approved countries.
Page 197: Added Congolese Franc to Currency Code Table.
3.0

Global: Removed Advance Copy watermark.
Page 61: Added to footnote, sentence beginning Also, please note that code 31 40 0X can
Page 64: Added Note: Balance Inquiry is only available via the Web Services IP Payments
Page 87: Added Note 2 CID Response Codes are only available via Web Services IP Payments
Page 94: Added Note: Data Field 47 is only available via Web Services IP Payments Gateway
Page 107: Added Note 2 The Available Amount remaining on Prepaid Cards is only available
Currency Code Table: Changed Swaziland currency name from Lilangeni to Emalengeni.

3.0
Advance Pages 5, 96 & 102: Deleted references to third party processors and/or added terminal and software vendors
Copy
Pages 4-5: Added section entitled Prepaid Card Partial Auth & Auth with Balance Return.
Pages 50, 55, 94-102 & 131-134: Added Field 47 to support Keyed CID and Prepaid Card functions.
Page 61: For MTI=0100 and 0200, added code 31 40 0X and footnote.
Page 64: Added explanation entitled Balance Inquiry Prepaid Cards Only.
Page 81: Added Response Code 06.
Pages 86-89, Field 44: Added Field Requirement C1 = Mandatory Amex Keyed CID program & GAN auth
response messages only. Optional Travelers Cheque. Also, expanded Response Source Code and added CID
Response Code descriptions, and added examples.
Pages 94-102 & 131-135: Added Field 47.
October 22, 2010
POS020055
This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties
without the express prior written consent of American Express Travel Related Services Company, Inc.
Revision Log
Page 103: Added paragraph beginning: Note: Merchants certified for the Amex Keyed CID
Page 106: Added Field Requirement C2 = Mandatory if Field 47 = 181 or 182
Page 107: Added paragraph and Note beginning For MTI = 110 & 0210 For Response Message on Prepaid
Card Auth Requests
Pages 185-195: Added subsection entitled Typical Prepaid Card Partial Authorization & Authorization with
Balance Return Process Flows.
ii
2.8

Pages 3, 15, 74, 90, 120 & 152: Deleted references to third party processors and/or added terminal and
software vendors.
Page 53 and throughout document: Changed from BN/binary numeric to BCD/ binary coded decimal
(multiple occurrences).
Page 54 and throughout document: Changed from BH/binary hexadecimal to H/hexadecimal (multiple
occurrences).
Pages 59 & 68: Changed Field Requirement C2 from Mandatory Debit/credit adjustments and voids to
Mandatory - All, if Amex Cardmember Account Number is manually entered.
Page 68: Changed 0320 Field Requirement from C2 to M and deleted C3.
Page 81: Added code 06.
Page 120: In paragraph beginning During certification, deleted Similarly, Amex strongly recommends
that vendors use the certification process to confirm that their software, devices and systems are capable of
populating and transmitting appropriate information.
Page 103: In Field Requirement, changed from C1 to C.
Pages 132 & 134: Added Field 54 to 0110 & 0210.
Page 137: Changed Bit 14 Field Requirement from C/C to M/M.
2.7

Global: Merged contents of POS010005, v5.4, with POS020055, v2.6 (this spec); and removed all generic
references to Web Services, as this version replaces both.
Global: Revised message names to align with ISO 8583.
Page xi, Preface: Deleted stricken text: and settled with American Express, and with other card acquirers.
Page xii: Deleted PIP Spec Expresspay Addendum (POS020055-EP) and added Dial-Up Communication
Guide (POS020086).
Page 4: Revised Expresspay requirements and added Magstripe Mode details.
Page 12: Added underlined text Important Note for Web Services IP Payments Gateway Users.
Page 20: In bullet for 0330 response, changed from upload batch from terminal to host to response
message contains a processing code
Page 24: Merged High-Speed Internet and Dial-Up info in Recommended Time-Out Values section.
Pages 49-50: Reduced Max Field Length bytes to reflect binary coded decimal entries.
Page 53: Added Important Note for Web Services IP Payments Gateway Users
Page 59: Deleted stricken text: The VLI must indicate the exact length of the account number without
padding.
Page 63: Deleted or US Dollars, if Field 49 is omitted and added, Merchants must certify for each currency
submitted.
Pages 63, 105, 106, 123 & 127: Changed from only US Dollars to US Dollars and select global currencies
and added, For more info please contact your American Express representative.
Pages 60-129 Made the following changes to Data Field Descriptions:
In fields with BCD entries, changed VLI and Length of Field, as necessary, to reflect shorter, packed
bits/BCD value.
Changed references from bytes to digits or characters, as applicable, when bytes actually refers to
POS020055
October 22, 2010
Revision Log
4-bit nibbles.
Replaced Example 1/2 text and diagrams with new Sample Data, which more accurately describes
proper field layout.
Page 74: Deleted stricken text: The VLI must indicate the exact length of the Track 2 data actually
transmitted without padding. Also, relocated notes 1 & 2 from the page that follows.
Pages 74, 90 & 150: Added references to Expresspay Pseudo-Mag Stripe Formats
Pages 77 & 93 (Fields 35 & 45): Added Expresspay Pseudo-Mag Stripe Format descriptions and Sample Data.
Page 79: Combined Auth Code and Referral Queue Field Requirement tables, and revised/added notes C1, C2
and C3.
Page 80: Changed from international to regional, two places.
Page 86: Added paragraphs beginning For an (MTI) 0220 request submitted to void an Off-Line Sale
transaction thru end of Field 44 Description, including Sample Data.
Page 90: Relocated notes 1 & 2 from a page that follows.
Page 105: Changed all Field Requirements from C1 to M and deleted Note C1.
Page 108: Deleted stricken text: (USA ZIP or international Postal code)
Pages 108-129, Private Use Data Fields 60-63: Extensively revised/expanded detailed descriptions and Sample Data to clarify MTI-specific layouts.
Pages 131-144: Updated tables to reflect changes in Field Descriptions.
Pages 183-184: Added Expresspay Pseudo-Mag Stripe Formats section.
Pages 196-201: Deleted Country Codes (not used in this spec) and added global currencies (previously, US
Dollars only).
Pages 211-218: Added EBCDIC & ASCII Code Translation Table.
2.6

Page 15: Changed Note from Lodging and Auto Rental applications to Lodging, Auto Rental and
eCommerce/Mail Order applications
Pages 114 & 116: In Fields 61 and 62, changed from C to C2 and added C1.
Page 115: Changed Example 2 from 00 08 31 31 32 32 33 33 34 34 to 20 20.
2.5

Pages 114 & 116: In both Fields 61 and 62, deleted Field Requirements C1 and C3; changed from C2 and
C4 to C; deleted Cx = Optional; and added Auth and Auth Void to N/A.
Pages 131 & 140: Deleted Bits 61 and 62.
Page 139, Bits 61 & 62: Changed Auth Void from O to .
Page 141, Bits 61 & 62: Changed Auth and Auth Void from O to .
Pages 153-182: Corrected subfield names, lengths, positions and diagrams in Magnetic Stripe Formats section,
in Appendix.
Pages 75 & 91-92: Corrected magnetic stripe sample data used in examples.
2.4

Page xii, Related Documents: Added Expresspay Addendum and HTTPS Communication Guide.
Page 4: Added Expresspay section.
Pages 35, 36, 37, 39, 41, 43 & 78: Changed incorrect references from Authorization Identification Response
(Field 38) to Additional Response Data (Field 44).
Page 62: Added explanatory text in paragraphs entitled For MTI=0400 & 0420.
Page 65: Added Note beginning For Reversal Request (0400) and Reversal Advice Request
Magnetic Stripe Formats Section: Added LRC to ANSI X4.16 Track 1 and Track 2 Formats.
October 22, 2010
POS020055
iii
Revision Log
iv
2.3

Page 79: For Authorization Code, changed from 0220=M to =C1 and added Note C1.
2.3

Pages 25-45: Added Disconnect bar between transactions in process flow diagrams.
Page 59: Changed from 0200=C to =C1, from 0220=C to =C2, from 0320=C to =M and
added Note C2.
Page 63: Added Note 2 For Void transactions
Page 65: Added Note 2 This field is
Page 68: Changed from 0220=C to =C2, from 0320=C to =C3, added Notes C2 and C3, and
added paragraph beginning Note for C2 & C3: Date, Expiration must be submitted
Pages 74 & 90: Changed from 0320=C to 0320 = .
Page 78: Changed from 0230=M to =C2 and added Note C2.
Page 86: Note C1, added Mandatory - Voids of Off-Line Sale and deleted N/A - Off-Line Sale, Debit
Adjust/Void and Credit Adjust/Void. Also, deleted For 220 requests, this field contains a code that indicates
the source of the 0210 response that generated the 0220 message; and changed from 06=Off-line approval
to sale.
Page 103: Deleted stricken text Special certification is required, and use in specific messages (as determined
by Message Type Identifier) varies by merchant.
Pages 152-181: Updated Mag Stripe Formats.
2.2

Page 15: In note, deleted Purchasing Card.
Pages 118, 123-126: For Lodging & Auto Rental, deleted 0200 & 0220 references to Bit 63 (unused).
2.1

Page 9: Added second example to Invalid Card Capture Type.
Page 62: Added paragraph beginning Note: 92 00 0X is entered in this field
Pages 108-109: Changed from For MTI=0100, 0200 & 0220 to For MTI=0100 & 0200 and from
Examples of 0100, 0200 & 0220 Request to ...0100 & 0200 Request
Pages 110: Changed from For MTI=0110, 0210 & 0230 to For MTI=0110 & 210 and from Examples of
0110, 0210 & 0230 AVS to 0110 & 0210 AVS
Page 117: Changed from Batch Identification to Invoice/ROC/SOC (number), two places.
Page 127-128: Added (previously omitted) 6-byte Reserved (zeros) subfield, two places.
Pages 130-144: Changed format of Data Field/ Message Usage Tables to improve readability.
2.0

Global modifications: Converted all field descriptions and examples from ASCII to BCD and hexadecimal.
Also, made the following additional changes:
Page 53: Added new subsections explaining BCD and hexadecimal formats.
Page 74-75 & 91: Changed sample data to match examples in Amex Mag Stripe Formats section and corrected
field formats for Track 1 & 2 data.
Page 84: Added backslash as subfield separator.
Page 103: Added (previously omitted) Data Type Definition Code.
Page 151: Added Amex Card examples that show CID/4DBC/4CSC locations.
1.4

Page 63: For USD/840 transactions only, changed 000009999999 to 000999999999. Also, added For
other currencies, the USD equivalentmust not exceed $99,999.99 USD.
POS020055
October 22, 2010
Revision Log
Page 103: Changed requirement for 0100, 0200 & 0220 from to C1; and added sentence beginning C1 =
Cond. Merchants transmitting.
Page 108: Changed requirement for 0220 from to O, and 0230 from to C1. Changed For
MTI=0100 & 0200 to 0100, 0200 & 0220.
Page 109: Changed from For MTI=0110 & 0210 to 0110, 0210 & 0230, and Example of 0110 &
0210 to 0110, 0210 & 0230; and added above changes to Message Usage Table.
1.3

Pages 118-126 & Message Usage Table: Changed requirement for 0220 from to C; changed all
references from 0200 & 0320 to 0200, 0220 & 0320; updated 0220 entries for Bit 63 in summary table.
1.2

Page 11: Deleted introductory paragraph beginning The American Express PIP Interface uses two
Pages 12-13: Added Important Note and expanded explanation of ISO 8583 messages.
Pages 61-62: Added descriptions for MTI 0200, 0220, 0320 & 0500, inadvertently omitted in previous
releases.
Page 110: Added code R=AVS Unavailable and Note: The AVS response (which is used to help validate
the identity of the Cardholder)
Pages 118-126 & Message Usage Table: Added Field 63 Requirement for MTI 0200 = C2, changed each
instance of MTI 0320 to 0200 and 0320 (eight places), and updated Data Field/Message Usage Table.
1.1

Pages 108-110: Added AVS requirements to 0100/0200 & 0110/0210 messages.
1.0

Initial release. Created by removing XML references from POS020050, v1.0 and adding ISO 8583
information from POS010005, v5.4.
October 22, 2010
POS020055
This page is intentionally left blank.
vi
POS020055
October 22, 2010
Table of Contents
Preface .................................................................................................................................................. xi
Organization .......................................................................................................................................... xi
Related Documents............................................................................................................................... xii
1.0
Introduction to Credit Authorization ................................................................................. 1
1.1
Overview ................................................................................................................................ 1
1.2
Shadow File Processing ......................................................................................................... 1
1.3
Industry-Specific Special Processing ..................................................................................... 2
1.4
Card Acceptance Guidelines .................................................................................................. 3
1.5
Prepaid Card Partial Authorization & Authorization with Balance Return ........................... 4
1.5.1
Partial Authorization .............................................................................................................. 4
1.5.2
Authorization with Balance Return ........................................................................................ 5
1.6
Expresspay ............................................................................................................................. 6
2.0
Introduction to Plural Interface Processing (PIP) ............................................................ 7
2.1
Overview ................................................................................................................................ 7
2.2
American Express Capture Host ............................................................................................ 8
3.0
Express 3000 PIP Interface Messages............................................................................... 11
3.1
Overview of ISO 8583 Messages ......................................................................................... 12
3.2
Terminal Identification Data Fields ..................................................................................... 14
3.3
Authorization Only Messages .............................................................................................. 15
3.4
Financial Capture Messages ................................................................................................. 17
3.5
File Update Messages .......................................................................................................... 20
3.6
Reversal Messages ............................................................................................................... 21
3.7
Reconciliation Messages ...................................................................................................... 23
3.8
Recommended Time-Out Values ......................................................................................... 24
3.8.1
Web Services IP Payments Gateway, High-Speed Internet Connection .............................. 24
3.8.2
Dial-Up Communications .................................................................................................... 24
4.0
Standard Process Flow Diagrams (Capture Host) .......................................................... 25
4.1
Authorizations Normal Processing.................................................................................. 26
4.2
Authorizations Reversal Processing ................................................................................ 26
4.3
Financial Transactions Normal Processing ..................................................................... 27
4.4
Financial Transactions Referral Processing .................................................................... 28
October 22, 2010
POS020055
vii
Table of Contents
4.5
Financial Transactions Advice Processing (Normal) ...................................................... 29
4.6
Financial Transactions Advice Processing (Time-Out) ................................................... 30
4.7
Financial Transactions Reversal Processing .................................................................... 31
4.8
File Updates Time-Out Processing .................................................................................. 33
4.9
Reconciliation Messages ......................................................................................................33
4.10
Reconciliation Time-Out Processing .................................................................................... 33
4.11
Close Batch Normal Processing ...................................................................................... 33
4.12
Close Batch Error Processing .......................................................................................... 34
5.0
Stand-In Process Flow Diagrams (GAN) .......................................................................... 35
5.1
Authorizations GAN Normal Processing ........................................................................ 36
5.2
Authorizations GAN Reversal Processing....................................................................... 37
5.3
Financial Transactions GAN Normal Processing ............................................................ 39
5.4
Financial Transactions GAN Referral Processing ........................................................... 40
5.5
Financial Transactions GAN Advice Processing (Normal) ............................................. 41
5.6
Financial Transactions GAN Advice Processing (Time-Out) ......................................... 42
5.7
Financial Transactions GAN Reversal Processing .......................................................... 43
5.8
Other Message Formats ........................................................................................................ 45
6.0
ISO 8583 Message Formats................................................................................................ 47
6.1
Guidelines for Using the ISO 8583 Format .......................................................................... 47
6.2
Variations from ISO 8583 .................................................................................................... 48
6.3
ISO 8583 Message Bit Map Table........................................................................................ 48
7.0
PIP Terminal Interface Data Fields................................................................................... 51
7.1
Data Field Descriptions ........................................................................................................ 52
7.2
Data Field/Message Usage Tables ...................................................................................... 130
7.2.1
0100 Authorization Request .......................................................................................... 131
7.2.2
0110 Authorization Response ........................................................................................ 132
7.2.3
0200 Financial Transaction Request (Auth & Capture)................................................. 133
7.2.4
0210 Financial Transaction Response ........................................................................... 134
7.2.5
0220 Financial Transaction Advice Request (Capture) ................................................. 135
7.2.6
0230 Financial Transaction Advice Response ............................................................... 136
7.2.7
0320 Transaction Upload Advice Request (Terminal-to-Host) ..................................... 137
viii
POS020055
October 22, 2010
Table of Contents
7.2.8
0330 Transaction Upload Advice Response .................................................................. 138
7.2.9
0400 Reversal Request .................................................................................................. 139
7.2.10
0410 Reversal Response ............................................................................................... 140
7.2.11
0420 Reversal Advice Request...................................................................................... 141
7.2.12
0430 Reversal Advice Response ................................................................................... 142
7.2.13
0500 Reconciliation Request......................................................................................... 143
7.2.14
0510 Reconciliation Response ...................................................................................... 144
8.0
Edit Tests on Data Input .................................................................................................. 145
8.1
Cardmember Account Number Check Digit Computation* ............................................... 146
8.2
Expiration Date Edit Test ................................................................................................... 148
8.3
Transaction Amount Edit Test ........................................................................................... 148
8.4
ROC Number Edit Test ...................................................................................................... 148
8.5
SOC Number Edit Test ...................................................................................................... 149
8.6
Batch Number Edit Test ..................................................................................................... 149
8.7
Total Amount Edit Test...................................................................................................... 149
8.8
Business Date Edit Test ..................................................................................................... 149
8.9
Tip or Tax Information Edit Test ....................................................................................... 150
8.10
Track 1 or Track 2 Data ..................................................................................................... 150
9.0
Appendix ........................................................................................................................... 151
9.1
American Express Cards Typical Examples ................................................................. 151
9.2
American Express Magnetic Stripe Formats ...................................................................... 152
9.2.1
ANSI X4.16 Standard ........................................................................................................ 153
9.2.2
ISO 7813 Standard ............................................................................................................. 153
9.2.3
New Definitions and Values ............................................................................................... 154
9.2.4
ANSI X4.16 / ISO 7813Track 1 Message Formats ............................................................ 155
9.2.5
ANSI X4.16 / ISO 7813Track 2 Message Formats ............................................................ 170
9.3
Expresspay Pseudo-Magnetic Stripe Formats .................................................................... 183
9.4
Typical Prepaid Card Partial Authorization & Authorization with Balance Return
Process Flows ..................................................................................................................... 185
9.4.1
Partial Authorization Scenarios .......................................................................................... 186
9.4.2
Authorization with Balance Return Scenarios ................................................................... 191
October 22, 2010
POS020055
ix
Table of Contents
9.5
Currency Codes .................................................................................................................. 196
9.6
Street Codes ........................................................................................................................ 202
9.7
ISO Account Number Ranges ............................................................................................ 205
10.0
Glossary ............................................................................................................................. 207
11.0
EBCDIC & ASCII Code Translation Table .................................................................... 211
POS020055
October 22, 2010
Preface
This document is addressed to systems programmers and terminal engineers who design data capture
systems to be used with the American Express PIP terminal interface. This document defines the requirements of the American Express terminal-to-host interface for non-American Express POS data
capture terminals. The term PIP (Plural Interface Processing) implies that transactions can be captured
and settled with American Express.
American Express will certify non-American Express owned POS terminals that conform to this specification, and allow those terminals to access the American Express network for capturing American
Express charges, and other charges as opted for by the Merchant.
To be certified, you must request the certification script from the Manager of the POS Engineering
Department. This script contains the instructions for conducting the test. Once you have passed, you
will be certified on the American Express system. Subsequent revised terminal versions may be submitted for retesting. Revisions that are not submitted for retesting may be decertified if they do not
conform to this specification.
Organization
This document contains the following sections:
1.0
Introduction to Credit Authorization
2.0
Introduction to Plural Interface Processing (PIP)
3.0
Express 3000 PIP Interface Messages
4.0
Standard Process Flow Diagrams (Capture Host)
5.0
Stand-In Process Flow Diagrams (GAN)
6.0
ISO 8583 Message Formats
7.0
PIP Terminal Interface Data Fields
8.0
Edit Tests on Data Input
9.0
Appendix
10.0
Glossary
11.0
EBCDIC & ASCII Code Translation Table
October 22, 2010
POS020055
xi
Related Documents
Web Services IP Payments Gateway HTTPS Communication Guide (POS020052)
American Express Dial-Up Communication Guide (POS020086)
International Standard ISO 8583:1987, Financial Transaction Card Originated Interchange

Messages Interchange Message Specifications
International Standard ISO/IEC 7813, Identification Cards Financial Transaction Cards

(Track I and Track II Specifications)
American National Standards Institute ANSI X4.16, Financial Transaction Cards Magnetic
Stripe Encoding
xii
POS020055
October 22, 2010
1.0
Introduction to Credit Authorization
1.1
Overview
The American Express PIP Capture Host is a sophisticated system that provides two methods of processing. Shadow file processing is used for retail and restaurant applications, which incorporates the
best features of host- and terminal-based EDC processing. Primarily, this allows the system to perform
host-based processing, in which the terminal is always assumed financially correct. This means that at
settlement time, if the Capture Hosts batch balances with the terminals reconciliation, then the shadow
file is submitted for payment. If the terminal does not balance with the Capture Host, then the shadow
file is replaced with the terminals batch.
Store and forward processing is used for Lodging, Purchasing Card, Travel (Sign & Travel) and Auto
Rental applications, and is a typical, terminal-based capture system. This method of processing allows
the establishment to perform authorizations as needed, and then settle the batch later.
1.2
Shadow File Processing
The Capture Host maintains a copy of the batch by recording each transaction that is processed by the
terminal. When transactions are approved, they are recorded and may be used for settlement, when
the terminal has successfully reconciled with the Capture Host. The terminal is responsible for updating
the Capture Host of all financial transactions including off-line sales, adjustments and voids.
Retail minimum transaction set:
Close Batch
Off-Line Sale
Refund
Sale
Void
Restaurant minimum transaction set:
Close Batch
Debit Adjustment
Off-Line Sale
Refund
Sale
Void
October 22, 2010
POS020055
1.3
Industry-Specific Special Processing
1.3.1
Lodging Processing
Lodging processing is supported by the American Express Capture Host and uses a simple store and
forward method for submitting batches. Authorization transactions are allowed from a Lodging terminal. Sales and other 02x0 message type transactions are not allowed.
1.3.2
Purchase Card Processing
The American Express Capture Host supports Purchasing Card applications. These applications are
intended for Merchants who supply goods and services for companies. This allows companies to issue
cards to their employees who purchase small dollar items, and allows them to circumvent the lengthy,
paper process associated with POS.
Like the Lodging application, Purchasing Card uses a similar store and forward method.
1.3.3
Auto Rental Processing
Auto Rental Processing is supported by the American Express Capture Host, and it uses a simple store
and forward method for submitting batches. Authorization transactions are allowed from an Auto Rental
terminal. Sales and other 02x0 message type transactions are not allowed.
Note: This application may only be used when the rental and return locations are the same.
1.3.4
Travel (Sign & Travel) Processing
The American Express Capture Host supports the American Express Travel (Sign & Travel) application,
which allows Cardmembers to request extended payments for Travel purchases.
Like the Lodging application, Travel uses a similar store and forward method.
POS020055
October 22, 2010
1.4
Card Acceptance Guidelines
American Express Card creation standards for magnetic stripe layouts may include additional data
undefined in currently published American Express implementations of ANSI X4.16 and ISO 7813
formats. Magnetic stripe data fields in current use will not be moved; however, discretionary or
unused fields may be redefined for use with future American Express Card products. Therefore, the
subfield definitions referenced in Section 8.1 are for reference only and may not reflect all American
Express Card variations that may be encountered. For this reason, when Track 1 or Track 2 data is
read from a magnetic stripe, the acquirer, their devices, systems, software, and terminal and software
vendors should capture all characters between the start and end sentinels, strip off the sentinels and
LRC, and forward the remainder to American Express in the appropriate ISO 8583 Track 1 Data or
Track 2 Data field, without regard to the specific lengths referenced in Section 8.1. For more information, see American Express Magnetic Stripe Formats and Expresspay Pseudo-Magnetic Stripe
Formats beginning on pages 152 and 183.
If the Merchants system supports capture of both Track 1 and Track 2, both tracks should be forwarded.
If only one track is captured, Track 1 is preferred (see page 90). For systems that capture only Track 2,
this less desirable alternative may be supplied in lieu of Track 1 (see page 74). American Express
security requirements prohibit the storage of track data within Merchant or processor systems. Character
spaces should not be stripped. In addition, data should not be padded to standardize track lengths, and
it should be transmitted as read.
The Authorization Request Message contains the Point of Service Entry Mode (Field 22) that describes
point-of-service processing capabilities (see page 70). Merchants, and terminal and software vendors,
are strongly advised to ensure that authorization data is accurate.
For more information, please contact your American Express representative.
October 22, 2010
POS020055
1.5
Prepaid Card Partial Authorization & Authorization with

Balance Return
The Prepaid Card Partial Authorization and Authorization with Balance Return programs are designed
to help Merchants provide Card balance information to American Express Prepaid Cardholders at the
point of sale. ISO 8583 formatted messages are exchanged to determine available funds and help the
Merchant successfully complete Prepaid Card transactions in a timely manner.
Please note that the Partial Authorization and Authorization with Balance Return programs only apply
to American Express Prepaid Cards. Merchants that participate are not required to know which
American Express products are prepaid. Instead, their authorization systems are modified using this
specification to indicate their ability to support these features. American Express returns specified
information for transactions that qualify. Otherwise, responses will be the same as those received
today.
American Express strongly recommends Partial Authorization; because a request is approved for the
remaining balance, rather than declined, when insufficient funds remain to cover the original amount.
Note: For typical process flows and examples see page 185.
1.5.1
Partial Authorization
The Partial Authorization program allows American Express to authorize a transaction for a value
less than the original, Merchant-requested amount. Partial Authorization is used when a Prepaid Card
has insufficient funds to cover the original amount of the request. And, rather than receiving a denial
message, the transaction is approved for the balance remaining on the Card.
An approved Authorization Response includes two separate amount fields one that shows the value
actually approved, and another that echoes the original amount requested. These values allow the
Merchant to determine how much must be collected from the customer to complete the transaction.
The Merchant can then collect the outstanding amount of the transaction from the Cardholder, via
another form of payment. The advantage of this function is that all of this information is provided to
the Merchant and Cardholder in one authorization request/response message exchange.
In addition, the remaining-balance is returned, which allows the Merchant to print or display the
amount remaining on the prepaid Card product (if any).
In 0100 and 0200 messages, Function Code 181 is transmitted in Field 47 (Additional Data National) to indicate that a Merchant accepts Partial Authorizations. The approved amount is returned
in Field 4 (Amount, Transaction) of the 0110 or 0210 response message. The original requested
authorization amount is returned in Field 47 (Additional Data - National); and the available amount
remaining on the Card (including a zero balance) is returned in Field 54 (Amounts, Additional).
POS020055
October 22, 2010
1.5.2
Authorization with Balance Return
As an alternative to the Partial Authorization program, American Express offers the Authorization
with Balance Return program.
The Authorization with Balance Return program allows Merchants that choose not to use the Partial
Authorization Program to receive the Prepaid Card balance on the 0110or 0210 response message.
Field 47 (Additional Data - National) of the 0100 or 0200 message is used to identify an Authorization with Balance Return request. The available balance is returned to the Merchant in Field 54
(Amounts, Additional) in the 0110 or 0210 response message, even if the transaction is denied. Transactions that are denied for insufficient funds can be resubmitted for an amount equal to or less than
the remaining balance provided in the 0110 or 0210 response message.
Merchants should develop internal instructions for using the Prepaid Card Partial Authorization or
Authorization with Balance Return Programs at their point of sale. American Express will allow
authorized Merchants that conform to this specification and pass our certification tests to access the
American Express network to acquire Partial Authorization or Authorization with Balance Return.
Terminal and software vendors must develop support for both Partial Authorization and Authorization
with Balance Return functionalities in order to provide the ability for their Merchants to utilize either
program. Additional information may be obtained from your American Express representative.
Note: Prepaid Card Balance Inquiry may also be performed utilizing either the Partial Authorization
or the Authorization with Balance Return program. This can be done by simply entering an amount of
zero in the Field 4 (Amount, Transaction). The transaction will be approved, and the available balance
is returned in Field 54 (Amounts, Additional). A new authorization request can then be created for an
amount equal to or less than the remaining balance.
October 22, 2010
POS020055
1.6
Expresspay
If supporting Expresspay, Merchants and vendor software must support Magstripe Mode.
It is mandatory for US Software and Terminal Vendors to certify they can pass Expresspay data.
In order to submit transactions from Expresspay Cards for authorization and settlement, the Merchant or
US Software and Terminal Vendors must submit data to American Express in the formats prescribed
in this guide.
Expresspay Requirements
Magstripe Mode
Track 1 (Field 45) and/or Track 2 (Field 35) must be present. For information on Expresspay Pseudo-Magnetic Stripe Formats, see
page 183.
POS Data Code (Field 22)
Position 1 = 0 (Contactless transactions, including American Express Expresspay)

Position 2 = 2 (Magnetic strip read; Track 1 and/or Track 2)
Notes:
1. Expresspay transactions must originate at a contactless reader and cannot be manually keyed.
2. It is important to note that pseudo-magnetic stripe data from a chip card contactless reader differs slightly from track data obtained
from a magnetic stripe read. For this reason, when Magstripe Mode, Track 1 and/or Track 2 pseudo-magnetic stripe data is supplied
intact, the start and end sentinels should be stripped off; and all remaining characters between the sentinels (including the Interchange
Designator and Service Code) should be forwarded to American Express without alteration, in the appropriate ISO 8583 Track 1
and/or Track 2 field (Data Fields 45 and/or 35, respectively). For complete lists of allowable Interchange Designator/Service Code
combinations, see pages 162 and 174, respectively.
POS020055
October 22, 2010
2.0
Introduction to Plural Interface Processing (PIP)
2.1
Overview
The primary function of a Plural Interface Processing (PIP) terminal is to interface with American
Express and other card acquirers. PIP capability allows the terminal to transmit transaction data
directly to American Express (or other card acquirers) for authorizations and financial settlement
between the Merchant, card acquirers and Cardmembers. PIP terminals may also have access to other
transaction services such as check guarantee services.
The benefits realized by a Merchant that uses a PIP terminal or device include:
Only one terminal is needed to authorize and settle transactions with American Express and other
card acquirers.
The Merchant may qualify for reduced transaction costs and a better discount rate by transmitting
directly to card acquirers.
Message types processed and/or captured through the American Express PIP Interface include:
Authorizations
Sales
Refunds
Voids
Debit and Credit Adjustments
Debit and Credit File Updates
Reversals
Financial Reconciliation (Settlement)
The messages used to process these transactions are described in Section 3.0, Express 3000 PIP
Interface Messages. The logical processing flows for these messages are illustrated in Section 4.0,
Standard Process Flow Diagrams (Capture Host) and Section 5.0, Stand-In Process Flow Diagrams
(GAN). For more information on the American Express GAN, see page 35.
October 22, 2010
POS020055
2.2
American Express Capture Host
The American Express Capture Host receives and processes message transmitted from the Merchants
terminal. If the Capture Host is unavailable, the American Express Global Authorization Network
(GAN) system may substitute for the Capture Host and respond to the terminal. For more information
on the American Express GAN, see page 35.
The Capture Host performs several interface activities:
Approves or refers authorization requests.
Maintains a transaction shadow file for the terminal.
Adds and updates terminal problems to a trouble list.
Reconciles and closes batches from the terminal.
Supports suspended batches.
Settles batches with the financial settlement and payment systems.
2.2.1
Authorization Requests
The terminal transmits authorization requests to the Capture Host. The Capture Host performs a check
digit computation on the account number to verify that the number is a valid American Express account
number. (For check-digit computation instructions, see page 146).
2.2.2
Transaction Shadow Files
The Capture Host maintains and stores a shadow file that contains all transactions processed through
American Express for each terminal. All the transactions stored in a terminal at any one time are called
a batch of transactions. The shadow file plays an active role when closing a terminals batch.
When a terminals batch is closed, the terminal transaction count, and sales and refund totals must
match the Capture Host shadow file totals. If the totals do not match, the Capture Host transmits a
request for the terminal to upload all transactions stored in the terminal, and it places them in a new
shadow file, thus overwriting the original shadow file.
POS020055
October 22, 2010
2.2.3
Terminal Problem Trouble List
When placed on the trouble list, a terminal appears to be operational to the Merchant; but it cannot
process American Express transactions, until the problem is cleared from the list.
Some typical problems that may appear on the trouble list include the following:
Invalid Card Capture Type The types of message requests that can be transmitted from a
terminal to the Capture Host are assigned to the terminal, specific to card type. See below:
Example 1 If the terminal is set up to transmit sale capture requests on American Express
Cards, and an authorization-only request for an American Express Card is sent; the card
capture type is invalid, and the terminal is placed on the trouble list.
Example 2 If the terminal is set up to transmit authorization-only requests (non-capture),

and a sale capture request is sent; the card capture type is invalid, and the terminal is placed
on the trouble list.
Unrecognized Descriptor Code(s) in Private Use Data (Field 61) American Express assigns a
series of two-digit, Item Descriptor Codes to each terminal. These codes describe the merchandise
or services purchased using a specific terminal. If a code is transmitted that American Express
does not recognize, the terminal is placed on the trouble list.
Invalid Batch Number in Private Use Data (Field 60) A unique batch number must be assigned
to each batch. This entry must be all numerals and cannot be 000000 or 999999. If the batch
number is invalid, the terminal is placed on the trouble list.
Incorrectly Formatted Message If mandatory data is missing or a field is incorrectly formatted,

the terminal is placed on the trouble list. Some examples are:
Alpha characters present in a numeric-only field.

Data length is not the specified size.
Mandatory field is missing.
Invalid Batch Request If the terminal attempts to close a batch when none is open, it is placed
on the trouble list.
Terminal and Shadow File Totals Do Not Match When a terminal attempts to close a batch,
the Capture Host compares the totals at the terminal with those in its shadow file. If they do not
match, the terminal will be placed on the trouble list. On the next attempt to reconcile, the Capture
Host will request that the terminal upload all transactions to a new shadow file.
October 22, 2010
POS020055
2.2.4
Reconciling and Closing Batches at the Terminal
The POS operator at the establishment initiates the procedure to close (settle) a batch at the terminal.
The terminal notifies the Capture Host that it is closing the batch, and that the totals reflect the debits
and credits for the current batch.
When the Capture Host receives the close batch request, it compares the totals in the terminals request
to those in the shadow file. If the figures agree, the batch in the Capture Host is marked as closed, and
a close batch response is sent to the terminal. A text message is also sent from the Capture Host to the
terminals display.
If the figures do not agree, the terminal will be placed on the trouble list. On the next attempt to reconcile, the Capture Host instructs the terminal to upload all the details for the batch. The Capture Host
compares the figures received during the upload request with the totals transmitted by the terminal
during the original close request. If those totals match, the Capture Host overlays its current batch
figures in the shadow file with all the transaction details received during the upload. The terminal
transmits another close request, and the Capture Host compares the totals in the close request to the
new uploaded totals. If those figures match, the Capture Host closes the batch.
Once the batch is closed at the terminal, it must be deleted from the terminals memory.
If the uploaded details do not balance with the totals sent from the terminal in the original request, the
Capture Host automatically blocks any activities for that batch. In addition, any errors received during
the entire settlement process will result in the Capture Host blocking out terminal activities and notifying American Express.
2.2.5
Financial Settlement
The Capture Host settles its closed batches with one of the various systems used for financial settlement and payment to Merchants. The closed batches are sent for settlement via a submission file.
10
POS020055
October 22, 2010
3.0
Express 3000 PIP Interface Messages
This section contains the following topics:

3.1
Overview of ISO 8583 Messages
3.2
Terminal Identification Data Fields
3.3
Authorization Only Messages
3.4
Financial Capture Messages
3.5
File Update Messages
3.6
Reversal Messages
3.7
Reconciliation Messages
3.8
Recommended Time-Out Value
October 22, 2010
POS020055
11
3.1
Overview of ISO 8583 Messages
Important Note for Web Services IP Payments Gateway Users: ISO 8583 messages created per
this specification must be converted to binary coded decimal (BCD) and hexadecimal configuration before being transmitted as an ASCII string to the American Express IP Payments Gateway.
Similarly, ASCII files returned from American Express will be in binary coded decimal (BCD)
and hexadecimal configuration and may require conversion to a format compatible with the
Merchants terminal/system.
The ISO 8583 standard defines a bit-mapped message format. The first ten bytes of a message are
composed of a four-byte message type code that identifies the type of transaction being transmitted
and an eight-byte bit map that indicates the data fields that immediately follow. These two fields
always precede the transaction data in each message.
Each digit of the message type code identifies a message attribute. Definitions of the attributes are:
First position / Version Number This number is always 0 (zero).
Second position / Message Class The message classes used by the American Express PIP
interface are:
1
2
3
4
5
8
12
Authorization
Financial Capture
File Update
Reversals
Reconciliation
Maintenance
Third position / Message Function

0
1
2
3
4
5-9
=
=
=
=
=
=
=
=
=
=
=
=
Request
Response to a Request
Advice
Response to an Advice
Notification
Reserved for ISO use
Fourth position / Transaction Originator This digit is always 0 (zero) for American
Express PIP interface requests and responses.
POS020055
October 22, 2010
3.1
Overview of ISO 8583 Messages (Continued)
The bit map (which indicates the data fields used in a message) is eight bytes (64 bits) long. Each bit
represents a data field defined in this specification, and contains either the value 1 to indicate the
presence of the field or a 0 (zero) to indicate its absence. The binary indicators are then translated
to hexadecimal notation.
The first ten bytes of a typical message are shown below. Message type code 0200 (in binary coded
decimal [BCD] format) appears in the first two bytes (highlighted in positions 1 and 2), and indicates
that this is a financial capture request (a.k.a., sale transaction). The remaining 8 bytes contain the
primary bit map (in hexadecimal notation). For details on how to populate a bit map, see page 57.
Message:
02
00
30
20
05
80
20
C8
80
00
Position:
10
This specification contains information on each transaction used by the American Express PIP interface, and only those fields used by American Express are included. Additional information on the ISO
standard and/or ISO field definitions is available in International Standard ISO 8583.
In addition to ISO 8583-defined, standard data fields, several Private Use fields are used to transport
unique, American Express requirements. Also, some Private Use fields may be redefined for different
transactions, depending on the message type specified. For example, Private Use Data, Field 63 may
contain batch count and amount subfields for some message types and industry-specific transaction
information subfields for others.
For more information, see PIP Terminal Interface Data Fields section, beginning on page 51.
October 22, 2010
POS020055
13
3.2
Terminal Identification Data Fields
American Express assigns the identification data fields, listed below, to each terminal and/or Merchant/
Service Establishment.
3.2.1
Field 41 Card Acceptor Terminal Identification
American Express assigns an eight-digit, Card Acceptor Terminal Identification code (a.k.a., Terminal
ID) to every terminal that accesses the American Express PIP Interface. The Terminal ID uniquely
identifies the terminal to the Capture Host and must appear in the Field 41 of all messages. For details,
see page 82.
3.2.2
Field 42 Card Acceptor Identification Code
American Express assigns a Card Acceptor Identification Code (a.k.a., Merchant ID, which is typically
the 10-digit, American Express Service Establishment/SE Number) to every Merchant that accepts
American Express Cards. This number must appear in Field 42 of all Merchant-generated request
messages sent to American Express. For details, see page 83.
3.2.3
Field 61 Private Use Data
American Express assigns a series of two-digit, Transaction Item Descriptor Codes to each terminal.
These values are entered in Private Use Data, Field 61. These codes, when cross-referenced to
American Express descriptor tables, describe the merchandise or services purchased using a specific
terminal. Descriptor codes are approved by American Express before the terminal is permitted to
access the American Express PIP Interface, and must be provided in Field 61 in every Financial
Capture, Batch Upload and Financial Reversal message, as stipulated in the Field Requirement table
on page 114.
14
POS020055
October 22, 2010
3.3
Authorization Only Messages
An authorization is defined as an approval of a transaction, given by the card or check issuer. The
terminal does not capture approval authorizations, only transactions for settlement.
Transactions processed using authorization-only messages are:
Authorizations
American Express Travelers Cheque Verifications
Authorization Voids
3.3.1
Authorizations
An authorization is a transaction approval from the card issuer to a Merchant/Service Establishment

(SE). An approval code is provided as proof of authorization. Authorization type transactions are not
captured for settlement (see Sale Transaction on page 17). Therefore, this message-type cannot be
assigned (in the terminal) to card-types that rely on the Capture Host to capture and settle the information. For example, within the same terminal, American Express Cards cannot be processed using
both authorization and sale transactions.
Note: Authorization messages are supported for Lodging, Auto Rental and eCommerce/Mail
Order applications only.
3.3.2
American Express Travelers Cheque Verifications
American Express Travelers Cheques can be verified using the American Express PIP Interface. This
verification reduces the fraudulent use of Travelers Cheques.
3.3.3
Authorization Voids
The Authorization Void is used to reverse an authorization-only transaction that was previously
processed through the terminal.
October 22, 2010
POS020055
15
3.3.4
Message Formats
The American Express PIP Interface utilizes Authorization Request (0100) and Authorization Response
(0110) Messages. Different fields and data may be required in each message, depending on the type of
transaction authorized.
Authorization Request (0100) Message
Authorization Request
American Express Travelers Cheque Authorization Request
Authorization Void Request
Authorization Response (0110) Message
Authorization Response
American Express Travelers Cheque Authorization Response
Authorization Void Response
Note: See Data Field/Message Usage Tables beginning on page 130.
16
POS020055
October 22, 2010
3.4
Financial Capture Messages
Financial capture messages are stored (captured) in the terminal and at the Capture Host. These
messages are later used by the Merchant/Service Establishment to settle with card issuer or acquirer
and receive payment. An explanation of transaction types that are captured appears below.
3.4.1
Sale Transaction
A sale is a transaction that is transmitted for authorization and, if approved, is captured for settlement.
An approval code is provided, if the transaction is authorized/approved.
3.4.2
Refund Transaction
A refund is a credit transaction that is captured and (later) posted for settlement.
3.4.3
Void Transaction
A void is used to cancel a sale or refund transaction within the current batch in the terminal. A void
cannot be used to cancel a transaction in a closed batch.
3.4.4
Sale Completion
A sale completion is commonly used in an authorization voice referral, where the terminal directs the
POS operator at the Merchant location to call the card issuer for authorization. If the transaction is
authorized during that call, the terminal automatically prompts the POS operator to enter the approval
code manually. The entire transaction, including the new approval code, is transmitted later as a sale
completion, in conjunction with an on-line sale or authorization.
October 22, 2010
POS020055
17
3.4.5
Off-Line Sale Transaction
An off-line sale transaction is normally used by a Merchant/Service Establishment that has already
obtained an authorization for a transaction, but is accumulating transactions for reconciliation and
posting. Each off-line sale transaction can later be transmitted to the host in conjunction with an
approved on-line sale or authorization. The benefit is that two transactions (one on-line and one
off-line) are sent to the host in one call.
3.4.6
Debit Adjustment
A debit adjustment is an additional charge associated with an existing transaction in the terminal. For
example, when a restaurant charge is first authorized, it may not include the tip. The tip is processed
later as a debit adjustment. The transmission scheme of debit adjustments is identical to off-line sale
transactions, where the message is later transmitted with an approved on-line sale or authorization.
3.4.7
Off-Line Void Transaction
An off-line void transaction is processed and transmitted in the same manner as a debit adjustment,
except that the transaction amount in the Amount, Transaction (Field 4) is set to zero (0).
3.4.8
Credit Adjustment
A credit adjustment is an additional credit associated with an existing transaction in the batch. A credit
adjustment uses the same transmission scheme as a debit adjustment.
3.4.9
Off-Line Refund Transaction
A refund may be entered off-line to accumulate refund transactions. The terminal can transmit each
refund in conjunction with an approved on-line sale or authorization request to the host.
18
POS020055
October 22, 2010
3.4.10
Message Formats
The American Express PIP Interface utilizes four financial capture messages:
Financial Transaction Request (0200) Message
Financial Transaction Response (0210) Message
Sale
Financial Transaction Advice Request (0220) Message
Sale
Sale Completion
Off-Line Sale
Debit Adjustment/Void
Credit Adjustment/Void
Off-Line Refund
Financial Transaction Advice Response (0230) Message
Sale Completion
Off-Line Sale
Debit Adjustment/Void
Credit Adjustment/Void
Off-Line Refund
October 22, 2010
POS020055
19
3.5
File Update Messages
The American Express PIP Interface uses file update messages to upload transactions from the terminal
to the Capture Host shadow file, when the terminals transactions balance properly with the Merchant/
Service Establishment, but not with the Capture Hosts shadow file.
3.5.1
Transaction Upload Advice Request (0320) Message (upload batch request, terminal to host)
Message Formats
Debit
Credit
Transaction Upload Advice Response (0330) Message (response message contains a processing
code that prompts the terminal to transmit the next transaction, if another exists)
Debit
Credit
The terminal initiates all request messages. The Capture Host transmits all response messages to the
terminal.
20
POS020055
October 22, 2010
3.6
Reversal Messages
The terminal uses a reversal message to nullify the effects of a previous, incomplete financial or
authorization transaction. A reversal message prevents accidental duplication of financial or
authorization transactions in the Capture Host, and it is always used when a time-out occurs at the
terminal during the transmission of a financial or authorization request.
For example, if a terminal sends a sale transaction to the Capture Host, and the terminal experiences
a time-out prior to receiving the response message from the host, the terminal has no way of determining if the Capture Host received the original transaction. Because the POS operator at the Merchant
location will send the data again, thus creating a duplicate transaction, the terminal must transmit a
reversal to the Capture Host prior to resending the data. When the Capture Host receives the reversal,
it will return a Reversal Response message to the terminal.
After the terminal receives the Reversal Response, it can process additional transactions. However,
the terminal must not transmit any transactions prior to receipt of the Reversal Response. The Capture
Host is unable to identify and block duplicate transactions; therefore, the Merchants terminal,
device or system is responsible for not transmitting any transactions to the Capture Host until the
reversal is processed and cleared.
If the Capture Host is unavailable when a reversal is transmitted from the terminal, the reversal message
is transmitted to the American Express GAN system, which stands in for the Capture Host. When the
Capture Host becomes available, the terminal sends a reversal advice message to the Capture Host, as
notification that one or more transactions stored in the terminal were processed through the GAN.
For more information on the American Express Global Authorization Network (GAN), see page 35.
October 22, 2010
POS020055
21
3.6.1
Authorization
Travelers Cheque Approval
Authorization Void
Sale
Refund
Reversal Advice Request (0420)
Authorization
Authorization Void
Sale
Reversal Response (0410)
Message Formats
Reversal Request (0400)
Authorization
Authorization Void
Sale
Refund
Reversal Advice Response (0430)
Authorization
Authorization Void
Sale
Refund
22
POS020055
October 22, 2010
3.7
The terminal uses reconciliation messages to settle transactions with the Capture Host. Explanations
of these transactions appear below.
3.7.1
Close Batch
When a terminal reconciles its transactions with the Capture Host, it performs a procedure called
closing. A batch is closed in the terminal, when all transactions in the batch are reconciled with the
host.
Once a batch is closed, it can no longer be accessed by the terminal; and the terminal must delete its
copy of the batch from the terminals memory.
3.7.2
Reconciliation Request (0500)
Message Formats
Close Batch
Reconciliation Response (0510)
Close Batch
October 22, 2010
POS020055
23
3.8
Recommended Time-Out Values
3.8.1
Web Services IP Payments Gateway, High-Speed Internet

Connection
Merchant terminals, devices and systems using the format detailed in this specification connect to
American Express via the American Express IP Payments Gateway. While the exact time-out value
for specific applications may vary, American Express suggests that 15 seconds be used as a system
default.
3.8.2
Dial-Up Communications
Time-out values must be programmed into the terminal. The values listed below are used by American
Express.
3.8.2.1
10 Second Time-Out
Advice messages (0220, 0320, 0420) transmitted after the successful receipt of a Financial Transaction (0210) or Authorization (0110) Response Message
Reversal messages (0400) transmitted after the successful receipt of a Financial Transaction
(0210) or Authorization (0110) Response Message
3.8.2.2
20 Second Time-Out
No response from the primary NAC when the terminal dials for communications. The terminal
must automatically dial the secondary NAC telephone number, when the primary NAC has not
responded after 20 seconds
3.8.2.3
30 Second Time-Out
Authorization Requests (0100)
Financial Capture Requests (0200)
Reconciliation Requests (0500)
Advice messages (0220, 0320, 0420) transmitted upon initiation of a transaction at the terminal
(such as a card swipe)
Reversal messages (0400) transmitted upon initiation of a transaction at the terminal (such as a
card swipe)
24
POS020055
October 22, 2010
4.0
Standard Process Flow Diagrams (Capture Host)
This section contains diagrams that illustrate typical standard process flows, including normal processing scenarios and time-out (reversal) and error examples, for messages processed by the American
Express Capture Host.
Standard (Capture Host) process flow diagrams include the following:
4.1
Authorizations Normal Processing
4.2
Authorizations Reversal Processing
4.3
Financial Transactions Normal Processing
4.4
Financial Transactions Referral Processing
4.5
Financial Transactions Advice Processing (Normal)
4.6
Financial Transactions Advice Processing (Time-Out)
4.7
Financial Transactions Reversal Processing
4.8
File Updates Time-Out Processing
4.9
4.10
Reconciliation Time-Out Processing
4.11
Close Batch Normal Processing
4.12
Close Batch Error Processing
October 22, 2010
POS020055
25
4.1
Authorizations Normal Processing
The terminal transmits an Authorization Request (0100) Message containing transaction details to the
Capture Host. The Host returns an Authorization Response (0110) Message, which indicates that the
transaction is approved, referred (for voice authorization) or denied/declined.
If an authorization request is referred for voice authorization and subsequently approved, the card
acquirer gives the Merchant an approval code, which must be entered in the terminal and added to the
Record of Charge (ROC).
Terminal
Host
Authorization Request (0100)

Authorization Response (0110)
Disconnect
4.2
Authorizations Reversal Processing
A terminal typically times out after a predetermined transmission delay (e.g., 15 seconds). When a
time-out occurs, a Reversal Request (0400) Message is automatically generated by the terminal and
transmitted to the Capture Host. No other messages can be transmitted until a Reversal Response
(0410) Message is received by the terminal. For example, if a card is swiped at the terminal before a
Reversal Response is received, another Reversal Request message is transmitted to the Capture Host
before the new authorization request is processed.
When the terminal receives a Reversal Response message from the Capture Host, it automatically
transmits the new authorization request message. If a Reversal Response is not received, the terminal
times-out and does not transmit the authorization request message to the Capture Host.
Terminal
Host

Time-Out
Disconnect
Transaction Initiated (Card Swipe)
Disconnect
Disconnect
26
POS020055
October 22, 2010
4.2
Authorizations Reversal Processing (Continued)
If a time-out occurs during the transmission of an Authorization Request (0100) Message, and the
subsequent Reversal Request (0400) Message also times out without the terminal receiving a Reversal
Response (0410) Message; the authorization request must be reinitiated. In this case, when the card is
swiped, the Reversal Request (0400) Message is retransmitted; and when a Reversal Response (0410)
is received, the original Authorization Request (0100) Message is sent.
Terminal
Host

Time-Out
Disconnect
Time-Out
Disconnect
Disconnect
Disconnect
4.3
Financial Transactions Normal Processing
The terminal transmits a Financial Transaction Request (0200) Message to the Capture Host. The Host
processes the authorization, captures the transaction for settlement and returns a Financial Transaction
Response (0210) Message to the terminal.
The scenario below is typical for American Express transactions that are authorized. However, this
diagram does not apply to transactions referred for voice authorization. For Referral Processing, see
subsection that follows.
Terminal
Host
Financial Transaction Request (0200)
Authorized and Captured at Host

Financial Transaction Response (0210)
Disconnect
October 22, 2010
POS020055
27
4.4
Financial Transactions Referral Processing
If an authorization or financial request is referred for voice authorization, the terminal disconnects
from the Capture Host; and the Merchant calls the American Express authorization center for a verbal
approval. If the acquirer approves the request, an approval code is given to the Merchant. The Merchant
manually enters the approval code into the terminal, which prepares a sale completion Financial Transaction Advice Request (0220) Message. However, this request message is not immediately transmitted
to the Capture Host for processing. Instead, the message is stored in the terminal until a Financial Transaction (0210) or Authorization (0110) Response Message is received by the terminal. The response
message must be for an approved (authorized) transaction and must contain an approval code.
When the response message is received by the terminal, the sale completion Financial Transaction
Advice Request (0220) Message is immediately transmitted to the Capture Host, during the same call.
A sale completion Financial Transaction Advice Response (0230) Message is returned to the terminal.
Terminal
Host
Financial Transaction Request (0200)-1

Financial Transaction Response (0210)-1
with Voice Referral
Disconnect
Merchant picks up handset or

calls issuer for voice authorization
If transaction is approved, issuer

provides approval code to Merchant
Merchant enters approval code at
terminal. Terminal stores code in
Financial Transaction Advice Request (0220)-1
Disconnect (Merchant hangs up)
Financial Transaction Request (0200)-2
Financial Transaction Response (0210)-2
Disconnect
Financial Transaction Advice Response (0230)-1
Disconnect
28
POS020055
October 22, 2010
4.5
Financial Transactions Advice Processing (Normal)
When a Merchant enters an amount adjustment or an off-line transaction on the terminal, a Financial
Transaction Advice Request (0220) Message is generated. However, the message is not immediately
transmitted to the Capture Host. Instead, it is held and transmitted when one of the following
conditions is met:
When the terminal receives an Authorization (0110) or Financial Transaction (0210) Response
Message that contains an approve response code.
When a Reconciliation Request (0500) Message is transmitted to the Capture Host.

(Advice request messages must be transmitted before reconciliation can occur.)
The Financial Transaction Advice Request (0220) Message is automatically forwarded to the Capture
Host in conjunction with the receipt of the authorization/financial response or transmission of the
Reconciliation Request (0500) Message, and the Host returns a Financial Transaction Advice
Response (0230) Message.
Terminal
Host
(See note below)

Approved Financial Transaction
Response (0210)
Disconnect

Advice Response (0230)
Disconnect
Financial Transaction Advice Request (0220)

Advice Response (0230)
Disconnect

Financial Transaction Advice Response (0230)
Disconnect
Note: Offline transactions are stored at the terminal until a Financial Transaction Response (0210) Message is successfully
received by the terminal. At that time, the first Financial Transaction Advice Request (0220) Message is sent to the host.
October 22, 2010
POS020055
29
4.6
Financial Transactions Advice Processing (Time-Out)
If a time-out occurs during the transmission of a Financial Transaction Advice Request (0220)
Message, the advice request is resent after a response for another transaction (e.g., sale or authorization
request) is received.
Terminal
Host

Disconnect
Time-Out
Disconnect
Disconnect
Disconnect
30
POS020055
October 22, 2010
4.7
Financial Transactions Reversal Processing
When a time-out occurs during the transmission of a Financial Transaction Request (0200) Message,
the Capture Host may or may not receive the message. Because the Merchant will resubmit the transaction, which may result in the creation of a duplicate, the terminal automatically transmits a Reversal
Request (0400) Message before processing another transaction. This reversal cancels the original
transaction, if it was received by the Capture Host. The Host responds by transmitting a Reversal
Response (0410) Message with a Reversal accepted response code.
If the time-out occurs before the Capture Host receives the original transaction, the Host responds to
the Reversal Request with a Reversal not found response code.
After the Reversal Response message is received at the terminal, the terminal can attempt to process
additional transactions.
If a time-out occurs during the transmission of the reversal, no other transactions will be accepted by
the terminal until a Reversal Response message is received from the Capture Host. If a new transaction is initiated at the terminal, the Reversal Request will be retransmitted, and no transactions will
be sent to the Capture Host until a Reversal Response is received.
4.7.1
Reversal Processing Scenario A

Terminal
Host

Time-Out
Disconnect

Disconnect
Disconnect
October 22, 2010
POS020055
31
4.7.2
Reversal Processing Scenario B

Terminal
Host

Time-Out

Time-Out
Disconnect
Transaction initiated (Card Swipe)
Disconnect

Disconnect
4.7.3
Reversal Processing Scenario C

Terminal
Host

Time-Out
Time-Out
Disconnect
Time-Out
Disconnect
Disconnect

Disconnect
32
POS020055
October 22, 2010
4.8
File Updates Time-Out Processing
If a time-out occurs during the uploading of transactions, the terminal is not permitted to perform any
activities other than to restart the downloading or uploading of transactions. The terminal displays a
Please Retry time-out response.
4.9
Reconciliation messages are used to close a batch. The Capture Host maintains a shadow file of the
transactions stored in the terminal so that during reconciliation, the Capture Host shadow batch can be
compared to the terminal batch. If both batch totals match, only Reconciliation (05XX) Messages are
needed to close the batch.
However, if the batch totals do not match, Transaction Upload Advice Request (03XX) Messages
must be used in conjunction with Reconciliation (05XX) Messages to close the batch.
The flow diagrams for reconciliation messages include:
For more information on the above, see subsections that follow.
4.10
Reconciliation Time-Out Processing
If a time-out occurs during the exchange of reconciliation messages, the terminal is not permitted to
perform any activities other than to restart the reconciliation process. The terminal is responsible for
locking out all other traffic until the reconciliation process is successfully completed. Since a terminal
locks-up upon initiation of any transaction type other than reconciliation (05XX), the American Express
Terminal Help Desk must usually be called to reinitiate the reconciliation process.
4.11
When a Merchant closes a terminal batch, a Reconciliation Request (0500) Message containing
settlement details is transmitted to the Capture Host. When the Host receives the batch close request,
it compares totals in the terminals request to those in the shadow file. If the figures agree, the Capture
Host returns a Reconciliation Response (0510) Message that contains an Approved response code.
The Capture Host also sends a text message to the terminals display.
Terminal
Host

Disconnect
October 22, 2010
POS020055
33
4.12
During settlement, if the Capture Host shadow file and terminal batch totals do not match, the Host
returns a Reconciliation Response (0510) Message with a Bad reconciliation send detail response
code. The terminal transmits a Transaction Upload Advice Request (0320) Message upload request
containing the first transaction in the batch; and the Capture Host returns a Transaction Upload Advice
Response (0330) Message with a processing code that prompts the terminal to transmit the next transaction, if another exists. This process continues until all transactions in the terminal are uploaded to a
new shadow file in the Capture Host.
After the Capture Host receives all transactions in the batch, the terminal transmits another
Reconciliation Request (0500) Message. The Host shadow file and terminal batch totals should
match, since both now contain the same data; and the batch should close properly. However, if the
batch totals are not the same, the terminal is placed on the trouble list.
Terminal
Host
Totals do not match with host

Reconciliation Response (0510) with error
message to upload messages from the terminal
Disconnect
Transaction Upload Advice Request (0320)

Upload Request for first transaction in batch
Transaction Upload Advice Response (0330)
Disconnect
03XX message exchanges continue
until all transactions in the batch
are uploaded to the host
Transaction Upload Advice Request (0320)
Upload Request for last transaction in batch
Transaction Upload Advice Response (0330)
Disconnect
Disconnect
34
POS020055
October 22, 2010
5.0
Stand-In Process Flow Diagrams (GAN)
The Global Authorization Network (GAN) stands-in (substitutes) when the American Express Capture
Host is unavailable. The GAN transmits Authorization Response Messages similar to the Capture
Host, except that Additional Response Data (Field 44) contains code 02 indicating that the response
is from the GAN. For more information on Express 3000 PIP Interface Messages, see page 11.
This section contains diagrams that illustrate typical stand-in process flows, including normal processing scenarios and time-out (reversal) examples, for the messages processed by the American Express
GAN.
Stand-in (GAN) process flow diagrams include the following:
5.1
Authorizations GAN Normal Processing
5.2
Authorizations GAN Reversal Processing
5.3
Financial Transactions GAN Normal Processing
5.4
Financial Transactions GAN Referral Processing
5.5
Financial Transactions GAN Advice Processing (Normal)
5.6
Financial Transactions GAN Advice Processing (Time-Out)
5.7
Financial Transactions GAN Reversal Processing
5.8
Other Message Formats
October 22, 2010
POS020055
35
5.1
Authorizations GAN Normal Processing
The terminal transmits an Authorization Request (0100) Message to the Capture Host, which is temporarily unavailable. The GAN substitutes for the host, and returns an Authorization Response (0110)
Message, which indicates that the transaction is approved, referred for voice authorization or denied/
declined. This message contains code 02 in Additional Response Data (Field 44), which indicates
that the response is from the GAN.
If an authorization request is referred for voice authorization and subsequently approved, the card
acquirer gives the Merchant an approval code, which must be entered in the terminal and added to the
Record of Charge (ROC).
Terminal
Host
Capture Host Unavailable

from GAN
Disconnect
36
POS020055
October 22, 2010
5.2
Authorizations GAN Reversal Processing
Reversals that occur during a GAN session are processed similar to those in a Capture Host session.
When a time-out occurs during the processing of an Authorization Request (0100) Message, the Capture
Host may or may not receive the transaction. Because the Merchant will resubmit the transaction,
which may result in the creation of a duplicate, the terminal automatically transmits a Reversal
Request (0400) Message before processing another transaction. If the GAN stands in for the Capture
Host, it transmits a Reversal Response (0410) Message with code 02 in Additional Response Data
(Field 44). The terminal must store this response as a Reversal Advice Request (0420) Message.
When the terminal subsequently receives a response from the Capture Host containing code 01 in
Additional Response Data (Field 44), the Reversal Advice Request (0420) Message (which was
stored in the terminal) is transmitted to the Capture Host.
Terminal
Host

Time-Out
Terminal stores as

from GAN
Disconnect

from Capture Host
Disconnect
from Capture Host
Disconnect
October 22, 2010
POS020055
37
5.2
Authorizations GAN Reversal Processing (Continued)
If a time-out occurs during the transmission of an Authorization Request (0100) Message, and the subsequent Reversal Request (0400) Message also times out without the terminal receiving a Reversal
Response (0410) Message, no Reversal Advice Request (0420) Message is stored in the terminal. In
this case, the authorization request must be reinitiated.
Terminal
Host

Time-Out
Time-Out
Disconnect
Transaction initiated at terminal
(e.g. card swipe)

from GAN
Disconnect
38
POS020055
October 22, 2010
5.3
Financial Transactions GAN Normal Processing
When the Capture Host is unavailable, a Financial Transaction Request (0200) Message is routed to
the GAN, which stands in for the Capture Host and returns Financial Transaction Response (0210)
Messages with code 02 in Additional Response Data (Field 44). The terminal must store each
Financial Transaction Response (0210) Message as a Financial Transaction Advice Request (0220)
Message.
Additional Response Data (Field 44), the Financial Transaction Advice Request (0220) Messages
(which were stored in the terminal) are transmitted to the Capture Host. Advice messages cannot be
transmitted to the GAN.
The scenario below is typical for American Express financial transactions that are authorized. However,
this diagram does not apply to transactions referred for voice authorization. For Referral Processing,
see subsection that follows.
Terminal
Host
Stored by terminal as a
Message with GAN Indicator

from GAN
Disconnect

Disconnect

Disconnect
October 22, 2010
POS020055
39
5.4
Financial Transactions GAN Referral Processing
A financial request referred for voice authorization via the GAN is processed the same as one referred
by the Capture Host. The Merchant calls the American Express authorization center for a verbal approval. If the acquirer approves the request, an approval code is given to the Merchant. The Merchant
manually enters the approval code into the terminal, which prepares a sale completion Financial
Transaction Advice Request (0220) Message. Because sale completion messages cannot be accepted
by the GAN, the terminal must store that message until the Capture Host is available.
When an approved Authorization (0110) or Financial Transaction (0210) Response Message is
received from the Capture Host, the terminal automatically transmits the sale completion Financial
Transaction Advice Request (0220) Message to the Host, during the same call. A sale completion
Financial Transaction Advice Response (0230) Message is returned to the terminal.
Terminal
Host

with Voice Referral
Disconnect
Merchant picks up handset or
calls issuer for voice authorization
If transaction is approved, issuer

provides approval code to Merchant
Merchant enters approval code
at terminal. Terminal stores code
in advice request message
Disconnect (Merchant hangs up)
Authorized and Captured by Capture Host
Disconnect
Disconnect
40
POS020055
October 22, 2010
5.5
Financial Transactions GAN Advice Processing (Normal)
Advice messages cannot be processed by the GAN. Therefore, terminal-generated advice messages
must be stored until the Capture Host is available, as determined by the terminal receiving an Authorization (0110) or Financial Transaction (0210) Response Message with Additional Response Data
(Field 44), omitted or containing code 01.
Terminal
Host
Note: See pages 29 and 30 for more information

on Advice Message processing.
Stored by Terminal as
Financial Transaction Advice Request Message
(0220)-3 with GAN Indicator

from GAN
Disconnect

Response (0210)
Disconnect

Disconnect
Note: The process continues for Financial Transaction Advice Request Messages (0220)-2 and -3. These messages are
sent after an approved Authorization (0110) or Financial Transaction (0210) Response Message is received by a terminal.
October 22, 2010
POS020055
41
5.6
Financial Transactions GAN Advice Processing (Time-Out)
If a time-out occurs during the transmission of an advice request message, and the GAN substitutes for
the Capture Host in processing subsequent transactions; then the advice message that was awaiting
response from the Capture Host must be stored in the terminal and be the first advice message transmitted when the Capture Host becomes available. This applies regardless of the order in which other
advice messages may be stored.
Terminal
Host
(See note below)

Response (0210)
Disconnect

Time-Out
Disconnect
(e.g. card swipe)
Advice messages cannot be processed by GAN.

Terminal continues to store message (0220)-1
until Capture Host is available.

from GAN
Disconnect

(e.g. card swipe)

from Capture Host
Disconnect

from Capture Host
Disconnect
Note: See pages 29 and 30 for more information on Advice Message processing.
42
POS020055
October 22, 2010
5.7
Financial Transactions GAN Reversal Processing
Reversals that occur during a GAN session are processed similar to those in a Capture Host session.
When a time-out occurs during the transmission of a Financial Transaction Request (0200) Message,
the Capture Host may or may not receive the message. Because the Merchant will resubmit the transaction, which may result in the creation of a duplicate, the terminal automatically transmits a Reversal
Request (0400) Message before processing another transaction. If the GAN stands-in for the Capture
Host when the Reversal Request message is transmitted, the GAN returns a Reversal Response (0410)
Message with code 02 in Additional Response Data (Field 44). The terminal must store the response
message as a Reversal Advice Request (0420) Message.
Additional Response Data (Field 44), the Reversal Advice Request (0420) Message (which was
stored in the terminal) is transmitted to the Capture Host.
5.7.1
GAN Reversal Processing Scenario A

Terminal
Host

Time-Out
Disconnect
(e.g. card swipe)
Terminal stores as

from GAN
Disconnect

from Capture Host
Disconnect
with GAN Indicator
from Capture Host
Disconnect
October 22, 2010
POS020055
43
5.7.2
GAN Reversal Processing Scenario B

Terminal
Host

Time-Out

Time-Out
Disconnect
Transaction initiated (card swipe)
Terminal stores as

from GAN
Disconnect
Terminal stores as Financial Advice

Request (0220) with GAN Indicator

from GAN
Disconnect

from Capture Host
Disconnect

with GAN Indicator
from Capture Host
Disconnect
44
POS020055
October 22, 2010
5.8
Other Message Formats
The GAN stands-in only for authorization functions, and it is not a complete substitute for the American
Express Capture Host. For example, the GAN cannot process Transaction Upload Advice Request
(03XX) and Reconciliation (05XX) Messages. Therefore, these are not included in this section.
If a terminal attempts to process one of these messages during a GAN session, the terminal will timeout, an error will be returned (e.g., HOST N/A), and the terminal may be unable to process American
Express transactions until the Capture Host is again available.
See Section 4.0, Standard Processing Flow Diagrams (Capture Host), for more information on Capture
Host processing flows.
October 22, 2010
POS020055
45
46
POS020055
October 22, 2010
6.0
ISO 8583 Message Formats
This section defines numerous request and response messages, as defined for the ISO 8583 format.
These messages are constructed as specified in the ISO 8583-1987 standard. If your system supports a
different version of ISO 8583, please notify your American Express Technical Sales Representative.
6.1
Guidelines for Using the ISO 8583 Format
ISO 8583 standard provides for variable length messages that are bit map driven. A bit map consists
of a 64-bit string contained within an eight-byte field. The data content of a message is determined
by the value (1) or (0) of bits in a bit map field. Each bit is associated with a unique data field.
A few of the fields are fixed-length and others are variable-length. A length subfield or Variable
Length Indicator (VLI) precedes the variable length data fields. The length of the VLI will be
encoded in either two or three character bytes. The length of the VLI is not included in the length
of the data field it describes.
For example:
LLVAR When present with a variable length field specification, this indicates that the data
field contains two subfields:
LL indicates the number of positions in the VLI and the value in the VLI shows the length of
the variable-length data field that follows. The length may be 01 to 99, unless otherwise restricted.
VAR is the variable length data field.
Example: 27 Byte, LLVAR indicates a variable length data field with a maximum length of 25
characters and 2 characters for the length subfield.
LLLVAR When present with a variable length specification, this indicates that the data field
contains two subfields:
LLL indicates the number of positions in the variable-length data field that follows. Length may
be 001 to 999, unless otherwise restricted.
Example: 503 Byte, LLLVAR indicates a variable-length data field with a maximum length of
500 characters and 3 characters for the length subfield.
Unless otherwise specified, all fixed-length numeric fields should be right justified and zero
filled, fixed-length alphanumeric fields should be upper case, left justified and character space
filled, and binary fields should be in eight-bit blocks that are left justified and zero filled.
October 22, 2010
POS020055
47
6.1
Guidelines for Using the ISO 8583 Format (Continued)

Some fields are not supported in this version of the AMEX ISO 8583 interface. However, to allow
all processes to consistently and accurately deal with all data fields, all the attributes of all 64 data
elements in the primary bit map are listed on page 49 and must be allowed while developing the
interface.
This allows a message to be sent, even when it contains unsupported data. The data will not be
processed by the recipient nor returned to the sender, but the definitions allow each system to step
past unsupported elements to get to the following fields.
6.2
Variations from ISO 8583
Except as noted in the detailed message flows, for most messages or data fields, no individual data
field should exceed 290 bytes. For details, please contact your American Express representative.
Messages transmitted to American Express must not exceed 900 bytes in total length. Since all
data fields in the 0100 section are not used for a given transaction, this maximum would not be
exceeded. For example, Data Fields 45 and 35, TRACK 1 DATA and TRACK 2 DATA, are not
used in Card Not Present transactions. For assistance in selecting optional data fields, and determining the appropriate formats and variable field lengths to use, please contact your American
Express representative.
American Express reserves the right to modify field parameters (e.g., changing Field Type from
numeric to alphanumeric, or vice-versa) to meet specific business and/or internal data and system
requirements.
6.3
ISO 8583 Message Bit Map Table
ISO 8583 may utilize either one or two 64-position bit maps, which are designated as the Primary and
Secondary Bit Maps, to indicate which of up to 128 fields are contained in a message. However, at
this writing, American Express uses only the Primary Bit Map to indicate which of the first 64 fields
are included in each applicable message. The Secondary Bit Map and corresponding fields 65-128 are
unused at this time, and descriptive message format information is omitted from this document.
Notes:
1. Data fields shown in reversed text (white letters on a black background) are not used by American
Express, and unauthorized use of these fields may cause system problems and/or message rejection.
2. Bit 1 (BIT MAP SECONDARY) in the Primary Bit Map must be 0. Use of Secondary Bit Map
fields may cause system problems and/or message rejection.
48
POS020055
October 22, 2010
6.3.1
Primary Bit Map
Note: For Field Type, A = Alpha, N = Numeric, S = Special characters, B = Binary, BCD = Binary Coded Decimal
Data
Field
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
Data Element Name
Max. Field Length
MESSAGE TYPE IDENTIFIER (MTI)

BIT MAP - PRIMARY
BIT MAP SECONDARY
PRIMARY ACCOUNT NUMBER (PAN)
PROCESSING CODE
AMOUNT, TRANSACTION
AMOUNT, SETTLEMENT
AMOUNT, CARDHOLDER BILLING
DATE AND TIME, TRANSMISSION
AMOUNT, CARDHOLDER BILLING FEE
CONVERSION RATE, SETTLEMENT
CONVERSION RATE, CARDHOLDER BILLING
SYSTEMS TRACE AUDIT NUMBER
TIME, LOCAL TRANSACTION
DATE, LOCAL TRANSACTION
DATE, EXPIRATION
DATE, SETTLEMENT
DATE, CONVERSION
DATE, CAPTURE
MERCHANT TYPE
COUNTRY CODE, ACQUIRING INSTITUTION
COUNTRY CODE, PAN EXTENDED
COUNTRY CODE, FORWARDING INSTITUTION
POINT OF SERVICE ENTRY MODE
APPLICATION PAN NUMBER
NETWORK INTERNATIONAL IDENTIFIER (NII)
POINT OF SERVICE CONDITION CODE
POINT OF SERVICE CAPTURE CODE
AUTHORIZING IDENTIFICATION RESPONSE LENGTH
AMOUNT, TRANSACTION FEE
AMOUNT, SETTLEMENT FEE
AMOUNT, TRANSACTION PROCESSING FEE
AMOUNT, SETTLEMENT PROCESSING FEE
ACQUIRING INSTITUTION IDENTIFICATION CODE
FORWARDING INSTITUTION IDENTIFICATION CODE
PRIMARY ACCOUNT NUMBER, EXTENDED
TRACK 2 DATA
October 22, 2010
2 bytes, fixed
8 bytes, 64 bits
8 bytes, 64 bits
11 bytes, LLVAR
3 bytes, fixed
6 bytes, fixed
12 bytes, fixed
12 bytes, fixed
10 bytes, fixed
8 bytes, fixed
8 bytes, fixed
8 bytes, fixed
3 bytes, fixed
3 bytes, fixed
2 bytes, fixed
2 bytes, fixed
2 bytes, fixed
4 bytes, fixed
4 bytes, fixed
4 bytes, fixed
3 bytes, fixed
3 bytes, fixed
3 bytes, fixed
2 bytes, fixed
3 bytes, fixed
2 bytes, fixed
1 bytes, fixed
2 bytes, fixed
1 byte, fixed
8 bytes, fixed
8 bytes, fixed
8 bytes, fixed
8 bytes, fixed
13 bytes, LLVAR
13 bytes, LLVAR
30 bytes, LLVAR
38 bytes, LLVAR
Field Type
N
B (Hexadecimal)
B
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
N
ANS
POS020055
49
6.3.1
Primary Bit Map
Note: For Field Type, A = Alpha, N = Numeric, S = Special characters, B = Binary, BCD = Binary Coded Decimal
Data
Field
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
50
Data Element Name
Max. Field Length
TRACK 3 DATA
RETRIEVAL REFERENCE NUMBER (RRN)
AUTHORIZATION IDENTIFICATION RESPONSE
RESPONSE CODE
SERVICE RESTRICTION CODE
CARD ACCEPTOR TERMINAL IDENTIFICATION
CARD ACCEPTOR IDENTIFICATION CODE
CARD ACCEPTOR NAME/LOCATION
ADDITIONAL RESPONSE DATA
TRACK 1 DATA
ADDITIONAL DATA - ISO
ADDITIONAL DATA NATIONAL
ADDITIONAL DATA PRIVATE
CURRENCY CODE, TRANSACTION
CURRENCY CODE, SETTLEMENT
CURRENCY CODE, CARDHOLDER BILLING
PERSONAL IDENTIFICATION NUMBER (PIN) DATA
SECURITY RELATED CONTROL INFORMATION
AMOUNTS, ADDITIONAL
RESERVED - ISO
RESERVED - ISO
RESERVED - NATIONAL
RESERVED - NATIONAL
RESERVED FOR NATIONAL USE
PRIVATE - RESERVED
PRIVATE - RESERVED
PRIVATE - RESERVED
PRIVATE - RESERVED
MESSAGE AUTHENTICATION CODE (MAC) FIELD
POS020055
107 bytes, LLLVAR

12 bytes, fixed
6 bytes, fixed
2 bytes, fixed
3 bytes, fixed
8 bytes, fixed
15 bytes, fixed
40 bytes, fixed
26 bytes, LLVAR
77 bytes, LLVAR
1002 bytes, LLLVAR
1002 bytes, LLLVAR
7 bytes, LLLVAR
2 bytes, fixed
3 bytes, fixed
3 bytes, fixed
8 bytes, 64 bits
18 bytes, fixed
14 bytes, LLLVAR
1002 bytes, LLLVAR
1002 bytes, LLLVAR
1002 bytes, LLLVAR
1002 bytes, LLLVAR
1002 bytes, LLLVAR
31 bytes, LLLVAR
10 bytes, LLLVAR
8 bytes, LLLVAR
42 bytes, LLLVAR
8 bytes, 64 bits
Field Type
NS
AN
AN
AN
AN
ANS
ANS
ANS
AN
AN
AN
AN
AN
N
N
N
B
N
ANS
ANS
ANS
ANS
ANS
ANS
ANS
ANS
ANS
ANS
B
October 22, 2010
7.0
PIP Terminal Interface Data Fields
This section defines the content and format for information transmitted in the data fields that comprise
the request and response messages exchanged between the Merchant (acquirer) and American Express.
Subsections include the following:
7.1
Data Field Descriptions Detailed descriptions for all data fields in American Express PIP
Terminal Interface messages.
7.2
Data Field/Message Usage Tables Tables that list the data fields needed to build each type
of message, along with a brief summary of field requirements.
October 22, 2010
POS020055
51
7.1
Data Field Descriptions
This subsection contains detailed descriptions of all data fields used in the various messages used by
the American Express PIP Terminal Interface. See data field definition attributes below.
Length of Field For variable-length data, the minimum and maximum acceptable lengths are
specified (e.g., 3 bytes minimum, 14 bytes maximum). These values include the Variable Length
Indicator (VLI), which is indicated by LLVAR or LLLVAR, where the Ls indicate the
number of digits in the VLI. Data may be any length up to the maximum allowed, and should not
be padded with zeros, spaces or other characters, unless otherwise specified (see note below).
Note: VLIs and variable data transmitted as binary coded decimal (BCD) entries must have an
even number of digits, and data with odd digit-lengths must be padded to complete the unused
nibble in the remaining partial byte. See further explanation on page 53.
For fixed-length data, the exact length is indicated (e.g., 6 bytes, fixed). In this case, entries must
be the specified length, including padding, if necessary. Unless otherwise specified, fixed-length
alphanumeric data is upper case, left justified and character space filled, as necessary; and
numeric data is right justified and zero filled.
Field Type In this specification, the data field types include numeric, alphanumeric, special
characters and binary, including binary coded decimal (BCD) and hexadecimal configurations.
Unless otherwise indicated, alpha characters should be upper case.
Field Format Indicates binary coded decimal (BCD) and/or hexadecimal format, as applicable
to a specific field. See explanations on page 53.
Field Requirement Data field usage, specified by Message Type Identifier code table. See list
of all message type codes on page 56, and message type explanations that follow in this section.
Also, see explanation of requirements, below.
M (Mandatory) This data field is required and must be populated in the message(s)
indicated. Field omission or invalid data may result in processing errors or rejection of the
message or file.
O (Optional) This data field is optional and its inclusion or omission does not affect
normal processing.
C (Conditional) Use of this data field is determined by specific conditions that are
explained in Field Requirement Table notes or the Description that immediately follows.
or N/A This data field is not used in the message(s) indicated.
Description Details describe expected entries in data fields that comprise Merchant-generated
request messages, or data that populates fields in responses returned from American Express.
52
POS020055
October 22, 2010
7.1
Data Field Descriptions (Continued)
While individual fields reflect ISO requirements as alphanumeric, numeric, etc., all fields in messages
created per this specification must be converted to binary coded decimal (BCD) or hexadecimal format,
as specified in the Data Field Descriptions.
Important Note for Web Services IP Payments Gateway Users: ISO 8583 messages created per
this specification must be converted to binary coded decimal and hexadecimal configuration
before being transmitted as an ASCII string to the American Express IP Payments Gateway.
Similarly, ASCII files returned from American Express will be in binary coded decimal (BCD)
and hexadecimal configuration and may require conversion to a format compatible with the
Merchants terminal/system.
Binary Coded Decimal (BCD) Format
Data in binary coded decimal (BCD) format is transmitted in 8-bit blocks, with each digit stored on
four bits (one nibble), and each byte representing two digits (00 to 99). Some legacy specifications may also refer to this format as binary numeric, packed numeric, packed bits or packed decimal.
BCD entries must have an even number of digits, and data with odd digit-lengths must be padded to
complete the unused nibble in the remaining partial byte. If a padding character is necessary, it is added
per the instructions in the description for that field. For example, entries for three-digit Variable Length
Indicators (VLIs) and odd-digit, fixed width fields normally are right justified and zero filled. However,
there are numerous exceptions to this guideline; and specific instructions for individual fields should be
followed.
In this specification, the ISO 8583 field length refers to the number of significant numerals or characters represented by the binary formatted data, less any padding that was added to complete an unused
nibble in a remaining partial byte.
For example, when the three-digit VLI 005 is transmitted in BCD format, it is right justified, padded
with a leading zero, and converted to binary 8-bit blocks with each digit stored on four bits (one nibble)
and each byte representing two digits (00 to 99). Thus, even though the ISO 8583 specified VLI
length (LLL) is 3 bytes, the VLI is actually transmitted as 00 05, which is two bytes of BCD data
representing four digits.
For a two-digit VLI (LL), no padding is necessary; and the VLI is transmitted as one byte of BCD
data representing two digits.
October 22, 2010
POS020055
53
7.1
Hexadecimal Format
Entries in hexadecimal format are mapped directly as eight bits per byte, with the value for any byte
of data varying from hexadecimal 00 to hexadecimal FF. For example, 10-byte numeric value
1234567890 is transmitted as 31 32 33 34 35 36 37 38 39 30.
Similarly, alpha characters are converted to their hexadecimal equivalents. For example, alpha text
MESSAGE is transmitted as 4D 45 53 53 41 47 45.
For hexadecimal data, padding for odd digit-length values is unnecessary; and ISO 8583 field lengths
are normally observed without adjustment.
54
POS020055
October 22, 2010
7.1
Data Fields in This Section:
Bit
2
3
4
11
12
13
14
15
22
24
25
35
37
38
39
41
42
43
44
45
47
48
49
54
60
61
62
63
Field Name
Message Type Identifier
Bit Map - Primary
Primary Account Number (PAN)
Processing Code
Amount, Transaction
Systems Trace Audit Number
Time, Local Transaction
Date, Local Transaction
Date, Expiration
Date, Settlement
Point of Service Entry Mode
Network International Identifier (NII)
Point of Service Condition Code
Track 2 Data
Retrieval Reference Number (RRN)
Authorization Identification Response
Response Code
Card Acceptor Terminal Identification
Card Acceptor Identification Code
Card Acceptor Name/Location
Additional Response Data
Track 1 Data
Additional Data - National
Additional Data - Private
Currency Code, Transaction
Additional Amounts
Private Use Data
Private Use Data
Private Use Data
Private Use Data
Page
56
57
59
61
63
65
66
67
68
69
70
72
73
74
78
79
81
82
83
84
86
90
94
103
105
106
108
114
116
118
Note: See Data Field/Message Usage Tables beginning on

page 130.
October 22, 2010
POS020055
55
7.1
Data Field None
Length of Field:
2 bytes, fixed
Field Type:
Numeric
Field Format:
Binary coded decimal (BCD)
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
This field contains a Message Type Identifier, which is a code

that indicates the type of data contained in this message.
Valid entries include the following:
01 00 = Authorization Request
01 10 = Authorization Response
02 00 = Financial Transaction Request (Auth & Capture)
02 10 = Financial Transaction Response
02 20 = Financial Transaction Advice Request (Capture)
02 30 = Financial Transaction Advice Response
03 20 = Transaction Upload Advice Request (Terminal-to-
Host)
03 30 = Transaction Upload Advice Response
04 00 = Reversal Request
04 10 = Reversal Response
04 20 = Reversal Advice Request
04 30 = Reversal Advice Response
05 00 = Reconciliation Request
05 10 = Reconciliation Response
56
POS020055
October 22, 2010
7.1
Data Field None
Bit Map - Primary
Length of Field:
8 bytes, 64 bits, fixed length for each bit map
Field Type:
Binary
Field Format:
Hexadecimal
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
Each bit in this data field signifies the presence (value 1) or

absence (value 0) of a field in the Authorization Request (0100)
Message.
If the field is mandatory, or is optional and the Merchant elects
to use that field, its assigned bit map position must contain a
value of 1, to indicate the field is present. If the field is
optional and not used, its assigned bit map position must contain
a value of 0, to indicate the field is omitted.
Note: Bit 1 (BIT MAP SECONDARY) in the Primary Bit Map
must be 0. Use of Secondary Bit Map fields may cause system
problems and/or message rejection.
October 22, 2010
POS020055
57
7.1
Data Field None
Bit Map Primary (Continued)
The diagram below illustrates a 64-bit string contained within an eight-byte field. Each bit signifies
the presence (1) or absence (0) of the data field used within the 0100 message format:
1
2
3
4
0
0
1
1
9
10
11
12
0
0
1
0
17
18
19
20
0
0
0
0
25
26
27
28
1
0
0
0
33
34
35
36
0
0
1
0
41
42
43
44
1
1
0
0
49
50
51
52
1
0
0
0
57
58
59
60
0
0
0
0
5
6
7
8
0
0
0
0
13
14
15
16
0
0
0
0
21
22
23
24
0
1
0
1
29
30
31
32
0
0
0
0
37
38
39
40
0
0
0
0
45
46
47
48
1
0
0
0
53
54
55
56
0
0
0
0
61
62
63
64
0
0
0
0
The following diagram illustrates how to calculate the hexadecimal equivalent of the bit map from the
table shown above:
Position 1-8
0011 = 3
0000 = 0
Position 17-24
0000 = 0
0101 = 5
Position 33-40
0010 = 2
0000 = 0
Position 49-56
1000 = 8
0000 = 0
Position 9-16
0010 = 2
0000 = 0
Position 25-32
1000 = 8
0000 = 0
Position 41-48
1100 = C
1000 = 8
Position 57-64
0000 = 0
0000 = 0
Hexadecimal equivalents for bit map:

0000 = 0
1000 = 8
0001 = 1
1001 = 9
0010 = 2
1010 = A
0011 = 3
1011 = B
0100 = 4
1100 = C
0101 = 5
1101 = D
0110 = 6
1110 = E
0111 = 7
1111 = F
The hexadecimal equivalent for the bit map in this ISO 8583 Message (as shown above) is:
30 20 05 80 20 C8 80 00
58
POS020055
October 22, 2010
7.1
Data Field 2
Length of Field:
Variable Length Indicator:
Length of Variable Data:
2 bytes minimum, 11 bytes maximum, (LLVAR)

1 byte, right justified, zero filled
10 bytes maximum
Field Type:
Numeric
Field Format:
Field Requirement:
0100
C1
0110
0200
C1
0210
0220
C2
0230
0400
C1
0410
0420
C1
0430
0500
0510
0320
M
0330
C1 = Mandatory All, except Travelers Cheque, if American Express Cardmember

Account Number is manually entered. N/A Travelers Cheque.
C2 = Mandatory All, if American Express Cardmember Account Number is manually
entered. Note: PAN must be submitted, because American Express security requirements prohibit the storage of track data within Merchant or processor systems.
Description:
This field contains the Primary Account Number (a.k.a., Cardmember Account Number), preceded by a two-digit, Variable
Length Indicator (VLI). The VLI must indicate the exact length
of the account number.
Check digit validation is required. For details, see page 146.
In the example that follows, the two-digit VLI is 15, and the
digits that follow are the American Express Account Number,
both of which are transmitted in binary coded decimal (BCD)
format. The account number is 15 digits (an odd length), which
must be padded with a trailing F or 0; and 16 digits of
variable data are actually transmitted.
See example on next page.
October 22, 2010
POS020055
59
7.1
Data Field 2
Primary Account Number (PAN) (Continued)

Sample Data
Comments
15
VLI (2 digits)
371449635311004
PAN (15 digits)
15 37 14 49 63 53 11 00 4F
60
Position
Bytes
Comments
2-digit VLI in binary coded decimal (BCD) format.
2-9
15-digit PAN padded with trailing F or 0 in binary coded

decimal (BCD) format.
POS020055
October 22, 2010
7.1
Data Field 3
Processing Code
Length of Field:
3 bytes, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
Description:
This field contains the Processing Code that corresponds to the

financial service requested. Codes are derived from ISO 8583;
however, the last digit in this entry is used as a flow control
indicator when multiple records are transmitted. The Merchants
system must set this digit to indicate the status of the next data
exchange. Valid codes include the following:
For MTI = 0100
Transaction Processing Codes (Specify flow control X value)

00 40 0X
04 40 0X
20 40 0X
31 40 0X
For MTI = 0200
=
=
=
=
Card Authorization Request

American Express Travelers Cheque
Authorization Void (Reversal)
American Express Prepaid Card Balance Inquiry *
Transaction Processing Code (Specify flow control X value)

00 40 0X = Sale
31 40 0X = American Express Prepaid Card Balance Inquiry*
For MTI = 0220

22 40 0X
02 40 0X
00 40 0X
20 40 0X
00 40 0X
=
=
=
=
=
Credit Adjustment / Void

Debit Adjustment / Void
Off-Line Sale
Off-Line Refund
Sale Completion
For Processing Code = 31 40 0X, Amount, Transaction (Field 4) must be zero. Otherwise, Response Code
30 (Edit error - message format) is returned in Field 39. Also, please note that code 31 40 0X can only used
when file transfer is via the Web Services IP Payments Gateway using a high-speed Internet connection.
October 22, 2010
POS020055
61
7.1
Data Field 3
Processing Code (Continued)
For MTI = 0320

00 40 0X = Sale Upload
20 40 0X = Credit Upload
For MTI = 0400 & 0420
When a time-out occurs during transmission of an authorization

or financial request, a reversal message is generated to nullify
the incomplete transaction data and prevent accidental record
duplication in the Capture Host. For more information, see pages
21, 26, 28, 31, 37 and 43.
The Processing Code entered in the Reversal Request (0400)
or Reversal Advice Request (0420) Message must be the same
value used in the original 0100, 0200 or 0220 request that is
being reversed.
For MTI = 0500

92 00 0X = Close Batch
96 00 0X = Close Batch Following Batch Upload
Note: 92 00 0X is entered in this field when a terminal batch

is initially closed. If the Capture Host shadow file and terminal
batch totals do not match, the terminal uploads all transactions
awaiting settlement; and another Reconciliation Request (0500)
Message containing Transaction Processing Code 96 00 0X is
transmitted. For more information, see pages 33-34.
Flow Control Digits (Substitute for X in above, as applicable)
0
1
2
3
=
=
=
=
No more messages to send

More messages to follow, hold line (host-to-terminal)
Parameter update pending (host-to-terminal)
Prepare for batch upload (terminal-to-host)
Note: X is an invalid value, and is used for illustration

purposes only. Flow control digit (0-3) must be specified.
62
POS020055
October 22, 2010
7.1
Data Field 4
Amount, Transaction
Length of Field:
6 bytes, fixed (see USD transaction limit, below)
Field Type:
Numeric, right justified, zero filled
Field Format:
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
0510
0320
M
0330
In the request messages indicated above, this field contains the

total Transaction Amount (including tip and/or tax), in the currency designated by the Transaction Currency Code entry in
Field 49 (see page 105).
At this writing, only transactions in US Dollars and select global
currencies are accepted. Merchants must certify for each currency
submitted. For more information, please contact your American
For Void transactions (i.e., Debit/credit voids), Amount, Transaction must be zero (00 00 00 00 00 00).
For US Dollar (840) transactions, two decimal places are implied.
Thus, the value $100.00 would be entered as:
00 00 00 01 00 00
American Express limits the maximum value that can be
approved in this field. While most entries must not exceed
00 00 09 99 99 99, some locations may submit transaction
amounts in specific currencies up to 00 09 99 99 99 99.
However, please note that a transaction amount greater than
the maximum allowed will result in an invalid amount edit
error. For more information on maximum values, see Currency
Codes on page 196.
October 22, 2010
POS020055
63
7.1
Data Field 4
Amount, Transaction (Continued)

Balance Inquiry Prepaid Cards Only
A Prepaid Card Balance Inquiry for American Express Prepaid
Card products can be submitted by zero-filling Field 4 (Amount,
Transaction), if Field 3 (Processing Code) value is 31 40 0X
and Field 47 (Additional Data - National) value is 181 (Partial
Authorization) or 182 (Authorization with Balance Return).
The available balance is returned in response message Field 54
(Amounts, Additional). However, the following conditions apply:
Balance inquiries can only be processed for American Express

Prepaid Cards. For all other American Express Card products,
Field 54 is not returned and Response Code 58 (Invalid
Service) is returned in Field 39.
Amount, Transaction (this field) must be zero. Otherwise,

Response Code 30 (Edit error - message format) is
returned in Field 39.
Note: Balance Inquiry is only available via the Web Services

IP Payments Gateway using a high-speed Internet connection.
64
POS020055
October 22, 2010
7.1
Data Field 11
Length of Field:
3 bytes, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
This field contains the Systems Trace Audit Number, which is a

POS device/Merchant system-generated sequential number that
uniquely identifies a transaction. This sequence number should
be incremented for each request message transmitted to American
Express; and when 99 99 99 is reached, the following request
should restart at 00 00 01.
Notes:
1. Zero (00 00 00) is an invalid value and must not be used.
2. This field is mandatory for processing this message, and it
will be preserved and returned in the response message without alteration.
3. For Reversal Request (0400) and Reversal Advice Request
(0420) Messages only, the Systems Trace Audit Number
entered in this field must be the same value used in the
original 0100, 0200 or 0220 request that is being reversed.
October 22, 2010
POS020055
65
7.1
Data Field 12
Length of Field:
3 bytes, fixed
Field Type:
Numeric, hh mm ss
Field Format:
Field Requirement:
Description:
66
0100
0110
M
0200
0210
M
0220
M
0230
O
0400
0410
M
0420
0430
M
0500
0510
M
0320
M
0330
This field contains the Transaction Time, which is the local time
when the transaction took place at the card acceptor location. The
format is hh mm ss, and the value must be a valid time.
Subfield
Definition
Digits
Range
hh
mm
ss
Hour
Minute
Second
2
2
2
00-23
00-59
00-59
POS020055
October 22, 2010
7.1
Data Field 13
Length of Field:
2 bytes, fixed
Field Type:
Numeric, MM DD
Field Format:
Field Requirement:
Description:
October 22, 2010
0100
0110
M
0200
0210
M
0220
M
0230
O
0400
0410
M
0420
0430
M
0500
0510
M
0320
M
0330
This field contains the Transaction Date, which is the local date
when the transaction took place at the card acceptor location. The
format is MM DD, and the value must be a valid date.
Subfield
Definition
Digits
Range
MM
DD
Month
Day
2
2
01-12
01-31
POS020055
67
7.1
Data Field 14
Date, Expiration
Length of Field:
2 bytes, fixed
Field Type:
Numeric, YY MM
Field Format:
Field Requirement:
0100
C1
0110
0200
C1
0210
0220
C2
0230
0400
C1
0410
0420
C1
0430
0500
0510
0320
M
0330
C1 = Mandatory All, except Travelers Cheque, if Primary Account Number (Field 2) is

manually entered. N/A Travelers Cheque.
C2 = Mandatory All, if Primary Account Number (Field 2) is manually entered. Note:
Date, Expiration must be submitted, because American Express security requirements
prohibit the storage of track data within Merchant or processor systems.
Description:
This field contains the Expiration Date embossed on the face of

the American Express Card.
Please note that most American Express Card products are embossed with dates in format MM YY, which may require that the
data entered in this field be converted by reversing the month
and year values from the Card, so that this entry appears in
format YY MM.
This entry must be a valid date. No default values or zeros will
be accepted.
Subfield
Definition
Digits
Range
YY
Year
Last 2 only
00-99
MM
Month
01-12
Note: This field is not required if the message contains either

Track 1 (preferred) or Track 2 data read from the Cards magnetic
stripe.
68
POS020055
October 22, 2010
7.1
Data Field 15
Date, Settlement
Length of Field:
2 bytes, fixed
Field Type:
Numeric, MM DD
Field Format:
Field Requirement:
Description:
0100
0110
0200
0210
0220
0230
0400
0410
0420
0430
0500
O
0510
0320
0330
This field contains the Transaction Settlement Date. This optional

field may be used to transmit a Summary of Charge (SOC) batch
business date. If data is submitted, the format is MM DD, and the
value must be a valid date.
Subfield
Definition
Digits
Range
MM
DD
Month
Day
2
2
01-12
01-31
Note: If no data is provided, American Express systems substitute the Merchant/processor system capture date for internal
processing.
October 22, 2010
POS020055
69
7.1
Data Field 22
Length of Field:
2 bytes, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
Description:
0100
M
0110
0200
M
0210
0220
M
0230
0400
M
0410
0420
M
0430
0500
0510
0320
M
0330
This field contains the Point of Service (POS) Entry Mode code
(a.k.a., POS/Point of Service Data Code), which is a series of
values that identify terminal capability, security data and specific
conditions present at the time the transaction occurred at the
point of service.
This three-byte code is transmitted in binary coded decimal (BCD)
format, and the odd length must be padded. For example, 022,
must be padded with a leading zero to create the even-length
value 00 22, and four digits of data are actually transmitted.
The POS Entry Mode code is composed of two subcodes. Positions 1 and 2 indicate the Card Data Input Capability of the POS
device, e.g., Magnetic Stripe Read, Integrated Circuit Card (ICC),
etc. Similarly, Position 3 indicates the Cardholder Authentication
Capability (i.e., the primary means used to verify the Cardmembers identity), e.g., PIN entry.
Merchants should always attempt to populate all positions in the
POS Entry Mode code with valid data. However, if the applicable information is unavailable or unknown, the Merchant should
consult with their American Express representative to determine
the appropriate value(s) to use.
The POS Entry Mode code must be determined from the table of
values on the next page.
70
POS020055
October 22, 2010
7.1
Data Field 22
Point of Service Entry Mode (Continued)

Note: Codes shown in -reversed text- (white letters on a black background) are defined by ISO,
but are either reserved for future use or not currently defined by American Express. For information
on these codes, please contact your American Express representative.
Pos.
1&2
Code
Card Data Input Capability This subfield indicates the maximum capability of
the device used to originate this transaction.
00
01
02
03
04
05
06-60
Unspecified
Manual
Magnetic stripe
Bar code
Optical Character Recognition (OCR)
Integrated Circuit Card (ICC)
Reserved
Pos. 3
Code
Cardholder Authentication Capability This subfield indicates the primary

means used to verify the Cardmembers identity at this terminal.
0
1
2
3-9
October 22, 2010
Unspecified
PIN entry capability
No PIN entry capability
Reserved
POS020055
71
7.1
Data Field 24
Length of Field:
2 bytes, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
This field contains the Network International Identifier (NII)

code that identifies the processing host from the international
network of card processors. Valid codes include the following:
003 = American Express
This three-byte code is transmitted in binary coded decimal (BCD)

format, and the odd length must be padded. Specifically, 003
72
POS020055
October 22, 2010
7.1
Data Field 25
Length of Field:
1 byte, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
Description:
0100
M
0110
0200
M
0210
0220
M
0230
0400
M
0410
0420
M
0430
0500
0510
0320
M
0330
This field contains the POS (Point of Service) Condition Code,

which indicates the condition under which the transaction took
place at the point of sale/service. Valid codes include the
following:
00 = Normal presentation
06 = Pre-authorization request
October 22, 2010
POS020055
73
7.1
Data Field 35
Track 2 Data
Length of Field:

37 bytes maximum
Field Type:
Alphanumeric (upper case) & special characters
Field Format:
Field Requirement:
0100
C
0110
0200
C
0210
0220
C
0230
0400
C
0410
0420
C
0430
0500
0510
0320
0330
C = Mandatory All, except Travelers Cheque, if Track 2 data is available from Card
swipe. N/A Travelers Cheque.
Description:
This field contains the information encoded in a valid Track 2

read, preceded by a two-digit, Variable Length Indicator (VLI).
The VLI must indicate the exact length of the Track 2 data.
Track 1 and Track 2 data formats may vary slightly between various American Express systems. The field definitions referenced
in Section 9.2 are for reference only and may not reflect all variations that may be encountered. For this reason, when Track 1 or
Track 2 data is supplied intact, the acquirer, their devices, systems,
software, and terminal and software vendors should capture all
characters between the start and end sentinels, strip off the sentinels and LRC, and forward the remainder to American Express in
the appropriate ISO 8583 Track 1 or Track 2 field, without regard
to the specific lengths referenced in Section 9.2.
For more information, see American Express Magnetic Stripe
Formats and Expresspay Pseudo-Magnetic Stripe Formats beginning on pages 152 and 183.
Notes:
1. If Tracks 1 and 2 are both captured, both should be forwarded.
If only one track is captured, Track 1 is preferred (see page
90). For systems that capture only Track 2, this less desirable
alternative may be supplied in lieu of Track 1 (see page 74).
2. American Express security requirements prohibit the storage
of track data within Merchant or processor systems.
74
POS020055
October 22, 2010
7.1
Data Field 35
Track 2 Data (Continued)
ANSI X4.16 Format
In the example below, the two-digit VLI is 29, and the digits
that follow are the 29 characters of ANSI X4.16 Track 2 data,
both of which are transmitted in binary coded decimal (BCD)
format. The character D is used to depict the field separator.
Track 2 data is 29 characters (an odd length), which must be
padded with a trailing F or 0 (zero); and 30 digits of variable
data are actually transmitted in 15 bytes. The total length (VLI
plus variable data) is 16 bytes.
Sample Data
Comments
29
VLI (2 digits)
371449635311004D9403910112345 ANSI X4.16 Track 2 Data

(29 digits)
1
0
5 _6
29 37 14 49 63 53 11 00 4D 94 03 91 01 12 34 5F
October 22, 2010
Position
Bytes
Comments
2-16
15
29 digits of ANSI X4.16 Track 2 Data padded with trailing F or

0 in binary coded decimal (BCD) format.
POS020055
75
7.1
Data Field 35
ISO 7813 Format
that follow are the 37 characters of ISO 7813 Track 2 data, both
of which are transmitted in binary coded decimal (BCD) format.
The character = is used to depict the field separator. Track 2
data is 37 characters (an odd length), which must be padded with
a trailing F or 0 (zero); and 38 digits of variable data are actually transmitted in 19 bytes. The total length (VLI plus variable
data) is 20 bytes.
Sample Data
Comments
37
VLI (2 digits)
371449635311004=940310191011234567800 ISO 7813 Track 2 Data

(37 digits)
1
0
5 _6
2
0
37 37 14 49 63 53 11 00 4= 94 03 10 19 10 11 23 45 67 80 0F
76
Position
Bytes
Comments
2-20
19
37 digits of ISO 7813 Track 2 Data padded with trailing F or

0 in binary coded decimal (BCD) format.
POS020055
October 22, 2010
7.1
Data Field 35
Expresspay Pseudo-Magnetic
Stripe Format
that follow are the 37 characters of Expresspay Pseudo-Magnetic
Stripe Track 2 data, both of which are transmitted in binary coded
decimal (BCD) format. The character = is used to depict the
field separator. Track 2 data is 37 characters (an odd length),
which must be padded with a trailing F or 0 (zero); and 38
digits of variable data are actually transmitted in 19 bytes. The
total length (VLI plus variable data) is 20 bytes.
Sample Data
Comments
37
VLI (2 digits)
371449635311004=111270212342474312345 Pseudo-Magnetic Stripe

Track 2 Data (37 digits)
1
0
5 _6
2
0
37 37 14 49 63 53 11 00 4= 11 12 70 21 23 42 47 43 12 34 5F
Position
October 22, 2010
Bytes
Comments
2-20
19
37 digits of Pseudo-Magnetic Stripe Track 2 Data padded with

trailing F or 0 in binary coded decimal (BCD) format.
POS020055
77
7.1
Data Field 37
Length of Field:
12 bytes, fixed
Field Type:
Alphanumeric (upper case)
Field Format:
Hexadecimal
Field Requirement:
0100
0110
M
0200
0210
M
0220
C1
0230
C2
0400
0410
M
0420
0430
M
0500
0510
O
0320
M
0330
C1 = Mandatory Debit Adjustment/Void and Credit Adjustment/Void.

N/A Sale Completion, Off-Line Sale and Off-Line Refund.
C2 = Mandatory Sale Completion, Off-Line Sale and Off-Line Refund.
N/A Debit Adjustment/Void and Credit Adjustment/Void.
Description:
This field contains the Retrieval Reference Number (RRN),

which is an American Express-assigned, unique, 12-character
reference number used to identify a specific transaction for
further processing (e.g., adjustment, void, etc.).
This entry is shown in hexadecimal format and mapped directly
as eight bits per byte, with the value for any byte of data varying
from hexadecimal 00 to hexadecimal FF. For example, the
12-byte RRN 1234567890AB would be transmitted as:
1
1
0
31 32 33 34 35 36 37 38 39 30 41 42
While the Merchant POS device/system must retain an RRN

received from the American Express Capture Host, an RRN from
the American Express Global Authorization Network (GAN),
which is standing-in for the Capture Host, should be disregarded.
Note: The GAN substitutes for the American Express Capture
Host when the host is unavailable, and returns response messages
(similar to those generated by the Capture Host) to the Merchant
POS device/system. GAN-generated messages can be identified
by the value 02 in 0110 message, Field 44, Additional Response
Data. For details, see page 86.
For more information on Express 3000 PIP Interface Messages
and GAN, see pages 11 and 35, respectively.
78
POS020055
October 22, 2010
7.1
Data Field 38
Length of Field:
6 bytes, fixed
Field Type:
Alphanumeric, upper case, left justified, character space filled
Field Format:
Hexadecimal
Field Requirement:
0100
0110
C1
0200
0210
C1
0220
C2
0230
0400
0410
0420
0430
0500
0510
0320
C3
0330
C1 = Mandatory if Response Code (Field 39) in same message is 00 (Approval/

Accepted). Optional if Response Code is 02 (Please call with referral queue
number). For more information, see page 81.
C2 = Mandatory Sale Complete and Off-Line Sale. N/A All other transactions.
C3 = Mandatory Debit Upload. N/A Credit Upload.
Description:
The content of this field is dependent on the value in Field 39,

Response Code.
six-byte Authorization Code 123456 would be transmitted as:
1
31 32 33 34 35 36
See descriptions of Authorization Code and Referral Queue

Number responses on next page.
October 22, 2010
POS020055
79
7.1
Data Field 38
Authorization Identification Response (Continued)
For Authorization Code
If Response Code = 00 (Approval/Accepted), this field contains the American Express-assigned, Authorization Code that
corresponds to the originating authorization or financial request
message.
Valid formats include the following:
NNNNNN = Authorization code for all US and some regional
American Express Merchants.

Note: All US Merchants must comply with the
American Express Six-Digit Approval Code policy.
NNNNNN = Authorization code for American Express-supported
Cards.
NN~~~~ = Authorization code for some regional American
Express Merchants, only.

For Referral Queue Number
If Response Code = 02 (Please call with referral queue number),

this optional subfield may contain a four-digit, American Expressassigned Referral Queue Number that corresponds to the originating authorization or financial request message. If this field is
populated, the Referral Queue Number should be given to the
American Express Authorizer when the Merchant calls American
Express to complete the authorization process.
Valid formats include the following:
NNNN~~ = American Express Referral Queue Number.
American Express option only Not provided for

all American Express products; e.g., Gift Card
Note: In the examples on this page, N is an alphanumeric
character, and the tilde (~) represents a character space.
80
POS020055
October 22, 2010
7.1
Data Field 39
Response Code
Length of Field:
2 bytes, fixed
Field Type:
Alphanumeric (upper case)
Field Format:
Hexadecimal
Field Requirement:
Description:
0100
0110
M
0200
0210
M
0220
0230
M
0400
0410
M
0420
0430
M
0500
0510
M
0320
0330
M
This field contains a Response Code that indicates the American

Express disposition for this transaction.
two-byte Response Code 00 would be transmitted as:
1
30 30
00
01
02
03
06
12
13
14
19
25
30
51
October 22, 2010
=
=
=
=
=
=
=
=
=
=
=
=
Approval/Accepted (See p. 79)

Referral
Please call with referral queue number (See p. 80)
Bad SE (Merchant) Number
Partial Approval (Prepaid Cards Only)
Bad processing code
Bad amount
Bad Cardholder account information
Edit error
Terminal not identified or inactive
Edit error - message format
Credit denied
58
76
77
78
79
82
85
91
94
95
96
AA
=
=
=
=
=
=
=
=
=
=
=
=
Invalid service
Bad descriptor code
Close batch error
Old ROC not found
Batch already open
No SOC slots identified
Batch not found
System not available
Duplicate sequence number
Bad reconciliation Send detail
Misc. processing error
Card capture type invalid
POS020055
81
7.1
Data Field 41
Length of Field:
8 bytes, fixed
Field Type:
Field Format:
Hexadecimal
Field Requirement:
Description:
0100
M
0110
M
0200
M
0210
M
0220
M
0230
M
0400
M
0410
M
0420
M
0430
M
0500
M
0510
M
0320
M
0330
M
This field contains the Card Acceptor Terminal Identification,

which is a terminal provider-assigned, unique, eight-character,
code that identifies a specific terminal or POS device at a Merchant location.
eight-byte Card Acceptor Terminal ID 12345678 would be
transmitted as:
1
31 32 33 34 35 36 37 38
Note: American Express assigns this value for devices owned by

and/or leased through American Express.
82
POS020055
October 22, 2010
7.1
Data Field 42
Length of Field:
15 bytes, fixed
Field Type:
Alphanumeric (upper case) & special characters, left justified,

character space filled
Field Format:
Hexadecimal
Field Requirement:
Description:
0100
M
0110
0200
M
0210
0220
M
0230
0400
M
0410
0420
M
0430
0500
M
0510
0320
M
0330
O
This field contains the Card Acceptor Identification Code, which

identifies the Merchant in a POS transaction. Typically, this field
contains the 10-digit, American Express-assigned Service Establishment/SE Number.
10-byte SE Number 1234567890 would be transmitted as:
1
1
0
31 32 33 34 35 36 37 38 39 30 20 20 20 20 20
October 22, 2010
POS020055
83
7.1
Data Field 43
Length of Field:
40 bytes, fixed
Field Type:
Alphanumeric (upper case) & special characters, left justified,

character space filled
Field Format:
Hexadecimal
Field Requirement:
Description:
0100
O
0110
0200
O
0210
0220
O
0230
0400
O
0410
0420
O
0430
0500
0510
0320
O
0330
This field contains the Card Acceptor Name and/or Location.
Card Acceptor Name The Merchants business name that

appears on the storefront and/or customer receipts, commonly referred to as the DBA (Doing Business As) name.
Card Acceptor Location The store/location street address,

city, state, country and/or postal code. Alternately, this field
may contain a customer service phone number for a phoneor mail-order businesses, or e-mail and/or Web address for
an Internet-based business.
The backslash (\) symbol must be used as a subfield separator

between individual sub-elements of this field.
This entry must be easily recognized by the Cardmember to avoid
unnecessary inquiries. If the name is more than 40 characters, use
proper and meaningful abbreviation, when possible. Do not
truncate.
This data is shown in hexadecimal format and mapped directly
from hexadecimal 00 to hexadecimal FF.
See example on next page.
84
POS020055
October 22, 2010
7.1
Data Field 43
Card Acceptor Name/Location (Continued)

Sample Data
Comments
XYZ~STORE\1234~ABC~ST\PHX\AZ\USA\85054~~
Card Acceptor Name and/or Location

(40 characters)
Note: Tildes (~) represent character spaces.

0
1
1
0
2
0
58 59 5A 20 53 54 4F 52 45 5C 31 32 33 34 20 41 42 43 20 53
2
1
3
0
4
0
54 5C 50 48 58 5C 41 5A 5C 55 53 41 5C 38 35 30 35 34 20 20
October 22, 2010
Position
Bytes
1-40
40
Comments
40 characters of Card Acceptor Name and/or Location data
(40 bytes fixed length, upper case, left justified, character space
filled) shown in hexadecimal format.
POS020055
85
7.1
Data Field 44
Length of Field:

25 bytes maximum
Field Type:
Alphanumeric
Field Format:
Binary coded decimal (BCD) and hexadecimal
Field Requirement:
0100
0110
C1
0200
0210
C1
0220
C2
0230
O
0400
0410
O
0420
0430
O
0500
0510
O
0320
0330
O
C1 = Mandatory American Express Keyed CID Program and GAN authorization

response messages only. Optional Travelers Cheque.
C2 = Mandatory Voids of Off-Line Sale transactions (use code 06).
Optional Sale Completion and Off-Line Refund.
Description:
This field contains Additional Response Data that corresponds to

the message in which appears.
For MTI = 0220
This field is used in specific Financial Transaction Advice (0220)

Messages to indicate transaction type. In a message transmitted
to void an Off-Line Sale transaction, this field must contain a
two-digit VLI, followed by the constant literal 06 to indicate
Off-Line Sale. Optionally, this value may also be transmitted
for Sale Completion and Off-Line Refund transactions. For more
information on Financial Capture Messages, see pages 17-19.
For MTI = 0110, 0210, 0230,

0330, 0410, 0430 and 0510
Response Source Code
For all of these response messages, this field may contain a

Response Source Code that indicates the origin of the response
message (e.g., Capture Host, GAN, etc.).
Valid Response Source Codes include the following:
00 = Unspecified
01 = Capture Host-generated response
02 = GAN-generated response (for more information on the
Global Authorization Network, see page 35)

06 = Off-Line Sale
86
POS020055
October 22, 2010
7.1
Data Field 44
Additional Response Data (Continued)
For MTI = 0110 and 0210

Keyed CID Program
For these response messages only, this field may contain a CID
Response Code that indicates the disposition of the CID/4DBC/
4CSC value forwarded in the corresponding request message.
To receive a CID response in this field, a Merchant must be
certified for the American Express Keyed CID Program, and
Data Fields 47 and 48 must be populated per program requirements. For more information, see note below.
Valid CID Response Codes include the following:
Y = CID matched
N = CID did not match
U = CID was not checked
Notes:
1. Merchants certified for the American Express Keyed CID
Program must use Data Fields 47 (Additional Data - National)
and 48 (Additional Data - Private) in the Authorization (0100)
or Financial Transaction (0200) Request Message (as applicable) to transport the CID Indicator and CID code (a.k.a.,
4DBC or 4CSC). After processing, American Express returns
the CID Response Code in Data Field 44 (Additional Response Data) of the corresponding Authorization (0110) or
Financial Transaction (0210) Request Response Message.
For more information, see pages 86, 94 and 103.
2. CID Response Codes are only available via the Web Services
IP Payments Gateway using a high-speed Internet connection.
October 22, 2010
POS020055
87
7.1
Data Field 44
Example
MTI = 0110, 0210, 0220, 0230,
0330, 0410, 0430 and 0510
In the example below, the two-digit VLI is 02, which is transmitted in binary coded decimal (BCD) format; and the digits that
follow are the two-digit Response Source Code, which are shown
in hexadecimal format.
Response Source Code Only
Note: Response Source Code 01 (Capture Host-generated response) was used in the example. However, for MTI = 0220, the
Merchant must populate this subfield with the constant literal transaction type code value 06 (Off-Line Sale), when this message is
used to void an Off-Line Sale transaction.
Sample Data
Comments
02
VLI (2 digits)
01
Response Source Code (2 digits)
02 30 31
88
Position
Bytes
Comments
2-3
2-digit Response Source Code shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 44
Example
MTI = 0110 and 0210
In the example below, the two-digit VLI is 01, which is transmitted in binary coded decimal (BCD) format; and the digit that
follows is the one-character CID Response Code, which is shown
in hexadecimal format.
Keyed CID Program Only
Sample Data
Comments
01
VLI (2 digits)
CID Response Code (1 character)
01 59
Example
MTI = 0110 and 0210
Response Source Code
and Keyed CID Program
Position
Bytes
Comments
1-character CID Response Code shown in hexadecimal format.
In the example below, the two-digit VLI is 02, which is transmitted in binary coded decimal (BCD) format; and the digits that
follow are the two-digit Response Source Code and one-character
CID Response Code, which are shown in hexadecimal format.
Sample Data
Comments
03
VLI (2 digits)
01
Response Source Code (2 digits)
CID Response Code (1 character)
03 30 31 59
October 22, 2010
Position
Bytes
Comments
2-3
2-digit Response Source Code shown in hexadecimal format.
1-character CID Response Code shown in hexadecimal format.
POS020055
89
7.1
Data Field 45
Track 1 Data
Length of Field:

76 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
C
0110
0200
C
0210
0220
C
0230
0400
C
0410
0420
C
0430
0500
0510
0320
0330
C = Mandatory All, except Travelers Cheque, if Track 1 data is available from Card
swipe. N/A Travelers Cheque.
Description:
This field contains the information encoded in a valid Track 1

read, preceded by a two-digit, Variable Length Indicator (VLI).
The actual Track 1 data is composed of alphanumeric and special
characters, and a field separator value.
Track 1 and Track 2 data formats may vary slightly between various American Express systems. The field definitions referenced
in Section 9.2 are for reference only and may not reflect all variations that may be encountered. For this reason, when Track 1 or
Track 2 data is supplied intact, the acquirer, their devices, systems,
software, and terminal and software vendors should capture all
characters between the start and end sentinels, strip off the sentinels and LRC, and forward the remainder to American Express in
the appropriate ISO 8583 Track 1 or Track 2 field, without regard
to the specific lengths referenced in Section 9.2.
For more information, see American Express Magnetic Stripe
Formats and Expresspay Pseudo-Magnetic Stripe Formats beginning on pages 152 and 183.
Notes:
1. If Tracks 1 and 2 are both captured, both should be forwarded.
If only one track is captured, Track 1 is preferred (see page
90). For systems that capture only Track 2, this less desirable
alternative may be supplied in lieu of Track 1 (see page 74).
2. American Express security requirements prohibit the storage
of track data within Merchant or processor systems.
90
POS020055
October 22, 2010
7.1
Data Field 45
ANSI X4.16 Format
In the example below, the two-digit VLI is 59, which is transmitted in binary coded decimal (BCD) format; and the characters
that follow are the 59 characters of ANSI X4.16 Track 1 data,
which are shown in hexadecimal. The caret symbol (^) is used to
depict field separators, and tildes (~) represent character spaces.
The total length (VLI plus variable data) is 60 bytes.
Sample Data
Comments
59
VLI (2 digits)
B3714~496353~11004^FROST/CHARLES~F.JR~~~~~~~~^9403910112345
ANSI X4.16 Track 1 Data

(59 characters)
0
1
1
0
2
0
59 42 33 37 31 34 20 34 39 36 33 35 33 20 31 31 30 30 34 5E
2
1
3
0
4
0
46 52 4F 53 54 2F 43 48 41 52 4C 45 53 20 46 2E 4A 52 20 20
4
1
5
0
6
0
20 20 20 20 20 20 5E 39 34 30 33 39 31 30 31 31 32 33 34 35
Position
October 22, 2010
Bytes
Comments
2-60
59
59 characters of ANSI X4.16 Track 1 Data shown in hexadecimal

format.
POS020055
91
7.1
Data Field 45
ISO 7813 Format
In the example below, the two-digit VLI is 76, which is transmitted in binary coded decimal (BCD) format; and the characters
that follow are the 76 bytes of ISO 7813 Track 1 data, which are
shown in hexadecimal. The caret symbol (^) is used to depict
field separators, and tildes (~) represent character spaces. The
total length (VLI plus variable data) is 77 bytes.
0
1
Sample Data
Comments
76
VLI (2 digits)
B371449635311004^FROST/CHARLES~F.JR~~~~~~~~^
94031019101123456789012345678901
ISO 7813 Track 1 Data

(76 characters)
1
0
2
0
76 42 33 37 31 34 34 39 36 33 35 33 31 31 30 30 34 5E 46 52
2
1
3
0
4
0
4F 53 54 2F 43 48 41 52 4C 45 53 20 46 2E 4A 52 20 20 20 20
4
1
5
0
6
0
20 20 20 20 5E 39 34 30 33 31 30 31 39 31 30 31 31 32 33 34
6
1
7
0
35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31
Position
92
Bytes
Comments
2-77
76
76 characters of ISO 7813 Track 1 Data shown in hexadecimal

format.
POS020055
October 22, 2010
7.1
Data Field 45
Expresspay Pseudo-Magnetic
Stripe Format
In the example below, the two-digit VLI is 60 and the digits

that follow are the 60 bytes of Track 1 data shown in Expresspay
Pseudo-Magnetic Stripe Format. The character ^ is used to
depict the field separator. The total length (VLI plus variable
data) is 61 bytes.
Sample Data
Comments
60
VLI (2 digits)
B371449635311004^VALUED/CARDMEMBER~~~~12345^1211702123424743 Pseudo-Magnetic Stripe

Track 1 Data
(60 characters)
0
1
1
0
2
0
60 42 33 37 31 34 34 39 36 33 35 33 31 31 30 30 34 5E 56 41
2
1
3
0
4
0
4C 55 45 44 2F 43 41 52 44 4D 45 4D 42 45 52 20 20 20 20 31
4
1
5
0
6
0
32 33 34 35 5E 31 32 31 31 37 30 32 31 32 33 34 32 34 37 34 33
Position
October 22, 2010
Bytes
Comments
2-61
60
60 characters of Pseudo-Magnetic Stripe Track 1 Data shown in

hexadecimal format.
POS020055
93
7.1
Data Field 47
Length of Field:
3 bytes minimum, 31 bytes maximum, (LLLVAR)

2 bytes, right justified, zero filled
29 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
C1
0110
C2
0200
C1
0210
C2
0220
0230
0400
0410
0420
0430
0500
0510
0320
0330
C1 = Mandatory Specific Merchants identified for prepaid card functionality. All designated Merchants are informed by their American Express representative. Mandatory
American Express Keyed CID Program. N/A Travelers Cheque and Auth Void.
Optional All other Merchants for prepaid card functionality, but strongly recommended.
C2 = Mandatory return of original transaction amount for Partial Authorization transactions
(from 0100/0200 request message, Data Field 4, Amount, Transaction), if request message contains Function Code 181 or 182.
Description:
This field contains Additional Data that corresponds to the message in which it appears. See details on pages indicated below:
Message Type Indicator (MTI)
Page
0100 & 0200
95
0110 & 0210
102
Note: Data Field 47 is only available via the Web Services IP

Payments Gateway using a high-speed Internet connection.
94
POS020055
October 22, 2010
7.1
Data Field 47
Additional Data - National (Continued)
For MTI = 0100 & 0200
Keyed CID Program and Prepaid Card Function

Merchants participating in the American Express Keyed CID
Program, and/or specifically selected to utilize Prepaid Card
functionality, must populate this field with the codes below, as
applicable:
CID Indicator Code This code indicates that the Merchants system supports the American Express CID Response
Code, which is returned in Data Field 44 (Additional Response Data) of Authorization (0110) and Financial Transaction (0210) Response Messages.
Prepaid Card Function Code This code indicates that the

Merchants system supports the American Express Prepaid
Card Partial Authorization or Authorization with Balance
Return function.
The Variable Length Indicator (VLI), which corresponds to the

length of the variable data in this field, also indicates the data
transported.
VLI
Data Subfields / Contents
001
003
004
CID Indicator only

Prepaid Card Function Code only
CID Indicator and Prepaid Card Function Code
Example
001Y
003181
004Y181
Note: See applicable codes in subfield descriptions that follow.
Special certification is required for all of these features. For more

information, please contact your American Express representative.
During certification, terminal and software vendors must demonstrate the ability to populate and transmit appropriate information
in this field.
October 22, 2010
POS020055
95
7.1
Data Field 47

American Express CID Indicator
Merchants participating in the American Express Keyed CID
Program must populate this field with the constant literal Y
(Yes), to indicate that their system supports the CID Response
code returned in Data Field 44 of 0110/0210 response messages.
Note: Merchants certified for the American Express Keyed CID
or Financial Transaction (0200) Request Message (as applicable)
to transport the CID Indicator and CID code (a.k.a., 4DBC or
4CSC). After processing, American Express returns the CID
Response Code in Data Field 44 (Additional Response Data) of
the corresponding Authorization (0110) or Financial Transaction
(0210) Response Message. For more information, see pages 86,
94 and 103.
American Express Prepaid Card Function Code
Valid entries include:
181 = Prepaid Card Partial Authorization Supported
182 = Prepaid Card Authorization with Balance Return

Supported
These codes enhance acceptance, functionality and usage of

American Express Prepaid Card products at the POS. For these
special Prepaid Card services, terminal and software vendors are
required to support both Prepaid Card function, specifically
Partial Authorization and Authorization with Balance Return.
This enables their Merchants to select either option. Direct Link
Merchants have the choice of selecting the feature(s) they want
to support. American Express strongly recommends Partial
Authorization, because it approves a request for the remaining
balance rather than declining it when there are insufficient funds
to cover the original amount.
96
POS020055
October 22, 2010
7.1
Data Field 47

181 = Prepaid Card Partial Authorization Supported Indicates that the Merchants system accepts and processes
Prepaid Card response messages for partial authorization of transaction amounts less than the full value originally submitted for authorization. Please note that the
Merchant must collect the remainder from the Cardmember via another form of payment.
Merchants certified for Prepaid Card Partial Authorization should use code 181 for all transactions, and
American Express systems will determine which Card
products require a partial Authorization Response.
Specifically, non-prepaid Card products are ineligible
for Partial Authorization; and using code 181 will
not affect normal authorization requests.
When applicable, Partial Authorization-related data is
returned in the Authorization Response (0110) Message
Data Fields, below:
Data Field 4 Amount, Transaction
Data Field 39 Response Code
Data Field 47 Additional Data - National
Data Field 54 Amounts, Additional
These data fields represent the amount authorized, the

amount requested, the action taken and the balance
remaining on the prepaid card. For details, see pages
63, 81, 94 and 106, respectively.
October 22, 2010
POS020055
97
7.1
Data Field 47

182 = Prepaid Card Authorization with Balance Return Supported Indicates that the Merchants system and/or
POS device accepts and processes Prepaid Card balances in response messages. This alternative for systems that do not support partial authorizations returns
the Prepaid Card balance to the Merchant so that an
authorization request can be resubmitted for the available amount when transactions are denied for insufficient balance. Another form of payment (i.e., split tender) can be requested for the remainder.
Merchants certified for Prepaid Card Authorization
with Balance Return should use code 182 for all
transactions, and American Express systems will determine which Card products require a response related to
Authorization with Balance Return. Specifically, nonprepaid Card products are ineligible for Authorization
with Balance Return; and using code 182 will not
affect normal authorization requests. Using code 182
indicates that the Merchant is requesting an authorization for the full amount, and that their system supports
the return of Prepaid Card balance information from
American Express.
When applicable, Authorization with Balance Returnrelated data is returned in the Authorization Response
(0110) Message Data Fields, below:
Data Field 39 Response Code
Data Field 54 Amounts, Additional
These data fields represent the action taken and the

balance remaining on the prepaid card. For details,
see pages 81 and 106, respectively.
98
POS020055
October 22, 2010
7.1
Data Field 47

A Prepaid Card Balance Inquiry for American Express Prepaid
Card products can be submitted by zero-filling Field 4 (Amount,
Transaction), if Field 3 (Processing Code) value is 31 40 0X
and Field 47 (Additional Data - National) value is 181 (Partial
Authorization) or 182 (Authorization with Balance Return).
The available balance is returned in response message Field 54
(Amounts, Additional). However, the following conditions apply:
Balance inquiries can only be processed for American Express

Prepaid Cards. For all other American Express Card products,
Field 54 is not returned and Response Code 58 (Invalid
Service) is returned in Field 39.
Amount, Transaction (this field) must be zero. Otherwise,

Response Code 30 (Edit error - message format) is
returned in Field 39.
Note: Merchant certification is required to receive Balance

Inquiry Responses.
Example
MTI = 0100 & 0200
The three-digit VLI is transmitted in binary coded decimal

(BCD) format, and the odd length must be padded. Specifically, 004, must be padded with a leading zero to create
the even-length value 00 04, and four digits of data are
actually transmitted.
The one-character CID Identifier Code is shown in hexadecimal format.
CID Identifier Code Only
Sample Data
Comments
001
VLI (3 digits)
CID Identifier Code (1 character)
00 04 59
October 22, 2010
Position
Bytes
1-2
3-digit VLI in binary coded decimal (BCD) format, padded with a

leading zero.
Comments
1-character CID Identifier Code shown in hexadecimal format.
POS020055
99
7.1
Data Field 47
Example
MTI = 0100 & 0200

The three-digit Prepaid Card Function Code is shown in

hexadecimal format.
Prepaid Card Function Code

Only
Sample Data
Comments
003
VLI (3 digits)
181
Prepaid Card Function Code (3 digits)
00 03 31 38 31
100
Position
Bytes
Comments
1-2

leading zero.
3-5
3-digit Prepaid Card Function Code shown in hexadecimal

format.
POS020055
October 22, 2010
7.1
Data Field 47
Example
MTI = 0100 & 0200

The one-character CID Identifier Code is shown in hexadecimal format.
The three-digit Prepaid Card Function Code is shown in

hexadecimal format.
CID Identifier Code and

Prepaid Card Function Code
Sample Data
Comments
004
VLI (3 digits)
CID Identifier Code (1 character)
181
Prepaid Card Function Code (3 digits)
00 04 59 31 38 31
October 22, 2010
Position
Bytes
Comments
1-2

leading zero.
1-character CID Identifier Code shown in hexadecimal format.
4-6
3-digit Prepaid Card Function Code shown in hexadecimal

format.
POS020055
101
7.1
Data Field 47
For MTI = 0110 & 0210
Prepaid Card Original Transaction Amount

For Authorization (0110) and Financial Transaction (0210)
Response Messages, this field contains the original transaction
amount (i.e., the amount requested) when a partial authorization
is approved for an American Express Prepaid Card product.
Merchants must be certified for Partial Authorization for the
original amount to be returned in this field. This data is only
present in the response message, when Data Field 47, ADDITIONAL DATA - NATIONAL, in the originating request
message contains Function Code 181.
Positions 3-14 of this field are the original transaction amount
from Data Field 4, AMOUNT, TRANSACTION, in the originating Authorization (0100) or Financial Transaction (0200)
Request Message.
Example
MTI = 0110 and 0210

The 12-digit original transaction amount is shown in hexadecimal format.
Prepaid Card Original

Transaction Amount
The example shown is the entry for a $100.00 original transaction

amount in US Dollars (840), with two decimal places implied.
Sample Data
Comments
012
VLI (3 digits)
000000010000
Original Transaction Amount (12 digits)
1
0
00 12 30 30 30 30 30 30 30 31 30 30 30 30
102
Position
Bytes
Comments
1-2

leading zero.
3-14
12
12-digit, fixed length, Original Transaction Amount is right justified and zero filled, and shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 48
Length of Field:

5 bytes maximum
Field Type:
Alphanumeric
Field Format:
Field Requirement:
0100
C
0110
0200
C
0210
0220
C
0230
0400
0410
0420
0430
0500
0510
0320
0330
C = Conditional Merchants transmitting American Express Auth, Sale, Sale

Completion & Off-Line Sale transactions only (special certification required).
This field is reserved for Merchants specifically selected by American Express to
participate in the Keyed CID Program. Special certification is required. For more
information, please contact your American Express representative.
Note: This field is not used by most Merchants and details are provided for reference
only.
Description:
This field contains the American Express Card Identifier (CID)

code, preceded by a Variable Length Indicator (VLI) and Data
Type Definition code, constant literal 4.
4 = Four-Digit Batch Code; a.k.a., 4DBC or 4CSC
Note: Merchants certified for the American Express Keyed CID

or Financial Transaction (0200) Request Message (as applicable)
to transport the CID Indicator and CID code (a.k.a., 4DBC or
4CSC). After processing, American Express returns the CID
Response Code in Data Field 44 (Additional Response Data) of
the corresponding Authorization (0110) or Financial Transaction
(0210) Response Message. For more information, see pages 86,
94 and 103.
October 22, 2010
POS020055
103
7.1
Data Field 48
Additional Data - Private (Continued)

Although this is a variable length field, the variable data is always
five bytes, which is explained below:

The one-digit Data Type Definition code, constant literal 4,

follows the VLI and is transmitted in binary coded decimal
(BCD) format. This odd length must be padded. Specifically,
4, must be padded with a leading zero to create the evenlength value 04, and two digits of data are actually transmitted.
The four-digit Card Identifier (CID) code is shown in hexadecimal format, and follows the Data Type Definition code.
The example below shows the entry for CID code 1234.
For locations of CID/4DBC/4CSC on American Express Card

products, see page 151.
Sample Data
Comments
005
VLI (3 digits)
Data Type Definition Code (1 digit)
1234
CID/4DBC/4CSC (4 digits)
_1
00 05 04 31 32 33 34
104
Position
Bytes
Comments
1-2

leading zero.
1-digit Data Type Definition code in binary coded decimal (BCD)

format, padded with a leading zero.
4-7
4-digit American Express Card CID/4DBC/4CSC, shown in

hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 49
Length of Field:
2 bytes, fixed
Field Type:
Numeric
Field Format:
Field Requirement:
Description:
0100
M
0110
0200
M
0210
0220
M
0230
0400
M
0410
0420
M
0430
0500
M
0510
0320
M
0330
This field contains a numeric Transaction Currency Code that

indicates the currency used in this transaction. For example, the
code for US Dollars is 840.
The three-digit, currency code is transmitted in binary coded
decimal (BCD) format, and the odd length must be padded. Specifically, 840, must be padded with a leading zero to create the
even-length value 08 40, and four digits of data are actually
transmitted.
Note: At this writing, only transactions in US Dollars and select
global currencies are accepted. For information on other currency
codes and decimal point positions, please contact your American
October 22, 2010
POS020055
105
7.1
Data Field 54
Additional Amounts
Length of Field:

12 bytes maximum
Field Type:
Alphanumeric
Field Format:
Field Requirement:
0100
C1
0110
C2
0200
O
0210
C2
0220
C3
0230
0400
C4
0410
0420
C4
0430
0500
0510
0320
O
0330
C1 = Optional Auth. N/A Travelers Cheque and Auth Void.

C2 = Mandatory if Field 47 (Function Code) = 181 or 182, and data is available.
C3 = Optional Sale Completion, Off-Line Sale and Debit Adjust/Void.
N/A Credit Adjust/Void and Off-Line Refund.
C4 = Optional Auth and Sale. N/A Travelers Cheque, Auth Void and Refund.
Description:
This field may contain a tip or tax amount applicable to this transaction, which must be included as part of the total Transaction
Amount entered in Field 4. This value must be in the currency
designated by the Transaction Currency Code (see page 105).
global currencies are accepted. For more information, please
contact your American Express representative.
This data is for information only, and the value entered is used
exclusively to print the tip or tax amount on the final facsimile
ROC. This entry is not used in conjunction with other fields to
calculate the Transaction Amount or any other totals.
12 bytes. See example on next page.
106
POS020055
October 22, 2010
7.1
Data Field 54
Additional Amounts (Continued)

The 12-digit, fixed length, Additional Amount is right justified and zero filled.
The example shown is the entry for a $5.00 additional amount in

US Dollars (840), with two decimal places implied.
Sample Data
Comments
012
VLI (3 digits)
000000000500
Additional Amount (12 digits)
1
0
00 12 30 30 30 30 30 30 30 30 30 35 30 30
For MTI = 0110 & 0210
Position
Bytes
1-2

leading zero.
Comments
3-14
12
12-digit, fixed length, Additional Amount is right justified and zero

filled, and shown in hexadecimal format.
For Response Message on Prepaid Card Authorization Requests,

this field contains the available amount remaining on certain
American Express Prepaid Card products. It is present in the
response message, when Data Field 47, ADDITIONAL DATA NATIONAL, in the originating request message contains codes
181 or 182. Merchants may wish to display this value on
the POS terminal or print it on the customer receipt.
Notes:
1. Balances may not be returned for some Prepaid Cards.
2. The Available Amount remaining on Prepaid Cards is only
available via the Web Services IP Payments Gateway using a
high-speed Internet connection.
October 22, 2010
POS020055
107
7.1
Data Field 60
Private Use Data
Length of Field:

29 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
O
0110
C1
0200
O
0210
C1
0220
0230
0400
0410
0420
C2
0430
0500
M
0510
0320
M
0330
C1= Mandatory Responses for Auth, Sale, Sale Completion and Off-Line Sale,
if Address Verification Service (AVS) data was submitted in request message.
N/A Travelers Cheque, Auth Void and Refund.
C2= Mandatory Auth and Sale. N/A Travelers Cheque, Auth Void and Refund.
Description:
The contents of this field are limited by the Message Type Identifier (MTI) entry for this transaction. See below.
For MTI = 0100 & 0200
For Authorization (0100) and Financial Transaction (0200) Requests that transport Address Verification Service (AVS) data,
this field must contain the Cardmembers billing Postal Code
(USA ZIP), and Billing Address (see Street Codes on page 202).
29 bytes, which is explained below:

The Cardmembers billing Postal Code and Billing Address

are shown in hexadecimal format, upper case, left justified
and character space filled to 29 bytes.
108
The nine-character Cardmember billing Postal Code is

shown in hexadecimal format. For addresses in the US,
this is a numeric 5+4 ZIP; or it is a five-digit ZIP, left
justified and character space filled to nine characters.
POS020055
October 22, 2010
7.1
Data Field 60
Private Use Data (Continued)
For MTI = 0100 & 0200
(Continued)
Cardmember Billing Postal Code & Billing Address (cont.)
The 20-character Cardmember Billing Address is shown

in hexadecimal format. Entry should be abbreviated,
upper case, left justified and character space filled, or
truncated, as necessary.
Sample Data
Comments
029
VLI (3 digits)
85054~~~~
Cardmember Billing Postal Code (9 characters)
18850~N~56~ST~PHOENI
Cardmember Billing Address (20 characters)

0
1
1
0
2
0
00 29 38 35 30 35 34 20 20 20 20 31 38 38 35 30 20 4E 20 35
2
1
3
0
36 20 53 54 20 50 48 4F 45 4E 49
October 22, 2010
Position
Bytes
Comments
1-2

leading zero.
3-11
ZIP (USA), padded to 9 bytes, if necessary; shown in hexadecimal format.
12-31
20
Billing Address, padded or truncated to 20 bytes, as necessary;

shown in hexadecimal format.
POS020055
109
7.1
Data Field 60
For MTI = 0110 & 0210
For Authorization (0110) and Financial Transaction (0210)

Response Messages that transport Address Verification Service
(AVS) data, this field contains the AVS response code for the
data submitted in the corresponding request message. Valid
codes include the following:
Y = Yes, Postal Code and Billing Address are both correct.
N = No, Postal Code and Billing Address are both incorrect.
A = Billing Address only correct.
Z = Billing Postal Code only correct.
R = AVS unavailable
Note: The AVS response (which is used to help validate the identity of the Cardholder) is generated independently from other
authorization and financial response data; and the Authorization
Response (a.k.a., Approval Code) returned in Data Field 38
(which indicates the Cardmembers account status) is not influenced by the AVS result. Merchants should use both of these
responses to evaluate risk and reduce fraud.
one byte, which is explained below:

The one-character AVS response code is shown in hexadecimal format.
Sample Data
Comments
001
VLI (3 digits)
Data Type Definition Code (1 character)
00 01 59
110
Position
Bytes
Comments
1-2

leading zero.
1-character AVS response code in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 60
For MTI = 0320 & 420
For Transaction Upload Advice Request (0320) Message batch

upload requests, this field must contain the Message Type Identifier and Systems Trace Audit Number (a.k.a., sequence number)
that correspond to the original transaction now being retransmitted as part of a batch upload.
For Reversal Advice Request (0420) Messages, this field may
contain the original Message Type Identifier and Systems Trace
Audit Number (a.k.a., sequence number) for an authorization or
sale transaction previously submitted to the Global Authorization
Network (GAN) when the Capture Host was unavailable.
For more information on Message Type Identifier and Systems
Trace Audit Number, see pages 56 and 65, respectively.
Although this is a variable length field, for 0320 and 0420
messages the variable data is always 22 bytes, which includes
a 12-byte Reserved subfield, which is explained below:
October 22, 2010

The four-digit Message Type Identifier is shown in hexadecimal format.
The six-digit Systems Trace Audit Number is shown in hexadecimal format.
The 12-character Reserved subfield is character space filled

and shown in hexadecimal format.
POS020055
111
7.1
Data Field 60
For MTI = 0320 & 420
(Continued)
Sample Data
Comments
022
VLI (3 digits)
0320 or 0420
Message Type Identifier (MTI) (4 digits)
123456
Systems Trace Audit Number (6 digits)
~~~~~~~~~~~~
Reserved subfield (12 character spaces)

0
1
1
0
2
0
00 22 30 33 32 30 31 32 33 34 35 36 20 20 20 20 20 20 20 20 20 20 20 20
112
Position
Bytes
1-2

leading zero.
Comments
3-6
4-digit Message Type Identifier (MTI) shown in hexadecimal

format.
7-12
6-digit Systems Trace Audit Number shown in hexadecimal

format.
13-24
12
12-character Reserved subfield shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 60
For MTI = 0500
For Reconciliation Request (0500) Message, close batch

requests, this field must contain the Batch Identification Number
assigned by the terminal or Merchant system when a batch is
closed. This value is used when referencing a specific group of
financial transactions.
This entry must be all numerals and cannot be 000000 or
999999.
six bytes, which is explained below:

The six-digit Batch Identification Number is right justified

and zero filled, and shown in hexadecimal format.
Sample Data
Comments
006
VLI (3 digits)
001234
Batch Identification Number (6 digits)
00 06 30 30 31 32 33 34
October 22, 2010
Position
Bytes
Comments
1-2

leading zero.
3-8
6-digit Batch Identification Number shown in hexadecimal

format.
POS020055
113
7.1
Data Field 61
Private Use Data
Length of Field:

8 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
C1
0110
0200
M
0210
0220
M
0230
0400
C2
0410
0420
C2
0430
0500
0510
0320
M
0330
C1 = Mandatory Auth and Auth Void. N/A Travelers Cheque.

C2 = Mandatory Sale and Refund. N/A Auth, Auth Void and Travelers Cheque.
Description:
This field contains a series of up to four, American Expressassigned, two-digit, Item Descriptor Codes, which correspond to
the merchandise and/or services sold using this POS terminal or
device. These codes are provided to the Merchant during set-up,
and their use is required for access American Express systems.
eight bytes, which is explained below:
114

Up to four, two-digit Item Descriptor Codes are left justified

and character space filled, and shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 61

Sample Data
Comments
008
VLI (3 digits)
11
Item Descriptor Code #1 (2 digits)
22
33
~~
Note: Tildes (~) represent character spaces (i.e., no code).

0
1
1
0
00 08 31 31 32 32 33 33 20 20
October 22, 2010
Position
Bytes
1-2
3-digit Variable VLI in binary coded decimal (BCD) format,

padded with a leading zero.
Comments
3-4
2-digit Item Descriptor Code #1 shown in hexadecimal format.
5-6
7-8
9-10
POS020055
115
7.1
Data Field 62
Private Use Data
Length of Field:

6 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
C1
0110
0200
M
0210
0220
M
0230
0400
C2
0410
0420
C2
0430
0500
M
0510
0320
M
0330
C1 = Mandatory Auth and Auth Void. N/A Travelers Cheque.

C2 = Mandatory Sale and Refund. N/A Auth, Auth Void and Travelers Cheque.
Description:
This field contains the Invoice Number (a.k.a., Record of Charge

or ROC Number) assigned to this transaction, or the Summary
of Charge/SOC Number for a closed batch. This value is usually
generated by the POS terminal or device, or the Merchants
system. However, for off-line transactions, this number may be
taken from the preprinted ROC on which this transaction was
recorded.
This entry cannot be 000000 (six zeros), and the value must
be unique within a batch.
six bytes. See examples on next page.
116

The six-digit Invoice Number is right justified and zero filled.
POS020055
October 22, 2010
7.1
Data Field 62

Sample Data
Comments
006
VLI (3 digits)
001234
Invoice/ROC/SOC Number (6 digits)
00 06 30 30 31 32 33 34
October 22, 2010
Position
Bytes
Comments
1-2

leading zero.
3-8
6-digit Invoice/ROC/SOC Number shown in hexadecimal format.
POS020055
117
7.1
Data Field 63
Private Use Data
Length of Field:

40 bytes maximum
Field Type:
Field Format:
Field Requirement:
0100
C1
0110
0200
C2
0210
0220
C2
0230
0400
C1
0410
0420
C1
0430
0500
M
0510
O
0320
C3
0330
C1 = Mandatory Travelers Cheque only. N/A All others.

C2 = Mandatory Purchasing Card and Travel (Sign & Travel) industries.
N/A All others.
C3 = Mandatory Purchasing Card, Travel (Sign & Travel), Lodging, and Auto Rental
industries. N/A All others.
Description:
This field is used in several messages to transport different

information, and its contents are limited by the Message Type
Identifier (MTI) entry for this transaction.
In 0100, 0400 and 0420 requests, this field transports check

guarantee data for American Express Travelers Cheques.
In 0200 sale, 0220 sale completion and 0320 batch upload

requests, Purchasing Card and Travel (Sign & Travel) industries use this field to transport additional transaction details.
In 0320 batch upload requests only, Lodging and Auto Rental

industries use this field to transport additional transaction
details.
In 0500 close batch requests, this field must contain close

batch summary data.
In 0510 close batch responses, this field may contain batch

file processing status information.
See Note on next page.
118
POS020055
October 22, 2010
7.1
Data Field 63

Note: Although this is a variable length field, all subfields have
specific requirements; and the maximum length of typical variable data transmitted in this field is 40 bytes, which does not
include the Variable Length Indicator (VLI).
The three-digit VLI is transmitted in binary coded decimal (BCD)
format, and the odd length must be padded. For example, 040,
All variable data defined on the following pages (except the VLI)
are shown in hexadecimal format. See specific examples for
details on subfields that must be justified or filled.
For MTI = 0100, 0400 & 0420
American Express Travelers Cheque Subfields

The two-digit Table Identifier Code, the constant literal 07

(American Express Travelers Cheque), is shown in hexadecimal format.
The nine-digit Check Number is shown in hexadecimal

format.
Sample Data
Comments
011
VLI (3 digits)
07
Table Identifier Code (2 digits)
123456789
Check Number (9 digits)
0
1
1
0
00 11 30 37 31 32 33 34 35 36 37 38 39
October 22, 2010
Position
Bytes
1-2

leading zero.
Comments
3-4
2-digit Table Identifier Code shown in hexadecimal format.
5-13
9-digit Check Number shown in hexadecimal format.
POS020055
119
7.1
Data Field 63
For MTI = 0200, 0220 & 0320
Purchasing Card Data Subfields


(Purchasing Card Data), is shown in hexadecimal format.
The nine-digit SE (Service Establishment) Reference Number

is shown in hexadecimal format. This may be the original
Record of Charge (ROC) or invoice number from a POS
terminal, or a reference number from a Merchants computerized cash register or order processing system. This entry
can be any combination of characters and numerals; however, the value must be a cross-reference to a Merchants
record, so charge information can be readily retrieved.
The nine-character Customer Reference Number is shown

in hexadecimal format. This customer-designated reference
number for a transaction (e.g., purchase order, cost center,
project number, etc.) is provided by the Cardmember and
entered in Merchants system at the point-of-sale. If provided
by the Merchants customer, this subfield is required. This
data may be displayed in the statement/reporting process and
it may include client-specific accounting information.
During certification, terminal and software vendors must
demonstrate the ability to populate and transmit appropriate
information in this field.
120
The five-character Ship-To Postal Code is shown in hexadecimal format. For USA addresses, use the five-digit ZIP
code from the shipping address.
POS020055
October 22, 2010
7.1
Data Field 63
For MTI = 0200, 0220 & 0320
Purchasing Card Data Subfields (Continued)
0
1
Sample Data
Comments
025
VLI (3 digits)
17
123456789
SE Reference (ROC/Invoice) Number (9 digits)
123456789
Customer Reference Number (9 digits)
12345
Ship-To Postal Code (5 digits)
1
0
2
0
00 25 31 37 31 32 33 34 35 36 37 38 39 31 32 33 34 35 36 37
2
1
38 39 31 32 33 34 35
October 22, 2010
Position
Bytes
1-2

leading zero.
Comments
3-4
5-13
9-digit SE Reference Number shown in hexadecimal format.
14-22
9-digit Customer Reference Number shown in hexadecimal

format.
23-27
5-digit Ship-To Postal Code shown in hexadecimal format.
POS020055
121
7.1
Data Field 63
For MTI = 0200, 0220 & 0320
Travel (Sign & Travel) Data Subfields


(Travel Data), is shown in hexadecimal format.
The one-digit Payment Method Code is shown in hexadecimal format. This entry indicates if extended payment was
requested by the Cardmember. Valid codes include:
0 = No extended payment processing
1 = Extended payment processing required
0
1
The 14-character Ticket Number is shown in hexadecimal

format. This entry is the ticket or other reference number
printed on the source document, upper case, left justified and
character space filled, as necessary. This subfield is character
space filled if unused, or if data is unavailable.
Sample Data
Comments
017
VLI (3 digits)
18
Payment Method Code (2 digit)
81AB1234567890
Ticket Number (14 characters)
1
0
00 17 31 38 31 41 42 31 32 33 34 35 36 37 38 39 30 20 20
122
Position
Bytes
1-2

leading zero.
Comments
3-4
2-digit Payment Method Code shown in hexadecimal format.
6-19
14
14-character Ticket Number shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 63
For MTI = 0320
Lodging Data Subfields
October 22, 2010


(Lodging Data), is shown in hexadecimal format.
The nine-character Folio Number is shown in hexadecimal

format. This entry, which can be any combination of characters and numerals (upper case, left justified and character
space filled), is the Merchant- or authorized Third Party
Processor-designated reference number assigned to the itemized statement of charges/credits associated with this stay.
The nine-character Reference Number is shown in hexadecimal format. This may be the original Record of Charge (ROC)
or invoice number from a POS terminal, or a reference number from a Merchants computerized cash register or order
processing system. This entry can be any combination of
characters and numerals (upper case, left justified and character space filled); however, the value must be a cross-reference to a Merchants record, so charge information can be
readily retrieved.
The four-digit Arrival Date is shown in hexadecimal format.

This entry may be the actual or scheduled date that the guest
checked-in. The format is MMDD, and the value must be a
valid date.
The four-digit Departure Date is shown in hexadecimal

format. This entry may be the actual or scheduled date that
the guest checked-out. The format is MMDD, and the value
must be a valid date.
POS020055
123
7.1
Data Field 63
For MTI = 0320
Lodging Data Subfields (Continued)
The 12-digit Room Rate is shown in hexadecimal format.

This entry is the nightly rate for one room, right justified and
zero filled, in the currency designated by Currency Code,
Transaction entry (see page 105). If multiple rates apply, enter
room rate applicable to first night stay.
Note: At this writing, only transactions in US Dollars and
select global currencies are accepted. For more information,
please contact your American Express representative.
0
1
Sample Data
Comments
040
VLI (3 digits)
10
1234567AB
Folio Number (9 characters)
AB1234567
Reference Number (9 characters)
0611
Arrival Date (4 digits)
0612
Departure Date (4 digits)
000000001000
Room Rate (12 digits)
1
0
2
0
00 40 31 30 31 32 33 34 35 36 37 38 39 31 32 33 34 35 36 37
2
1
3
0
4
0
38 39 30 31 30 31 30 31 30 32 30 30 30 30 30 30 30 31 30 30 30 30
124
Position
Bytes
1-2

leading zero.
Comments
3-4
5-13
9-character Folio Number shown in hexadecimal format.
14-22
9-character Reference Number shown in hexadecimal format.
23-26
4-digit Arrival Date shown in hexadecimal format.
27-30
4-digit Departure Date shown in hexadecimal format.
31-42
12
12-digit Room Rate shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 63
For MTI = 0320
Auto Rental Data Subfields
October 22, 2010


(Auto Rental Data), is shown in hexadecimal format.
The one-character Adjustment Indicator is shown in hexadecimal format. This subfield is currently unused and character
space filled; and it is reserved for future use.
The nine-character Agreement Number (a.k.a., Invoice or

Contract Number) is shown in hexadecimal format. This
value, which may be be any combination of characters or
numerals (upper case, left justified and character space filled),
is the Merchant-defined reference number that corresponds
to the rental agreement issued by the Auto Rental agency
and signed by Cardmember. This Entry may become part
of descriptive bill on Cardmembers statement.
The six-digit Rental Date is shown is hexadecimal format.

This entry is the local date when vehicle was rented and/or
picked up. The format is MMDDYY, and the value must be a
valid date.
The six-digit Return Date is shown is hexadecimal format.

This entry is the local date when the vehicle was returned,
and the value must be greater than or equal to the entry in the
Rental Date subfield. The format is MMDDYY, and the value
must be a valid date.
POS020055
125
7.1
Data Field 63
For MTI = 0320
Auto Rental Data Subfields (Continued)

Sample Data
Comments
024
VLI (3 digits)
19
Adjustment Indicator (1 character space)
123456789
Agreement Number (9 characters)
010106
Rental Date (6 digits)
010206
Return Date (6 digits)

0
1
1
0
2
0
00 24 31 39 20 31 32 33 34 35 36 37 38 39 30 31 30 31 30 06
2
1
30 31 30 31 30 36
126
Position
Bytes
Comments
1-2

leading zero.
3-4
1-character Adjustment Indicator shown in hexadecimal format.
6-14
9-character Agreement Number shown in hexadecimal format.
15-20
6-digit Rental Date shown in hexadecimal format.
21-26
6-digit Return Date shown in hexadecimal format.
POS020055
October 22, 2010
7.1
Data Field 63
For MTI = 0500
Close Batch Summary Data Subfields

The three-digit Batch Debit Count is shown in hexadecimal

format. This entry is the total quantity of debit transactions in
a batch settlement file, including reversals and adjustments.
The 12-digit Batch Debit Amount is shown in hexadecimal

format. This entry is the total of all debits in a specified
batch, including reversals and adjustments, in the currency
designated by the Currency Code, Transaction entry (see
page 105).
The three-digit Batch Credit Count is shown in hexadecimal

format. This entry is the total quantity of credit transactions in
a batch settlement file, including reversals and adjustments.
The 12-digit Batch Credit Amount is shown in hexadecimal

format. This entry is the total of all credits in the specified
batch, including reversals and adjustments, in the currency
designated by the Currency Code, Transaction entry (see
page 105).
The six-digit Reserved subfield is zero filled and shown in

hexadecimal format.
All subfields must be right justified and zero filled. Amounts

must be in the currency designated by the Currency Code, Transaction entry (see page 105).
global currencies are accepted. For more information, please
contact your American Express representative.
October 22, 2010
POS020055
127
7.1
Data Field 63
For MTI = 0500
Close Batch Summary Data Subfields (Continued)
0
1
Sample Data
Comments
036
VLI (3 digits)
003
Batch Debit Count (3 digits)
000000012345
Batch Debit Amount (12 digits)
001
Batch Credit Count (3 digits)
000000001234
Batch Credit Amount (12 digits)
000000
Reserved subfield (6 zeros)
1
0
2
0
00 36 30 30 33 30 30 30 30 30 30 30 31 32 33 34 35 30 30 31
2
1
3
0
30 30 30 30 30 30 30 30 31 32 33 34 30 30 30 30 30 30
128
Position
Bytes
1-2

leading zero.
Comments
3-5
3-digit Batch Debit Count in hexadecimal format.
6-17
12
12-digit Batch Debit Amount in hexadecimal.
18-20
3-digit Batch Credit Count in hexadecimal format.
21-32
12
12-digit Batch Credit Amount in hexadecimal.
33-38
6-digit Reserved subfield in hexadecimal.
POS020055
October 22, 2010
7.1
Data Field 63
For MTI = 0510
Close Batch Response Subfields

This field is optional for close batch response messages and contains information to be displayed on a terminal screen, in response
to closing a batch. 40-bytes of data are formatted for viewing as
two 20-character lines of text.
Sample Data
Comments
040
VLI (3 digits)
AP~150000~~~~$100.00 Close Batch Response Text Line #1 (20 characters)

BATCH~~123456-123456 Close Batch Response Text Line #2 (20 characters)

0
1
1
0
2
0
00 40 41 50 20 31 35 30 30 30 30 20 20 20 20 24 31 30 30 2E
2
1
3
0
4
0
30 30 42 41 54 43 48 20 20 31 32 33 34 35 36 2D 31 32 33 34 35 36
October 22, 2010
Position
Bytes
Comments
1-2

leading zero.
3-22
20
20-character Close Batch Response Text Line #1 shown in

hexadecimal format.
23-42
20
20-character Close Batch Response Text Line #2 shown in

hexadecimal format.
POS020055
129
7.2
Data Field/Message Usage Tables
This subsection contains Data Field/Message Usage Tables for the following ISO 8583 Messages:
7.2.1
0100 Authorization Request
7.2.2
0110 Authorization Response
7.2.3
0200 Financial Transaction Request (Auth & Capture)
7.2.4
0210 Financial Transaction Response
7.2.5
0220 Financial Transaction Advice Request (Capture)
7.2.6
0230 Financial Transaction Advice Response
7.2.7
0320 Transaction Upload Advice Request (Terminal-to-Host)
7.2.8
0330 Transaction Upload Advice Response
7.2.9
0400 Reversal Request
7.2.10
0410 Reversal Response
7.2.11
0420 Reversal Advice Request
7.2.12
0430 Reversal Advice Response
7.2.13
0500 Reconciliation Request
7.2.14
0510 Reconciliation Response
130
POS020055
October 22, 2010
7.2.1
Data
Type
Field Format
0100 - Auth Void
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
ISO 8583 Bit Number
Field Length
0100 - Travelers Cheque
1. For Data Type, A = Alpha, N = Numeric, S = Special characters, B = Binary

2. For Field Format, BCD = Binary coded decimal, H = Hexadecimal
3. For Message Type Identifier (e.g., 0100, 0110, 0200, 0210, etc.), M = Mand., O = Opt., C = Cond., = N/A
Data Field Name
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
35
Track 2 Data
38 bytes, LLVAR
ANS
BCD
74
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
45
Track 1 Data
77 bytes, LLVAR
ANS
BCD / H*
90
47
31 bytes, LLLVAR
ANS
BCD / H*
94
48
7 bytes, LLLVAR
AN
BCD / H*
103
49
BCD
105
54
Additional Amounts
14 bytes, LLLVAR
AN
BCD / H*
106
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD / H*
108
H*
2 bytes, fixed
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD /
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
ANS
H*
118
63
*
0100 Authorization Request
0100 - Auth
Notes:
Private Use Data
42 bytes, LLLVAR
BCD /
VLI / Variable data; e.g. BCD / H indicates that VLI is in binary coded decimal (BCD) format, and variable data is in hexadecimal.
October 22, 2010
POS020055
131
7.2.2
Field Length
Data
Type
Field Format
0110 - Auth Void

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
ISO 8583 Bit Number

*
0110 Authorization Response
0110 - Auth
Notes:
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
38
6 bytes, fixed
AN
79
39
Response Code
2 bytes, fixed
AN
81
41
8 bytes, fixed
ANS
82
44
26 bytes, LLVAR
AN
BCD / H*
86
47
31 bytes, LLLVAR
ANS
BCD / H*
94
54
Amounts, Additional
14 bytes, LLLVAR
AN
BCD / H*
106
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD / H*
108
132
POS020055
October 22, 2010
7.2.3

Data Field Name
Field Length
Data
Type
Field Format
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
35
Track 2 Data
38 bytes, LLVAR
ANS
BCD
74
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
45
Track 1 Data
77 bytes, LLVAR
ANS
BCD / H*
90
H*
47
31 bytes, LLLVAR
ANS
BCD /
94
48
7 bytes, LLLVAR
AN
BCD / H*
103
49
BCD
105
54
Additional Amounts
14 bytes, LLLVAR
AN
BCD / H*
106
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD / H*
108
H*
2 bytes, fixed
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD /
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
ANS
H*
118
63
*
0200 Financial Transaction Request (Auth & Capture)
0200 - Sale
ISO 8583 Bit Number
Notes:
Private Use Data
42 bytes, LLLVAR
BCD /
October 22, 2010
POS020055
133
7.2.4
0210 Financial Transaction Response

Data Field Name
Field Length
Data
Type
Field Format
0210 - Sale
ISO 8583 Bit Number
Notes:
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
38
6 bytes, fixed
AN
79
39
Response Code
2 bytes, fixed
AN
81
41
8 bytes, fixed
ANS
82
44
26 bytes, LLVAR
AN
BCD / H*
86
H*
47
31 bytes, LLLVAR
ANS
BCD /
94
54
Amounts, Additional
14 bytes, LLLVAR
AN
BCD / H*
106
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD / H*
108
134
POS020055
October 22, 2010
7.2.5
2 bytes, fixed
BCD
Bit Map - Primary
0220 - Off-Line Refund
Field Format
0220 - Credit Adjustment/Void
Data
Type
0220 - Debit Adjustment/Void
Field Length
0220 - Off-Line Sale

Data Field Name
ISO 8583 Bit Number

*
0220 Financial Transaction Advice Request (Capture)
0220 - Sale Completion
Notes:
Page
56
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
35
Track 2 Data
38 bytes, LLVAR
ANS
BCD
74
37
12 bytes, fixed
AN
78
38
6 bytes, fixed
AN
79
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
44
26 bytes, LLVAR
AN
BCD / H*
86
45
Track 1 Data
77 bytes, LLVAR
ANS
BCD / H*
90
H*
47
31 bytes, LLLVAR
ANS
48
7 bytes, LLLVAR
AN
49
54
Additional Amounts
2 bytes, fixed
14 bytes, LLLVAR
94
BCD / BCD / H*
BCD /
103
BCD
105
AN
BCD / H*
106
H*
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD /
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
63
Private Use Data
42 bytes, LLLVAR
ANS
BCD / H*
118
October 22, 2010
POS020055
135
7.2.6
Field Length
Data
Type
Field Format
0230 - Off-Line Sale
0230 - Debit Adjustment/Void
0230 - Credit Adjustment/Void
0230 - Off-Line Refund

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
ISO 8583 Bit Number

*
0230 Financial Transaction Advice Response
0230 - Sale Completion
Notes:
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
39
Response Code
2 bytes, fixed
AN
81
8 bytes, fixed
ANS
82
26 bytes, LLVAR
AN
BCD / H*
86
41
44
136
POS020055
October 22, 2010
7.2.7
Field Length
Data
Type
Field Format
0320 - Credit Upload

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
37
12 bytes, fixed
AN
78
38
6 bytes, fixed
AN
79
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
105
49
BCD
54
Additional Amounts
14 bytes, LLLVAR
AN
BCD / H*
106
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD / H*
108
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD / H*
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
ANS
H*
118
63
*
0320 Transaction Upload Advice Request (Terminal-to-Host)
0320 - Debit Upload
ISO 8583 Bit Number
Notes:
Private Use Data
2 bytes, fixed
42 bytes, LLLVAR
BCD /
October 22, 2010
POS020055
137
7.2.8
Field Length
Data
Type
Field Format
0330 - Credit Upload

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
11
3 bytes, fixed
BCD
65
24
2 bytes, fixed
BCD
72
39
Response Code
2 bytes, fixed
AN
81
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
86
44
*
0330 Transaction Upload Advice Response
0330 - Debit Upload
ISO 8583 Bit Number
Notes:
26 bytes, LLVAR
AN
BCD /
H*
138
POS020055
October 22, 2010
7.2.9
Field Length
Data
Type
Field Format
0400 - Auth Void
0400 - Sale
0400 - Refund

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
ISO 8583 Bit Number

*
0400 Reversal Request
0400 - Auth
Notes:
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
35
Track 2 Data
38 bytes, LLVAR
ANS
BCD
74
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
45
Track 1 Data
77 bytes, LLVAR
ANS
BCD / H*
90
49
54
Additional Amounts
2 bytes, fixed
14 bytes, LLLVAR
BCD
105
AN
BCD / H*
106
H*
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD /
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
63
Private Use Data
42 bytes, LLLVAR
ANS
BCD / H*
118
October 22, 2010
POS020055
139
7.2.10
Field Length
Data
Type
Field Format
0410 - Auth Void
0410 - Sale
0410 - Refund

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
ISO 8583 Bit Number

*
0410 Reversal Response
0410 - Auth
Notes:
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
39
Response Code
2 bytes, fixed
AN
81
8 bytes, fixed
ANS
82
26 bytes, LLVAR
AN
BCD / H*
86
41
44
140
POS020055
October 22, 2010
7.2.11
Data
Type
Field Format
0420 - Auth Void
0420 - Sale
0420 - Refund
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
ISO 8583 Bit Number
Field Length

Data Field Name
8 bytes, 64 bits
57
11 bytes, LLVAR
BCD
59
Processing Code
3 bytes, fixed
BCD
61
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
14
Date, Expiration
2 bytes, fixed
BCD
68
22
2 bytes, fixed
BCD
70
24
2 bytes, fixed
BCD
72
25
1 byte, fixed
BCD
73
35
Track 2 Data
38 bytes, LLVAR
ANS
BCD
74
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
43
40 bytes, fixed
ANS
84
45
Track 1 Data
77 bytes, LLVAR
ANS
BCD / H*
90
49
54
Additional Amounts
2 bytes, fixed
14 bytes, LLLVAR
BCD
105
AN
BCD / H*
106
H*
60
Private Use Data
31 bytes, LLLVAR
ANS
BCD /
108
61
Private Use Data
10 bytes, LLLVAR
ANS
BCD / H*
114
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD / H*
116
ANS
H*
118
63
*
0420 Reversal Advice Request
0420 - Auth
Notes:
Private Use Data
42 bytes, LLLVAR
BCD /
October 22, 2010
POS020055
141
7.2.12
Field Length
Data
Type
Field Format
0430 - Auth Void
0430 - Sale
0430 - Refund

Data Field Name
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
ISO 8583 Bit Number

*
0430 Reversal Advice Response
0430 - Auth
Notes:
Amount, Transaction
6 bytes, fixed
BCD
63
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
39
Response Code
2 bytes, fixed
AN
81
8 bytes, fixed
ANS
82
26 bytes, LLVAR
AN
BCD / H*
86
41
44
142
POS020055
October 22, 2010
7.2.13
0500 Reconciliation Request

Data Field Name
Field Length
Data
Type
Field Format
0500 - Close
ISO 8583 Bit Number
Notes:
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
11
3 bytes, fixed
BCD
65
15
Date, Settlement
2 bytes, fixed
BCD
69
24
2 bytes, fixed
BCD
72
41
8 bytes, fixed
ANS
82
42
15 bytes, fixed
ANS
83
49
60
Private Use Data
2 bytes, fixed
31 bytes, LLLVAR
BCD
105
ANS
BCD / H*
108
H*
116
118
62
Private Use Data
8 bytes, LLLVAR
ANS
BCD /
63
Private Use Data
42 bytes, LLLVAR
ANS
BCD / H*
October 22, 2010
POS020055
143
7.2.14
0510 Reconciliation Response

Data Field Name
Field Length
Data
Type
Field Format
0510 - Close
ISO 8583 Bit Number
Notes:
Page
2 bytes, fixed
BCD
56
Bit Map - Primary
8 bytes, 64 bits
57
Processing Code
3 bytes, fixed
BCD
61
11
3 bytes, fixed
BCD
65
12
3 bytes, fixed
BCD
66
13
2 bytes, fixed
BCD
67
24
2 bytes, fixed
BCD
72
37
12 bytes, fixed
AN
78
39
Response Code
2 bytes, fixed
AN
81
41
8 bytes, fixed
ANS
82
H*
44
26 bytes, LLVAR
AN
BCD /
63
Private Use Data
42 bytes, LLLVAR
ANS
BCD / H*
86
118
144
POS020055
October 22, 2010
8.0
Edit Tests on Data Input
Information entered at, or generated by, a PIP terminal is subject to edit tests. These tests are used to
measure the validity of the data swiped, and/or entered, at the terminal.
Both the terminal and Capture Host are responsible for testing transaction information. This section
describes the following tests:
8.1
Cardmember Account Number Check Digit Computation*
8.2
Expiration Date Edit Test
8.3
Transaction Amount Edit Test
8.4
ROC Number Edit Test
8.5
SOC Number Edit Test
8.6
Batch Number Edit Test
8.7
Total Amount Edit Test
8.8
Business Date Edit Test
8.9
Tip or Tax Information Edit Test
8.10
Track 1 or Track 2 Data
__________________________
* Also known as the Modulus 10 Check.
October 22, 2010
POS020055
145
8.1
Cardmember Account Number Check Digit Computation*
For financial cards accepted by the American Express PIP interface, the last digit to the right in the
Cardmember account number is referred to as the check digit. Based on this check digit, a computation is made using the rest of the numbers, the result of which should equal the check digit. This
computation determines the validity of an account number by calculating the check digit and
comparing it to the given check digit.
The steps to perform the calculation are:
1. Do not include the check digit in the calculation.
2. Starting with the last digit to the right (not including the check digit), and working right to left,
multiply every other digit by two (2).
3. If any product of Step 2 is a two-digit number, add the two digits of the product.
4. Add the products produced in Step 3.
5. Add all the digits not used in Step 2 (excluding the check digit).
6. Add the results of Step 4 and Step 5.
7. If the result of Step 6 is a multiple of ten (10, 20, 30, etc.), the check digit is zero (0). If the result
of Step 6 is not a multiple of ten, subtract that result from the next higher multiple of ten. The
result is the check digit.
If the calculated check digit matches the given check digit, the Cardmembers account number is
valid. If the check digits do not match, the Cardmember number is invalid. If the account number is
invalid when received by the host, the Response Code field in the response message from the host
will contain code 19 (Edit Error).
An example of the Cardmember account number check digit verification process is provided on the
next page.
Also known as the Modulus 10 Check.
146
POS020055
October 22, 2010
8.1
Cardmember Account Number Check Digit Computation (Continued)
Example:
Cardmember #373872186011004
1. Do not include the check

digit (last number to the
right) in the calculation.
The check digit is 4

1
2. Starting with the last digit

to the right, and working
right to left, multiply every
other digit by two.
7
x2
14
8
x2
16
2
x2
4
8
x2
16
0
x2
0
1
x2
2
0
x2
0
3. If any product of Step 2 is

a two-digit number, add
the two digits together.
4. Add the products

produced in Step 3.
5. Add all the digits not used

in Step 2.
6. Add the results of Steps 4

and 5.
25
+ 21
= 46
7. If the result of Step 6 is a

multiple of 10, the check
digit is zero (0). If the
result of Step 6 is not a
multiple of 10, subtract the
result from the next higher
multiple of 10. The new
result is the calculated
check digit.
50
46
If the calculated check

digit matches the given
check digit, the Cardmember account number
is valid.
= 25
= 21
Given check digit is 4.

Calculated check digit is 4.
Account Number is valid.
If the check digits do not

match, the Cardmember
number is invalid and must
be flagged as invalid.
October 22, 2010
POS020055
147
8.2
Expiration Date Edit Test
All expiration dates manually entered at the terminal should contain a two-digit numeric month
(01-12), followed by a two-digit numeric year (00-99).
If the entry fails the edit test, the Response Code field in the response message from the Capture Host
will contain code 19 (Edit Error).
A transaction must not be rejected at the terminal, if the expiration date listed is earlier than the
current date.
8.3
Transaction Amount Edit Test
The transaction amount entered at the terminal must be numeric, and the length must be between one
and seven digits, including two decimal places (the decimal point is assumed). For example, if the
transaction amount is $100.64, the field data should read as 0010064.
If the amount fails the edit test, the Response Code field in the response message from the Capture
Host will contain code 19 (Edit Error).
8.4
ROC Number Edit Test
A Record of Charge (ROC) Number is assigned to each transaction by the terminal and is printed on
the ROC, if the terminal has a printer attached.
If American Express pre-printed debit or credit forms are used, the ROC Number is the pre-printed
number found on the ROC form. In this case, the ROC number (from the form) must be manually
entered using the terminal keyboard. This ROC Number must be a six-digit numeric value with
leading zeros (such as 000012), stored in private use field 62.
If the ROC Number fails the edit test, the Response Code field in the response message from the
Capture Host will contain code 96 (Miscellaneous Processing Error).
148
POS020055
October 22, 2010
8.5
SOC Number Edit Test
A Summary of Charges (SOC) Number is required when closing a batch. The SOC Number can be
generated from the terminal, if a printer is attached. Or, the SOC number can be manually entered
from the keyboard, if the Merchant uses pre-printed SOC forms. The SOC Number must be a sixdigit numeric value with leading zeros, stored in private use field 62.
If the SOC Number fails the edit test, the Response Code field in the response message from the
8.6
Batch Number Edit Test
A Batch Number is assigned by the terminal to every batch created in that terminal. The Batch
Number is a six-digit number with leading zeros; however, the number must never be 000000 or
999999.
If the Batch Number fails the edit test, the Response Code field in the response message from the
8.7
Total Amount Edit Test
The two total amounts stored in the terminal (Total Sales/Debits and Total Credits) must be from onedigit to eight-digit numeric values, including two decimal places (the decimal point is assumed). If
the values do not match between the terminal and the Capture Hosts shadow file, the host sends a
Reconciliation Response (0510) Message with Response Code 95 (Bad Reconciliation Send
Detail). Transactions are then uploaded from the terminal to the Capture Host. See Section 4,
Standard Processing Flow Diagram (Capture Host), for details on this process.
8.8
Business Date Edit Test
During a Close Batch procedure, the terminal prompts the Merchant for the business date. This entry
is optional; but if the date is entered, it must follow this format: Four-digits composed of a two-digit
month and two-digit day (MMDD).
If the Business Date fails the edit test, the Response Code field in the response message from the
Capture Host will contain code 19 (Edit Error).
October 22, 2010
POS020055
149
8.9
Tip or Tax Information Edit Test
If a terminal uses the Tip or Tax Information processing feature, the tip or tax entered at the terminal
must be between one and seven-digits in length, numeric, with two decimal places (the decimal point
is assumed).
If the Tip or Tax Information amount fails the edit test, the Response Code field in the response
message from the Capture Host will contain code 19 (Edit Error).
8.10
Track 1 or Track 2 Data
Magnetic stripe data contained on either Track 1 (preferred) or Track 2 must pass parity and LRC tests,
and the account number (PAN) must pass the check digit test described in this section. If any of these
tests fail, the account number and expiration date must be manually entered at the terminal. The terminal
does not perform any edits on magnetic stripe data, other than these three tests.
Track 1 (preferred) and Track 2 formats are provided in the Appendix of this document.
Note: Track 1 is preferred. For more information, see American Express Magnetic Stripe Formats and
Expresspay Pseudo-Magnetic Stripe Formats beginning on pages 152 and 183.
150
POS020055
October 22, 2010
9.0
Appendix
The Appendix contains the following subsections:

9.1
American Express Cards Typical Examples
9.2
American Express Magnetic Stripe Formats
9.3
Expresspay Pseudo-Magnetic Stripe Formats
9.4
Typical Prepaid Card Partial Authorization & Authorization with Balance Return Process
Flows
9.5
Currency Codes
9.6
Street Codes
9.7
ISO Account Number Ranges
9.1
American Express Cards Typical Examples
In each of the following illustrations of American Express Card products, the Card Identifier
(CID/4DBC/4CSC; a.k.a., 4DBC or 4CSC an American Express security feature) is circled. For
details on CID/4DBC/4CSC entry in the Authorization Request (0100) Message, see page 103.
For more information on the American Express Keyed CID/4DBC/4CSC Program, please contact
your American Express representative.
October 22, 2010
POS020055
151
9.2
American Express Magnetic Stripe Formats
Merchants that use the ISO 8583 message format may elect to read American Express magnetic card
stripes. Merchants must design their systems to accept the following card formats, both of which are
used by American Express:
ANSI X4.16 standard
ISO 7813 standard
If Tracks 1 and 2 are both captured, both should be forwarded. If only one track is captured, Track 1 is
preferred (see page 90). For systems that capture only Track 2, this less desirable alternative may be
supplied in lieu of Track 1 (see page 74).
Magnetic stripe data contained on either Track 1 (preferred) or Track 2 must pass parity and LRC
tests prior to the transmitting of this data to American Express. The American Express Cardmember
Account Number must pass the check digit test described on page 146.
Discretionary Data is used by American Express for the effective date, card identifier, and in Track 2,
language code. Unused portions of Discretionary Data are omitted at card creation time in all formats
except ISO 7813, Track 2, where zeros are used.
Notes:
1. Track 1 and Track 2 data formats may vary slightly between various American Express systems.
The field definitions referenced in this section are for reference only and may not reflect all variations that may be encountered. For this reason, when Track 1 and/or Track 2 data is supplied intact,
the acquirer, their devices, systems, software, and terminal and software vendors should capture
all characters between the start and end sentinels, strip off the sentinels and LRC, and forward the
remainder to American Express in the appropriate ISO 8583 Track 1 and/or Track 2 field, without
regard to the specific lengths referenced in this section.
2. If the Merchants system supports capture of both Track 1 and Track 2, both tracks must be forwarded. If only one track is captured, Track 1 is preferred (see page 90). For systems that capture
only Track 2, this less desirable alternative may be supplied in lieu of Track 1 (see page 74). American Express requires all Merchants and service providers as part of their Card Acceptance or servicing agreements to adhere to the American Express Data Security Operating Policy (DSOP). The
policy requires Merchants to comply with the Payment Card Industry Security Standard to process,
store or transmit Cardmember payment information. More information on the American Express
DSOP and the PCI Data Security Standard can be found at www.americanexpress.com/datasecurity.
3. During certification, Merchants must demonstrate the ability to populate and transmit Track 1 Data
and/or Track 2 Data (Fields 45 and 35, respectively) for Card Present transactions when track data
is successfully read from a valid Card swipe. Similarly, terminal and software vendors must demonstrate the ability to populate and transmit Track 1 Data and/or Track 2 Data (Fields 45 and 35,
respectively) for Card Present transactions when track data is successfully read from a valid Card
swipe. After certification, Merchants, and terminal and software vendors, must forward all Point
of Sale-provided track data in the appropriate field(s).
The American Express magnetic stripe formats are provided on the next page.
152
POS020055
October 22, 2010
9.2.1
ANSI X4.16 Standard
Track 1 (Preferred)
Field Name
Track 2
Digit
Start Sentinel
Format Code
Account Number (PAN) *
Field Separator
Cardmember Name
Field Separator
Expiration Date (YYMM)
Effective Date (YYMM)
Discretionary Data
End Sentinel
LRC
Unused
1
1
17
1
26
1
4
4
5
1
1
17
Total
79
9.2.2
Field Name
Digit
Start Sentinel
Account Number (PAN)
Field Separator
Discretionary Data
End Sentinel
LRC
Unused
1
15
1
4
4
5
1
1
8
Total
40
ISO 7813 Standard
Track 1 (Preferred)
Field Name
Track 2
Digit
Start Sentinel
Format Code
Field Separator
Cardmember Name
Field Separator
Interchange Designator
Service Code
Discretionary Data
End Sentinel
LRC
1
1
15
1
26
1
4
1
2
4
21
1
1
Total
79
Field Name
Digit
Start Sentinel
Field Separator
Service Code
Discretionary Data
Language Code
End Sentinel
LRC
1
15
1
4
1
2
4
8
2
1
1
Total
40
Account Number (PAN) numeric format includes spaces in the 17-digit field parameter.
Longitudinal Redundancy Check; may or may not be present in ANSI X4.16 format.
Longitudinal Redundancy Check.
October 22, 2010
POS020055
153
9.2.3
New Definitions and Values
The Interchange Designator indicates whether the American Express Card can be used outside the
country of issue.
1
= Available for international interchange.
= Chip card
= Available for interchange only in country of issue.
= Not available for general interchange.
= System test card.
The Service Code indicates whether the Card can be used for ATM/Cash Access, or if positive
authorization is required.
01
= No restrictions.
02
= No ATM service.
03
= ATM service only.
10
= No cash advance.
11
= No cash advance or ATM service.
20
= Requires positive authorization by issuer or issuers agent.
The Language Code is used to identify non-Canadian versus Canadian Cardmembers; and if
Canadian, whether English or French language.
00
= Non-Canadian Cardmembers.
01
= Canadian Cardmembers English Language.
02
= Canadian Cardmembers French Language.
154
POS020055
October 22, 2010
9.2.4
ANSI X4.16 / ISO 7813 Track 1 Message Formats
Subfield 1 ANSI X4.16

Subfield 1 ISO 7813
START SENTINEL
START SENTINEL
Length of Field:
1 byte
Field Type:
Special character
Approximate Position:
Position 1 ANSI X4.16

Position 1 ISO 7813
Constant:
Required Field:
Mandatory
Description:
This field identifies the beginning of a stripe.

Notes:
1. The START SENTINEL is not sent in the authorization
request message.
2. The constant literal % appears here for example purposes
only. Other values may appear in actual magnetic stripe data
for American Express Cards.
The diagram below, and those on the following pages, show the approximate position of each field for
ISO 7813 Standard Track 1.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
155
9.2.4
ANSI X4.16 / ISO 7813 Track 1 Message Formats (Cont.)

Subfield 2 ISO 7813
FORMAT CODE
FORMAT CODE
Length of Field:
1 byte
Field Type:
Alpha

Position 2 ISO 7813
Constant:
Required Field:
Mandatory
Description:
This field indicates the use of standard format B;

format A is for proprietary use only.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
156
POS020055
October 22, 2010
9.2.4

Subfield 3 ISO 7813
ACCOUNT NUMBER (PAN)

Length of Field:
17 bytes ANSI X4.16

15 bytes ISO 7813
Field Type:
Numeric
Positions 3-19 ANSI X4.16

Positions 3-17 ISO 7813
Constant:
None
Required Field:
Mandatory
Description:
This field contains the Cardmembers PRIMARY ACCOUNT

NUMBER (PAN).
Note:
(ANSI X4.16, only)
The ACCOUNT NUMBER (PAN) numeric format includes

spaces in the 17-digit field parameter.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
157
9.2.4

Subfield 4 ISO 7813
FIELD SEPARATOR
FIELD SEPARATOR
Length of Field:
1 byte
Field Type:
Special character

Position 18 ISO 7813
Constant:
Required Field:
Mandatory
Description:
This field separates units of information within the track.

Note: The constant literal ^ appears here for example purposes
only. Other special character values may appear in actual magnetic stripe data for American Express Cards. Alpha and numeric
values are not permitted. The Field Separator values in Track 1
must be the same.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
158
POS020055
October 22, 2010
9.2.4

Subfield 5 ISO 7813
CARDMEMBER NAME
CARDMEMBER NAME
Length of Field:
26 bytes
Field Type:
Alphanumeric & special characters

Constant:
None
Required Field:
Mandatory
Description:
This field contains the Cardmembers name, which is encoded in

magnetic stripe data for American Express Cards. The following
characters are used to separate the elements of a Cardmembers
name:
/ (virgule) = surname/first name separator.
(space) = first name/middle name separator, or first

name/middle initial separator (as required). Spaces used to
fill the name field are not to be removed from this field.
. (period) = name/title separator (as required).
Examples:
Surname only: FROST/
Surname, first name: FROST/CHARLES
Surname, first name, middle initial: FROST/CHARLES F
Surname, first initial, middle initial: FROST/C F
Surname, first name, middle name, title:

FROST/CHARLES FRANCIS.JR
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
159
9.2.4

Subfield 6 ISO 7813
FIELD SEPARATOR
FIELD SEPARATOR
Length of Field:
1 byte
Field Type:
Special character

Constant:
Required Field:
Mandatory
Description:

Note: The constant literal ^ appears here for example purposes
only. Other special character values may appear in actual magnetic stripe data for American Express Cards. Alpha and numeric
values are not permitted. The value in this subfield must be the
same as the value in Subfield 4 (Field Separator) in Track 1.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
160
POS020055
October 22, 2010
9.2.4

Subfield 7 ISO 7813
EXPIRATION DATE
EXPIRATION DATE
Length of Field:
4 bytes
Field Type:
Numeric, YYMM

Constant:
None
Required Field:
Mandatory
Description:
This field contains the year and month in which the American
Express Card is no longer valid.
The card expires on the last day of the month.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
161
9.2.4
Special Note for Subfields 8 and 9

Subfields 8 and 9 (ISO 7813) are used in conjunction with each
other. However, only certain combinations are valid for American
Express Card magnetic stripe data. The following values are the
possible combinations of Interchange Designators and Service
Codes that are valid for American Express Card Track data. The
composite descriptions for these values are derived by combining
the definitions of the individual subfields.
101
102
103
106
120
121
122
123
126
201
206
220
221
223
226
501
502
503
506
520
521
522
526
601
606
621
622
626
701
702
703
901
902
903
These three-digit combinations may be used by card issuers to

request specific authorization processing. Currently, American
Express does not expect Merchants to interrogate and act on these
codes at the terminal level. Merchants that wish to participate in
such processing may need to update their terminals and would
require additional certification. For details, contact your American
162
POS020055
October 22, 2010
9.2.4
Subfield 8 ISO 7813
INTERCHANGE DESIGNATOR
Length of Field:
1 byte
Field Type:
Numeric

Note: This field applies only to ISO 7813 Standard Track 1 and
is not applicable to ANSI X4.16.
Constant:
None
Required Field:
Mandatory
Description:
This field indicates whether the American Express Card can be

used outside the country of issue.
1
2
5
6
=
=
=
=
Available for international interchange.

Chip card.
Available for interchange only in country of issue.
Chip card, available for interchange only in country of
issue.
7 = Not available for general interchange.
9 = System test card.
See Special Note for Subfields 8 and 9, on page 162.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
163
9.2.4
Subfield 9 ISO 7813
SERVICE CODE
Length of Field:
2 bytes
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:
This field indicates whether the American Express Card can

be used for ATM/Cash Access, or if positive authorization is
required.
01 = No restrictions.
02
03
06
10
11
20
=
=
=
=
=
=
21
22
23
26
=
=
=
=
No ATM service.
ATM Service only.
No restrictions; prompt for PIN, if PIN pad is present.
No cash advance.
No cash advance or ATM service.
Requires positive authorization by issuer or issuers
agent.
Authorization by issuer only.
Authorization by issuer only; Goods & Services.
Authorization by issuer only; ATM only, PIN required.
Authorization by issuer only; prompt for PIN, if PIN pad
is present.

Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
164
POS020055
October 22, 2010
9.2.4

Subfield 10 ISO 7813
EFFECTIVE DATE
EFFECTIVE DATE
Length of Field:
4 bytes
Field Type:
Numeric, YYMM

Constant:
None
Required Field:
Mandatory
Description:
Express Card becomes valid.
The card becomes valid on the first day of the month.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
165
9.2.4

DISCRETIONARY DATA
DISCRETIONARY DATA
Length of Field:
5 bytes ANSI X4.16

21 bytes ISO 7813
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:
This field contains American Express discretionary data.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
166
POS020055
October 22, 2010
9.2.4

END SENTINEL
END SENTINEL
Length of Field:
1 byte
Field Type:
Special character

Constant:
Required Field:
Mandatory
Description:
This field identifies the end of the stripe.

Notes:
1. The END SENTINEL is not sent in the authorization request
message.
2. The constant literal ? appears here for example purposes
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
October 22, 2010
POS020055
167
9.2.4

LONGITUDINAL REDUNDANCY CHECK (LRC)

Length of Field:
1 byte
Field Type:
Binary

Constant:
None
Required Field:
Mandatory
Description:
This unique character appears in each stripe and immediately

follows the end sentinel, when the card is read from the start
sentinel.
This field is used as an error-checking device and will vary for
each card.
Notes:
1. LRC is not sent in an authorization request message.
2. LRC may or may not be present in ANSI X4.16 format.
Message:
Position:
%
1
B
2
3
3
7
4
1
5
4
6
4
7
9
8
6
9
3
10
5
11
3
12
1
13
1
14
0
15
0
16
4
17
^
18
F
19
R
20
Message:
Position:
O
21
S
22
T
23
/
24
C
25
H
26
A
27
R
28
L
29
E
30
S
31
32
F
33
.
34
J
35
R
36
37
38
39
40
Message:
Position:
41
42
43
44
^
45
9
46
4
47
0
48
3
49
1
50
0
51
1
52
9
53
1
54
0
55
1
56
1
57
2
58
3
59
4
60
Message:
Position:
5
61
6
62
7
63
8
64
9
65
0
66
1
67
2
68
3
69
4
70
5
71
6
72
7
73
8
74
9
75
0
76
1
77
?
78
79
168
POS020055
October 22, 2010
9.2.4
UNUSED
Length of Field:
17 bytes ANSI X4.16
Field Type:
Binary

Note: This field applies only to ANSI X4.16 Standard Track 1
and is not applicable to ISO 7813.
Constant:
None
Required Field:
No
Description:
Reserved for future use.
October 22, 2010
POS020055
169
9.2.5
ANSI X4.16 / ISO 7813 Track 2 Message Formats

Subfield 1 ISO 7813
START SENTINEL
START SENTINEL
Length of Field:
1 byte
Field Type:
Special character

Position 1 ISO 7813
Constant:
Required Field:
Mandatory
Description:
This field identifies the beginning of a stripe.

Notes:
1. The START SENTINEL is not sent in the authorization
request message.
2. The constant literal ; appears here for example purposes
The diagram below, and those on the following pages, show the approximate position of each field for
ISO 7813 Track 2.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
170
POS020055
October 22, 2010
9.2.5

Subfield 2 ISO 7813

Length of Field:
15 bytes
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:
This field contains the Cardmembers PRIMARY ACCOUNT

NUMBER (PAN).
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
October 22, 2010
POS020055
171
9.2.5

Subfield 3 ISO 7813
FIELD SEPARATOR
FIELD SEPARATOR
Length of Field:
1 byte
Field Type:
Alpha or special character

Constant:
Required Field:
Mandatory
Description:

Note: The constant literal = appears here for example purposes
only. Other alpha or special character values may appear in
actual magnetic stripe data for American Express Cards.
Numeric values are not permitted.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
172
POS020055
October 22, 2010
9.2.5

Subfield 4 ISO 7813
EXPIRATION DATE
EXPIRATION DATE
Length of Field:
4 bytes
Field Type:
Numeric, YYMM

Constant:
None
Required Field:
Mandatory
Description:
Express Card is no longer valid.
The card expires on the last day of the month.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
October 22, 2010
POS020055
173
9.2.5
Special Note for Subfields 5 and 6

Subfields 5 and 6 (ISO 7813) are used in conjunction with each
other. However, only certain combinations are valid for American
Express Card magnetic stripe data. The following values are the
possible combinations of Interchange Designators and Service
Codes that are valid for American Express Card Track data. The
composite descriptions for these values are derived by combining
the definitions of the individual subfields.
101
102
103
106
120
121
122
123
126
201
206
220
221
223
226
501
502
503
506
520
521
522
526
601
606
621
622
626
701
702
703
901
902
903
These three-digit combinations may be used by card issuers to

request specific authorization processing. Currently, American
Express does not expect Merchants to interrogate and act on these
codes at the terminal level. Merchants that wish to participate in
such processing may need to update their terminals and would
require additional certification. For details, contact your American
174
POS020055
October 22, 2010
9.2.5
Subfield 5 ISO 7813
INTERCHANGE DESIGNATOR
Length of Field:
1 byte
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:

used outside the country of issue.
1
2
5
6
=
=
=
=
Available for international interchange.

Chip card.
Available for interchange only in country of issue.
Chip card, available for interchange only in country of
issue.
7 = Not available for general interchange.
9 = System test card.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
October 22, 2010
POS020055
175
9.2.5
Subfield 6 ISO 7813
SERVICE CODE
Length of Field:
2 bytes
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:

used for ATM/Cash Access, or if positive authorization is
required.
01
02
03
06
10
11
20
=
=
=
=
=
=
=
21
22
23
26
=
=
=
=
No restrictions.
No ATM service.
ATM Service only.
No restrictions; prompt for PIN, if PIN pad is present.
No cash advance.
No cash advance or ATM service.
Requires positive authorization by issuer or issuers
agent.
Authorization by issuer only.
Authorization by issuer only; Goods & Services.
Authorization by issuer only; ATM only, PIN required.
Authorization by issuer only; prompt for PIN, if PIN pad
is present.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
176
POS020055
October 22, 2010
9.2.5

Subfield 7 ISO 7813
EFFECTIVE DATE
EFFECTIVE DATE
Length of Field:
4 bytes
Field Type:
Numeric, YYMM

Constant:
None
Required Field:
Mandatory
Description:
Express Card becomes valid.
The card becomes valid on the first day of the month.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
October 22, 2010
POS020055
177
9.2.5

Subfield 8 ISO 7813
DISCRETIONARY DATA
DISCRETIONARY DATA
Length of Field:
5 bytes ANSI X4.16

8 bytes ISO 7813
Field Type:
Numeric

Constant:
None
Required Field:
Mandatory
Description:
This field contains American Express discretionary data.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
178
POS020055
October 22, 2010
9.2.5
Subfield 9 ISO 7813
LANGUAGE CODE
Length of Field:
2 bytes
Field Type:
Numeric

Note: This field applies only to ISO 7813 Standard Track 2
and is not applicable to ANSI X4.16
Constant:
None
Required Field:
Mandatory
Description:
This field identifies non-Canadian versus Canadian

Cardmembers; and if Canadian, whether English or French
language.
00 = Non-Canadian Cardmembers.
01 = Canadian Cardmembers English Language.
02 = Canadian Cardmembers French Language.
Note: Other format options exist for specific American
Express Card-issuing partners. Ask your American Express
representative for more details, if applicable.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
October 22, 2010
POS020055
179
9.2.5

END SENTINEL
END SENTINEL
Length of Field:
1 byte
Field Type:
Special character

Constant:
Required Field:
Mandatory
Description:
This field identifies the end of the stripe.

Notes:
1. The END SENTINEL is not sent in the authorization request
message.
2. The constant literal ? appears here for example purposes
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
0
19 20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39 40
180
POS020055
October 22, 2010
9.2.5


Length of Field:
1 byte
Field Type:
Binary

Constant:
None
Required Field:
Mandatory
Description:
This unique character appears in each stripe and immediately

follows the end sentinel, when the card is read from the start
sentinel.
This field is used as an error-checking device and will vary for
each card.
Notes:
1. LRC is not sent in an authorization request message.
2. LRC may or may not be present in ANSI X4.16 format.
Message:
Position:
;
1
3
2
7
3
1
4
4
5
4
6
9
7
6
8
3
9
5
10
3
11
1
12
1
13
0
14
0
15
4
16
=
17
9
18
4
19
0
20
Message:
Position:
3
21
1
22
0
23
1
24
9
25
1
26
0
27
1
28
1
29
2
30
3
31
4
32
5
33
6
34
7
35
8
36
0
37
0
38
?
39
40
October 22, 2010
POS020055
181
9.2.5
UNUSED
Length of Field:
8 bytes ANSI X4.16
Field Type:
Binary

Note: This field applies only to ANSI X4.16 Standard Track 2
and is not applicable to ISO 7813.
Constant:
None
Required Field:
No
Description:
Reserved for future use.
182
POS020055
October 22, 2010
9.3
Expresspay Pseudo-Magnetic Stripe Formats
In an Expresspay magstripe transaction, chip card data is transmitted in Track 1 (Field 45) and/or
Track 2 (Field 35). The Merchants POS device must format the chip-card payment data into pseudomagnetic stripe Track 1 and/or Track 2 data, which is then used to populate Fields 45 and/or 35, respectively, in the authorization request (0100) message. For more information, see pages 90 and 74.
The following data elements are generated by the POS device (using the chip on the Expresspay Card
product) and utilized to construct the pseudo Track 1 and Track 2 formats shown on the next page.
Account Number The Application PAN retrieved from the Expresspay Card product in the
Read Application Data phase is in EMV-compressed-numeric format, which is converted to the
appropriate character format for inclusion in Track 1 (Field 45) and/or Track 2 (Field 35).
Cardmember Name The Cardmember Name retrieved from the Expresspay Card product in
the Read Application Data phase is a variable-length alphanumeric value up to 26 bytes long. The
Cardmember Name entry that appears in pseudo Track 1 is formed from the chip card Cardmember
Name data element, as follows:
If Cardmember Name is longer than 21 bytes, it is truncated to 21 bytes.
If Cardmember Name is less than 21 bytes long, it is left justified and character space filled to
21 bytes.
Note: The Cardmember Name retrieved from the Expresspay Card product may contain a generic
name that is common for all cards.
ATC The Application Transaction Counter (ATC) retrieved from the Expresspay Card product
is a two-byte hex value converted to a decimal value and padded with leading zeros, prior to populating Track 1 (Field 45) and/or Track 2 (Field 35). The last five digits are placed in the applicable
field of the track data.
Expiration Date The Application Expiration Date retrieved from the Expresspay Card product
is in format YYMMDD. The DD is dropped prior to populating the relevant field of track data.
Application Cryptogram The 5CSC data field in the track data is used to convey a portion of
the cryptogram returned from the Expresspay Card product in response to the GENERATE AC
command.
The cryptogram is an eight-byte hex value that is modified prior to populating this field. First, the
five most-significant bytes are discarded. Then, the three remaining least-significant bytes are
converted to a decimal value, which is then used in this field.
For example, for cryptogram 12 35 69 AB CD 11 29 87, the five most-significant bytes are
discarded, leaving 11 29 87, which is then converted to the decimal value 1124743. If the
resultant value is less than five digits long, it is padded with leading zeros to five digits. However,
this example is seven digits long, so the first two digits are discarded, leaving the five-digit value
24743, which is then placed in this field of the track data.
Service Code This data field is extracted from the Track 2 Equivalent Data retrieved from the
Expresspay Card product in the Read Application Data phase.
October 22, 2010
POS020055
183
9.3.1
Expresspay Pseudo Track 1 & Track 2 Subfields
Track 1 (Preferred)
Field Name
Track 2
Digit
Start Sentinel
Format Code
Field Separator
Cardmember Name
ATC
Field Separator
Service Code
Unpredictable Number
Cryptogram
End Sentinel
1
1
15
1
21
5
1
4
1
2
4
5
1
Total
62
184
Field Name
POS020055
Digit
Start Sentinel
Field Separator
Service Code
Unpredictable Number
Cryptogram
ATC
End Sentinel
1
15
1
4
1
2
4
5
5
1
Total
39
October 22, 2010
9.4
Typical Prepaid Card Partial Authorization & Authorization with

Balance Return Process Flows
The table below shows additional data that Partial Authorization- and Partial Authorization with
Balance Return-certified Merchants must include in all 0100 and 0200 authorization messages:
Certification
Message Type
Both Partial Auth,

and Authorization
with Balance Return
All 0100 & 0200

auth requests
Partial Auth only
All 0100 & 0200

auth requests
Authorization with
Balance Return only
All 0100 & 0200

auth requests
Field
Value
Description of Use
Full transaction amount

requested for auth
Full transaction amount requested for

authorization
47 - Additional Data National
181
Merchant system supports optional

Partial Auth response data
182
Merchant system supports optional

Authorization with Balance Return
response data
4 - Amount, Transaction
The table below shows optional additional data that Partial Authorization- and Partial Authorization
with Balance Return-certified Merchants may receive in some 0110 and 0210 response messages:
Certification
Message Type
Field
Value
Partial Auth only
Some 0110 &

0210 responses
Partial Auth only
Some 0110 &

0210 responses
39 - Response Code
004 = Partial Auth
Indicates response is a Partial Auth
Partial Auth only
Some 0110 &

0210 responses
Full transaction amount

originally requested
Only present for Partial Auth

(Field 39 = 06)
Partial Auth only
Some 0110 &

0210 responses
54 - Amounts, Additional
Balance remaining on
Prepaid Card product
Present if Merchant system supports

Partial Auth and Prepaid Card
Primary Account Number is valid
Authorization with
Balance Return only
All 0110 & 0210

responses
Original amount, echo

returned
Same value as Field 4 in original

auth request
Authorization with
Balance Return only
All 0110 & 0210

responses
39 - Response Code
Routine values for

No special Response Codes are
approve, deny, refer, etc. used for Authorizations with Balance
Return.
Authorization with
Balance Return only
Some 0110 &

0210 responses
54 - Amounts, Additional
Balance remaining on
Prepaid Card product
Description of Use
Actual amount authorized Only present for Partial Auth

(not original amount)
(Field 39 = 06)
Present if Merchant system supports

Authorizations with Balance Return
and Prepaid Card Primary Account
Number is valid
The premises and scenarios on the following pages further clarify how support for either Partial
Authorization or Authorization with Balance Return affects the Merchants message content for all
American Express products.
October 22, 2010
POS020055
185
9.4.1
Partial Authorization Scenarios
The scenarios below are based on various premises for Prepaid Card versus other American Express
Card products. All assume that a Merchant and POS do nothing to distinguish between these two
product categories.
9.4.1.1
Partial Authorization Scenario #1
Premise: A customer has an American Express Prepaid Card, which has a remaining balance of
$25.00; and the Merchant tries to authorize a $40.00 charge. American Express returns a partial
authorization for the balance remaining on the Card, which is $25.00.
The Merchant builds the 0100 or 0200 request message with Field 47 set to 181, which indicates
support for Partial Authorizations.
The transaction is processed by American Express, and the 0110 or 0210 response contains the
following data:
Field 4, Amount, Transaction is modified to contain the actual amount authorized, which is
$25.00.
Field 39, Response Code contains code 06, which indicates that this response is a partial
authorization.
Note: This code is only returned for Prepaid Card products when the authorization is for a
partial amount.
186
Field 47, Additional Data - National now contains the full transaction amount originally
requested in Field 4 of the request message, which is $40.00.
Field 54, Amounts, Additional contains the balance remaining on the Prepaid Card product
after this authorization, which is $0.00.
POS020055
October 22, 2010
9.4.1.2
Premise: The Merchant tries to authorize a $10.00 charge; and American Express returns an authorization for the requested $10.00 and the remaining balance, which is $15.00.
following data:
Field 4, Amount, Transaction is echo returned and contains the original amount, which is
$10.00 (a BAU response).
Field 39, Response Code contains code 00, which indicates full approval (a BAU
response).
Note: Field 47 is not returned, because the full amount was approved.
9.4.1.3
Premise: The Merchant tries to authorize a $25.00 charge, which is the exact balance remaining on
the Prepaid Card product; and American Express returns an authorization for the requested $25.00
and the remaining balance, which is $0.00.
following data:
Field 39, Response Code contains code 00, which indicates full approval (a BAU
response).
Note: Field 47 is not returned, because the full amount was approved.
October 22, 2010
POS020055
187
9.4.1.4
Premise: A customer has an American Express Prepaid Card, that is denied for any reason, other than
insufficient funds. For instance, the Card may be canceled; or the Merchant may not be authorized
to accept the Card product (e.g., a Be My Guest Card, which is valid only at restaurants, would be
declined if presented for payment at a retail establishment).
The Merchant tries to authorize a $50.00 charge; and American Express returns a Credit Denied
message, which does not include the Card balance. (American Express does not return balance
information if a Card is denied for any reason, other than insufficient funds.) Please note that while
this scenario is similar to a decline or referral for a proprietary Card (see Scenario #7 on page 190),
there is no significance to the presence or absence of Field 54 on Credit Denied or referred transactions.
following data:
Field 39, Response Code contains code 51, which indicates Credit Denied (a BAU response).
Note: Fields 47 and 54 are not returned, because the request was declined.
188
POS020055
October 22, 2010
9.4.1.5
Premise: A customer has an American Express Prepaid Card, which has no remaining balance; and
the Merchant tries to authorize a $50.00 charge. American Express returns a decline message, which
includes the Card balance.
following data:
Field 39, Response Code contains code 51, which indicates Credit Denied (a BAU
response).
Field 54, Amounts, Additional contains the balance remaining on the Prepaid Card product,
which is $0.00.
Note: Field 47 is not returned, because the request was declined.
9.4.1.6
Premise: A customer has an American Express proprietary or GNS Card, and the Merchant tries to
authorize a $100.00 charge. American Express returns an approval for the full transaction amount.
following data:
Field 39, Response Code = 00, indicating full authorization (a BAU response).
Field 4, Amount, Transaction The original amount, $100.00, is echo returned (a BAU
response).
Note: Fields 47 and 54 are not returned for American Express proprietary or GNS Cards.
October 22, 2010
POS020055
189
9.4.1.7
Premise: A customer has an American Express Proprietary or GNS Card, and the Merchant tries
to authorize a $50.00 charge. The system will respond with either a Credit Denied or Referral, for
whatever reason, as a BAU condition. No balance information is returned.
following data:
Field 39, Response Code Depending upon the Merchant, this value may be 51 indicating Credit Denied, or 01 indicating Referral (a BAU response).
response).
Note: Fields 47 and 54 are not returned for American Express proprietary or GNS cards.
9.4.1.8
Premise: A customer has an American Express Prepaid Card and wants to know how much is still
available on the card. The merchant will need to do a Balance Inquiry. (Card Balance is $28.00)
The Merchant builds the 0100 or 0200 request message with Field 3 set to 31 40 0X which is the
processing code for a Balance Inquiry, Field 4 set to $0.00 dollar amount, and Field 47 set to
181, which indicates support for Partial Authorizations.
following data:
190
Field 39, Response Code 00 indicating Accepted.
Field 54, Amounts, Additional This field contains the balance remaining on the Prepaid
Card product, which is $28.00
POS020055
October 22, 2010
9.4.2
Authorization with Balance Return Scenarios
There are several scenarios described below based upon several premises for prepaid vs. other
American Express Cards.
9.4.2.1
Authorization with Balance Return Scenario #1
Premise: A customer has an American Express Prepaid Card, which has a balance of $25.00 remaining for purchases; and the Merchant tries to authorize a $25.00 charge. The system will respond with
a full authorization as indicated plus the remaining balance on the card after this transaction, in this
case $0.00.
support for Authorization with Balance Return.
following data:
Field 4, Amount, Transaction The original amount, 25.00, is echo returned (a BAU
response).
Field 54, Amounts, Additional This field contains the balance remaining on the card after
this authorization, in this case $0.00.
Note: Under Authorization with Balance Return, Field 47 is not used.
October 22, 2010
POS020055
191
9.4.2.2
Premise: The Merchant tries to authorize a $10.00 charge. The system will respond with a full
authorization on the requested $10.00 and return the remaining balance, in this case $15.00.
following data:
Field 39, Response Code = 00, indicating full approval (a BAU response).
response).
Field 54, Amounts, Additional This field contains the remaining balance on the card after
this authorization, in this case $15.00
Note: Under Balance Return, Field 47 is not used.
9.4.2.3
Premise: A customer has an American Express Prepaid Card which is being denied for any reason
other than insufficient funds. There are many reasons why a Prepaid Card could be denied. For
example, the card may have been cancelled for any reason, or the Merchant may not be authorized to
accept this product (e.g., the Be My Guest Card can only be used at restaurants, and it would be
declined if used at a retailer).
The Merchant tries to authorize a $50.00 charge. The system will respond with a Credit Denied;
because American Express returns no balance when a transaction is declined for any reason other than
insufficient funds, and this response looks just like a decline/referral for a proprietary Card. The
Merchant should not read anything into the presence or absence of Field 54 on Credit Denied transactions.
support for Authorization with Balance return.
following data:
Field 39, Response Code = 51, indicating Credit Denied (a BAU response).
response).
Note: Under Balance Return, Field 47 is not used; and American Express does not return
Field 54 when a card is declined for any reason other than insufficient funds.
192
POS020055
October 22, 2010
9.4.2.4
Premise: A customer has an American Express Prepaid Card, which has no remaining balance or has
insufficient balance to fully authorize this transaction; and the Merchant tries to authorize a $50.00
charge. The system will respond with a Credit Denied. Balance information is returned.
following data:
response).
Field 54, Amounts, Additional This field contains the balance, which in this case is $0.00,
because no funds remain on this card.
9.4.2.5
Premise: The Merchant tries to authorize a $50.00 charge when the Card only has a $20.00 balance.
The system will respond with a Credit Denied. Balance information is returned.
following data:
response).
Field 54, Amounts, Additional This field contains the card balance, which is $20.00.
The Merchant can choose to resubmit the transaction for the available balance, in this case $20.00,
which would be approved. Some client hosts can be programmed to resubmit the transaction
automatically so the clerk does not have to re-swipe the card.
October 22, 2010
POS020055
193
9.4.2.6
Premise: A customer has an American Express Proprietary or GNS Card, and the Merchant tries to
authorize a $100.00 charge. The system will respond with a full authorization
following data:
response).
Note: Fields 47 and 54 are not returned for American Express or GNS Cards.
9.4.2.7
Premise: A customer has an American Express proprietary or GNS card, and the Merchant tries to
authorize a $50.00 charge. The system will respond with either a Credit Denied or Referral. No
balance information is returned. This response looks just like a decline/referral sometimes returned
for a Prepaid Card. The Merchant should not read anything into the presence or absence of Field 54
on Credit Denied/Referred transactions.
following data:
Field 39, Response Code Depending upon the Merchant, this may be 51 indicating
Credit Denied, or 01 indicating Referral (a BAU response).
response).
Note: Fields 47 and 54 are not returned for American Express or GNS Cards.
194
POS020055
October 22, 2010
9.4.2.8
Premise: A customer has an American Express Prepaid Card and wants to know how much is still
available on the card. The merchant will need to do a Balance Inquiry. (Card Balance is $28.00)
The Merchant builds the 0100 or 0200 request message with Field 3 set to 31 40 0X which is the
processing code for a Balance Inquiry, Field 4 set to $0.00 dollar amount, and Field 47 set to
182, which indicates support for Authorization with Balance Return.
following data:
Field 39, Response Code 00 indicating Accepted.
Field 54, Amounts, Additional This field contains the balance remaining on the Prepaid
Card product, which is $28.00
October 22, 2010
POS020055
195
9.5
Currency Codes
The following table lists the Currency Codes used by American Express in Currency Name order.
Currencies from countries with which American Express is prohibited from doing business due to USA
economic sanctions, or which may be subject to other internal American Express restrictions, are
shown in shaded text and should not be used. For more information, please contact your American
9.5.1
Currency Codes Currency Name Order
Notes: 1. Currency of prohibited country Prohibited country currencies are those with which American Express is prohibited from doing business due to
economic sanctions. No currency information is shown for these countries.
2. The American Express designated name, code and/or decimalization for this currency may differ from ISO 4217.
3. Dec column indicates number of implied decimal places.
4. Maximum Value allowed is 000009999999, unless otherwise indicated.
Currency Name
Country or Entity Name
Afghanistan Afghani
Albanian Lek
Algerian Dinar
Angolan Kwanza
Argentine Peso
Armenian Dram
Aruban Guilder
Australian Dollar
Australian Dollar
Australian Dollar
Australian Dollar
Australian Dollar
Australian Dollar
Australian Dollar
Australian Dollar
Azerbaijanian Manat
Bahamian Dollar
Bahraini Dinar
Bangladesh Taka
Barbados Dollar
Belarusian Ruble
Belize Dollar
Bermudian Dollar
Bhutan Ngultrum
Bolivar Fuerte
Bolivian Boliviano
Bosnian Mark
Botswana Pula
Brazilian Real
Brunei Dollar
Cuba
Iran
Myanmar
Sudan
Afghanistan
Albania
Algeria
Angola
Argentina
Armenia
Aruba
Australia
Christmas Island
Cocos (Keeling) Islands
Heard and McDonald Islands
Kiribati
Nauru
Norfolk Island
Tuvalu
Azerbaijan
Bahamas
Bahrain
Bangladesh
Barbados
Belarus
Belize
Bermuda
Bhutan
Venezuela
Bolivia
Bosnia and Herzegovina
Botswana
Brazil
Brunei Darussalam
196
POS020055
Code
Dec
(See Note 3)
Notes
Maximum Value
(See Note 4)
1
1
1
1
971
008
012
973
032
051
533
036
036
036
036
036
036
036
036
944
044
048
050
052
974
084
060
064
937
068
977
072
986
096
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
3
2
2
0
2
2
2
2
2
2
2
2
2
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
October 22, 2010
9.5.1
Currency Name
Code
Bulgarian Lev
Burundi Franc
Cambodian Riel
Canadian Dollar
Cape Verde Escudo
Cayman Islands Dollar
Central French Polynesian Franc
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BCEAO
CFA Franc BEAC
CFA Franc BEAC
CFA Franc BEAC
CFA Franc BEAC
CFA Franc BEAC
CFA Franc BEAC
Chilean Peso
China Yuan Renminbi
Colombian Peso
Comoro Franc
Congolese Franc
Costa Rican Colon
Czech Koruna
Danish Krone
Danish Krone
Danish Krone
Djibouti Franc
Dominican Republic Peso
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
E. Caribbean Dollar
Ecuadorian Sucre
Egyptian Pound
Bulgaria
Burundi
Cambodia
Canada
Cape Verde
Cayman Islands
French Polynesia
New Caledonia
Wallis and Futuna Islands
Benin
Burkina Faso
Cote DIvoire (Ivory Coast)
Guinea-Bissau
Mali
Niger
Senegal
Togo
Cameroon
Central African Republic
Chad
Congo, Republic of the
Equatorial Guinea
Gabon
Chile
China
Colombia
Comoros
Congo, Democratic Republic of
Costa Rica
Czech Republic
Denmark
Faroe Islands
Greenland
Djibouti
Dominican Republic
Anguilla
Antigua and Barbuda
Dominica
Grenada
Montserrat
St. Kitts-Nevis
St. Lucia
St. Vincent and the Grenadines
West Indies
Ecuador
Egypt
975
108
116
124
132
136
953
953
953
952
952
952
952
952
952
952
952
950
950
950
950
950
950
152
156
170
174
976
188
203
208
208
208
262
214
951
951
951
951
951
951
951
951
951
218
818
October 22, 2010
Dec
(See Note 3)
2
0
2
2
2
2
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
0
2
2
0
2
2
2
2
2
2
0
2
2
2
2
2
2
2
2
2
2
2
3
Notes
Maximum Value
(See Note 4)
000999999999
000999999999
000999999999
2
2
2
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
2
2
000999999999
000999999999
POS020055
197
9.5.1
Currency Name
Code
El Salvadorian Colon
Estonia Kroon
Ethiopian Birr
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Euro
Falkland Islands Pound
Fiji Dollar
Gambia Dalasi
Georgia Lari
Ghanaian Cedi
Gibraltar Pound
Guatemalan Quetzal
Guinean Franc
Guyana Dollar
El Salvador
Estonia
Ethiopia
Aland Islands
American Samoa
Andorra
Austria
Belgium
Croatia, Republic of
Cyprus
Ethiopia
Finland
France
French Guiana
French Southern Territories
Germany
Greece
Guadeloupe
Ireland
Italy
Luxembourg
Malta
Martinique
Mayotte
Monaco
Montenegro
Netherlands
Portugal
Reunion
San Marino
Slovakia
Slovenia
Spain
St. Barthelemy
St. Martin
St. Pierre and Miquelon
Vatican City State (Holy See)
Falkland Islands (Malvinas)
Fiji
Gambia
Georgia
Ghana
Gibraltar
Guatemala
Guinea
Guyana
222
233
230
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
978
238
242
270
981
936
292
320
324
328
198
POS020055
Dec
(See Note 3)
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
0
2
Notes
Maximum Value
(See Note 4)
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
October 22, 2010
9.5.1
Currency Name
Code
Haiti Gourde
Honduran Lempira
Hong Kong Dollar
Hungarian Forint
Icelandic Krona
Indian Rupee
Indonesian Rupiah
Iraqi Dinar
Jamaican Dollar
Japanese Yen
Jordanian Dinar
Kazakhstan Tenge
Kenyan Shilling
Kuna
Kuwaiti Dinar
Kyrgyzstan Som
Laotian Kip
Latvian Lats
Lebanese Pound
Lesotho Loti
Liberian Dollar
Libyan Dinar
Lithuanian Litas
Macao Pataca
Macedonia Denar
Malagasy Ariary
Malawi Kwacha
Malaysian Ringgit
Maldive Rufiyaa
Mauritania Ouguiya
Mauritius Rupee
Metical
Mexican Peso
Moldovan Leu
Mongolian Tugrik
Moroccan Dirham
Moroccan Dirham
Namibian Dollar
Nepalese Rupee
Netherlands Antillian Guilder
New Israeli Shekel
New Taiwan Dollar
New Zealand Dollar
New Zealand Dollar
New Zealand Dollar
New Zealand Dollar
Haiti
Honduras
Hong Kong
Hungary
Iceland
India
Indonesia
Iraq
Jamaica
Japan
Jordan
Kazakhstan
Kenya
Kuwait
Kyrgyzstan
Lao Peoples Democratic Republic
Latvia
Lebanon
Lesotho
Liberia
Libyan Arab Jamahiriya
Lithuania
Macau
Macedonia
Madagascar
Malawi
Malaysia
Maldives
Mauritania
Mauritius
Mozambique
Mexico
Moldova, Republic of
Mongolia
Morocco
Western Sahara
Namibia
Nepal
Netherlands Antilles
Israel
Taiwan
Cook Islands
New Zealand
Niue
Pitcairn
332
340
344
348
352
356
360
368
388
392
400
398
404
191
414
417
418
428
422
426
430
434
440
446
807
969
454
458
462
478
480
943
484
498
496
504
504
516
524
532
376
901
554
554
554
554
October 22, 2010
Dec
(See Note 3)
2
2
2
2
2
2
2
3
2
0
3
2
2
2
3
2
2
2
2
2
2
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
Notes
Maximum Value
(See Note 4)
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
POS020055
199
9.5.1
Currency Name
Code
New Zealand Dollar

Nicaraguan Cordoba Oro
Nigeria Naira
North Korean Won
Norwegian Krone
Norwegian Krone
Norwegian Krone
Omani Rial
Pakistan Rupee
Papua New Guinea Kina
Paraguan Guarani
Peruvian Nuevo Sol
Peso Uruguayo
Philippine Peso
Polish Zloty
Pound Sterling
Pound Sterling
Pound Sterling
Pound Sterling
Qatari Rial
Romanian Leu
Russian Federation Ruble
Rwanda Franc
Samoa Tala
Sao Tome and Principe Dobra
Saudi Arabian Riyal
Serbian Dinar
Seychelles Rupee
Sierra Leone Leone
Singapore Dollar
Solomon Islands Dollar
Somali Shilling
South African Rand
South African Rand
South Korean Won
Sri Lanka Rupee
St. Helena Pound
Surinam Dollar
Swaziland Emalengeni
Swedish Krona
Swiss Franc
Swiss Franc
Syrian Pound
Tajik Somoni
Tanzanian Shilling
Thailand Baht
Tokelau
Nicaragua
Nigeria
Korea, Democratic Peoples Republic of
Bouvet Island
Norway
Svalbard and Jan Mayen Islands
Oman
Pakistan
Papua New Guinea
Paraguay
Peru
Uruguay
Philippines
Poland
Guernsey
Isle of Man
Jersey
United Kingdom
Qatar
Romania
Russian Federation
Rwanda
Western Samoa
Sao Tome and Principe
Saudi Arabia
Serbia (see also, Macedonia)
Seychelles
Sierra Leone
Singapore
Solomon Islands
Somalia
Namibia
South Africa
Korea, Republic of
Sri Lanka
St. Helena
Suriname
Swaziland
Sweden
Liechtenstein
Switzerland
Syrian Arab Republic
Tajikistan
Tanzania, United Republic of
Thailand
554
558
566
2
2
2
578
578
578
512
586
598
600
604
858
608
985
826
826
826
826
634
946
643
646
882
678
682
941
690
694
702
090
706
710
710
410
144
654
968
748
752
756
756
760
972
834
764
2
2
2
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
0
2
2
2
2
2
2
2
2
2
2
2
0
2
2
2
2
2
2
2
2
2
2
2
200
POS020055
Dec
(See Note 3)
Notes
Maximum Value
(See Note 4)
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
October 22, 2010
9.5.1
Currency Name
Code
Tongan Paanga
Trinidad and Tobago Dollar
Tunisian Dinar
Turkish Lira
U.A.E. Dirham
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
U.S. Dollar
Uganda Shilling
Ukraine Hryvnia
Uzbekistan Som
Vanuatu Vatu
Vietnamese Dong
Yemeni Rial
Zambia Kwacha
Zimbabwe Dollar
Tonga
Trinidad and Tobago
Tunisia
Turkey
United Arab Emirates
American Samoa
British Indian Ocean Territory
Ecuador
Guam
Haiti
Marshall Islands
Micronesia, Federated States of
Northern Mariana Islands
Palau
Panama
Puerto Rico
Timor-Leste
Turks and Caicos Islands
U.S. Minor Outlying Islands
United States
Virgin Islands, British
Virgin Islands, U.S.
Uganda
Ukraine
Uzbekistan
Vanuatu
Vietnam
Yemen
Zambia
Zimbabwe
776
780
788
949
784
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
840
800
980
860
548
704
886
894
716
October 22, 2010
Dec
(See Note 3)
2
2
3
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
2
Notes
Maximum Value
(See Note 4)
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
000999999999
2
POS020055
201
9.6
Street Codes
These American Express-defined street codes should be used in ISO 8583 address entries.
9.6.1
Street Numbers
Length of Code
Street Code
Definition
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
2 bytes
2 bytes
2 bytes
2 bytes
1
2
3
4
5
6
7
8
9
10
11
12
13
1ST
2ND
3RD
4TH
5TH
6TH
7TH
8TH
9TH
10TH
11TH
12TH
13TH
9.6.2
Spelled Numbers
Length of Code
Street Code
Definition
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
2 bytes
1
2
3
4
5
6
7
8
9
10
FIRST
SECOND
THIRD
FOURTH
FIFTH
SIXTH
SEVENTH
EIGHTH
NINTH
TENTH
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
1 byte
2 bytes
1
2
3
4
5
6
7
8
9
10
ONE
TWO
THREE
FOUR
FIVE
SIX
SEVEN
EIGHT
NINE
TEN
202
POS020055
October 22, 2010
9.6.3
Street Abbreviations
Code
Length
Street
Code
Code
Definition
Code
Length
Street
Code
Code
Definition
1 byte
2 bytes
2 bytes
3 bytes
3 bytes
4 bytes
4 bytes
3 bytes
2 bytes
3 bytes
4 bytes
3 bytes
2 bytes
3 bytes
2 bytes
2 bytes
2 bytes
1 byte
3 bytes
3 bytes
2 bytes
3 bytes
3 bytes
2 bytes
2 bytes
3 bytes
2 bytes
2 bytes
2 bytes
2 bytes
3 bytes
1 byte
1 byte
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
3 bytes
3 bytes
#
AV
AV
BCH
BDG
BLVD
BRCH
BRK
BY
CIR
CNYN
CRK
CT
CTR
CV
DL
DR
E
FLD
FOR
FT
GRV
HBR
HL
HS
HWY
LD
LK
LN
MT
MTN
N
N
NE
NW
PK
PK
PL
PL
POB
POB
APT
AVE
AVENUE
BEACH
BRIDGE
BOULEVARD
BRANCH
BROOK
BAY
CIRCLE
CANYON
CREEK
COURT
CENTER
COVE
DALE
DRIVE
EAST
FIELD
FOREST
FORT
GROVE
HARBOR
HILL
HOUSE
HIGHWAY
LAND
LAKE
LANE
MOUNT
MOUNTAIN
NO
NORTH
NORTHEAST
NORTHWEST
PARK
PEAK
PLACE
PLAIN
_BX
BOX
3 bytes
3 bytes
3 bytes
3 bytes
3 bytes
2 bytes
2 bytes
2 bytes
3 bytes
3 bytes
2 bytes
2 bytes
2 bytes
2 bytes
2 bytes
1 byte
1 byte
2 bytes
3 bytes
2 bytes
2 bytes
2 bytes
3 bytes
3 bytes
1 byte
2 bytes
POB
POB
POB
POB
POB
PT
PT
RD
RDG
RIV
RT
RT
RT
RT
RT
S
S
SE
SQR
ST
ST
SW
VLG
VLY
W
WY
P_O_BOX
PO_BOX
PO_BX
POBOX
POBX
POINT
PORT
ROAD
RIDGE
RIVER
R#
ROUTE
RR
RRT
RURAL ROUTE
SO
SOUTH
SOUTHEAST
SQUARE
STREET
SUITE
SOUTHWEST
VILLAGE
VALLEY
WEST
WAY
October 22, 2010
POS020055
203
9.6.4
International Abbreviations
Change From
ZERO
CERO
NULL
PRIMO
PREMIER
PREMIRE
PRIMER
PRIMER(O)
ERSTER
UNO
UNO
UN
EINS
UM
UMA
SECONDO
DEUXIME
SEGUNDO
ZWEITER
DUE
DOS
DEUX
ZWEI
DOIS
DUAS
TERZO
TROISIME
TERCER(O)
TERCER
DRITTER
TRE
TRES
TROIS
DREI
TRES
QUARTO
QUATRIME
CUARTO
VIERTER
QUATTRO
CUATRO
QUATRE
204
To
0
0
0
1
1
1
1
1
1
1
1
1
1
1
1
2
2
2
2
2
2
2
2
2
2
3
3
3
3
3
3
3
3
3
3
4
4
4
4
4
4
4
Change From
VIER
QUATRO
CUATRO
QUINTO
CINQUIME
QUINTO
FNFTER
CINQUE
CINCO
CINQ
FNF
CINCO
SESTO
SIXIME
SEXTO
SECHSTER
SEI
SEIS
SIX
SECHS
SEIS
SETTIMO
SEPTIME
SPTIMO
SIEBTER
SETTE
SIETE
SEPT
SIEBEN
SETE
OTTAVO
HUITIME
OCTAVO
ACHTER
OTTO
OCHO
HUIT
ACHT
OITO
NONO
NEUVIME
NOVENO
To
4
4
4
5
5
5
5
5
5
5
5
5
6
6
6
6
6
6
6
6
6
7
7
7
7
7
7
7
7
7
8
8
8
8
8
8
8
8
8
9
9
9
Change From
NEUNTER
NOVE
NUEVE
NEUF
NEUN
NOVE
DECIMO
DIXIME
DCIMO
ZEHNTER
DIECI
DIEZ
DIX
ZEHN
ALAM
ALAMEDA
ALLEE
ALMIRANTE
AM
AMTE
AN DEN
AN DER
ANTINGUO
AP
APARTAMENTO
APTO
AUF DEN
AUF DER
AVE
AVENIDA
BARRANCA
BLOCO
BLV
BOSQUE
BOSQUES
BQE
BQUES
BRIG
BRIGADEIRO
BSQUE
CALLE
CALLEJON
To
9
9
9
9
9
9
10
10
10
10
10
10
10
10
AL
AL
A
ALM
A
ALM
AD
AD
ANT
APT
APT
APT
AD
AD
AV
AV
BCA
BL
BLVD
BOSQ
BOSQ
BOSQ
BOSQ
BRI
BRI
BOSQ
C
CJON
Change From
CALZADA
CAMINO
CAP
CAPITAO
CERRADA
CIRCUITO
COR
CORONEL
CZDA
DIAGONAL
DON
DONA
DOUTOR
EDIFICIO
ENGENHEIRO
FILHO
FRANCISCO
FTES
FUENTE
FUENTES
GAL
GENERAL
GENERAL
GUILLERMO
HACIENDA
IN DEN
IN DER
JARDIN
MARECHAL
MONTE
NORTE
NOSSA
NOSSO
NTE
ORIENTE
PARQUE
PIS
PISO
PLAZA
POSTFACH
PRACA
PRAIA
POS020055
To
CALZ
CAM
CP
CP
CDA
CTO
CEL
CEL
CALZ
DIAG
DN
DNA
DR
EDIF
ENG
FIL
FCO
FNTE
FNTE
FNTE
GEN
GRAL
GEN
GMO
HDA
ID
ID
JD
MAL
MTE
N
NSA
NSO
N
OTE
PQE
P
P
PZA
PF
PCA
PRA
Change From
PREFEITO
PRESIDENTE
PRIVADA
PRIVADO
PROF
PROFESSOR
PROLONGACION
PUERTO
RETORNO
RINCON
RODOV
RODOVIA
RUA
SAN
SANTA
SENHOR
SENHORA
SIERRA
STRASSE
SUR
VISC
VISCONDE
VOR DEN
VOR DER
To
PREF
PRES
PRIV
PRIV
PRF
PRF
PROL
PTO
RET
RCON
ROD
ROD
R
SN
STA
SHR
SHRA
SA
STR
S
VIS
VIS
VD
VD
October 22, 2010
9.7
ISO Account Number Ranges
The number ranges below are registered for card issuers as prescribed by the International
Organization for Standardization.
Range
Assigned To
1001 1999
IATA
2001 2999
IATA
300000 305999
Diners Club
340000 349999
American Express
352800 358999
Japan Credit Bureau (JCB)
360000 369999
Diners Club
370000 379999
American Express
380000 389999
Diners Club
390000 392799
Carte Blanche
392900 399999
Carte Blanche
4 Range (partial)
VISA
5 Range (partial)
MasterCard
601100 601199
Discover
For a complete list, see ISO Numeric Register.
October 22, 2010
POS020055
205
206
POS020055
October 22, 2010
10.0
Glossary
Acquirer
See Card Acquirer.
Authorization
A process where a financial transaction is approved or rejected

by the Capture Host for acceptance by the Merchant.
Binary Coded Decimal
See explanation on page 53.
Hexadecimal
See explanation on page 54.
Batch
A file of transactions held by the terminal. Only one batch may

be open in the terminal at any time.
Batch Number
A unique number that identifies a batch to the Capture Host.

The batch number cannot be 000000.
Capture Host
An American Express system that processes financial requests

from certified American Express and non-American Express terminals. The Capture Host stores or captures financial information
and uses that data to reconcile transactions between American
Express and the Merchant. The reconciled information is then
used for financial settlement between the Merchant and American Express, and between American Express and the Cardholder.
Card Acceptor Number
A number assigned by American Express to every Merchant that

accepts American Express Cards. This number is a 15-character
number, and must appear in Field 42 of every message sent to
American Express by the terminal.
Card Acquirer
A financial institution or representative that obtains financial transaction data from Merchants and transmits that data into authorization/settlement systems for processing and reconciliations.
Card Issuer
A financial institution or representative that issues transaction

cards to Cardmembers.
CAS
See Credit Authorization System.
Certification Testing
A testing process to which all non-American Express terminals

must submit, to become certified to use the American Express
PIP Interface.
Certified Terminal
A non-American Express terminal that has been subjected to

certification tests and has been officially approved by American
Express.
October 22, 2010
POS020055
207
10.0
Glossary (Continued)
Check Digit
The right-most digit of cards being subjected to a Modulus 10

test.
Closed Batch
A batch that has been reconciled with American Express. Once

the batch is closed, the terminal must delete the batch from its
memory; and it will no longer have access to the batch.
Credit Authorization System
The system used by American Express for authorizations.
Descriptor Code
A set of two-digit numbers assigned to each terminal, used to

describe the purchases made at that terminal.
File Update
A message that allows transfer of messages between the terminal

and the Capture Host. The file update message is used in cases
where the terminal has lost its transactions, or if the terminal is
not in balance with the Capture Host during a close batch procedure.
GAN
See Global Authorization Network.
Global Authorization Network
A system that stands-in for the Credit Authorization System,

when it is unavailable.
ISO 8583 Standard
A standard for financial transaction message exchange, established by the International Organization for Standardization.
American Express uses the 1987 version of the ISO 8583
standard.
Issuer
See Card Issuer.
Modulus 10 Check
A test used to determine the validity of a card number.
Open Batch
A batch of transactions stored in the terminal that has not been

closed. There can only be one open batch stored in the terminal.
PIP
See Plural Interface Processing.
Plural Interface Processing
A method to allow a terminal or other point-of-sale device to

access one or more card issuers or acquirers to obtain authorizations and financial settlement.
Processing Flow
The order of message exchanges between the terminal and the

Capture Host in a given situation.
208
POS020055
October 22, 2010
10.0
Glossary (Continued)
Reconciliation
A process where the terminal matches up its totals for a specific

batch with the shadow file in the Capture Host. If the totals match,
the batch will be closed. If the totals do not match, the terminal
uploads its transactions to the Capture Host; and another reconciliation is performed.
Record of Charge
A physical record of a debit or credit. A ROC can be printed out

from the terminal (if a ROC printer is attached) and signed by
the Cardholder. Or, it may be a standard, American Express
charge or credit form, manually filled-in by the Merchant and
signed by the Cardholder.
ROC
See Record of Charge.
ROC Number
A number that appears on the ROC when it is printed from the

terminal or that appears at the bottom of an American Express
pre-printed debit or credit form.
Shadow File
A file in the Capture Host that contains all the transactions for
the current open batch stored in a specific terminal. The shadow
file is used or referenced during most activities performed by the
terminal, when accessing the American Express PIP Interface.
SOC
See Summary of Charges.
SOC Number
A number provided by the Merchant to identify the summary of

charges for the batch.
Summary of Charges
A summary of debits and credits for a specific batch, prepared

when closing the batch.
Terminal Help Desk
A department within American Express devoted to the front-line

resolution of terminal problems.
Terminal ID
An eight-character number assigned to every terminal that accesses the American Express PIP Interface. This number must
appear in field 41 of every message sent to American Express by
the terminal.
Trouble List
A list, maintained by the Terminal Service Unit, to report problems that occur at the terminal. While the terminal is on the
trouble list, it will be unable to process transactions that would
use the American Express PIP Interface.
October 22, 2010
POS020055
209
210
POS020055
October 22, 2010
11.0
EBCDIC & ASCII Code Translation Table
11.1
EBCDIC & ASCII Code Translation Table Part A

Instruction
Dec.
Hex
(RR)
Graphics and Controls
7-Track Tape
Card Code
BCDIC (2)
EBCDIC
EBCDIC (1)
ASCII
00
NUL
NUL
12-0-1-8-9
0000 0000
01
SOH
SOH
12-1-9
0000 0001
02
STX
STX
12-2-9
0000 0010
03
ETX
ETX
12-3-9
0000 0011
04
SPM
PF
EOT
12-4-9
0000 0100
05
BALR
HT
ENQ
12-5-9
0000 0101
06
BCTR
LC
ACK
12-6-9
0000 0110
07
BCR
BEL
12-7-9
0000 0111
08
SSK
BS
12-8-9
0000 1000
09
ISK
10
0A
SVC
11
BCDIC
DEL
Binary
HT
12-1-8-9
0000 1001
SMM
LF
12-2-8-9
0000 1010
0B
VT
VT
12-3-8-9
0000 1011
12
0C
FF
FF
12-4-8-9
0000 1100
13
0D
CR
CR
12-5-8-9
0000 1101
14
0E
MVCL
SO
SO
12-6-8-9
0000 1110
15
0F
CLCL
SI
SI
12-7-8-9
0000 1111
16
10
LPR
DLE
DLE
12-11-1-8-9
0001 0000
17
11
LNR
DC1
DC1
11-1-9
0001 0001
18
12
LTR
DC2
DC2
11-2-9
0001 0010
19
13
LCR
TM
DC3
11-3-9
0001 0011
20
14
NR
RES
DC4
11-4-9
0001 0100
21
15
CLR
NL
NAK
11-5-9
0001 0101
22
16
OR
BS
SYN
11-6-9
0001 0110
23
17
XR
IL
ETB
11-7-9
0001 0111
24
18
LR
CAN
CAN
11-8-9
0001 1000
25
19
CR
EM
EM
11-1-8-9
0001 1001
26
1A
AR
CC
SUB
11-2-8-9
0001 1010
27
1B
SR
CU1
ESC
11-3-8-9
0001 1011
28
1C
MR
IFS
FS
11-4-8-9
0001 1100
29
1D
DR
IGS
GS
11-5-8-9
0001 1101
30
1E
ALR
IRS
RS
11-6-8-9
0001 1110
31
1F
SLR
IUS
US
11-7-8-9
0001 1111
32
20
LPDR
DS
SP
11-0-1-8-9
0010 0000
33
21
LNDR
SOS
| !
0-1-9
0010 0001
FS
"
0-2-9
0010 0010
0-3-9
0010 0011
34
22
LTDR
35
23
LCDR
October 22, 2010
POS020055
211
11.1
EBCDIC & ASCII Code Translation Table Part A

Instruction
Dec.
Hex
(RR)

BCDIC
EBCDIC (1)
ASCII
7-Track Tape
Card Code
BCDIC (2)
EBCDIC
Binary
36
24
HDR
BYP
0-4-9
0010 0100
37
25
LRDR
LF
0-5-9
0010 0101
38
26
MXR
ETB
&
0-6-9
0010 0110
39
27
MXDR
ESC
'
0-7-9
0010 0111
40
28
LDR
0-8-9
0010 1000
41
29
CDR
0-1-8-9
0010 1001
42
2A
ADR
SM
0-2-8-9
0010 1010
43
2B
SDR
CU2
0-3-8-9
0010 1011
0-4-8-9
0010 1100
ENQ
0-5-8-9
0010 1101
0010 1110
44
2C
MDR
45
2D
DDR
46
2E
AWR
ACK
0-6-8-9
47
2F
SWR
BEL
0-7-8-9
0010 1111
48
30
LPER
12-11-0-1-8-9
0011 0000
49
31
LNER
1-9
0011 0001
50
32
LTER
2-9
0011 0010
51
33
LCER
3-9
0011 0011
SYN
52
34
HER
PN
4-9
0011 0100
53
35
LRER
RS
5-9
0011 0101
54
36
AXR
UC
6-9
0011 0110
55
37
SXR
EOT
7-9
0011 0111
56
38
LER
8-9
0011 1000
57
39
CER
1-8-9
0011 1001
58
3A
AER
2-8-9
0011 1010
3-8-9
0011 1011
4-8-9
0011 1100
59
3B
SER
60
3C
MER
DC4
<
61
3D
DER
NAK
5-8-9
0011 1101
62
3E
AUR
>
6-8-9
0011 1110
63
3F
SUR
7-8-9
0011 1111
CU3
SUB
Notes (for Part A):

1. Two columns of EBCDIC graphics are shown. The first gives standard bit pattern assignments. The second shows the T-11 and TN
text printing chains (120 graphics).
2. Add C (check bit) for odd or even parity as needed, except as noted.
3. For even parity, use CA.
Two-Character BSC Data Link Controls:
Function
EBCDIC
ASCII
ACK-0
ACK-1
WACK
RVI
DLE,X'70'
DLE,X'61'
DLE,X'68'
DLE,X'7C'
DLE,0
DLE,1
DLE,;
DLE,<
212
POS020055
October 22, 2010
11.2
EBCDIC & ASCII Code Translation Table Part B

Instruction
Dec.
Hex
(RX)

BCDIC
EBCDIC (1)
7-Track Tape
Card Code
ASCII
BCDIC (2)
EBCDIC
(3)
Binary
64
40
STH
no punches
0100 0000
65
41
LA
12-0-1-9
0100 0001
Sp
Sp
66
42
STC
12-0-2-9
0100 0010
67
43
IC
12-0-3-9
0100 0011
68
44
EX
12-0-4-9
0100 0100
69
45
BAL
12-0-5-9
0100 0101
70
46
BCT
12-0-6-9
0100 0110
71
47
BC
12-0-7-9
0100 0111
72
48
LH
12-0-8-9
0100 1000
73
49
CH
12-1-8
0100 1001
74
4A
AH
12-2-8
0100 1010
75
4B
SH
2 1
12-3-8
0100 1011
76
4C
MH
12-4-8
0100 1100
77
4D
12-5-8
0100 1101
78
4E
CVD
79
4F
CVB
80
50
ST
81
51
82
52
83
53
12-11-3-9
0101 0011
84
54
12-11-4-9
0101 0100
85
55
CL
12-11-5-9
0101 0101
86
56
12-11-6-9
0101 0110
<
<
B A 8 4
B A 8 4
<
B A 8 4 2
12-6-8
0100 1110
B A 8 4 2 1
12-7-8
0100 1111
&
&
B A
12
0101 0000
12-11-1-9
0101 0001
12-11-2-9
0101 0010
& +
B A 8
87
57
12-11-7-9
0101 0111
88
58
12-11-8-9
0101 1000
89
59
11-1-8
0101 1001
90
5A
11-2-8
0101 1010
91
5B
92
5C
8 4
93
5D
8 4
94
5E
AL
8 4 2
95
5F
SL
8 4 2 1
96
60
STD
97
61
98
62
99
63
October 22, 2010
2 1
1
11-3-8
0101 1011
11-4-8
0101 1100
11-5-8
0101 1101
11-6-8
0101 1110
11-7-8
0101 1111
11
0110 0000
0-1
0110 0001
11-0-2-9
0110 0010
11-0-3-9
0110 0011
POS020055
213
11.2
EBCDIC & ASCII Code Translation Table Part B

Instruction
(RX)

BCDIC
EBCDIC (1)
Card Code
BCDIC (2)
EBCDIC
Dec.
Hex
100
64
11-0-4-9
0110 0100
101
65
11-0-5-9
0110 0101
102
66
11-0-6-9
0110 0110
103
67
MXD
11-0-7-9
0110 0111
104
68
LD
11-0-8-9
0110 1000
105
69
CD
0-1-8
0110 1001
106
6A
AD
107
6B
SD
A 8
108
6C
MD
A 8 4
6D
DD
% (
109
A 8 4
110
6E
AW
111
6F
SW
112
70
STE
12-11-0
0111 0000
113
71
12-11-0-1-9
0111 0001
114
72
12-11-0-2-9
0111 0010
115
73
12-11-0-3-9
0111 0011
116
74
12-11-0-4-9
0111 0100
117
75
12-11-0-5-9
0111 0101
118
76
12-11-0-6-9
0111 0110
ASCII
7-Track Tape
j
2 1
1
0110 1010
0110 1011
0-4-8
0110 1100
0-5-8
0110 1101
0110 1110
0110 1111
>
>
A 8 4 2
A 8 4 2 1
0-7-8
119
77
78
LE
121
79
CE
122
7A
AE
12-11-0-7-9
0111 0111
12-11-0-8-9
0111 1000
# =
y
A
123
7B
SE
124
7C
ME
@ '
8 4
125
7D
DE
'
'
8 4
126
7E
AU
8 4 2
127
7F
SU
>
"
"
DEL
8 4 2 1
214
12-11
0-3-8
0-6-8
120
Binary
POS020055
2 1
1
1-8
0111 1001
2-8
0111 1010
3-8
0111 1011
4-8
0111 1100
5-8
0111 1101
6-8
0111 1110
7-8
0111 1111
October 22, 2010
11.3
EBCDIC & ASCII Code Translation Table Part C

Instruction
Dec.
Hex
128
80
129
81
and Format
SSM
130
82
LPSW
131
83
Diagnose

BCDIC
EBCDIC (1)
ASCII
-S
-S
7-Track Tape
Card Code
BCDIC (2)
EBCDIC
Binary
12-0-1-8
1000 0000
12-0-1
1000 0001
12-0-2
1000 0010
12-0-3
1000 0011
132
84
WRD
-S1
12-0-4
1000 0100
133
85
RDD
-S1
12-0-5
1000 0101
134
86
BXH
-RS
12-0-6
1000 0110
135
87
BXLE
-RS
12-0-7
1000 0111
1000 1000
136
88
SRL
-RS
12-0-8
137
89
SLL
-RS
12-0-9
1000 1001
138
8A
SRA
-RS
12-0-2-8
1000 1010
139
8B
SLA
-RS
12-0-3-8
1000 1011
140
8C
SRDL
-RS
12-0-4-8
1000 1100
141
8D
SLDL
-RS
12-0-5-8
1000 1101
142
8E
SRDA
-RS
12-0-6-8
1000 1110
143
8F
SLDA
-RS
12-0-7-8
1000 1111
144
90
STM
-RS
12-11-1-8
1001 0000
145
91
TM
-S1
12-11-1
1001 0001
146
92
MVI
-S1
12-11-2
1001 0010
147
93
TS
-S
12-11-3
1001 0011
148
94
NI
-S1
12-11-4
1001 0100
149
95
CLI
-S1
12-11-5
1001 0101
150
96
OI
-S1
12-11-6
1001 0110
151
97
XI
-S1
12-11-7
1001 0111
152
98
LM
-RS
12-11-8
1001 1000
153
99
12-11-9
1001 1001
154
9A
12-11-2-8
1001 1010
155
9B
156
9C
SIO, SIOF -S
157
9D
TIO, CLRIO -S
158
9E
HIO, HDV
-S
159
9F
TCH
-S
160
A0
161
A1
162
A2
163
A3
12-11-3-8
1001 1011
12-11-4-8
1001 1100
12-11-5-8
1001 1101
12-11-6-8
1001 1110
12-11-7-8
1001 1111
11-0-1-8
1010 0000
11-0-1
1010 0001
11-0-2
1010 0010
11-0-3
1010 0011
October 22, 2010
POS020055
215
11.3
EBCDIC & ASCII Code Translation Table Part C

Instruction
and Format

EBCDIC (1)
ASCII
Card Code
BCDIC (2)
EBCDIC
Dec.
Hex
164
A4
11-0-4
1010 0100
165
A5
11-0-5
1010 0101
166
A6
11-0-6
1010 0110
167
A7
11-0-7
1010 0111
168
A8
11-0-8
1010 1000
169
A9
11-0-9
1010 1001
170
AA
11-0-2-8
1010 1010
171
AB
11-0-3-8
1010 1011
172
AC
STNSM
-S1
11-0-4-8
1010 1100
173
AD
STOSM
-S1
11-0-5-8
1010 1101
174
AE
SIGP
-RS
11-0-6-8
1010 1110
175
AF
MC
-S1
11-0-7-8
1010 1111
12-11-0-1-8
1011 0000
12-11-0-1
1011 0001
12-11-0-2
1011 0010
B3
12-11-0-3
1011 0011
180
B4
12-11-0-4
1011 0100
181
B5
12-11-0-5
1011 0101
182
B6
-RS
12-11-0-6
1011 0110
-RS
176
B0
177
B1
LRA
178
B2
See below
179
BCDIC
7-Track Tape
STCTL
-RX
Binary
183
B7
12-11-0-7
1011 0111
184
B8
12-11-0-8
1011 1000
185
B9
12-11-0-9
1011 1001
186
BA
CS
-RS
12-11-0-2-8
1011 1010
187
BB
CDS
-RS
188
BC
189
BD
CLM
-RS
190
BE
STCM
-RS
191
BF
ICM
-RS
LCTL
12-11-0-3-8
1011 1011
12-11-0-4-8
1011 1100
12-11-0-5-8
1011 1101
12-11-0-6-8
1011 1110
12-11-0-7-8
1011 1111
Notes (for Part C):

Op code (S format)
B202 STIDP
B203 STIDC
B204 SCK
B205 STCK
B206 SCKC
216
B207 STCKC
B208 SPT
B209 STPT
B20A SPKA
B20B IPK
B20D PTLB
B210 SPX
B211 STPX
B212 STAP
B213 RRB
POS020055
October 22, 2010
11.4
EBCDIC & ASCII Code Translation Table Part D

Instruction
(SS)

BCDIC
EBCDIC (1)
ASCII
7-Track Tape
Card Code
BCDIC (2)
EBCDIC
Dec.
Hex
192
C0
193
C1
B A
194
C2
B A
195
C3
B A
196
C4
B A
197
C5
B A
198
C6
B A
199
C7
B A
200
C8
B A 8
201
C9
B A 8
202
Binary
12-0
1100 0000
12-1
1100 0001
12-2
1100 0010
2 1
12-3
1100 0011
12-4
1100 0100
12-5
1100 0101
4 2
12-6
1100 0110
4 2 1
12-7
1100 0111
12-8
1100 1000
B A 8
2
1
12-9
1100 1001
CA
12-0-2-8-9
1100 1010
203
CB
12-0-3-8-9
1100 1011
204
CC
12-0-4-8-9
1100 1100
205
CD
12-0-5-8-9
1100 1101
206
CE
12-0-6-8-9
1100 1110
207
CF
12-0-7-8-9
1100 1111
_
t
208
D0
209
D1
MVN
210
D2
MVC
2 1
2
1
11-0
1101 0000
11-1
1101 0001
11-2
1101 0010
211
D3
MVZ
212
D4
NC
213
D5
CLC
214
D6
OC
4 2
215
D7
XC
4 2 1
11-7
1101 0111
216
D8
11-8
1101 1000
217
D9
218
DA
11-3
1101 0011
11-4
1101 0100
11-5
1101 0101
11-6
1101 0110
11-9
1101 1001
12-11-2-8-9
1101 1010
219
DB
12-11-3-8-9
1101 1011
220
DC
TR
12-11-4-8-9
1101 1100
221
DD
TRT
12-11-5-8-9
1101 1101
222
DE
ED
12-11-6-8-9
1101 1110
223
DF
EDMK
224
E0
225
E1
226
227
E2
E3
October 22, 2010
12-11-7-8-9
1101 1111
A 8
0-2-8
1110 0000
11-0-1-9
1110 0001
0-2
1110 0010
2 1
0-3
1110 0011
POS020055
217
11.4
EBCDIC & ASCII Code Translation Table Part D

Instruction
(SS)

BCDIC
EBCDIC (1)
ASCII
7-Track Tape
Card Code
BCDIC (2)
EBCDIC
Dec.
Hex
228
E4
229
E5
230
E6
231
E7
232
E8
A 8
233
E9
A 8
234
235
236
EC
237
ED
238
239
240
F0
SRP
241
F1
MVO
242
F2
PACK
243
F3
UNPK
244
F4
245
F5
246
F6
247
F7
248
F8
ZAP
249
F9
CP
Binary
0-4
1110 0100
0-5
1110 0101
4 2
0-6
1110 0110
4 2 1
0-7
1110 0111
0-8
1110 1000
0-9
1110 1001
EA
11-0-2-8-9
1110 1010
EB
11-0-3-8-9
1110 1011
11-0-4-8-9
1110 1100
11-0-5-8-9
1110 1101
EE
11-0-6-8-9
1110 1110
EF
11-0-7-8-9
1110 1111
1111 0000
1111 0001
1111 0010
2 1
1111 0011
1111 0100
1111 0101
4 2
1111 0110
4 2 1
1111 0111
1111 1000
1111 1001
2
1
250
FA
AP
12-11-0-2-8-9
1111 1010
251
FB
SP
12-11-0-3-8-9
1111 1011
252
FC
MP
12-11-0-4-8-9
1111 1100
253
FD
DP
12-11-0-5-8-9
1111 1101
254
FE
12-11-0-6-8-9
1111 1110
255
FF
12-11-0-7-8-9
1111 1111
Notes (for Part D):

ANSI-Defined Printer Control Characters (A in RECFM field of DCB)
Code
Action before printing record
blank
0
+
1
Space 1 line
Space 2 lines
Space 3 lines
Suppress space
Skip to line 1 on new page
218
POS020055
October 22, 2010

Яяяяяя Amex Pip-Iso Oct2010

Uploaded by

Document Information

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

Яяяяяя Amex Pip-Iso Oct2010

Uploaded by

Copyright:

Available Formats

PLURAL INTERFACE PROCESSING (PIP)

TERMINAL INTERFACE SPECIFICATION

GLOBAL MERCHANT SERVICES

American Express Proprietary & Confidential

PIP Terminal Interface Spec (ISO 8583)

10/22/10 | J. Cheney | R. Wong | See Below

04/23/10 | J. Cheney | R. Wong | See Below

10/26/09 | J. Cheney | R. Wong | See Below

October 22, 2010

PIP Terminal Interface Spec (ISO 8583)

American Express Proprietary & Confidential

10/01/09 | J. Cheney | R. Wong | See Below

06/18/09 | J. Cheney | R. Wong | See Below

October 22, 2010

American Express Proprietary & Confidential

PIP Terminal Interface Spec (ISO 8583)

11/26/07 | J. Cheney | R. Wong | See Below

09/25/07 | J. Cheney | R. Wong | See Below

07/16/07 | J. Cheney | R. Wong | See Below

October 22, 2010

PIP Terminal Interface Spec (ISO 8583)

American Express Proprietary & Confidential

06/28/07 | J. Cheney | R. Wong | See Below

06/15/07 | J. Cheney | R. Wong | See Below

04/23/07 | J. Cheney | R. Wong | See Below

04/05/07 | J. Cheney | R. Wong | See Below

03/28/07 | J. Cheney | R. Wong | See Below

01/31/07 | J. Cheney | R. Wong | See Below

October 22, 2010

American Express Proprietary & Confidential

PIP Terminal Interface Spec (ISO 8583)

11/15/06 | J. Cheney | R. Wong | See Below

08/28/06 | J. Cheney | R. Wong | See Below

08/07/06 | J. Cheney | R. Wong | See Below

05/05/06 | J. Cheney | R. Wong | See Below

October 22, 2010

PIP Terminal Interface Spec (ISO 8583)

American Express Proprietary & Confidential

This page is intentionally left blank.

October 22, 2010

American Express Proprietary & Confidential

PIP Terminal Interface Spec (ISO 8583)

Introduction to Credit Authorization ................................................................................. 1

Shadow File Processing ......................................................................................................... 1

Industry-Specific Special Processing ..................................................................................... 2

Card Acceptance Guidelines .................................................................................................. 3

Partial Authorization .............................................................................................................. 4

Authorization with Balance Return ........................................................................................ 5

Introduction to Plural Interface Processing (PIP) ............................................................ 7

American Express Capture Host ............................................................................................ 8

Express 3000 PIP Interface Messages............................................................................... 11

Overview of ISO 8583 Messages ......................................................................................... 12

Terminal Identification Data Fields ..................................................................................... 14

Authorization Only Messages .............................................................................................. 15

Financial Capture Messages ................................................................................................. 17

File Update Messages .......................................................................................................... 20

Reversal Messages ............................................................................................................... 21

Reconciliation Messages ...................................................................................................... 23

Recommended Time-Out Values ......................................................................................... 24

Web Services IP Payments Gateway, High-Speed Internet Connection .............................. 24

Dial-Up Communications .................................................................................................... 24

Standard Process Flow Diagrams (Capture Host) .......................................................... 25

Authorizations Normal Processing.................................................................................. 26

Authorizations Reversal Processing ................................................................................ 26