Amex WS PIP Terminal Interface Spec ISO Apr2011 PDF

PLURAL INTERFACE PROCESSING (PIP)
TERMINAL INTERFACE SPECIFICATION

(ISO 8583 FORMAT) — APRIL 2011
GLOBAL MERCHANT SERVICES

POS020055, v3.2, April 22, 2011
Copyright © 2006-2011 American Express Travel Related Services Company, Inc. All rights re-
served. 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 me-
chanical 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.2 04/22/11 | J. Cheney | R. Wong | See Below

• Cover: Changed title from “OCTOBER 2010” to “APRIL 2011”.
• Page 63: Changed text, as indicated, “American Express limits the maximum allowable value that can be
approved in this field. While most entries must not exceed “000009999999”, some locations may submit
based on the US Dollar equivalent calculated by American Express. Transmitted transaction amounts in specific
currencies up to “000999999999”. However, please note that a transaction amount greater than the max-
imum allowed will result in an “invalid amount” edit error. For more information on maximum allowable
values, see Currency Codes on page 196.”
• Page 64 & 99: The available balance is returned in response message Field 54 (Amounts, Additional) of the
Authorization Response (0110) message.”
• Page 80: Added Note 1, “All Approval Codes are numeric for American Express Transactions”.
• Pages 196-201: Changed Note 4 text, as indicated, “Maximum Value allowed is the equivalent to either
“000009999999”, unless otherwise indicated.” ($99,999.99 USD) or “000999999999” ($9,999,999.99 USD)”.
Also, updated most Maximum Value entries; and added, deleted or changed the following Currency Codes:
– Changed, as indicated “Estonia Kroon Euro | Estonia | 233 978 | 2”
– Changed, as indicated “Malagasy Ariary | Madagascar | 969 | 2 0”
– Deleted “Netherlands Antillian Guilder | Netherland Antilles | 532 | 2”
– Added “Netherlands Antillian Guilder | Curaçao | 532 | 2”
– Added “Netherlands Antillian Guilder | Sint Maarten | 532 | 2”
– Added “New Manat | Turkmenistan | 934 | 2”
– Added “Panama Balboa | Panama | 590 | 2”
– Added “U.S. Dollar | Bonaire | 840 | 2”
– Added “U.S. Dollar | Saba | 840 | 2”
– Added “U.S. Dollar | St. Eustatius | 840 | 2”
• 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, Card-
member 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.
April 22, 2011 POS020055 i

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.
PIP Terminal Interface Spec (ISO 8583) American Express Proprietary & Confidential
Revision Log
• 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.

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

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

• 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”.
ii POS020055 April 22, 2011

Revision Log

• 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
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 Sam-
ple 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.
April 22, 2011 POS020055 iii

Revision Log

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

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

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

• Page 79: For Authorization Code, changed from “0220=M” to “…=C1” and added Note C1.

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

• Page 15: In note, deleted “Purchasing Card”.
• Pages 118, 123-126: For Lodging & Auto Rental, deleted 0200 & 0220 references to Bit 63 (unused).
iv POS020055 April 22, 2011

Revision Log

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

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

• Page 63: For USD/840 transactions only, changed “000009999999” to “000999999999”. Also, added “For
other currencies, the USD equivalent…must not exceed $99,999.99 USD.”
• 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.

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

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

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

• Initial release. Created by removing XML references from POS020050, v1.0 and adding ISO 8583
information from POS010005, v5.4.
April 22, 2011 POS020055 v

This page is intentionally left blank.
vi POS020055 April 22, 2011

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
April 22, 2011 POS020055 vii

Table of Contents
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
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
viii POS020055 April 22, 2011

Table of Contents
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
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
April 22, 2011 POS020055 ix

Table of Contents
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
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
x POS020055 April 22, 2011

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 re-
quirements 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 speci-
fication, 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 sub-
mitted 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
April 22, 2011 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 April 22, 2011

1.0 Introduction to Credit Authorization
1.1 Overview
The American Express PIP Capture Host is a sophisticated system that provides two methods of proc-
essing. 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 Host’s batch balances with the terminal’s 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 terminal’s 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
April 22, 2011 POS020055 1

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 termi-
nal. 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.
2 POS020055 April 22, 2011

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 infor-
mation, see American Express Magnetic Stripe Formats and Expresspay Pseudo-Magnetic Stripe
Formats beginning on pages 152 and 183.
If the Merchant’s 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.
April 22, 2011 POS020055 3

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).
4 POS020055 April 22, 2011

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 0110 or 0210 response message.
Field 47 (Additional Data - National) of the 0100 or 0200 message is used to identify an Authori-
zation 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. Trans-
actions 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.
April 22, 2011 POS020055 5

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.
6 POS020055 April 22, 2011

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.
April 22, 2011 POS020055 7

2.2 American Express Capture Host
The American Express Capture Host receives and processes message transmitted from the Merchant’s
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 terminal’s batch.
When a terminal’s 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.
8 POS020055 April 22, 2011

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.
April 22, 2011 POS020055 9

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 terminal’s 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
terminal’s display.
If the figures do not agree, the terminal will be placed on the trouble list. On the next attempt to recon-
cile, 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 terminal’s 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 notify-
ing American Express.
2.2.5 Financial Settlement
The Capture Host settles its closed batches with one of the various systems used for financial settle-
ment and payment to Merchants. The closed batches are sent for settlement via a submission file.
10 POS020055 April 22, 2011

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
April 22, 2011 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 configura-
tion 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
Merchant’s 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 = Authorization
2 = Financial Capture
3 = File Update
4 = Reversals
5 = Reconciliation
8 = Maintenance
• Third position / Message Function

0 = Request
1 = Response to a Request
2 = Advice
3 = Response to an Advice
4 = Notification
5-9 = Reserved for ISO use
• Fourth position / Transaction Originator — This digit is always “0” (zero) for American
Express PIP interface requests and responses.
12 POS020055 April 22, 2011

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: 1 2 3 4 5 6 7 8 9 10
This specification contains information on each transaction used by the American Express PIP inter-
face, 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.
April 22, 2011 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 April 22, 2011

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 infor-
mation. 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.
April 22, 2011 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 April 22, 2011

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.
April 22, 2011 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 April 22, 2011

The American Express PIP Interface utilizes four financial capture messages:
• Financial Transaction Request (0200) Message

– Sale
• Financial Transaction Response (0210) Message

– Sale
• Financial Transaction Advice Request (0220) Message

– 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
April 22, 2011 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 terminal’s transactions balance properly with the Merchant/
Service Establishment, but not with the Capture Host’s shadow file.
• Transaction Upload Advice Request (0320) Message (upload batch request, terminal to host)
– 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 April 22, 2011

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 deter-
mining 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 Merchant’s 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.
April 22, 2011 POS020055 21

• Reversal Request (0400)

– Authorization
– Travelers Cheque Approval
– Authorization Void
– Sale
• Reversal Response (0410)

– Authorization
– Sale
– Refund
• Reversal Advice Request (0420)

– Authorization
– Sale
– Refund
• Reversal Advice Response (0430)

– Authorization
– Sale
– Refund
22 POS020055 April 22, 2011

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 terminal’s memory.
• Reconciliation Request (0500)

– Close Batch
• Reconciliation Response (0510)

– Close Batch
April 22, 2011 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 Trans-
action (0210) or Authorization (0110) Response Message
• Reversal messages (0400) transmitted after the successful receipt of a Financial Transaction
(0210) or Authorization (0110) Response Message
• 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
• 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 April 22, 2011

4.0 Standard Process Flow Diagrams (Capture Host)
This section contains diagrams that illustrate typical standard process flows, including normal process-
ing 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.10 Reconciliation Time-Out Processing
4.11 Close Batch — Normal Processing
4.12 Close Batch — Error Processing
April 22, 2011 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)
Reversal Request (0400)

 Reversal Response (0410)
Disconnect
Disconnect
26 POS020055 April 22, 2011

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
April 22, 2011 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 Trans-
action 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 Trans-
action (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 Authorized and Captured at Host
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 Authorized and Captured at Host
 Financial Transaction Response (0210)-2

Disconnect
 Financial Transaction Advice Response (0230)-1
Disconnect
28 POS020055 April 22, 2011

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)
Financial Transaction Request (0200)
Approved Financial Transaction

 Response (0210)
Disconnect
 Advice Response (0230)
Disconnect
Financial Transaction Advice Request (0220) Authorized and Captured at Host

 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.
April 22, 2011 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
Financial Transaction Advice Request (0220)
Time-Out
Disconnect
Disconnect
Disconnect
30 POS020055 April 22, 2011

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 trans-
action, 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 trans-
action 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
April 22, 2011 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 April 22, 2011

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

• Close Batch — Normal Processing
• Close Batch — Error Processing
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 Close Batch — Normal Processing
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 terminal’s 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 terminal’s display.
Terminal Host
Reconciliation Request (0500)

 Reconciliation Response (0510)
Disconnect
April 22, 2011 POS020055 33

4.12 Close Batch — Error Processing
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 trans-
action, 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
Reconciliation Request (0500) 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
Reconciliation Request (0500)
 Reconciliation Response (0510)
Disconnect
34 POS020055 April 22, 2011

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 process-
ing 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
April 22, 2011 POS020055 35

5.1 Authorizations — GAN Normal Processing
The terminal transmits an Authorization Request (0100) Message to the Capture Host, which is tem-
porarily 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
Authorization Request (0100) Capture Host Unavailable
Authorization Response (0110)

 from GAN
Disconnect
36 POS020055 April 22, 2011

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
Reversal Request (0400) Capture Host Unavailable
Terminal stores as Reversal Response (0410)

Reversal Advice Request (0420)  from GAN
Disconnect
 from Capture Host
Disconnect
Reversal Advice Request (0420)
Reversal Advice Response (0430)
Disconnect
April 22, 2011 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 sub-
sequent 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)
Authorization Request (0100) Capture Host Unavailable

 from GAN
Disconnect
38 POS020055 April 22, 2011

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
Financial Transaction Request (0200) Capture Host Unavailable
Stored by terminal as a
Financial Transaction Response (0210)
Financial Transaction Advice Request (0220)  from GAN
Message with GAN Indicator
Disconnect

Disconnect
Disconnect
April 22, 2011 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 ap-
proval. 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)
Financial Transaction Request (0200) Authorized and Captured by Capture Host

Disconnect
Disconnect
40 POS020055 April 22, 2011

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 Authori-
zation (0110) or Financial Transaction (0210) Response Message with Additional Response Data
(Field 44), omitted or containing code “01”.
Terminal Host

Financial Transaction Advice Request (0220)-2 ] Note: See pages 29 and 30 for more information
on Advice Message processing.
Stored by Terminal as Financial Transaction Response (0210)

Financial Transaction Advice Request Message  from GAN
(0220)-3 with GAN Indicator
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.
April 22, 2011 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 trans-
mitted when the Capture Host becomes available. This applies regardless of the order in which other
advice messages may be stored.
Terminal Host
Financial Transaction Advice Request (0220)-1 (See note below)

 Response (0210)
Disconnect
Time-Out
Disconnect
(e.g. card swipe)
Advice messages cannot be processed by GAN. Financial Transaction Response (0210)

Terminal continues to store message (0220)-1  from GAN
until Capture Host is available.
Disconnect
(e.g. card swipe)

Disconnect
Financial Transaction Advice Response (0230)
Disconnect
Note: See pages 29 and 30 for more information on Advice Message processing.
42 POS020055 April 22, 2011

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 trans-
action, 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)

Disconnect

Disconnect
with GAN Indicator
Disconnect
April 22, 2011 POS020055 43

5.7.2 GAN Reversal Processing — Scenario B
Terminal Host

Time-Out
Time-Out
Disconnect
Transaction initiated (card swipe)
Disconnect
Terminal stores as Financial Advice Financial Transaction Response (0210)

Request (0220) with GAN Indicator  from GAN
Disconnect

Disconnect
with GAN Indicator
Disconnect
44 POS020055 April 22, 2011

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 time-
out, 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.
April 22, 2011 POS020055 45

46 POS020055 April 22, 2011

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.
April 22, 2011 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 deter-
mining 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 April 22, 2011

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 Data Element Name Max. Field Length Field Type
— MESSAGE TYPE IDENTIFIER (MTI) 2 bytes, fixed N
— BIT MAP - PRIMARY 8 bytes, 64 bits B (Hexadecimal)
1 BIT MAP – SECONDARY 8 bytes, 64 bits B
2 PRIMARY ACCOUNT NUMBER (PAN) 11 bytes, LLVAR N
3 PROCESSING CODE 3 bytes, fixed N
4 AMOUNT, TRANSACTION 6 bytes, fixed N
5 AMOUNT, SETTLEMENT 12 bytes, fixed N
6 AMOUNT, CARDHOLDER BILLING 12 bytes, fixed N
7 DATE AND TIME, TRANSMISSION 10 bytes, fixed N
8 AMOUNT, CARDHOLDER BILLING FEE 8 bytes, fixed N
9 CONVERSION RATE, SETTLEMENT 8 bytes, fixed N
10 CONVERSION RATE, CARDHOLDER BILLING 8 bytes, fixed N
11 SYSTEMS TRACE AUDIT NUMBER 3 bytes, fixed N
12 TIME, LOCAL TRANSACTION 3 bytes, fixed N
13 DATE, LOCAL TRANSACTION 2 bytes, fixed N
14 DATE, EXPIRATION 2 bytes, fixed N
15 DATE, SETTLEMENT 2 bytes, fixed N
16 DATE, CONVERSION 4 bytes, fixed N
17 DATE, CAPTURE 4 bytes, fixed N
18 MERCHANT TYPE 4 bytes, fixed N
19 COUNTRY CODE, ACQUIRING INSTITUTION 3 bytes, fixed N
20 COUNTRY CODE, PAN EXTENDED 3 bytes, fixed N
21 COUNTRY CODE, FORWARDING INSTITUTION 3 bytes, fixed N
22 POINT OF SERVICE ENTRY MODE 2 bytes, fixed N
23 APPLICATION PAN NUMBER 3 bytes, fixed N
24 NETWORK INTERNATIONAL IDENTIFIER (NII) 2 bytes, fixed N
25 POINT OF SERVICE CONDITION CODE 1 bytes, fixed N
26 POINT OF SERVICE CAPTURE CODE 2 bytes, fixed N
27 AUTHORIZING IDENTIFICATION RESPONSE LENGTH 1 byte, fixed N
28 AMOUNT, TRANSACTION FEE 8 bytes, fixed N
29 AMOUNT, SETTLEMENT FEE 8 bytes, fixed N
30 AMOUNT, TRANSACTION PROCESSING FEE 8 bytes, fixed N
31 AMOUNT, SETTLEMENT PROCESSING FEE 8 bytes, fixed N
32 ACQUIRING INSTITUTION IDENTIFICATION CODE 13 bytes, LLVAR N
33 FORWARDING INSTITUTION IDENTIFICATION CODE 13 bytes, LLVAR N
34 PRIMARY ACCOUNT NUMBER, EXTENDED 30 bytes, LLVAR N
35 TRACK 2 DATA 38 bytes, LLVAR ANS
April 22, 2011 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 Data Element Name Max. Field Length Field Type
36 TRACK 3 DATA 107 bytes, LLLVAR NS
37 RETRIEVAL REFERENCE NUMBER (RRN) 12 bytes, fixed AN
38 AUTHORIZATION IDENTIFICATION RESPONSE 6 bytes, fixed AN
39 RESPONSE CODE 2 bytes, fixed AN
40 SERVICE RESTRICTION CODE 3 bytes, fixed AN
41 CARD ACCEPTOR TERMINAL IDENTIFICATION 8 bytes, fixed ANS
42 CARD ACCEPTOR IDENTIFICATION CODE 15 bytes, fixed ANS
43 CARD ACCEPTOR NAME/LOCATION 40 bytes, fixed ANS
44 ADDITIONAL RESPONSE DATA 26 bytes, LLVAR AN
45 TRACK 1 DATA 77 bytes, LLVAR AN
46 ADDITIONAL DATA - ISO 1002 bytes, LLLVAR AN
47 ADDITIONAL DATA – NATIONAL 1002 bytes, LLLVAR AN
48 ADDITIONAL DATA – PRIVATE 7 bytes, LLLVAR AN
49 CURRENCY CODE, TRANSACTION 2 bytes, fixed N
50 CURRENCY CODE, SETTLEMENT 3 bytes, fixed N
51 CURRENCY CODE, CARDHOLDER BILLING 3 bytes, fixed N
52 PERSONAL IDENTIFICATION NUMBER (PIN) DATA 8 bytes, 64 bits B
53 SECURITY RELATED CONTROL INFORMATION 18 bytes, fixed N
54 AMOUNTS, ADDITIONAL 14 bytes, LLLVAR ANS
55 RESERVED - ISO 1002 bytes, LLLVAR ANS
56 RESERVED - ISO 1002 bytes, LLLVAR ANS
57 RESERVED - NATIONAL 1002 bytes, LLLVAR ANS
58 RESERVED - NATIONAL 1002 bytes, LLLVAR ANS
59 RESERVED FOR NATIONAL USE 1002 bytes, LLLVAR ANS
60 PRIVATE - RESERVED 31 bytes, LLLVAR ANS
64 MESSAGE AUTHENTICATION CODE (MAC) FIELD 8 bytes, 64 bits B
50 POS020055 April 22, 2011

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.
April 22, 2011 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 “L’s” 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 April 22, 2011

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
Merchant’s 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 specifica-
tions 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 charac-
ters 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.
April 22, 2011 POS020055 53

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 April 22, 2011

Data Fields in This Section: Bit Field Name Page

– Message Type Identifier 56
– Bit Map - Primary 57
2 Primary Account Number (PAN) 59
3 Processing Code 61
4 Amount, Transaction 63
11 Systems Trace Audit Number 65
12 Time, Local Transaction 66
13 Date, Local Transaction 67
14 Date, Expiration 68
15 Date, Settlement 69
22 Point of Service Entry Mode 70
24 Network International Identifier (NII) 72
25 Point of Service Condition Code 73
35 Track 2 Data 74
37 Retrieval Reference Number (RRN) 78
38 Authorization Identification Response 79
39 Response Code 81
41 Card Acceptor Terminal Identification 82
42 Card Acceptor Identification Code 83
43 Card Acceptor Name/Location 84
44 Additional Response Data 86
45 Track 1 Data 90
47 Additional Data - National 94
48 Additional Data - Private 103
49 Currency Code, Transaction 105
54 Additional Amounts 106
60 Private Use Data 108
Note: See Data Field/Message Usage Tables beginning on

page 130.
April 22, 2011 POS020055 55

Data Field — None Message Type Identifier
Length of Field: 2 bytes, fixed
Field Type: Numeric
Field Format: Binary coded decimal (BCD)
Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M M
Description: 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 April 22, 2011

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
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M M
Description: 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.
April 22, 2011 POS020055 57

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 0 9 0 17 0 25 1 33 0 41 1 49 1 57 0
2 0 10 0 18 0 26 0 34 0 42 1 50 0 58 0
3 1 11 1 19 0 27 0 35 1 43 0 51 0 59 0
4 1 12 0 20 0 28 0 36 0 44 0 52 0 60 0
5 0 13 0 21 0 29 0 37 0 45 1 53 0 61 0
6 0 14 0 22 1 30 0 38 0 46 0 54 0 62 0
7 0 15 0 23 0 31 0 39 0 47 0 55 0 63 0
8 0 16 0 24 1 32 0 40 0 48 0 56 0 64 0
The following diagram illustrates how to calculate the hexadecimal equivalent of the bit map from the
table shown above:
Position 1-8 Position 17-24 Position 33-40 Position 49-56

0011 = 3 0000 = 0 0010 = 2 1000 = 8
0000 = 0 0101 = 5 0000 = 0 0000 = 0
Position 9-16 Position 25-32 Position 41-48 Position 57-64

0010 = 2 1000 = 8 1100 = C 0000 = 0
0000 = 0 0000 = 0 1000 = 8 0000 = 0
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 April 22, 2011

Data Field 2 Primary Account Number (PAN)
Length of Field: 2 bytes minimum, 11 bytes maximum, (LLVAR)

Variable Length Indicator: 1 byte, right justified, zero filled
Length of Variable Data: 10 bytes maximum
Field Type: Numeric
C1 — C1 — C2 — M —
0400 0410 0420 0430 0500 0510

C1 — C1 — — —
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 require-
ments prohibit the storage of track data within Merchant or processor systems.
Description: This field contains the Primary Account Number (a.k.a., Card-
member 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.
April 22, 2011 POS020055 59

Data Field 2 Primary Account Number (PAN) (Continued)
Sample Data Comments

15 VLI (2 digits)
371449635311004 PAN (15 digits)
1 2 3 4 5 6 7 8 9
15 37 14 49 63 53 11 00 4F
Position Bytes Comments

1 1 2-digit VLI in binary coded decimal (BCD) format.
2-9 8 15-digit PAN padded with trailing “F” or “0” in binary coded
decimal (BCD) format.
60 POS020055 April 22, 2011

Data Field 3 Processing Code
Field Type: Numeric
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M 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 Merchant’s
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 = Card Authorization Request
04 40 0X = American Express Travelers Cheque
20 40 0X = Authorization Void (Reversal)
31 40 0X = American Express Prepaid Card Balance Inquiry *
For MTI = 0200 Transaction Processing Code (Specify flow control “X” value)
00 40 0X = Sale
31 40 0X = American Express Prepaid Card Balance Inquiry*
22 40 0X = Credit Adjustment / Void
02 40 0X = Debit Adjustment / Void
00 40 0X = Off-Line Sale
20 40 0X = Off-Line Refund
00 40 0X = 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.
April 22, 2011 POS020055 61

Data Field 3 Processing Code (Continued)
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.
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 = No more messages to send
1 = More messages to follow, hold line (host-to-terminal)
2 = Parameter update pending (host-to-terminal)
3 = 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 April 22, 2011

Data Field 4 Amount, Transaction
Length of Field: 6 bytes, fixed (see USD transaction limit, below)
Field Type: Numeric, right justified, zero filled
M M M M M M M —
0400 0410 0420 0430 0500 0510

M M M M — —
Description: In the request messages indicated above, this field contains the
total Transaction Amount (including tip and/or tax), in the cur-
rency 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, Trans-

action 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 allowable value in this

field based on the US Dollar equivalent calculated by American
Express. Transmitted transaction amounts greater than the maxi-
mum allowed will result in an “invalid amount” edit error. For
more information on maximum allowable values, see Currency
Codes on page 196.
April 22, 2011 POS020055 63

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 Field 54 (Amounts, Addition-
al) of the Authorization Response (0110) message. 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 April 22, 2011

Data Field 11 Systems Trace Audit Number
Field Type: Numeric
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M M
Description: 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 with-
out 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.
April 22, 2011 POS020055 65

Data Field 12 Time, Local Transaction
Field Type: Numeric, hh mm ss
— M — M M O M —
0400 0410 0420 0430 0500 0510

— M — M — M
Description: 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 Hour 2 00-23
mm Minute 2 00-59
ss Second 2 00-59
66 POS020055 April 22, 2011

Data Field 13 Date, Local Transaction
Field Type: Numeric, MM DD
— M — M M O M —
0400 0410 0420 0430 0500 0510

— M — M — M
Description: 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.

MM Month 2 01-12
DD Day 2 01-31
April 22, 2011 POS020055 67

Data Field 14 Date, Expiration
Field Type: Numeric, YY MM
C1 — C1 — C2 — M —
0400 0410 0420 0430 0500 0510

C1 — C1 — — —
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 em-
bossed 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.

YY Year Last 2 only 00-99
MM Month 2 01-12
Note: This field is not required if the message contains either

Track 1 (preferred) or Track 2 data read from the Card’s magnetic
stripe.
68 POS020055 April 22, 2011

Data Field 15 Date, Settlement
Field Type: Numeric, MM DD
— — — — — — — —
0400 0410 0420 0430 0500 0510

— — — — O —
Description: 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.

MM Month 2 01-12
DD Day 2 01-31
Note: If no data is provided, American Express systems substi-

tute the Merchant/processor system capture date for internal
processing.
April 22, 2011 POS020055 69

Data Field 22 Point of Service Entry Mode
Field Type: Numeric
M — M — M — M —
0400 0410 0420 0430 0500 0510

M — M — — —
Description: 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. Posi-

tions 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 Cardmem-
ber’s 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 applica-
ble 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 April 22, 2011

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.
Card Data Input Capability — This subfield indicates the maximum capability of
1&2 the device used to originate this transaction.
Code
00 Unspecified
01 Manual
02 Magnetic stripe
03 Bar code
04 Optical Character Recognition (OCR)
05 Integrated Circuit Card (ICC)
06-60 Reserved
Pos. 3 Cardholder Authentication Capability — This subfield indicates the primary

Code means used to verify the Cardmember’s identity at this terminal.
0 Unspecified
1 PIN entry capability
2 No PIN entry capability
3-9 Reserved
April 22, 2011 POS020055 71

Data Field 24 Network International Identifier (NII)
Field Type: Numeric
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M M
Description: 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 April 22, 2011

Data Field 25 Point of Service Condition Code
Length of Field: 1 byte, fixed
Field Type: Numeric
M — M — M — M —
0400 0410 0420 0430 0500 0510

M — M — — —
Description: 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
April 22, 2011 POS020055 73

Data Field 35 Track 2 Data

Field Type: Alphanumeric (upper case) & special characters
C — C — C — — —
0400 0410 0420 0430 0500 0510

C — C — — —
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 var-
ious American Express systems. The field definitions referenced
in Section 9.2 are for reference only and may not reflect all varia-
tions 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 senti-
nels 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 begin-
ning 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 April 22, 2011

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.

29 VLI (2 digits)
371449635311004D9403910112345 ANSI X4.16 Track 2 Data
(29 digits)
1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 _6
29 37 14 49 63 53 11 00 4D 94 03 91 01 12 34 5F

2-16 15 29 digits of ANSI X4.16 Track 2 Data padded with trailing “F” or
“0” in binary coded decimal (BCD) format.
April 22, 2011 POS020055 75

ISO 7813 Format In the example below, the two-digit VLI is “37”, and the digits
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 ac-
tually transmitted in 19 bytes. The total length (VLI plus variable
data) is 20 bytes.

37 VLI (2 digits)
371449635311004=940310191011234567800 ISO 7813 Track 2 Data
(37 digits)
1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 _6 7 8 9 0
37 37 14 49 63 53 11 00 4= 94 03 10 19 10 11 23 45 67 80 0F

2-20 19 37 digits of ISO 7813 Track 2 Data padded with trailing “F” or
“0” in binary coded decimal (BCD) format.
76 POS020055 April 22, 2011

Expresspay Pseudo-Magnetic In the example below, the two-digit VLI is “37”, and the digits
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.

37 VLI (2 digits)
371449635311004=111270212342474312345 Pseudo-Magnetic Stripe
Track 2 Data (37 digits)
1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 _6 7 8 9 0
37 37 14 49 63 53 11 00 4= 11 12 70 21 23 42 47 43 12 34 5F

2-20 19 37 digits of Pseudo-Magnetic Stripe Track 2 Data padded with
trailing “F” or “0” in binary coded decimal (BCD) format.
April 22, 2011 POS020055 77

Data Field 37 Retrieval Reference Number (RRN)
Field Type: Alphanumeric (upper case)
— M — M C1 C2 M —
0400 0410 0420 0430 0500 0510

— M — M — O
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 2 3 4 5 6 7 8 9 0 1 2
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 April 22, 2011

Data Field 38 Authorization Identification Response
Field Type: Alphanumeric, upper case, left justified, character space filled
— C1 — C1 C2 — C3 —
0400 0410 0420 0430 0500 0510

— — — — — —
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 2 3 4 5 6
31 32 33 34 35 36
See descriptions of Authorization Code and Referral Queue

Number responses on next page.
April 22, 2011 POS020055 79

Data Field 38 Authorization Identification Response (Continued)
For Authorization Code If Response Code = “00” (Approval/Accepted), this field con-
tains 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 Express-
assigned Referral Queue Number that corresponds to the origi-
nating 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
Notes:
1. All approval codes are numeric for American Express trans-
actions.
2. In the examples on this page, “N” is an alphanumeric
character, and the tilde (~) represents a character space.
80 POS020055 April 22, 2011

Data Field 39 Response Code
Field Type: Alphanumeric (upper case)
— M — M — M — M
0400 0410 0420 0430 0500 0510

— M — M — M
Description: 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 2
30 30
00 = Approval/Accepted (See p. 79) 58 = Invalid service

01 = Referral 76 = Bad descriptor code
02 = Please call with referral queue number (See p. 80) 77 = Close batch error
03 = Bad SE (Merchant) Number 78 = Old ROC not found
06 = Partial Approval (Prepaid Cards Only) 79 = Batch already open
12 = Bad processing code 82 = No SOC slots identified
13 = Bad amount 85 = Batch not found
14 = Bad Cardholder account information 91 = System not available
19 = Edit error 94 = Duplicate sequence number
25 = Terminal not identified or inactive 95 = Bad reconciliation – Send detail
30 = Edit error - message format 96 = Misc. processing error
51 = Credit denied AA = Card capture type invalid
April 22, 2011 POS020055 81

Data Field 41 Card Acceptor Terminal Identification
M M M M M M M M
0400 0410 0420 0430 0500 0510

M M M M M M
Description: 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 Mer-
chant location.

eight-byte Card Acceptor Terminal ID “12345678” would be
transmitted as:
1 2 3 4 5 6 7 8
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 April 22, 2011

Data Field 42 Card Acceptor Identification Code
Field Type: Alphanumeric (upper case) & special characters, left justified,
character space filled
M — M — M — M O
0400 0410 0420 0430 0500 0510

M — M — M —
Description: 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 Estab-
lishment/SE Number.

10-byte SE Number “1234567890” would be transmitted as:
1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
31 32 33 34 35 36 37 38 39 30 20 20 20 20 20
April 22, 2011 POS020055 83

Data Field 43 Card Acceptor Name/Location
Field Type: Alphanumeric (upper case) & special characters, left justified,
character space filled
O — O — O — O —
0400 0410 0420 0430 0500 0510

O — O — — —
Description: This field contains the Card Acceptor Name and/or Location.
• Card Acceptor Name — The Merchant’s business name that

appears on the storefront and/or customer receipts, common-
ly 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 phone-
or 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 April 22, 2011

Data Field 43 Card Acceptor Name/Location (Continued)

XYZ~STORE\1234~ABC~ST\PHX\AZ\USA\85054~~ Card Acceptor Name and/or Location
(40 characters)
Note: Tildes (~) represent character spaces.
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
58 59 5A 20 53 54 4F 52 45 5C 31 32 33 34 20 41 42 43 20 53
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
54 5C 50 48 58 5C 41 5A 5C 55 53 41 5C 38 35 30 35 34 20 20

1-40 40 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.
April 22, 2011 POS020055 85

Data Field 44 Additional Response Data

Field Type: Alphanumeric
Field Format: Binary coded decimal (BCD) and hexadecimal
— C1 — C1 C2 O — O
0400 0410 0420 0430 0500 0510

— O — O — 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, For all of these response messages, this field may contain a
0330, 0410, 0430 and 0510 — Response Source Code that indicates the origin of the response
Response Source Code 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 April 22, 2011

Data Field 44 Additional Response Data (Continued)
For MTI = 0110 and 0210 — For these response messages only, this field may contain a CID
Keyed CID Program 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 require-
ments. 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 appli-
cable) 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 Re-
sponse 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.
April 22, 2011 POS020055 87

Example — In the example below, the two-digit VLI is “02”, which is trans-
MTI = 0110, 0210, 0220, 0230, mitted in binary coded decimal (BCD) format; and the digits that
0330, 0410, 0430 and 0510 follow are the two-digit Response Source Code, which are shown
Response Source Code Only in hexadecimal format.
Note: Response Source Code “01” (Capture Host-generated re-

sponse) was used in the example. However, for MTI = 0220, the
Merchant must populate this subfield with the constant literal trans-
action type code value “06” (Off-Line Sale), when this message is
used to void an Off-Line Sale transaction.

02 VLI (2 digits)
01 Response Source Code (2 digits)
1 2 3
02 30 31

2-3 2 2-digit Response Source Code shown in hexadecimal format.
88 POS020055 April 22, 2011

MTI = 0110 and 0210 mitted in binary coded decimal (BCD) format; and the digit that
follows is the one-character CID Response Code, which is shown
Keyed CID Program Only in hexadecimal format.

01 VLI (2 digits)
Y CID Response Code (1 character)
1 2
01 59

2 1 1-character CID Response Code shown in hexadecimal format.
MTI = 0110 and 0210 mitted in binary coded decimal (BCD) format; and the digits that
follow are the two-digit Response Source Code and one-character
Response Source Code CID Response Code, which are shown in hexadecimal format.
and Keyed CID Program
03 VLI (2 digits)
01 Response Source Code (2 digits)
Y CID Response Code (1 character)
1 2 3 4
03 30 31 59

2-3 2 2-digit Response Source Code shown in hexadecimal format.
4 1 1-character CID Response Code shown in hexadecimal format.
April 22, 2011 POS020055 89

Data Field 45 Track 1 Data

C — C — C — — —
0400 0410 0420 0430 0500 0510

C — C — — —
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 var-
ious American Express systems. The field definitions referenced
in Section 9.2 are for reference only and may not reflect all varia-
tions 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 senti-
nels 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 begin-
ning 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 April 22, 2011

ANSI X4.16 Format In the example below, the two-digit VLI is “59”, which is trans-
mitted 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.

59 VLI (2 digits)
B3714~496353~11004^FROST/CHARLES~F.JR~~~~~~~~^9403910112345 ANSI X4.16 Track 1 Data
(59 characters)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
59 42 33 37 31 34 20 34 39 36 33 35 33 20 31 31 30 30 34 5E
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
46 52 4F 53 54 2F 43 48 41 52 4C 45 53 20 46 2E 4A 52 20 20
4 5 6
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
20 20 20 20 20 20 5E 39 34 30 33 39 31 30 31 31 32 33 34 35

2-60 59 59 characters of ANSI X4.16 Track 1 Data shown in hexadecimal
format.
April 22, 2011 POS020055 91

ISO 7813 Format In the example below, the two-digit VLI is “76”, which is trans-
mitted 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.

76 VLI (2 digits)
B371449635311004^FROST/CHARLES~F.JR~~~~~~~~^ ISO 7813 Track 1 Data
94031019101123456789012345678901 (76 characters)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
76 42 33 37 31 34 34 39 36 33 35 33 31 31 30 30 34 5E 46 52
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
4F 53 54 2F 43 48 41 52 4C 45 53 20 46 2E 4A 52 20 20 20 20
4 5 6
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
20 20 20 20 5E 39 34 30 33 31 30 31 39 31 30 31 31 32 33 34
6 7
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7
35 36 37 38 39 30 31 32 33 34 35 36 37 38 39 30 31

2-77 76 76 characters of ISO 7813 Track 1 Data shown in hexadecimal
format.
92 POS020055 April 22, 2011

Expresspay Pseudo-Magnetic In the example below, the two-digit VLI is “60” and the digits
Stripe Format 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.

60 VLI (2 digits)
B371449635311004^VALUED/CARDMEMBER~~~~12345^1211702123424743 Pseudo-Magnetic Stripe
Track 1 Data
(60 characters)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
60 42 33 37 31 34 34 39 36 33 35 33 31 31 30 30 34 5E 56 41
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
4C 55 45 44 2F 43 41 52 44 4D 45 4D 42 45 52 20 20 20 20 31
4 5 6
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
32 33 34 35 5E 31 32 31 31 37 30 32 31 32 33 34 32 34 37 34 33

2-61 60 60 characters of Pseudo-Magnetic Stripe Track 1 Data shown in
hexadecimal format.
April 22, 2011 POS020055 93

Data Field 47 Additional Data - National
Length of Field: 3 bytes minimum, 31 bytes maximum, (LLLVAR)

Variable Length Indicator: 2 bytes, right justified, zero filled
C1 C2 C1 C2 — — — —
0400 0410 0420 0430 0500 0510

— — — — — —
C1 = Mandatory – Specific Merchants identified for prepaid card functionality. All desig-
nated 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 mes-
sage contains Function Code “181” or “182”.
Description: This field contains Additional Data that corresponds to the mes-
sage 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 April 22, 2011

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 Mer-

chant’s system supports the American Express CID Response
Code, which is returned in Data Field 44 (Additional Re-
sponse Data) of Authorization (0110) and Financial Trans-
action (0210) Response Messages.
• Prepaid Card Function Code — This code indicates that the

Merchant’s 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 Example

001 CID Indicator only 001Y
003 Prepaid Card Function Code only 003181
004 CID Indicator and Prepaid Card Function Code 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 demon-

strate the ability to populate and transmit appropriate information
in this field.
April 22, 2011 POS020055 95

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 April 22, 2011

181 = Prepaid Card Partial Authorization Supported — Indi-

cates that the Merchant’s system accepts and processes
Prepaid Card response messages for partial authoriza-
tion of transaction amounts less than the full value orig-
inally submitted for authorization. Please note that the
Merchant must collect the remainder from the Card-
member via another form of payment.
Merchants certified for Prepaid Card Partial Authoriza-

tion 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.
April 22, 2011 POS020055 97

182 = Prepaid Card Authorization with Balance Return Sup-

ported — Indicates that the Merchant’s system and/or
POS device accepts and processes Prepaid Card bal-
ances in response messages. This alternative for sys-
tems that do not support partial authorizations returns
the Prepaid Card balance to the Merchant so that an
authorization request can be resubmitted for the avail-
able amount when transactions are denied for insuffi-
cient balance. Another form of payment (i.e., split ten-
der) 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 deter-
mine which Card products require a response related to
Authorization with Balance Return. Specifically, non-
prepaid 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 authoriza-
tion for the full amount, and that their system supports
the return of Prepaid Card balance information from
American Express.
When applicable, Authorization with Balance Return-
related 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 April 22, 2011

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 Field 54 (Amounts, Addition-
al) of the Authorization Response (0110) message. 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 — • The three-digit VLI is transmitted in binary coded decimal

MTI = 0100 & 0200 (BCD) format, and the odd length must be padded. Specifi-
CID Identifier Code Only cally, “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 hexa-

decimal format.

001 VLI (3 digits)
Y CID Identifier Code (1 character)
1 2 3
00 04 59

1-2 2 3-digit VLI in binary coded decimal (BCD) format, padded with a
leading zero.
3 1 1-character CID Identifier Code shown in hexadecimal format.
April 22, 2011 POS020055 99


MTI = 0100 & 0200 (BCD) format, and the odd length must be padded. Specifi-
Prepaid Card Function Code cally, “003”, must be padded with a leading zero to create
Only the even-length value “00 03”, and four digits of data are
• The three-digit Prepaid Card Function Code is shown in

hexadecimal format.

003 VLI (3 digits)
181 Prepaid Card Function Code (3 digits)
1 2 3 4 5
00 03 31 38 31

leading zero.
3-5 3 3-digit Prepaid Card Function Code shown in hexadecimal
format.
100 POS020055 April 22, 2011


MTI = 0100 & 0200 (BCD) format, and the odd length must be padded. Specific-
CID Identifier Code and ally, “004”, must be padded with a leading zero to create
Prepaid Card Function Code the even-length value “00 04”, and four digits of data are
• The one-character CID Identifier Code is shown in hexa-

decimal format.
• The three-digit Prepaid Card Function Code is shown in

hexadecimal format.

004 VLI (3 digits)
Y CID Identifier Code (1 character)
181 Prepaid Card Function Code (3 digits)
1 2 3 4 5 6
00 04 59 31 38 31

leading zero.
3 1 1-character CID Identifier Code shown in hexadecimal format.
4-6 3 3-digit Prepaid Card Function Code shown in hexadecimal
format.
April 22, 2011 POS020055 101

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, ADDI-
TIONAL 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 origi-
nating Authorization (0100) or Financial Transaction (0200)
Request Message.

MTI = 0110 and 0210 (BCD) format, and the odd length must be padded. Specifi-
Prepaid Card Original cally, “012”, must be padded with a leading zero to create
Transaction Amount the even-length value “00 12”, and four digits of data are
• The 12-digit original transaction amount is shown in hexa-

decimal format.
The example shown is the entry for a $100.00 original transaction

amount in US Dollars (840), with two decimal places implied.

012 VLI (3 digits)
000000010000 Original Transaction Amount (12 digits)
1
1 2 3 4 5 6 7 8 9 0 1 2 3 4
00 12 30 30 30 30 30 30 30 31 30 30 30 30

leading zero.
3-14 12 12-digit, fixed length, Original Transaction Amount is right justi-
fied and zero filled, and shown in hexadecimal format.
102 POS020055 April 22, 2011

Data Field 48 Additional Data - Private

C — C — C — — —
0400 0410 0420 0430 0500 0510

— — — — — —
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.
April 22, 2011 POS020055 103

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 three-digit VLI is transmitted in binary coded decimal

(BCD) format, and the odd length must be padded. Specifi-
cally, “005”, must be padded with a leading zero to create
• 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 even-
length value “04”, and two digits of data are actually trans-
mitted.
• The four-digit Card Identifier (CID) code is shown in hexa-

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

005 VLI (3 digits)
4 Data Type Definition Code (1 digit)
1234 CID/4DBC/4CSC (4 digits)
_1 2 3 4 5 6 7
00 05 04 31 32 33 34

leading zero.
3 1 1-digit Data Type Definition code in binary coded decimal (BCD)
format, padded with a leading zero.
4-7 4 4-digit American Express Card CID/4DBC/4CSC, shown in
hexadecimal format.
104 POS020055 April 22, 2011

Data Field 49 Currency Code, Transaction
Field Type: Numeric
M — M — M — M —
0400 0410 0420 0430 0500 0510

M — M — M —
Description: 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. Spe-
cifically, “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
April 22, 2011 POS020055 105

Data Field 54 Additional Amounts

C1 C2 O C2 C3 — O —
0400 0410 0420 0430 0500 0510

C4 — C4 — — —
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 trans-
action, 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 April 22, 2011

Data Field 54 Additional Amounts (Continued)

• The 12-digit, fixed length, Additional Amount is right justi-

fied and zero filled.
The example shown is the entry for a $5.00 additional amount in

US Dollars (840), with two decimal places implied.

012 VLI (3 digits)
000000000500 Additional Amount (12 digits)
1
1 2 3 4 5 6 7 8 9 0 1 2 3 4
00 12 30 30 30 30 30 30 30 30 30 35 30 30

leading zero.
3-14 12 12-digit, fixed length, Additional Amount is right justified and zero
filled, and shown in hexadecimal format.
For MTI = 0110 & 0210 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.
April 22, 2011 POS020055 107

Data Field 60 Private Use Data

O C1 O C1 — — M —
0400 0410 0420 0430 0500 0510

— — C2 — M —
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 Identi-
fier (MTI) entry for this transaction. See below.
For MTI = 0100 & 0200 For Authorization (0100) and Financial Transaction (0200) Re-
quests that transport Address Verification Service (AVS) data,
this field must contain the Cardmember’s billing Postal Code
(USA ZIP), and Billing Address (see Street Codes on page 202).

29 bytes, which is explained below:

• The Cardmember’s billing Postal Code and Billing Address

are shown in hexadecimal format, upper case, left justified
and character space filled to 29 bytes.
– 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.
108 POS020055 April 22, 2011

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.

029 VLI (3 digits)
85054~~~~ Cardmember Billing Postal Code (9 characters)
18850~N~56~ST~PHOENI Cardmember Billing Address (20 characters)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 29 38 35 30 35 34 20 20 20 20 31 38 38 35 30 20 4E 20 35
2 3
1 2 3 4 5 6 7 8 9 0 1
36 20 53 54 20 50 48 4F 45 4E 49

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

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 iden-
tity 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 Cardmember’s account status) is not influ-
enced 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 hexa-
decimal format.

001 VLI (3 digits)
Y Data Type Definition Code (1 character)
1 2 3
00 01 59

leading zero.
3 1 1-character AVS response code in hexadecimal format.
110 POS020055 April 22, 2011

For MTI = 0320 & 420 For Transaction Upload Advice Request (0320) Message batch
upload requests, this field must contain the Message Type Identi-
fier and Systems Trace Audit Number (a.k.a., sequence number)
that correspond to the original transaction now being retransmit-
ted 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:

• The four-digit Message Type Identifier is shown in hexa-

decimal format.
• The six-digit Systems Trace Audit Number is shown in hexa-

decimal format.
• The 12-character Reserved subfield is character space filled

and shown in hexadecimal format.
April 22, 2011 POS020055 111

For MTI = 0320 & 420 (Continued)

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 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4
00 22 30 33 32 30 31 32 33 34 35 36 20 20 20 20 20 20 20 20 20 20 20 20

leading zero.
3-6 4 4-digit Message Type Identifier (MTI) shown in hexadecimal
format.
7-12 6 6-digit Systems Trace Audit Number shown in hexadecimal
format.
13-24 12 12-character Reserved subfield shown in hexadecimal format.
112 POS020055 April 22, 2011

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.

006 VLI (3 digits)
001234 Batch Identification Number (6 digits)
1 2 3 4 5 6 7 8
00 06 30 30 31 32 33 34

leading zero.
3-8 6 6-digit Batch Identification Number shown in hexadecimal
format.
April 22, 2011 POS020055 113


C1 — M — M — M —
0400 0410 0420 0430 0500 0510

C2 — C2 — — —
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 Express-

assigned, 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:

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

and character space filled, and shown in hexadecimal format.
114 POS020055 April 22, 2011


008 VLI (3 digits)
11 Item Descriptor Code #1 (2 digits)
~~ Item Descriptor Code #4 (2 digits)
Note: Tildes (~) represent character spaces (i.e., no code).
0 1
1 2 3 4 5 6 7 8 9 0
00 08 31 31 32 32 33 33 20 20

1-2 2 3-digit Variable VLI in binary coded decimal (BCD) format,
padded with a leading zero.
3-4 2 2-digit Item Descriptor Code #1 shown in hexadecimal format.
April 22, 2011 POS020055 115


C1 — M — M — M —
0400 0410 0420 0430 0500 0510

C2 — C2 — M —
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 Merchant’s
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.

• The six-digit Invoice Number is right justified and zero filled.
116 POS020055 April 22, 2011


006 VLI (3 digits)
001234 Invoice/ROC/SOC Number (6 digits)
1 2 3 4 5 6 7 8
00 06 30 30 31 32 33 34

leading zero.
3-8 6 6-digit Invoice/ROC/SOC Number shown in hexadecimal format.
April 22, 2011 POS020055 117


C1 — C2 — C2 — C3 —
0400 0410 0420 0430 0500 0510

C1 — C1 — M O
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) indus-
tries 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 April 22, 2011

Note: Although this is a variable length field, all subfields have

specific requirements; and the maximum length of typical vari-
able 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 hexadeci-
mal format.
• The nine-digit Check Number is shown in hexadecimal
format.

011 VLI (3 digits)
07 Table Identifier Code (2 digits)
123456789 Check Number (9 digits)
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3
00 11 30 37 31 32 33 34 35 36 37 38 39

leading zero.
3-4 2 2-digit Table Identifier Code shown in hexadecimal format.
5-13 9 9-digit Check Number shown in hexadecimal format.
April 22, 2011 POS020055 119

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 Merchant’s comput-
erized cash register or order processing system. This entry
can be any combination of characters and numerals; how-
ever, the value must be a cross-reference to a Merchant’s
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 Merchant’s system at the point-of-sale. If provided
by the Merchant’s 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.
• The five-character Ship-To Postal Code is shown in hexa-

decimal format. For USA addresses, use the five-digit ZIP
code from the shipping address.
120 POS020055 April 22, 2011

For MTI = 0200, 0220 & 0320 Purchasing Card Data Subfields (Continued)

025 VLI (3 digits)
123456789 SE Reference (ROC/Invoice) Number (9 digits)
123456789 Customer Reference Number (9 digits)
12345 Ship-To Postal Code (5 digits)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 25 31 37 31 32 33 34 35 36 37 38 39 31 32 33 34 35 36 37
2
1 2 3 4 5 6 7
38 39 31 32 33 34 35

leading zero.
5-13 9 9-digit SE Reference Number shown in hexadecimal format.
14-22 9 9-digit Customer Reference Number shown in hexadecimal
format.
23-27 5 5-digit Ship-To Postal Code shown in hexadecimal format.
April 22, 2011 POS020055 121

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 hexadeci-

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

017 VLI (3 digits)
1 Payment Method Code (2 digit)
81AB1234567890 Ticket Number (14 characters)
0 1
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
00 17 31 38 31 41 42 31 32 33 34 35 36 37 38 39 30 20 20

leading zero.
5 1 2-digit Payment Method Code shown in hexadecimal format.
6-19 14 14-character Ticket Number shown in hexadecimal format.
122 POS020055 April 22, 2011

For MTI = 0320 Lodging Data Subfields


(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 charac-
ters and numerals (upper case, left justified and character
space filled), is the Merchant- or authorized Third Party
Processor-designated reference number assigned to the item-
ized statement of charges/credits associated with this stay.
• The nine-character Reference Number is shown in hexadeci-

mal format. This may be the original Record of Charge (ROC)
or invoice number from a POS terminal, or a reference num-
ber from a Merchant’s computerized cash register or order
processing system. This entry can be any combination of
characters and numerals (upper case, left justified and char-
acter space filled); however, the value must be a cross-refer-
ence to a Merchant’s 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.
April 22, 2011 POS020055 123

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.

040 VLI (3 digits)
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)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 40 31 30 31 32 33 34 35 36 37 38 39 31 32 33 34 35 36 37
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
38 39 30 31 30 31 30 31 30 32 30 30 30 30 30 30 30 31 30 30 30 30

leading zero.
5-13 9 9-character Folio Number shown in hexadecimal format.
14-22 9 9-character Reference Number shown in hexadecimal format.
23-26 4 4-digit Arrival Date shown in hexadecimal format.
27-30 4 4-digit Departure Date shown in hexadecimal format.
31-42 12 12-digit Room Rate shown in hexadecimal format.
124 POS020055 April 22, 2011

For MTI = 0320 Auto Rental Data Subfields


(Auto Rental Data), is shown in hexadecimal format.
• The one-character Adjustment Indicator is shown in hexadeci-

mal 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 Cardmember’s 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.
April 22, 2011 POS020055 125

For MTI = 0320 Auto Rental Data Subfields (Continued)

024 VLI (3 digits)
~ Adjustment Indicator (1 character space)
123456789 Agreement Number (9 characters)
010106 Rental Date (6 digits)
010206 Return Date (6 digits)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 24 31 39 20 31 32 33 34 35 36 37 38 39 30 31 30 31 30 06
2
1 2 3 4 5 6
30 31 30 31 30 36

leading zero.
5 1 1-character Adjustment Indicator shown in hexadecimal format.
6-14 9 9-character Agreement Number shown in hexadecimal format.
15-20 6 6-digit Rental Date shown in hexadecimal format.
21-26 6 6-digit Return Date shown in hexadecimal format.
126 POS020055 April 22, 2011

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, Trans-
action entry (see page 105).

global currencies are accepted. For more information, please
contact your American Express representative.
April 22, 2011 POS020055 127

For MTI = 0500 Close Batch Summary Data Subfields (Continued)

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)
0 1 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 36 30 30 33 30 30 30 30 30 30 30 31 32 33 34 35 30 30 31
2 3
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8
30 30 30 30 30 30 30 30 31 32 33 34 30 30 30 30 30 30

leading zero.
3-5 3 3-digit Batch Debit Count in hexadecimal format.
6-17 12 12-digit Batch Debit Amount in hexadecimal.
18-20 3 3-digit Batch Credit Count in hexadecimal format.
21-32 12 12-digit Batch Credit Amount in hexadecimal.
33-38 6 6-digit Reserved subfield in hexadecimal.
128 POS020055 April 22, 2011

For MTI = 0510 Close Batch Response Subfields
This field is optional for close batch response messages and con-
tains 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.

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 2
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0
00 40 41 50 20 31 35 30 30 30 30 20 20 20 20 24 31 30 30 2E
2 3 4
1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2
30 30 42 41 54 43 48 20 20 31 32 33 34 35 36 2D 31 32 33 34 35 36

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.
April 22, 2011 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 April 22, 2011

7.2.1 0100 — Authorization Request

Notes: 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
0100 - Travelers Cheque

ISO 8583 Bit Number
0100 - Auth Void

0100 - Auth
Data
Data Field Name Field Length Type Field Format Page
– Message Type Identifier 2 bytes, fixed N BCD M M M 56
– Bit Map - Primary 8 bytes, 64 bits B H M M M 57
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD C – C 59
3 Processing Code 3 bytes, fixed N BCD M M M 61
4 Amount, Transaction 6 bytes, fixed N BCD M M M 63
11 Systems Trace Audit Number 3 bytes, fixed N BCD M M M 65
14 Date, Expiration 2 bytes, fixed N BCD C – C 68
22 Point of Service Entry Mode 2 bytes, fixed N BCD M M M 70
24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M 72
25 Point of Service Condition Code 1 byte, fixed N BCD M M M 73
35 Track 2 Data 38 bytes, LLVAR ANS BCD C – C 74
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M 82
42 Card Acceptor Identification Code 15 bytes, fixed ANS H M M M 83
43 Card Acceptor Name/Location 40 bytes, fixed ANS H O O O 84
45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C – C 90
47 Additional Data - National 31 bytes, LLLVAR ANS BCD / H* C – – 94
48 Additional Data - Private 7 bytes, LLLVAR AN BCD / H* C – – 103
49 Currency Code, Transaction 2 bytes, fixed N BCD M M M 105
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O – – 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* O – – 108
61 Private Use Data 10 bytes, LLLVAR ANS BCD / H* M – M 114
62 Private Use Data 8 bytes, LLLVAR ANS BCD / H* M – M 116
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* – M – 118
* VLI / Variable data; e.g. “BCD / H” indicates that VLI is in binary coded decimal (BCD) format, and variable data is in hexadecimal.
April 22, 2011 POS020055 131

7.2.2 0110 — Authorization Response


ISO 8583 Bit Number
0110 - Auth Void

0110 - Auth
Data
– Message Type Identifier 2 bytes, fixed N BCD M M M 56
– Bit Map - Primary 8 bytes, 64 bits B H M M M 57
3 Processing Code 3 bytes, fixed N BCD M M M 61
4 Amount, Transaction 6 bytes, fixed N BCD M M M 63
11 Systems Trace Audit Number 3 bytes, fixed N BCD M M M 65
12 Time, Local Transaction 3 bytes, fixed N BCD M M M 66
13 Date, Local Transaction 2 bytes, fixed N BCD M M M 67
24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M 72
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M M 78
38 Authorization Identification Response 6 bytes, fixed AN H C C – 79
39 Response Code 2 bytes, fixed AN H M M M 81
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M 82
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* C O C 86
47 Additional Data - National 31 bytes, LLLVAR ANS BCD / H* C – – 94
54 Amounts, Additional 14 bytes, LLLVAR AN BCD / H* O – – 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* C – – 108
132 POS020055 April 22, 2011

7.2.3 0200 — Financial Transaction Request (Auth & Capture)

ISO 8583 Bit Number
0200 - Sale
Data
– Message Type Identifier 2 bytes, fixed N BCD M 56
– Bit Map - Primary 8 bytes, 64 bits B H M 57
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD C 59
3 Processing Code 3 bytes, fixed N BCD M 61
4 Amount, Transaction 6 bytes, fixed N BCD M 63
11 Systems Trace Audit Number 3 bytes, fixed N BCD M 65
14 Date, Expiration 2 bytes, fixed N BCD C 68
22 Point of Service Entry Mode 2 bytes, fixed N BCD M 70
24 Network International Identifier (NII) 2 bytes, fixed N BCD M 72
25 Point of Service Condition Code 1 byte, fixed N BCD M 73
35 Track 2 Data 38 bytes, LLVAR ANS BCD C 74
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M 82
42 Card Acceptor Identification Code 15 bytes, fixed ANS H M 83
43 Card Acceptor Name/Location 40 bytes, fixed ANS H O 84
45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C 90
47 Additional Data - National 31 bytes, LLLVAR ANS BCD / H* C 94
48 Additional Data - Private 7 bytes, LLLVAR AN BCD / H* C 103
49 Currency Code, Transaction 2 bytes, fixed N BCD M 105
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* O 108
61 Private Use Data 10 bytes, LLLVAR ANS BCD / H* M 114
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* C 118
April 22, 2011 POS020055 133

7.2.4 0210 — Financial Transaction Response

ISO 8583 Bit Number
0210 - Sale
Data
4 Amount, Transaction 6 bytes, fixed N BCD M 63
12 Time, Local Transaction 3 bytes, fixed N BCD M 66
13 Date, Local Transaction 2 bytes, fixed N BCD M 67
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M 78
38 Authorization Identification Response 6 bytes, fixed AN H C 79
39 Response Code 2 bytes, fixed AN H M 81
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* C 86
47 Additional Data - National 31 bytes, LLLVAR ANS BCD / H* C 94
54 Amounts, Additional 14 bytes, LLLVAR AN BCD / H* C 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* C 108
134 POS020055 April 22, 2011

7.2.5 0220 — Financial Transaction Advice Request (Capture)

0220 - Credit Adjustment/Void

0220 - Debit Adjustment/Void
0220 - Sale Completion
0220 - Off-Line Refund

ISO 8583 Bit Number
0220 - Off-Line Sale

Data
– Message Type Identifier 2 bytes, fixed N BCD M M M M M 56
– Bit Map - Primary 8 bytes, 64 bits B H M M M M M 57
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD C C M M C 59
3 Processing Code 3 bytes, fixed N BCD M M M M M 61
4 Amount, Transaction 6 bytes, fixed N BCD M M M M M 63
11 Systems Trace Audit Number 3 bytes, fixed N BCD M M M M M 65
12 Time, Local Transaction 3 bytes, fixed N BCD M M M M M 66
13 Date, Local Transaction 2 bytes, fixed N BCD M M M M M 67
14 Date, Expiration 2 bytes, fixed N BCD C C M M C 68
22 Point of Service Entry Mode 2 bytes, fixed N BCD M M M M M 70
24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M M M 72
25 Point of Service Condition Code 1 byte, fixed N BCD M M M M M 73
35 Track 2 Data 38 bytes, LLVAR ANS BCD C C – – C 74
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H – – M M – 78
38 Authorization Identification Response 6 bytes, fixed AN H M M – – – 79
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M M M 82
42 Card Acceptor Identification Code 15 bytes, fixed ANS H M M M M M 83
43 Card Acceptor Name/Location 40 bytes, fixed ANS H O O O O O 84
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O – C – O 86
45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C C – – C 90
47 Additional Data - National 31 bytes, LLLVAR ANS BCD / H* – – – – – 94
48 Additional Data - Private 7 bytes, LLLVAR AN BCD / BCD / H* C C – – – 103
49 Currency Code, Transaction 2 bytes, fixed N BCD M M M M M 105
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O O O – – 106
61 Private Use Data 10 bytes, LLLVAR ANS BCD / H* M M M M M 114
62 Private Use Data 8 bytes, LLLVAR ANS BCD / H* M M M M M 116
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* C C – – – 118
April 22, 2011 POS020055 135

7.2.6 0230 — Financial Transaction Advice Response

0230 - Credit Adjustment/Void

0230 - Debit Adjustment/Void
0230 - Sale Completion
0230 - Off-Line Refund

ISO 8583 Bit Number
0230 - Off-Line Sale

Data
12 Time, Local Transaction 3 bytes, fixed N BCD O O O O O 66
13 Date, Local Transaction 2 bytes, fixed N BCD O O O O O 67
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M – – M 78
39 Response Code 2 bytes, fixed AN H M M M M M 81
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O O O O O 86
136 POS020055 April 22, 2011

7.2.7 0320 — Transaction Upload Advice Request (Terminal-to-Host)

ISO 8583 Bit Number
0320 - Credit Upload

0320 - Debit Upload
Data
– Message Type Identifier 2 bytes, fixed N BCD M M 56
– Bit Map - Primary 8 bytes, 64 bits B H M M 57
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD M M 59
3 Processing Code 3 bytes, fixed N BCD M M 61
4 Amount, Transaction 6 bytes, fixed N BCD M M 63
11 Systems Trace Audit Number 3 bytes, fixed N BCD M M 65
12 Time, Local Transaction 3 bytes, fixed N BCD M M 66
13 Date, Local Transaction 2 bytes, fixed N BCD M M 67
14 Date, Expiration 2 bytes, fixed N BCD M M 68
22 Point of Service Entry Mode 2 bytes, fixed N BCD M M 70
24 Network International Identifier (NII) 2 bytes, fixed N BCD M M 72
25 Point of Service Condition Code 1 byte, fixed N BCD M M 73
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M 78
38 Authorization Identification Response 6 bytes, fixed AN H M – 79
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M 82
42 Card Acceptor Identification Code 15 bytes, fixed ANS H M M 83
43 Card Acceptor Name/Location 40 bytes, fixed ANS H O O 84
49 Currency Code, Transaction 2 bytes, fixed N BCD M M 105
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O O 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* M M 108
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* C C 118
April 22, 2011 POS020055 137

7.2.8 0330 — Transaction Upload Advice Response

ISO 8583 Bit Number
0330 - Credit Upload

0330 - Debit Upload
Data
– Message Type Identifier 2 bytes, fixed N BCD M M 56
– Bit Map - Primary 8 bytes, 64 bits B H M M 57
3 Processing Code 3 bytes, fixed N BCD M M 61
11 Systems Trace Audit Number 3 bytes, fixed N BCD M M 65
24 Network International Identifier (NII) 2 bytes, fixed N BCD M M 72
39 Response Code 2 bytes, fixed AN H M M 81
41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M 82
42 Card Acceptor Identification Code 15 bytes, fixed ANS H O O 83
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O O 86
138 POS020055 April 22, 2011

7.2.9 0400 — Reversal Request


ISO 8583 Bit Number
0400 - Auth Void
0400 - Refund
0400 - Auth
0400 - Sale
Data
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD C – C C C 59
14 Date, Expiration 2 bytes, fixed N BCD C – C C C 68
35 Track 2 Data 38 bytes, LLVAR ANS BCD C – C C C 74
45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C – C C C 90
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O – – O – 106
61 Private Use Data 10 bytes, LLLVAR ANS BCD / H* – – – M M 114
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* – M – – – 118
April 22, 2011 POS020055 139

7.2.10 0410 — Reversal Response


ISO 8583 Bit Number
0410 - Auth Void
0410 - Refund
0410 - Auth
0410 - Sale
Data
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M M M M 78
140 POS020055 April 22, 2011

7.2.11 0420 — Reversal Advice Request


ISO 8583 Bit Number
0420 - Auth Void
0420 - Refund
0420 - Auth
0420 - Sale
Data
2 Primary Account Number (PAN) 11 bytes, LLVAR N BCD C – C C C 59
14 Date, Expiration 2 bytes, fixed N BCD C – C C C 68
35 Track 2 Data 38 bytes, LLVAR ANS BCD C – C C C 74
45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C – C C C 90
54 Additional Amounts 14 bytes, LLLVAR AN BCD / H* O – – O – 106
60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* M – – M – 108
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* – M – – – 118
April 22, 2011 POS020055 141

7.2.12 0430 — Reversal Advice Response


ISO 8583 Bit Number
0430 - Auth Void
0430 - Refund
0430 - Auth
0430 - Sale
Data
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M M M M 78
142 POS020055 April 22, 2011

7.2.13 0500 — Reconciliation Request

ISO 8583 Bit Number
0500 - Close
Data
15 Date, Settlement 2 bytes, fixed N BCD O 69
42 Card Acceptor Identification Code 15 bytes, fixed ANS H M 83
49 Currency Code, Transaction 2 bytes, fixed N BCD M 105
April 22, 2011 POS020055 143

7.2.14 0510 — Reconciliation Response

ISO 8583 Bit Number
0510 - Close
Data
12 Time, Local Transaction 3 bytes, fixed N BCD M 66
13 Date, Local Transaction 2 bytes, fixed N BCD M 67
37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H O 78
39 Response Code 2 bytes, fixed AN H M 81
44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O 86
63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* O 118
144 POS020055 April 22, 2011

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.”
April 22, 2011 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 compu-
tation 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 Cardmember’s 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 April 22, 2011

8.1 Cardmember Account Number Check Digit Computation (Continued)
Example: Cardmember #373872186011004 The check digit is 4
1. Do not include the check 3 7 3 8 7 2 1 8 6 0 1 1 0 0

digit (last number to the
right) in the calculation.
2. Starting with the last digit 7 8 2 8 0 1 0
to the right, and working x2 x2 x2 x2 x2 x2 x2
right to left, multiply every 14 16 4 16 0 2 0
other digit by two.
3. If any product of Step 2 is 5 7 4 7 0 2 0
a two-digit number, add
the two digits together.
4. Add the products 5 + 7 + 4 + 7 + 0 + 2 + 0 = 25
produced in Step 3.
5. Add all the digits not used 3 + 3 + 7 + 1 + 6 + 1 + 0 = 21
in Step 2.
6. Add the results of Steps 4 25 + 21 = 46
and 5.
7. If the result of Step 6 is a 50 – 46 = 4
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.
If the calculated check Given check digit is 4.
digit matches the given
Calculated check digit is 4.
check digit, the Card-
member account number Account Number is valid.
is valid.
If the check digits do not
match, the Cardmember
number is invalid and must
be flagged as invalid.
April 22, 2011 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 April 22, 2011

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 six-
digit 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 one-
digit 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 Host’s 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).
April 22, 2011 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 April 22, 2011

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.
April 22, 2011 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 varia-
tions 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 Merchant’s system supports capture of both Track 1 and Track 2, both tracks must be for-
warded. 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). Ameri-
can Express requires all Merchants and service providers as part of their Card Acceptance or servic-
ing 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 dem-
onstrate 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 April 22, 2011

9.2.1 ANSI X4.16 Standard
Track 1 (Preferred) Track 2
Field Name Digit Field Name Digit

Start Sentinel 1 Start Sentinel 1
Format Code 1 Account Number (PAN) 15
Account Number (PAN) * 17 Field Separator 1
Field Separator 1 Expiration Date (YYMM) 4
Cardmember Name 26 Effective Date (YYMM) 4
Field Separator 1 Discretionary Data 5
Expiration Date (YYMM) 4 End Sentinel 1
Effective Date (YYMM) 4 LRC † 1
Discretionary Data 5 Unused 8
End Sentinel 1
LRC † 1 Total 40
Unused 17
Total 79
9.2.2 ISO 7813 Standard

Account Number (PAN) 15 Field Separator 1
Cardmember Name 26 Interchange Designator 1
Field Separator 1 Service Code 2
Expiration Date (YYMM) 4 Effective Date (YYMM) 4
Interchange Designator 1 Discretionary Data 8
Service Code 2 Language Code 2
Effective Date (YYMM) 4 End Sentinel 1
Discretionary Data 21 LRC ‡ 1
End Sentinel 1
LRC ‡ 1 Total 40
Total 79
*
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.
April 22, 2011 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.

2 = Chip card
5 = Available for interchange only in country of issue.
7 = Not available for general interchange.
9 = 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 issuer’s 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 April 22, 2011

9.2.4 ANSI X4.16 / ISO 7813 Track 1 Message Formats
Subfield 1 — ANSI X4.16 START SENTINEL

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

9.2.4 ANSI X4.16 / ISO 7813 Track 1 Message Formats (Cont.)
Subfield 2 — ANSI X4.16 FORMAT CODE

Subfield 2 — ISO 7813 FORMAT CODE
Field Type: Alpha

Constant: B
Description: This field indicates the use of standard format “B”;

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

Subfield 3 — ANSI X4.16 ACCOUNT NUMBER (PAN)

Subfield 3 — ISO 7813 ACCOUNT NUMBER (PAN)
Length of Field: 17 bytes — ANSI X4.16

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

Positions 3-17 — ISO 7813
Constant: None
Description: This field contains the Cardmember’s PRIMARY ACCOUNT

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

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

Subfield 4 — ANSI X4.16 FIELD SEPARATOR

Subfield 4 — ISO 7813 FIELD SEPARATOR

Constant: ^
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 mag-
netic 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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
158 POS020055 April 22, 2011

Subfield 5 — ANSI X4.16 CARDMEMBER NAME

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

Constant: None
Description: This field contains the Cardmember’s name, which is encoded in

magnetic stripe data for American Express Cards. The following
characters are used to separate the elements of a Cardmember’s
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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
April 22, 2011 POS020055 159



Constant: ^
Note: The constant literal “^” appears here for example purposes
only. Other special character values may appear in actual mag-
netic 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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
160 POS020055 April 22, 2011

Subfield 7 — ANSI X4.16 EXPIRATION DATE

Subfield 7 — ISO 7813 EXPIRATION DATE
Field Type: Numeric, YYMM

Constant: None
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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
April 22, 2011 POS020055 161

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 201 501 601 701 901

102 206 502 606 702 902
103 220 503 621 703 903
106 221 506 622
120 223 520 626
121 226 521
122 522
123 526
126
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 April 22, 2011

Subfield 8 — ISO 7813 INTERCHANGE DESIGNATOR
Field Type: Numeric
Approximate Position: Position 50 — ISO 7813

Note: This field applies only to ISO 7813 Standard Track 1 and
is not applicable to ANSI X4.16.
Constant: None
Description: This field indicates whether the American Express Card can be
used outside the country of issue.
1 =
Available for international interchange.
2 =
Chip card.
5 =
Available for interchange only in country of issue.
6 =
Chip card, available for interchange only in country of
issue.
See Special Note for Subfields 8 and 9, on page 162.
Message: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
April 22, 2011 POS020055 163

Subfield 9 — ISO 7813 SERVICE CODE
Field Type: Numeric
Approximate Position: Positions 51-52 — ISO 7813

Constant: None
Description: This field indicates whether the American Express Card can
be used for ATM/Cash Access, or if positive authorization is
required.
03 = ATM Service only.
06 = No restrictions; prompt for PIN, if PIN pad is present.
20 = Requires positive authorization by issuer or issuer’s
agent.
21 = Authorization by issuer only.
22 = Authorization by issuer only; Goods & Services.
23 = Authorization by issuer only; ATM only, PIN required.
26 = Authorization by issuer only; prompt for PIN, if PIN pad
is present.
Message: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
164 POS020055 April 22, 2011

Subfield 8 — ANSI X4.16 EFFECTIVE DATE

Subfield 10 — ISO 7813 EFFECTIVE DATE

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

Subfield 9 — ANSI X4.16 DISCRETIONARY DATA

Subfield 11 — ISO 7813 DISCRETIONARY DATA

Field Type: Numeric

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

Subfield 10 — ANSI X4.16 END SENTINEL

Subfield 12 — ISO 7813 END SENTINEL

Constant: ?
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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
April 22, 2011 POS020055 167

Subfield 11 — ANSI X4.16 LONGITUDINAL REDUNDANCY CHECK (LRC)

Subfield 13 — ISO 7813 LONGITUDINAL REDUNDANCY CHECK (LRC)
Field Type: Binary

Constant: None
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: % B 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 ^ F R
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
Message: ^ 9 4 0 3 1 0 1 9 1 0 1 1 2 3 4
Position: 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
Message: 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 ?
Position: 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79
168 POS020055 April 22, 2011

Subfield 12 — ANSI X4.16 UNUSED
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.
April 22, 2011 POS020055 169

9.2.5 ANSI X4.16 / ISO 7813 Track 2 Message Formats
Subfield 1 — ANSI X4.16 START SENTINEL

Subfield 1 — ISO 7813 START SENTINEL

Constant: ;
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: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
170 POS020055 April 22, 2011

Subfield 2 — ANSI X4.16 ACCOUNT NUMBER (PAN)

Subfield 2 — ISO 7813 ACCOUNT NUMBER (PAN)
Field Type: Numeric

Constant: None
Description: This field contains the Cardmember’s PRIMARY ACCOUNT

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


Field Type: Alpha or special character

Constant: =
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: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
172 POS020055 April 22, 2011

Subfield 4 — ANSI X4.16 EXPIRATION DATE

Subfield 4 — ISO 7813 EXPIRATION DATE

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

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 201 501 601 701 901

102 206 502 606 702 902
103 220 503 621 703 903
106 221 506 622
120 223 520 626
121 226 521
122 522
123 526
126
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 April 22, 2011

Subfield 5 — ISO 7813 INTERCHANGE DESIGNATOR
Field Type: Numeric
Approximate Position: Position 22 — ISO 7813

Constant: None
used outside the country of issue.
1 =
Available for international interchange.
2 =
Chip card.
5 =
Available for interchange only in country of issue.
6 =
Chip card, available for interchange only in country of
issue.
Message: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
April 22, 2011 POS020055 175

Subfield 6 — ISO 7813 SERVICE CODE
Field Type: Numeric

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

Subfield 5 — ANSI X4.16 EFFECTIVE DATE

Subfield 7 — ISO 7813 EFFECTIVE DATE

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

Subfield 6 — ANSI X4.16 DISCRETIONARY DATA

Subfield 8 — ISO 7813 DISCRETIONARY DATA

Field Type: Numeric

Constant: None
Description: This field contains American Express discretionary data.
Message: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
178 POS020055 April 22, 2011

Subfield 9 — ISO 7813 LANGUAGE CODE
Field Type: Numeric

Note: This field applies only to ISO 7813 Standard Track 2
and is not applicable to ANSI X4.16
Constant: None
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: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
April 22, 2011 POS020055 179

Subfield 7 — ANSI X4.16 END SENTINEL

Subfield 10 — ISO 7813 END SENTINEL

Constant: ?
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: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
180 POS020055 April 22, 2011

Subfield 8 — ANSI X4.16 LONGITUDINAL REDUNDANCY CHECK (LRC)

Subfield 11 — ISO 7813 LONGITUDINAL REDUNDANCY CHECK (LRC)
Field Type: Binary

Constant: None
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: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0
Position: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20
Message: 3 1 0 1 9 1 0 1 1 2 3 4 5 6 7 8 0 0 ?
Position: 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40
April 22, 2011 POS020055 181

Subfield 9 — ANSI X4.16 UNUSED
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 April 22, 2011

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 Merchant’s POS device must format the chip-card payment data into pseudo-
magnetic stripe Track 1 and/or Track 2 data, which is then used to populate Fields 45 and/or 35, respec-
tively, 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 popu-
lating 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.
April 22, 2011 POS020055 183

9.3.1 Expresspay Pseudo Track 1 & Track 2 Subfields

Account Number (PAN) 15 Field Separator 1
Cardmember Name 21 Interchange Designator 1
ATC 5 Service Code 2
Field Separator 1 Unpredictable Number 4
Expiration Date (YYMM) 4 Cryptogram 5
Interchange Designator 1 ATC 5
Service Code 2 End Sentinel 1
Unpredictable Number 4
Cryptogram 5 Total 39
End Sentinel 1
Total 62
184 POS020055 April 22, 2011

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 Field Value Description of Use

Both Partial Auth, All 0100 & 0200 4 - Amount, Transaction Full transaction amount Full transaction amount requested for
and Authorization auth requests requested for auth authorization
with Balance Return
Partial Auth only All 0100 & 0200 47 - Additional Data - 181 Merchant system supports optional
auth requests National Partial Auth response data
Authorization with All 0100 & 0200 47 - Additional Data - 182 Merchant system supports optional
Balance Return only auth requests National Authorization with Balance Return
response data
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 Description of Use

Partial Auth only Some 0110 & 4 - Amount, Transaction Actual amount authorized Only present for Partial Auth
0210 responses (not original amount) (Field 39 = 06)
Partial Auth only Some 0110 & 39 - Response Code 004 = Partial Auth Indicates response is a Partial Auth
0210 responses
Partial Auth only Some 0110 & 47 - Additional Data - Full transaction amount Only present for Partial Auth
0210 responses National originally requested (Field 39 = 06)
Partial Auth only Some 0110 & 54 - Amounts, Additional Balance remaining on Present if Merchant system supports
0210 responses Prepaid Card product Partial Auth and Prepaid Card
Primary Account Number is valid
Authorization with All 0110 & 0210 4 - Amount, Transaction Original amount, echo Same value as Field 4 in original
Balance Return only responses returned auth request
Authorization with All 0110 & 0210 39 - Response Code Routine values for No special Response Codes are
Balance Return only responses approve, deny, refer, etc. used for Authorizations with Balance
Return.
Authorization with Some 0110 & 54 - Amounts, Additional Balance remaining on Present if Merchant system supports
Balance Return only 0210 responses Prepaid Card product 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 Merchant’s message content for all
American Express products.
April 22, 2011 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.
– 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.
186 POS020055 April 22, 2011

Premise: The Merchant tries to authorize a $10.00 charge; and American Express returns an author-
ization 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.
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.
April 22, 2011 POS020055 187

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 trans-
actions.
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 April 22, 2011

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.
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.
April 22, 2011 POS020055 189

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” indi-
cating 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.
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:
– 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
190 POS020055 April 22, 2011

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 remain-
ing 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.
April 22, 2011 POS020055 191

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.
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 trans-
actions.
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 April 22, 2011

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.
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.
April 22, 2011 POS020055 193

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.
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 April 22, 2011

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
April 22, 2011 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 reversed 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 the equivalent to either “000009999999” ($99,999.99 USD) or “000999999999” ($9,999,999.99 USD).
Currency Name Country or Entity Name Code Dec Notes Maximum Value
(See Note 3) (See Note 4)
Cuba 1
Iran 1
Myanmar 1
Sudan 1
Afghanistan Afghani Afghanistan 971 2 000009999999
Albanian Lek Albania 008 2 000999999999
Algerian Dinar Algeria 012 2 2 000999999999
Angolan Kwanza Angola 973 2 000009999999
Argentine Peso Argentina 032 2 000009999999
Armenian Dram Armenia 051 2 000999999999
Aruban Guilder Aruba 533 2 000999999999
Australian Dollar Australia 036 2 000999999999
Australian Dollar Christmas Island 036 2 000009999999
Australian Dollar Cocos (Keeling) Islands 036 2 000009999999
Australian Dollar Heard and McDonald Islands 036 2 000009999999
Australian Dollar Kiribati 036 2 000009999999
Australian Dollar Nauru 036 2 000009999999
Australian Dollar Norfolk Island 036 2 000009999999
Australian Dollar Tuvalu 036 2 000009999999
Azerbaijanian Manat Azerbaijan 944 2 000009999999
Bahamian Dollar Bahamas 044 2 000999999999
Bahraini Dinar Bahrain 048 3 000999999999
Bangladesh Taka Bangladesh 050 2 000999999999
Barbados Dollar Barbados 052 2 000009999999
Belarusian Ruble Belarus 974 0 000009999999
Belize Dollar Belize 084 2 000009999999
Bermudian Dollar Bermuda 060 2 000009999999
Bhutan Ngultrum Bhutan 064 2 000009999999
Bolivar Fuerte Venezuela 937 2 000999999999
Bolivian Boliviano Bolivia 068 2 000999999999
Bosnian Mark Bosnia and Herzegovina 977 2 000999999999
Botswana Pula Botswana 072 2 000999999999
Brazilian Real Brazil 986 2 000009999999
Brunei Dollar Brunei Darussalam 096 2 000999999999
196 POS020055 April 22, 2011


Bulgarian Lev Bulgaria 975 2 000999999999

Burundi Franc Burundi 108 0 000009999999
Cambodian Riel Cambodia 116 2 000999999999
Canadian Dollar Canada 124 2 000999999999
Cape Verde Escudo Cape Verde 132 2 000009999999
Cayman Islands Dollar Cayman Islands 136 2 000999999999
Central French Polynesian Franc French Polynesia 953 0 2 000999999999
Central French Polynesian Franc New Caledonia 953 0 2 000009999999
Central French Polynesian Franc Wallis and Futuna Islands 953 0 2 000009999999
CFA Franc BCEAO Benin 952 0 000999999999
CFA Franc BCEAO Burkina Faso 952 0 000999999999
CFA Franc BCEAO Cote D’Ivoire (Ivory Coast) 952 0 000999999999
CFA Franc BCEAO Guinea-Bissau 952 0 000999999999
CFA Franc BCEAO Mali 952 0 000999999999
CFA Franc BCEAO Niger 952 0 000999999999
CFA Franc BCEAO Senegal 952 0 000999999999
CFA Franc BCEAO Togo 952 0 000999999999
CFA Franc BEAC Cameroon 950 0 000999999999
CFA Franc BEAC Central African Republic 950 0 000999999999
CFA Franc BEAC Chad 950 0 000999999999
CFA Franc BEAC Congo, Republic of the 950 0 000999999999
CFA Franc BEAC Equatorial Guinea 950 0 000999999999
CFA Franc BEAC Gabon 950 0 000999999999
Chilean Peso Chile 152 0 000999999999
China Yuan Renminbi China 156 2 000999999999
Colombian Peso Colombia 170 2 000999999999
Comoro Franc Comoros 174 0 000009999999
Congolese Franc Congo, Democratic Republic of 976 2 000009999999
Costa Rican Colon Costa Rica 188 2 000999999999
Czech Koruna Czech Republic 203 2 000999999999
Danish Krone Denmark 208 2 000999999999
Danish Krone Faroe Islands 208 2 000009999999
Danish Krone Greenland 208 2 000009999999
Djibouti Franc Djibouti 262 0 000009999999
Dominican Republic Peso Dominican Republic 214 2 000999999999
E. Caribbean Dollar Anguilla 951 2 000999999999
E. Caribbean Dollar Antigua and Barbuda 951 2 000999999999
E. Caribbean Dollar Dominica 951 2 000999999999
E. Caribbean Dollar Grenada 951 2 000999999999
E. Caribbean Dollar Montserrat 951 2 000999999999
E. Caribbean Dollar St. Kitts-Nevis 951 2 000999999999
E. Caribbean Dollar St. Lucia 951 2 000999999999
E. Caribbean Dollar St. Vincent and the Grenadines 951 2 000999999999
E. Caribbean Dollar West Indies 951 2 000009999999
Ecuadorian Sucre Ecuador 218 2 2 000999999999
Egyptian Pound Egypt 818 3 2 000999999999
April 22, 2011 POS020055 197


El Salvadorian Colon El Salvador 222 2 000999999999

Ethiopian Birr Ethiopia 230 2 000009999999
Euro Aland Islands 978 2 000999999999
Euro American Samoa 978 2 000999999999
Euro Andorra 978 2 000999999999
Euro Austria 978 2 000999999999
Euro Belgium 978 2 000999999999
Euro Croatia, Republic of 978 2 000999999999
Euro Cyprus 978 2 000999999999
Euro Estonia 978 2 000999999999
Euro Ethiopia 978 2 000009999999
Euro Finland 978 2 000999999999
Euro France 978 2 000999999999
Euro French Guiana 978 2 000009999999
Euro French Southern Territories 978 2 000009999999
Euro Germany 978 2 000999999999
Euro Greece 978 2 000999999999
Euro Guadeloupe 978 2 000999999999
Euro Ireland 978 2 000999999999
Euro Italy 978 2 000999999999
Euro Luxembourg 978 2 000009999999
Euro Malta 978 2 000999999999
Euro Martinique 978 2 000999999999
Euro Mayotte 978 2 000009999999
Euro Monaco 978 2 000999999999
Euro Montenegro 978 2 000999999999
Euro Netherlands 978 2 000999999999
Euro Portugal 978 2 000999999999
Euro Reunion 978 2 000999999999
Euro San Marino 978 2 000999999999
Euro Slovakia 978 2 000999999999
Euro Slovenia 978 2 000999999999
Euro Spain 978 2 000999999999
Euro St. Barthelemy 978 2 000999999999
Euro St. Martin 978 2 000999999999
Euro St. Pierre and Miquelon 978 2 000009999999
Euro Vatican City State (Holy See) 978 2 000999999999
Falkland Islands Pound Falkland Islands (Malvinas) 238 2 000009999999
Fiji Dollar Fiji 242 2 000999999999
Gambia Dalasi Gambia 270 2 000999999999
Georgia Lari Georgia 981 2 000999999999
Ghanaian Cedi Ghana 936 2 000009999999
Gibraltar Pound Gibraltar 292 2 000999999999
Guatemalan Quetzal Guatemala 320 2 000999999999
Guinean Franc Guinea 324 0 000009999999
Guyana Dollar Guyana 328 2 000999999999
198 POS020055 April 22, 2011


Haiti Gourde Haiti 332 2 000999999999

Honduran Lempira Honduras 340 2 000999999999
Hong Kong Dollar Hong Kong 344 2 000999999999
Hungarian Forint Hungary 348 2 000999999999
Icelandic Krona Iceland 352 2 000999999999
Indian Rupee India 356 2 000999999999
Indonesian Rupiah Indonesia 360 2 000999999999
Iraqi Dinar Iraq 368 3 000999999999
Jamaican Dollar Jamaica 388 2 000999999999
Japanese Yen Japan 392 0 000999999999
Jordanian Dinar Jordan 400 3 000999999999
Kazakhstan Tenge Kazakhstan 398 2 000999999999
Kenyan Shilling Kenya 404 2 000999999999
Kuna Croatia, Republic of 191 2 000999999999
Kuwaiti Dinar Kuwait 414 3 000999999999
Kyrgyzstan Som Kyrgyzstan 417 2 000009999999
Laotian Kip Lao People’s Democratic Republic 418 2 000009999999
Latvian Lats Latvia 428 2 000999999999
Lebanese Pound Lebanon 422 2 000999999999
Lesotho Loti Lesotho 426 2 000009999999
Liberian Dollar Liberia 430 2 000999999999
Libyan Dinar Libyan Arab Jamahiriya 434 3 000009999999
Lithuanian Litas Lithuania 440 2 000999999999
Macao Pataca Macau 446 2 000999999999
Macedonia Denar Macedonia 807 2 000999999999
Malagasy Ariary Madagascar 969 0 000009999999
Malawi Kwacha Malawi 454 2 000999999999
Malaysian Ringgit Malaysia 458 2 000999999999
Maldive Rufiyaa Maldives 462 2 000999999999
Mauritania Ouguiya Mauritania 478 2 000999999999
Mauritius Rupee Mauritius 480 2 000009999999
Metical Mozambique 943 2 000009999999
Mexican Peso Mexico 484 2 000009999999
Moldovan Leu Moldova, Republic of 498 2 000999999999
Mongolian Tugrik Mongolia 496 2 000999999999
Moroccan Dirham Morocco 504 2 000999999999
Moroccan Dirham Western Sahara 504 2 000009999999
Namibian Dollar Namibia 516 2 000009999999
Nepalese Rupee Nepal 524 2 000999999999
Netherlands Antillian Guilder Curaçao 532 2 000999999999
Netherlands Antillian Guilder Sint Maarten 532 2 000999999999
New Israeli Shekel Israel 376 2 000999999999
New Manat Turkmenistan 934 2 000009999999
New Taiwan Dollar Taiwan 901 2 000999999999
New Zealand Dollar Cook Islands 554 2 000009999999
New Zealand Dollar New Zealand 554 2 000999999999
April 22, 2011 POS020055 199


New Zealand Dollar Niue 554 2 000009999999

New Zealand Dollar Pitcairn 554 2 000009999999
New Zealand Dollar Tokelau 554 2 000009999999
Nicaraguan Cordoba Oro Nicaragua 558 2 000999999999
Nigeria Naira Nigeria 566 2 000999999999
North Korean Won Korea, Democratic People’s Republic of
Norwegian Krone Bouvet Island 578 2 000009999999
Norwegian Krone Norway 578 2 000999999999
Norwegian Krone Svalbard and Jan Mayen Islands 578 2 000009999999
Omani Rial Oman 512 3 000999999999
Pakistan Rupee Pakistan 586 2 000999999999
Panama Balboa Panama 590 2 000009999999
Papua New Guinea Kina Papua New Guinea 598 2 000999999999
Paraguan Guarani Paraguay 600 2 000999999999
Peruvian Nuevo Sol Peru 604 2 000999999999
Peso Uruguayo Uruguay 858 2 000999999999
Philippine Peso Philippines 608 2 000999999999
Polish Zloty Poland 985 2 000999999999
Pound Sterling Guernsey 826 2 000999999999
Pound Sterling Isle of Man 826 2 000999999999
Pound Sterling Jersey 826 2 000999999999
Pound Sterling United Kingdom 826 2 000999999999
Qatari Rial Qatar 634 2 000999999999
Romanian Leu Romania 946 2 000999999999
Russian Federation Ruble Russian Federation 643 2 000999999999
Rwanda Franc Rwanda 646 0 000009999999
Samoa Tala Western Samoa 882 2 000009999999
Sao Tome and Principe Dobra Sao Tome and Principe 678 2 000009999999
Saudi Arabian Riyal Saudi Arabia 682 2 000999999999
Serbian Dinar Serbia (see also, Macedonia) 941 2 000999999999
Seychelles Rupee Seychelles 690 2 000999999999
Sierra Leone Leone Sierra Leone 694 2 000009999999
Singapore Dollar Singapore 702 2 000999999999
Solomon Islands Dollar Solomon Islands 090 2 000009999999
Somali Shilling Somalia 706 2 000009999999
South African Rand Namibia 710 2 000009999999
South African Rand South Africa 710 2 000999999999
South Korean Won Korea, Republic of 410 0 000999999999
Sri Lanka Rupee Sri Lanka 144 2 000999999999
St. Helena Pound St. Helena 654 2 000009999999
Surinam Dollar Suriname 968 2 000999999999
Swaziland Emalengeni Swaziland 748 2 000009999999
Swedish Krona Sweden 752 2 000999999999
Swiss Franc Liechtenstein 756 2 000999999999
Swiss Franc Switzerland 756 2 000999999999
Syrian Pound Syrian Arab Republic 760 2 000999999999
200 POS020055 April 22, 2011


Tajik Somoni Tajikistan 972 2 000009999999

Tanzanian Shilling Tanzania, United Republic of 834 2 000999999999
Thailand Baht Thailand 764 2 000999999999
Tongan Pa’anga Tonga 776 2 000009999999
Trinidad and Tobago Dollar Trinidad and Tobago 780 2 000999999999
Tunisian Dinar Tunisia 788 3 000999999999
Turkish Lira Turkey 949 2 000999999999
U.A.E. Dirham United Arab Emirates 784 2 000999999999
U.S. Dollar American Samoa 840 2 000999999999
U.S. Dollar Bonaire 840 2 000999999999
U.S. Dollar British Indian Ocean Territory 840 2 000009999999
U.S. Dollar Croatia, Republic of 840 2 000999999999
U.S. Dollar Ecuador 840 2 000999999999
U.S. Dollar Guam 840 2 000999999999
U.S. Dollar Haiti 840 2 000999999999
U.S. Dollar Marshall Islands 840 2 000999999999
U.S. Dollar Micronesia, Federated States of 840 2 000999999999
U.S. Dollar Northern Mariana Islands 840 2 000999999999
U.S. Dollar Palau 840 2 000999999999
U.S. Dollar Panama 840 2 000999999999
U.S. Dollar Puerto Rico 840 2 000999999999
U.S. Dollar Saba 840 2 000999999999
U.S. Dollar St. Eustatius 840 2 000999999999
U.S. Dollar Timor-Leste 840 2 000009999999
U.S. Dollar Turks and Caicos Islands 840 2 000999999999
U.S. Dollar U.S. Minor Outlying Islands 840 2 000009999999
U.S. Dollar United States 840 2 000999999999
U.S. Dollar Virgin Islands, British 840 2 000999999999
U.S. Dollar Virgin Islands, U.S. 840 2 000999999999
Uganda Shilling Uganda 800 2 000009999999
Ukraine Hryvnia Ukraine 980 2 000999999999
Uzbekistan Som Uzbekistan 860 2 000009999999
Vanuatu Vatu Vanuatu 548 2 000999999999
Vietnamese Dong Vietnam 704 2 000999999999
Yemeni Rial Yemen 886 2 000009999999
Zambia Kwacha Zambia 894 2 2 000999999999
Zimbabwe Dollar Zimbabwe 716 2 000999999999
April 22, 2011 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 1ST
1 byte 2 2ND
1 byte 3 3RD
1 byte 4 4TH
1 byte 5 5TH
1 byte 6 6TH
1 byte 7 7TH
1 byte 8 8TH
1 byte 9 9TH
2 bytes 10 10TH
2 bytes 11 11TH
2 bytes 12 12TH
2 bytes 13 13TH
9.6.2 Spelled Numbers

Length of Code Street Code Definition
1 byte 1 FIRST
1 byte 2 SECOND
1 byte 3 THIRD
1 byte 4 FOURTH
1 byte 5 FIFTH
1 byte 6 SIXTH
1 byte 7 SEVENTH
1 byte 8 EIGHTH
1 byte 9 NINTH
2 bytes 10 TENTH
1 byte 1 ONE
1 byte 2 TWO
1 byte 3 THREE
1 byte 4 FOUR
1 byte 5 FIVE
1 byte 6 SIX
1 byte 7 SEVEN
1 byte 8 EIGHT
1 byte 9 NINE
2 bytes 10 TEN
202 POS020055 April 22, 2011

9.6.3 Street Abbreviations
Code Street Code Code Street Code

Length Code Definition Length Code Definition
1 byte # APT 3 bytes POB P_O_BOX
2 bytes AV AVE 3 bytes POB PO_BOX
2 bytes AV AVENUE 3 bytes POB PO_BX
3 bytes BCH BEACH 3 bytes POB POBOX
3 bytes BDG BRIDGE 3 bytes POB POBX
4 bytes BLVD BOULEVARD 2 bytes PT POINT
4 bytes BRCH BRANCH 2 bytes PT PORT
3 bytes BRK BROOK 2 bytes RD ROAD
2 bytes BY BAY 3 bytes RDG RIDGE
3 bytes CIR CIRCLE 3 bytes RIV RIVER
4 bytes CNYN CANYON 2 bytes RT R#
3 bytes CRK CREEK 2 bytes RT ROUTE
2 bytes CT COURT 2 bytes RT RR
3 bytes CTR CENTER 2 bytes RT RRT
2 bytes CV COVE 2 bytes RT RURAL ROUTE
2 bytes DL DALE 1 byte S SO
2 bytes DR DRIVE 1 byte S SOUTH
1 byte E EAST 2 bytes SE SOUTHEAST
3 bytes FLD FIELD 3 bytes SQR SQUARE
3 bytes FOR FOREST 2 bytes ST STREET
2 bytes FT FORT 2 bytes ST SUITE
3 bytes GRV GROVE 2 bytes SW SOUTHWEST
3 bytes HBR HARBOR 3 bytes VLG VILLAGE
2 bytes HL HILL 3 bytes VLY VALLEY
2 bytes HS HOUSE 1 byte W WEST
3 bytes HWY HIGHWAY 2 bytes WY WAY
2 bytes LD LAND
2 bytes LK LAKE
2 bytes LN LANE
2 bytes MT MOUNT
3 bytes MTN MOUNTAIN
1 byte N NO
1 byte N NORTH
2 bytes NE NORTHEAST
2 bytes NW NORTHWEST
2 bytes PK PARK
2 bytes PK PEAK
2 bytes PL PLACE
2 bytes PL PLAIN
3 bytes POB _BX
3 bytes POB BOX
April 22, 2011 POS020055 203

9.6.4 International Abbreviations

Change From To Change From To Change From To Change From To Change From To
ZERO 0 VIER 4 NEUNTER 9 CALZADA CALZ PREFEITO PREF
CERO 0 QUATRO 4 NOVE 9 CAMINO CAM PRESIDENTE PRES
NULL 0 CUATRO 4 NUEVE 9 CAP CP PRIVADA PRIV
PRIMO 1 QUINTO 5 NEUF 9 CAPITAO CP PRIVADO PRIV
PREMIER 1 CINQUIÈME 5 NEUN 9 CERRADA CDA PROF PRF
PREMIÈRE 1 QUINTO 5 NOVE 9 CIRCUITO CTO PROFESSOR PRF
PRIMER 1 FÜNFTER 5 DECIMO 10 COR CEL PROLONGACION PROL
PRIMER(O) 1 CINQUE 5 DIXIÈME 10 CORONEL CEL PUERTO PTO
ERSTER 1 CINCO 5 DÉCIMO 10 CZDA CALZ RETORNO RET
UNO 1 CINQ 5 ZEHNTER 10 DIAGONAL DIAG RINCON RCON
UNO 1 FÜNF 5 DIECI 10 DON DN RODOV ROD
UN 1 CINCO 5 DIEZ 10 DONA DNA RODOVIA ROD
EINS 1 SESTO 6 DIX 10 DOUTOR DR RUA R
UM 1 SIXIÈME 6 ZEHN 10 EDIFICIO EDIF SAN SN
UMA 1 SEXTO 6 ALAM AL ENGENHEIRO ENG SANTA STA
SECONDO 2 SECHSTER 6 ALAMEDA AL FILHO FIL SENHOR SHR
DEUXIÈME 2 SEI 6 ALLEE A FRANCISCO FCO SENHORA SHRA
SEGUNDO 2 SEIS 6 ALMIRANTE ALM FTES FNTE SIERRA SA
ZWEITER 2 SIX 6 AM A FUENTE FNTE STRASSE STR
DUE 2 SECHS 6 AMTE ALM FUENTES FNTE SUR S
DOS 2 SEIS 6 AN DEN AD GAL GEN VISC VIS
DEUX 2 SETTIMO 7 AN DER AD GENERAL GRAL VISCONDE VIS
ZWEI 2 SEPTIÈME 7 ANTINGUO ANT GENERAL GEN VOR DEN VD
DOIS 2 SÉPTIMO 7 AP APT GUILLERMO GMO VOR DER VD
DUAS 2 SIEBTER 7 APARTAMENTO APT HACIENDA HDA
TERZO 3 SETTE 7 APTO APT IN DEN ID
TROISIÈME 3 SIETE 7 AUF DEN AD IN DER ID
TERCER(O) 3 SEPT 7 AUF DER AD JARDIN JD
TERCER 3 SIEBEN 7 AVE AV MARECHAL MAL
DRITTER 3 SETE 7 AVENIDA AV MONTE MTE
TRE 3 OTTAVO 8 BARRANCA BCA NORTE N
TRES 3 HUITIÈME 8 BLOCO BL NOSSA NSA
TROIS 3 OCTAVO 8 BLV BLVD NOSSO NSO
DREI 3 ACHTER 8 BOSQUE BOSQ NTE N
TRES 3 OTTO 8 BOSQUES BOSQ ORIENTE OTE
QUARTO 4 OCHO 8 BQE BOSQ PARQUE PQE
QUATRIÈME 4 HUIT 8 BQUES BOSQ PIS P
CUARTO 4 ACHT 8 BRIG BRI PISO P
VIERTER 4 OITO 8 BRIGADEIRO BRI PLAZA PZA
QUATTRO 4 NONO 9 BSQUE BOSQ POSTFACH PF
CUATRO 4 NEUVIÈME 9 CALLE C PRACA PCA
QUATRE 4 NOVENO 9 CALLEJON CJON PRAIA PRA
204 POS020055 April 22, 2011

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.
April 22, 2011 POS020055 205

206 POS020055 April 22, 2011

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 ter-
minals. 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 Ameri-
can 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 trans-

action data from Merchants and transmits that data into authori-
zation/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.
April 22, 2011 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 pro-
cedure.
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, estab-
lished 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 authori-
zations and financial settlement.
Processing Flow The order of message exchanges between the terminal and the
Capture Host in a given situation.
208 POS020055 April 22, 2011

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 recon-
ciliation 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 ac-

cesses 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 prob-
lems 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.
April 22, 2011 POS020055 209

210 POS020055 April 22, 2011

11.0 EBCDIC & ASCII Code Translation Table
11.1 EBCDIC & ASCII Code Translation Table — Part A
Instruction Graphics and Controls 7-Track Tape Card Code

Dec. Hex (RR) BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
0 00 NUL NUL 12-0-1-8-9 0000 0000
1 01 SOH SOH 12-1-9 0000 0001
2 02 STX STX 12-2-9 0000 0010
3 03 ETX ETX 12-3-9 0000 0011
4 04 SPM PF EOT 12-4-9 0000 0100
5 05 BALR HT ENQ 12-5-9 0000 0101
6 06 BCTR LC ACK 12-6-9 0000 0110
7 07 BCR DEL BEL 12-7-9 0000 0111
8 08 SSK BS 12-8-9 0000 1000
9 09 ISK HT 12-1-8-9 0000 1001
10 0A SVC SMM LF 12-2-8-9 0000 1010
11 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
34 22 LTDR FS " 0-2-9 0010 0010
35 23 LCDR # 0-3-9 0010 0011
April 22, 2011 POS020055 211

11.1 EBCDIC & ASCII Code Translation Table — Part A

Dec. Hex (RR) BCDIC EBCDIC (1) ASCII 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
44 2C MDR , 0-4-8-9 0010 1100
45 2D DDR ENQ - 0-5-8-9 0010 1101
46 2E AWR ACK . 0-6-8-9 0010 1110
47 2F SWR BEL / 0-7-8-9 0010 1111
48 30 LPER 0 12-11-0-1-8-9 0011 0000
49 31 LNER 1 1-9 0011 0001
50 32 LTER SYN 2 2-9 0011 0010
51 33 LCER 3 3-9 0011 0011
52 34 HER PN 4 4-9 0011 0100
53 35 LRER RS 5 5-9 0011 0101
54 36 AXR UC 6 6-9 0011 0110
55 37 SXR EOT 7 7-9 0011 0111
56 38 LER 8 8-9 0011 1000
57 39 CER 9 1-8-9 0011 1001
58 3A AER : 2-8-9 0011 1010
59 3B SER CU3 ; 3-8-9 0011 1011
60 3C MER DC4 < 4-8-9 0011 1100
61 3D DER NAK = 5-8-9 0011 1101
62 3E AUR > 6-8-9 0011 1110
63 3F SUR SUB ? 7-8-9 0011 1111
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 DLE,X'70' DLE,0
ACK-1 DLE,X'61' DLE,1
WACK DLE,X'68' DLE,;
RVI DLE,X'7C' DLE,<
212 POS020055 April 22, 2011

11.2 EBCDIC & ASCII Code Translation Table — Part B

Dec. Hex (RX) BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
64 40 STH Sp Sp @ (3) no punches 0100 0000
65 41 LA A 12-0-1-9 0100 0001
66 42 STC B 12-0-2-9 0100 0010
67 43 IC C 12-0-3-9 0100 0011
68 44 EX D 12-0-4-9 0100 0100
69 45 BAL E 12-0-5-9 0100 0101
70 46 BCT F 12-0-6-9 0100 0110
71 47 BC G 12-0-7-9 0100 0111
72 48 LH H 12-0-8-9 0100 1000
73 49 CH I 12-1-8 0100 1001
74 4A AH ¢ ¢ J 12-2-8 0100 1010
75 4B SH . . . K B A 8 2 1 12-3-8 0100 1011
76 4C MH < < L B A 8 4 12-4-8 0100 1100
77 4D [ ( ( M B A 8 4 1 12-5-8 0100 1101
78 4E CVD < + + N B A 8 4 2 12-6-8 0100 1110
79 4F CVB | | O B A 8 4 2 1 12-7-8 0100 1111
80 50 ST & + & & P B A 12 0101 0000
81 51 Q 12-11-1-9 0101 0001
82 52 R 12-11-2-9 0101 0010
83 53 S 12-11-3-9 0101 0011
84 54 N T 12-11-4-9 0101 0100
85 55 CL U 12-11-5-9 0101 0101
86 56 O V 12-11-6-9 0101 0110
87 57 X W 12-11-7-9 0101 0111
88 58 L X 12-11-8-9 0101 1000
89 59 C Y 11-1-8 0101 1001
90 5A A ! ! Z 11-2-8 0101 1010
91 5B S $ $ $ [ B 8 2 1 11-3-8 0101 1011
92 5C M * * * \ B 8 4 11-4-8 0101 1100
93 5D D ] ) ) ] B 8 4 1 11-5-8 0101 1101
94 5E AL ; ; ; ¬ ^ B 8 4 2 11-6-8 0101 1110
95 5F SL Δ ¬ ¬ _ B 8 4 2 1 11-7-8 0101 1111
96 60 STD - - - ` B 11 0110 0000
97 61 / / / a A 1 0-1 0110 0001
98 62 b 11-0-2-9 0110 0010
99 63 c 11-0-3-9 0110 0011
April 22, 2011 POS020055 213

11.2 EBCDIC & ASCII Code Translation Table — Part B

Dec. Hex (RX) BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
100 64 d 11-0-4-9 0110 0100
101 65 e 11-0-5-9 0110 0101
102 66 f 11-0-6-9 0110 0110
103 67 MXD g 11-0-7-9 0110 0111
104 68 LD h 11-0-8-9 0110 1000
105 69 CD i 0-1-8 0110 1001
106 6A AD ¦ j 12-11 0110 1010
107 6B SD , , , k A 8 2 1 0-3-8 0110 1011
108 6C MD % ( % % l A 8 4 0-4-8 0110 1100
109 6D DD γ _ _ m A 8 4 1 0-5-8 0110 1101
110 6E AW \ > > n A 8 4 2 0-6-8 0110 1110
111 6F SW ? ? o A 8 4 2 1 0-7-8 0110 1111
112 70 STE p 12-11-0 0111 0000
113 71 q 12-11-0-1-9 0111 0001
114 72 r 12-11-0-2-9 0111 0010
115 73 s 12-11-0-3-9 0111 0011
116 74 t 12-11-0-4-9 0111 0100
117 75 u 12-11-0-5-9 0111 0101
118 76 v 12-11-0-6-9 0111 0110
119 77 w 12-11-0-7-9 0111 0111
120 78 LE x 12-11-0-8-9 0111 1000
121 79 CE y 1-8 0111 1001
122 7A AE Ъ : : z A 2-8 0111 1010
123 7B SE # = # # { 8 2 1 3-8 0111 1011
124 7C ME @ ' @ @ ¦ 8 4 4-8 0111 1100
125 7D DE : ' ' } 8 4 1 5-8 0111 1101
126 7E AU > = = ~ 8 4 2 6-8 0111 1110
127 7F SU √ " " DEL 8 4 2 1 7-8 0111 1111
214 POS020055 April 22, 2011

11.3 EBCDIC & ASCII Code Translation Table — Part C

Dec. Hex and Format BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
128 80 SSM -S 12-0-1-8 1000 0000
129 81 a a 12-0-1 1000 0001
130 82 LPSW -S b b 12-0-2 1000 0010
131 83 Diagnose c c 12-0-3 1000 0011
132 84 WRD -S1 d d 12-0-4 1000 0100
133 85 RDD -S1 e e 12-0-5 1000 0101
134 86 BXH -RS f f 12-0-6 1000 0110
135 87 BXLE -RS g g 12-0-7 1000 0111
136 88 SRL -RS h h 12-0-8 1000 1000
137 89 SLL -RS i i 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 j j 12-11-1 1001 0001
146 92 MVI -S1 k k 12-11-2 1001 0010
147 93 TS -S l l 12-11-3 1001 0011
148 94 NI -S1 m m 12-11-4 1001 0100
149 95 CLI -S1 n n 12-11-5 1001 0101
150 96 OI -S1 o o 12-11-6 1001 0110
151 97 XI -S1 p p 12-11-7 1001 0111
152 98 LM -RS q q 12-11-8 1001 1000
153 99 r r 12-11-9 1001 1001
154 9A 12-11-2-8 1001 1010
155 9B } 12-11-3-8 1001 1011
156 9C SIO, SIOF -S 12-11-4-8 1001 1100
157 9D TIO, CLRIO -S ) 12-11-5-8 1001 1101
158 9E HIO, HDV -S ± 12-11-6-8 1001 1110
159 9F TCH -S ▄ 12-11-7-8 1001 1111
160 A0 - 11-0-1-8 1010 0000
161 A1 ~ ° 11-0-1 1010 0001
162 A2 s s 11-0-2 1010 0010
163 A3 t t 11-0-3 1010 0011
April 22, 2011 POS020055 215

11.3 EBCDIC & ASCII Code Translation Table — Part C

Dec. Hex and Format BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
164 A4 u u 11-0-4 1010 0100
165 A5 v v 11-0-5 1010 0101
166 A6 w w 11-0-6 1010 0110
167 A7 x x 11-0-7 1010 0111
168 A8 y y 11-0-8 1010 1000
169 A9 z z 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
176 B0 0
12-11-0-1-8 1011 0000
177 B1 LRA -RX 1
12-11-0-1 1011 0001
178 B2 See below 2
12-11-0-2 1011 0010
179 B3 3
12-11-0-3 1011 0011
180 B4 4
12-11-0-4 1011 0100
181 B5 5
12-11-0-5 1011 0101
182 B6 STCTL -RS 6
12-11-0-6 1011 0110
183 B7 LCTL -RS 7
12-11-0-7 1011 0111
184 B8 8
12-11-0-8 1011 1000
185 B9 9
12-11-0-9 1011 1001
186 BA CS -RS 12-11-0-2-8 1011 1010
187 BB CDS -RS ┘ 12-11-0-3-8 1011 1011
188 BC ┐ 12-11-0-4-8 1011 1100
189 BD CLM -RS ] 12-11-0-5-8 1011 1101
190 BE STCM -RS ≠ 12-11-0-6-8 1011 1110
191 BF ICM -RS - 12-11-0-7-8 1011 1111
Notes (for Part C):
Op code (S format)
B202 – STIDP B207 – STCKC B20D – PTLB
B203 – STIDC B208 – SPT B210 – SPX
B204 – SCK B209 – STPT B211 – STPX
B205 – STCK B20A – SPKA B212 – STAP
B206 – SCKC B20B – IPK B213 – RRB
216 POS020055 April 22, 2011

11.4 EBCDIC & ASCII Code Translation Table — Part D

Dec. Hex (SS) BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
192 C0 ? { B A 8 2 12-0 1100 0000
193 C1 A A A B A 1 12-1 1100 0001
194 C2 B B B B A 2 12-2 1100 0010
195 C3 C C C B A 2 1 12-3 1100 0011
196 C4 D D D B A 4 12-4 1100 0100
197 C5 E E E B A 4 1 12-5 1100 0101
198 C6 F F F B A 4 2 12-6 1100 0110
199 C7 G G G B A 4 2 1 12-7 1100 0111
200 C8 H H H B A 8 12-8 1100 1000
201 C9 I I I B A 8 1 12-9 1100 1001
202 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 t 12-0-6-8-9 1100 1110
207 CF 12-0-7-8-9 1100 1111
208 D0 ! } B 8 2 11-0 1101 0000
209 D1 MVN J J J B 1 11-1 1101 0001
210 D2 MVC K K K B 2 11-2 1101 0010
211 D3 MVZ L L L B 2 1 11-3 1101 0011
212 D4 NC M M M B 4 11-4 1101 0100
213 D5 CLC N N N B 4 1 11-5 1101 0101
214 D6 OC O O O B 4 2 11-6 1101 0110
215 D7 XC P P P B 4 2 1 11-7 1101 0111
216 D8 Q Q Q B 8 11-8 1101 1000
217 D9 R R R B 8 1 11-9 1101 1001
218 DA 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 12-11-7-8-9 1101 1111
224 E0 ‡ \ A 8 2 0-2-8 1110 0000
225 E1 11-0-1-9 1110 0001
226 E2 S S S A 2 0-2 1110 0010
227 E3 T T T A 2 1 0-3 1110 0011
April 22, 2011 POS020055 217

11.4 EBCDIC & ASCII Code Translation Table — Part D

Dec. Hex (SS) BCDIC EBCDIC (1) ASCII BCDIC (2) EBCDIC Binary
228 E4 U U U A 4 0-4 1110 0100
229 E5 V V V A 4 1 0-5 1110 0101
230 E6 W W W A 4 2 0-6 1110 0110
231 E7 X X X A 4 2 1 0-7 1110 0111
232 E8 Y Y Y A 8 0-8 1110 1000
233 E9 Z Z Z A 8 1 0-9 1110 1001
234 EA 11-0-2-8-9 1110 1010
235 EB 11-0-3-8-9 1110 1011
236 EC s 11-0-4-8-9 1110 1100
237 ED 11-0-5-8-9 1110 1101
238 EE 11-0-6-8-9 1110 1110
239 EF 11-0-7-8-9 1110 1111
240 F0 SRP 0 0 0 8 2 0 1111 0000
241 F1 MVO 1 1 1 1 1 1111 0001
242 F2 PACK 2 2 2 2 2 1111 0010
243 F3 UNPK 3 3 3 2 1 3 1111 0011
244 F4 4 4 4 4 4 1111 0100
245 F5 5 5 5 4 1 5 1111 0101
246 F6 6 6 6 4 2 6 1111 0110
247 F7 7 7 7 4 2 1 7 1111 0111
248 F8 ZAP 8 8 8 8 8 1111 1000
249 F9 CP 9 9 9 8 1 9 1111 1001
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 Space 1 line
0 Space 2 lines
– Space 3 lines
+ Suppress space
1 Skip to line 1 on new page
218 POS020055 April 22, 2011


Amex WS PIP Terminal Interface Spec ISO Apr2011 PDF

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Amex WS PIP Terminal Interface Spec ISO Apr2011 PDF

Transféré par

Droits d'auteur :

Formats disponibles

PLURAL INTERFACE PROCESSING (PIP)

TERMINAL INTERFACE SPECIFICATION

GLOBAL MERCHANT SERVICES

Version Date | Content Owner | Prepared By | Description

3.2 04/22/11 | J. Cheney | R. Wong | See Below

April 22, 2011 POS020055 i

Version Date | Content Owner | Prepared By | Description

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

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

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

ii POS020055 April 22, 2011

Version Date | Content Owner | Prepared By | Description

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

April 22, 2011 POS020055 iii

Version Date | Content Owner | Prepared By | Description

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

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

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

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

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

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

iv POS020055 April 22, 2011

Version Date | Content Owner | Prepared By | Description

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

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

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

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

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

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

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

April 22, 2011 POS020055 v

This page is intentionally left blank.

vi POS020055 April 22, 2011

April 22, 2011 POS020055 vii

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

viii POS020055 April 22, 2011

7.0 PIP Terminal Interface Data Fields .................................................................................. 51

April 22, 2011 POS020055 ix

9.0 Appendix............................................................................................................................ 151

x POS020055 April 22, 2011

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

11.0 EBCDIC & ASCII Code Translation Table

April 22, 2011 POS020055 xi

• 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

• International Standard ISO/IEC 7813, Identification Cards — Financial Transaction Cards

xii POS020055 April 22, 2011

1.0 Introduction to Credit Authorization

1.2 Shadow File Processing

Retail minimum transaction set:

Restaurant minimum transaction set:

April 22, 2011 POS020055 1

1.3 Industry-Specific Special Processing

1.3.1 Lodging Processing