Яяяяяя Amex Pip-Iso Oct2010

GLOBAL MERCHANT SERVICES POS020055, v3.1, October 22, 2010

PLURAL INTERFACE PROCESSING (PIP) TERMINAL INTERFACE SPECIFICATION (ISO 8583 FORMAT) — OCTOBER 2010

Copyright © 2006-2010 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 | C ntent Ow r | Prepared By | Description o ne

3.1 10/22/10 | J. Cheney | R. Wong | See Below • Added new cover and modified format of Revision Log. • Page 63: Added paragraph beginning “American Express limits the maximum value that can be approved in

this field”. • Page 77: Changed last five digits in Expresspay Pseudo-Magnetic Stripe example from “00200” to “12345”. • Page 92: In ISO 7813 Format explanatory text, changed VLI from “60” to “76” bytes, changed total length

from “61” to “77” and appended “6789012345678901” (16 bytes) to end of example in diagram. • Page 93: Changed Expresspay Pseudo-Magnetic Stripe Format example, relative positions 40-44 from

“~~012” to “12345”. • Page 153, ISO 7813 Standard, Track 1: Changed Discretionary Data from 5 to 21 bytes, and deleted Unused

subfield, which was 16 bytes. Total (length) unchanged. • Pages 155-168: Appended “6789012345678901” (16 bytes) to end of sample data in diagrams. • Pages 162, 174: Changed text, as indicated, “Currently, American Express has no definite plans to require

USA does not expect Merchants to interrogate…” • Page 166: Changed Length of Field from “5 bytes” to “5 bytes – ANSI X4.16” and “21 bytes – ISO 7813”.

Also changed ISO 7813 Approximate Position from “57-61” to “57-77”. • Page 167: Changed ISO 7813 Approximate Position from “62” to “78”. • Page 168: Changed ISO 7813 Approximate Position from “63” to “79”. • Page 169: Deleted references to ISO 7813 (3 places), added “Note: This field applies only to ANSI X4.16

Standard Track 1 and is not applicable to ISO 7813” and deleted diagram containing sample data. • Pages 183-184: Revised Expresspay Pseudo-Magnetic Stripe Formats explanatory text and Track 1 & Track 2

Subfields, as follows: Changed “ATC” to “Application Transaction Counter (ATC)”. Changed Track 1, 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.

• Pages 196-201: Added Notes 3 and 4, inserted Maximum Value column in Currency Code tables and added “000999999999” for approved countries.

• Page 197: Added Congolese Franc to Currency Code Table.

3.0 04/23/10 | J. Cheney | R. Wong | See Below • 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 Tabl : d currency name from Lilangeni to Emalengeni. e Changed Swazilan

3.0 Advance

Copy

10/26/09 | J. Cheney | R. Wong | See Below • Pages 5, 96 & 102: Deleted references to third party processors and/or added “terminal and software vendors”• Pages 4-5: Added section entitled Prepaid Card Partial Auth & Auth with Balance Return. • Pages 50, 55, 94-102 & 131-134: Added Field 47 to support Keyed CID and Prepaid Card functions. • Page 61: For MTI=0100 and 0200, added code “31 40 0X” and footnote. • Page 64: Added explanation entitled Balance Inquiry – Prepaid Cards Only. • Page 81: Added Response Code “06”. • Pages 86-89, Field 44: Added Field Requirement “C1 = Mandatory – Amex Keyed CID program & GAN auth

response messages only. Optional – Travelers Cheque”. Also, expanded Response Source Code and added CID Response Code descriptions, and added examples.

• Pages 94-102 & 131-135: Added Field 47.

October 22, 2010 POS020055 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

ii POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties


Revision Log

Version Date | Content Owner | Prepared By | Description

• 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 eturn Proce s Flows. R s

2.8 10/01/09 | J. Cheney | R. Wong | See Below • 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 equirement from “C/C” to “M/M”. R

2.7 06/18/09 | J. Cheney | R. Wong | See Below • 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). • : 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


October 22, 2010 POS020055 iii This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties


Revision Log


4-bit nibbles. – Replaced “Example 1/2” text and diagrams with new “Sample Data”, which more accurately describes

proper field layout. • Page 74: Deleted stricken text: “The VLI must indicate the exact length of the Track 2 data actually

transmitted without padding.” Also, relocated notes 1 & 2 from the page that follows. • Pages 74, 90 & 150: Added references to “Expresspay Pseudo-Mag Stripe Formats…” • Pages 77 & 93 (Fields 35 & 45): Added Expresspay Pseudo-Mag Stripe Format descriptions and Sample Data.• Page 79: Combined Auth Code and Referral Queue Field Requirement tables, and revised/added notes C1, C2

and C3. • Page 80: Changed from “international” to “regional”, two places. • Page 86: Added paragraphs beginning “For an (MTI) 0220 request submitted to void an Off-Line Sale

transaction…” thru end of Field 44 Description, including Sample Data. • Page 90: Relocated notes 1 & 2 from a page that follows. • Page 105: Changed all Field Requirements from “C1” to “M” and deleted Note C1. • Page 108: Deleted stricken text: “…(USA ZIP or international Postal code)…” • Pages 108-129, Private Use Data Fields 60-63: Extensively revised/expanded detailed descriptions and 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 e -218: Add d EBCDIC & ASCII Code Translation Table.

2.6 11/26/07 | J. Cheney | R. Wong | See Below • 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 “00 08 31 31 32 32 33 33 34: Changed Example 2 from 34” to “… 20 20”.

2.5 09/25/07 | J. Cheney | R. Wong | See Below • Pages 114 & 116: In both Fields 61 and 62, deleted Field Requirements “C1” and “C3”; changed from “C2” and

“C4” to “C”; deleted Cx = Optional; and added Auth and Auth Void to N/A. • Pages 131 & 140: Deleted Bits 61 and 62. • Page 139, Bits 61 & 62: Changed Auth Void from “O” to “–”. • Page 141, Bits 61 & 62: Changed Auth and Auth Void from “O” to “–”. • Pages 153-182: Corrected subfield names, lengths, positions and diagrams in Magnetic Stripe Formats section,

in Appendix. • Pages 75 & 91-92: Corrected magnetic stripe sample data used in examples.

2.4 07/16/07 | J. Cheney | R. Wong | See Below • 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.


iv POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties


Revision Log

Version Date | Content Ow r | Prep By | Description ne ared

2.3 06/28/07 | J. Cheney | R. Wong | See Below • Page 79: For Authorization Code ed from “0220=M” to “…=C1” and added Note C1. , chang

2.3 06/15/07 | J. Cheney | R. Wong | See Below • 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. • 3: Added Note 2 “For Void transactions…” • Page 65: Added Note 2 “This field is…” • Page 68: Changed from “0220=C” to “…=C2”, from “0320=C” to “…=C3”, added Notes C2 and C3, and

added paragraph beginning “Note for C2 & C3: Date, Expiration must be submitted…” • Pages 74 & 90: Changed from “0320=C” to “0320 = — ”. • Page 78: Changed from “0230=M” to “…=C2” and added Note C2. • Page 86: Note C1, added “Mandatory - Voids of Off-Line Sale…” and deleted “N/A - Off-Line Sale, Debit

Adjust/Void and Credit Adjust/Void”. Also, deleted “For 220 requests, this field contains a code that indicates the source of the 0210 response that generated the 0220 message”; and changed from “06=Off-line approval” to “sale”.

• Page 103: Deleted stricken text “Special certification is required, and use in specific messages (as determined by Message Type Identifier) varies by merchant”.

• Pages 152-181: Updated Mag Stripe Formats.

2.2 04/23/07 | J. Cheney | R. Wong | See Below • Page 15: In note, deleted “Purchasing Card”. • Pages 118 o, 123-126: F r Lodging & Auto Rental, deleted 0200 & 0220 references to Bit 63 (unused).

2.1 04/05/07 | J. Cheney | R. Wong | See Below • 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 f Data Field/ Message Usage Tables to improve readability. o

2.0 03/28/07 | J. Cheney | R. Wong | See Below • Global modifications: Converted all field descriptions and examples from ASCII to BCD and hexadecimal.

Also, made the following additional changes: • Page 53: Added new subsections explaining BCD and hexadecimal formats. • Page 74-75 & 91: Changed sample data to match examples in Amex Mag Stripe Formats section and corrected

field formats for Track 1 & 2 data. • Page 84: Added backslash as subfield separator. • Page 103: Added (previously omitted) Data Type Definition Code. • Page 151: Added Amex Card examples that show CID/4DBC/4CSC locations.

1.4 01/31/07 | J. Cheney | R. Wong | See Below • 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.”


October 22, 2010 POS020055 v This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties


Revision Log


• Page 103: Changed requirement for 0100, 0200 & 0220 from “–” to “C1”; and added sentence beginning “C1 = Cond. – Merchants transmitting…”.

• Page 108: Changed requirement for 0220 from “–” to “O”, and 0230 from “–” to “C1”. Changed “For MTI=0100 & 0200” to “…0100, 0200 & 0220”.

• Page 109: Changed from “For MTI=0110 & 0210” to “…0110, 0210 & 0230”, and “Example of 0110 & 0210” to “…0110, 0210 & 0230”; and added above changes to Message Usage Table.

1.3 11/15/06 | J. Cheney | R. Wong | See Below • Pages 118-126 & Message Usage Table: Changed requirement for 0220 from “–” to “C”; changed all

references from “0200 & 0320” to “0200, 0220 & 0320”; updated 0220 entries for Bit 63 in summary table.

1.2 08/28/06 | J. Cheney | R. Wong | See Below • Page 11: Deleted introductory paragraph beginning “The American Express PIP Interface uses two…” • Pages 12-13: Added “Important Note” and expanded explanation of ISO 8583 messages. • Pages 61-62: Added descriptions for MTI 0200, 0220, 0320 & 0500, inadvertently omitted in previous

releases. • Page 110: Added code “R=AVS Unavailable” and “Note: The AVS response (which is used to help validate

the identity of the Cardholder)…” • Pages 118-126 & Message Usage Table: Added Field 63 Requirement for MTI 0200 = “C2”, changed each

instance of MTI “0320” to “0200 and 0320” (eight places), and updated Data Field/Message Usage Table.

1.1 08/07/06 | J. Cheney | R. Wong | See Below • Pages 108-110: Add d AVS requirements to 0100/0200 & 0110/0210 messages. e

1.0 05/05/06 | J. Cheney | R. Wong | See Below • Initial release. Created by removing XML references from POS020050, v1.0 and adding ISO 8583

information from POS010005, v5.4.


This page is intentionally left blank.

vi POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



Table of Contents

Preface .................................................................................................................................................. xi

Organization .......................................................................................................................................... xi

Related Documents ............................................................................................................................... xii

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

1.1 Overview ................................................................................................................................ 1

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

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

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

1.5 Prepaid Card Partial Authorization & Authorization with Balance Return ........................... 4

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

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

1.6 Expresspay ............................................................................................................................. 6

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

2.1 Overview ................................................................................................................................ 7

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

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

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

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

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

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

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

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

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

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

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

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

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

4.1 Authorizations — Normal Processing.................................................................................. 26

4.2 Authorizations — Reversal Processing ................................................................................ 26

4.3 Financial Transactions — Normal Processing ..................................................................... 27

4.4 Financial Transactions — Referral Processing .................................................................... 28

October 22, 2010 POS020055 vii This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



Table of Contents

4.5 Financial Transactions — Advice Processing (Normal) ...................................................... 29

4.6 Financial Transactions — Advice Processing (Time-Out) ................................................... 30

4.7 Financial Transactions — Reversal Processing .................................................................... 31

4.8 File Updates — Time-Out Processing .................................................................................. 33

4.9 Reconciliation Messages ...................................................................................................... 33

4.10 Reconciliation Time-Out Processing .................................................................................... 33

4.11 Close Batch — Normal Processing ...................................................................................... 33

4.12 Close Batch — Error Processing .......................................................................................... 34

5.0 Stand-In Process Flow Diagrams (GAN) .......................................................................... 35

5.1 Authorizations — GAN Normal Processing ........................................................................ 36

5.2 Authorizations — GAN Reversal Processing ....................................................................... 37

5.3 Financial Transactions — GAN Normal Processing ............................................................ 39

5.4 Financial Transactions — GAN Referral Processing ........................................................... 40

5.5 Financial Transactions — GAN Advice Processing (Normal) ............................................. 41

5.6 Financial Transactions — GAN Advice Processing (Time-Out) ......................................... 42

5.7 Financial Transactions — GAN Reversal Processing .......................................................... 43

5.8 Other Message Formats ........................................................................................................ 45

6.0 ISO 8583 Message Formats ................................................................................................ 47

6.1 Guidelines for Using the ISO 8583 Format .......................................................................... 47

6.2 Variations from ISO 8583 .................................................................................................... 48

6.3 ISO 8583 Message Bit Map Table ........................................................................................ 48

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

7.1 Data Field Descriptions ........................................................................................................ 52

7.2 Data Field/Message Usage Tables ...................................................................................... 130

7.2.1 0100 — Authorization Request .......................................................................................... 131

7.2.2 0110 — Authorization Response ........................................................................................ 132

7.2.3 0200 — Financial Transaction Request (Auth & Capture) ................................................. 133

7.2.4 0210 — Financial Transaction Response ........................................................................... 134

7.2.5 0220 — Financial Transaction Advice Request (Capture) ................................................. 135

7.2.6 0230 — Financial Transaction Advice Response ............................................................... 136

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

viii POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



Table of Contents

7.2.8 0330 — Transaction Upload Advice Response .................................................................. 138

7.2.9 0400 — Reversal Request .................................................................................................. 139

7.2.10 0410 — Reversal Response ............................................................................................... 140

7.2.11 0420 — Reversal Advice Request ...................................................................................... 141

7.2.12 0430 — Reversal Advice Response ................................................................................... 142

7.2.13 0500 — Reconciliation Request ......................................................................................... 143

7.2.14 0510 — Reconciliation Response ...................................................................................... 144

8.0 Edit Tests on Data Input .................................................................................................. 145

8.1 Cardmember Account Number Check Digit Computation* ............................................... 146

8.2 Expiration Date Edit Test ................................................................................................... 148

8.3 Transaction Amount Edit Test ........................................................................................... 148

8.4 ROC Number Edit Test ...................................................................................................... 148

8.5 SOC Number Edit Test ...................................................................................................... 149

8.6 Batch Number Edit Test ..................................................................................................... 149

8.7 Total Amount Edit Test ...................................................................................................... 149

8.8 Business Date Edit Test ..................................................................................................... 149

8.9 Tip or Tax Information Edit Test ....................................................................................... 150

8.10 Track 1 or Track 2 Data ..................................................................................................... 150

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

9.1 American Express Cards — Typical Examples ................................................................. 151

9.2 American Express Magnetic Stripe Formats ...................................................................... 152

9.2.1 ANSI X4.16 Standard ........................................................................................................ 153

9.2.2 ISO 7813 Standard ............................................................................................................. 153

9.2.3 New Definitions and Values ............................................................................................... 154

9.2.4 ANSI X4.16 / ISO 7813Track 1 Message Formats ............................................................ 155

9.2.5 ANSI X4.16 / ISO 7813Track 2 Message Formats ............................................................ 170

9.3 Expresspay Pseudo-Magnetic Stripe Formats .................................................................... 183

9.4 Typical Prepaid Card Partial Authorization & Authorization with Balance Return Process Flows ..................................................................................................................... 185

9.4.1 Partial Authorization Scenarios .......................................................................................... 186

9.4.2 Authorization with Balance Return Scenarios ................................................................... 191

October 22, 2010 POS020055 ix This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



Table of Contents

9.5 Currency Codes .................................................................................................................. 196

9.6 Street Codes ........................................................................................................................ 202

9.7 ISO Account Number Ranges ............................................................................................ 205

10.0 Glossary ............................................................................................................................. 207

11.0 EBCDIC & ASCII Code Translation Table .................................................................... 211

x POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



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

October 22, 2010 POS020055 xi This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



xii POS020055 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties


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


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

October 22, 2010 POS020055 1 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



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 October 22, 2010 This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties



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.




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




1.5.2 Authorization with Balance Return

As an alternative to the Partial Authorization program, American Express offers the Authorization with Balance Return program.

The Authorization with Balance Return program allows Merchants that choose not to use the Partial Authorization Program to receive the Prepaid Card balance on the 0110or 0210 response message. Field 47 (Additional Data - National) of the 0100 or 0200 message is used to identify an 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.




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.




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.




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.




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.




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.




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




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.




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: 0 2 0 0 3 0 2 0 0 5 8 0 2 0 C 8 8 0 0 0Position: 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.




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.




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.




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.




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.




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.





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





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.





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.





• Reversal Request (0400)

– Authorization – Travelers Cheque Approval – Authorization Void – Sale

• Reversal Response (0410)

– Authorization – Travelers Cheque Approval – Authorization Void – Sale – Refund

• Reversal Advice Request (0420)


• Reversal Advice Response (0430)







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




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)




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




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

Authorization Request (0100) Time-Out Disconnect

Transaction Initiated (Card Swipe)

Reversal Request (0400)

Reversal Response (0410) Disconnect






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

Authorization Request (0100) Time-Out Disconnect

Reversal Request (0400) Time-Out 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




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




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

Financial Transaction Advice Request (0220)-1 ] (See note below) Financial Transaction Request (0200)

Financial Transaction Request (0200) Authorized and Captured at Host

Approved Financial Transaction

Response (0210) Disconnect


Approved Financial Transaction 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.




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

Financial Transaction Request (0200)

Financial Transaction Response (0210) Disconnect

Financial Transaction Advice Request (0220) Time-Out Disconnect



Financial Transaction Advice Request (0220)





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

Financial Transaction Request (0200) Authorized and Captured at Host Time-Out Disconnect









4.7.2 Reversal Processing — Scenario B

Terminal Host

Financial Transaction Request (0200) Authorized and Captured at Host Time-Out


Transaction initiated (Card Swipe)





4.7.3 Reversal Processing — Scenario C

Terminal Host

Financial Transaction Request (0200) Time-Out












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




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




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




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




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

Authorization Request (0100) Time-Out

Reversal Request (0400) Capture Host Unavailable

Terminal stores as Reversal Advice Request (0420) Reversal Response (0410)

from GAN Disconnect


Authorization Response (0110) from Capture Host

Disconnect Reversal Advice Request (0420)

Reversal Advice Response (0430) from Capture Host

Disconnect




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

Authorization Request (0100) Time-Out


Transaction initiated at terminal (e.g. card swipe)

Authorization Request (0100) Capture Host Unavailable

Authorization Response (0110) from GAN

Disconnect




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.

When the terminal subsequently receives a response from the Capture Host containing code “01” in 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 Advice Request (0220)

Message with GAN Indicator Financial Transaction Response (0210)

from GAN

Disconnect Financial Transaction Request (0200) Authorized and Captured at Host







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


Financial Transaction Response (0210) 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







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)-1 ] Note: See pages 29 and 30 for more information on Advice Message processing. Financial Transaction Advice Request (0220)-2


Stored by Terminal as

Financial Transaction Advice Request Message (0220)-3 with GAN Indicator

Financial Transaction Response (0210)

from GAN

Disconnect Financial Transaction Request (0200) Authorized and Captured by Capture Host





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.




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

(See note below) Financial Transaction Advice Request (0220)-1

Financial Transaction Request (0200) Authorized and Captured by Capture Host Approved Financial Transaction


Financial Transaction Advice Request (0220)-1 Time-Out Disconnect



Advice messages cannot be processed by GAN. Terminal continues to store message (0220)-1

until Capture Host is available.

Financial Transaction Response (0210) from GAN

Disconnect Transaction initiated at terminal

(e.g. card swipe)

Financial Transaction Request (0200) Authorized and Captured by Capture Host Financial Transaction Response (0210)

from Capture Host Disconnect


Financial Transaction Advice Response (0230) from Capture Host

Disconnect

Note: See pages 29 and 30 for more information on Advice Message processing.




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.

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.

5.7.1 GAN Reversal Processing — Scenario A

Terminal Host

Financial Transaction Request (0200) Authorized and Captured at Host Time-Out Disconnect




from GAN Disconnect

Financial Transaction Request (0200) Authorized and Captured by Capture Host

Financial Transaction Response (0210) from Capture Host

Disconnect Reversal Advice Request (0420)

with GAN Indicator


Disconnect




5.7.2 GAN Reversal Processing — Scenario B

Terminal Host

Financial Transaction Request (0200) Authorized and Captured at Host Time-Out


Transaction initiated (card swipe)



from GAN Disconnect


Terminal stores as Financial Advice Request (0220) with GAN Indicator Financial Transaction Response (0210)

from GAN Disconnect

Financial Transaction Request (0200) Authorized and Captured by Capture Host Financial Transaction Response (0210)

from Capture Host Disconnect

Reversal Advice Request (0420) with GAN Indicator


Disconnect




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.




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.




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.




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






6.3.1 Primary Bit Map

Data Field

Data Element Name

Max. Field Length

Note: For Field Type, A = Alpha, N = Numeric, S = Special characters, B = Binary, BCD = Binary Coded Decimal

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 61 PRIVATE - RESERVED 10 bytes, LLLVAR ANS 62 PRIVATE - RESERVED 8 bytes, LLLVAR ANS 63 PRIVATE - RESERVED 42 bytes, LLLVAR ANS 64 MESSAGE AUTHENTICATION CODE (MAC) FIELD 8 bytes, 64 bits B


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.




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.




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.





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.





Data Fields in This Section: Bit Field Name Page – Message Type Identifier 56 – Bit Map - Primary 57

59 2 Primary Account Number (PAN) 3 Processing Code 61 4 Amount, Transaction 63 11 Systems Trace Audit Number 65 12 Time, Local Transaction 66

67 13 Date, Local Transaction 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 61 Private Use Data 114

116 62 Private Use Data 63 Private Use Data 118






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





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


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.





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





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


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.





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

Sample Data Comments VLI (2 digits) 15

PAN (15 digits) 371449635311004

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.







Data Field 3 Processing Code


Field Type: Numeric



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.



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.





Data Field 4 Amount, Transaction

Length of Field: 6 bytes, fixed (see USD transaction limit, below)

Field Type: Numeric, right justified, zero filled


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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 Express representative.

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 value that can be approved in this field. While most entries must not exceed “00 00 09 99 99 99”, some locations may submit transaction amounts in specific currencies up to “00 09 99 99 99 99”. However, please note that a transaction amount greater than the maximum allowed will result in an “invalid amount” edit error. For more information on maximum values, see Currency Codes on page 196.





Data Field 4 Amount, Transaction (Continued)

Balance Inquiry — Prepaid Cards Only

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

• Balance inquiries can only be processed for American Express Prepaid Cards. For all other American Express Card products, Field 54 is not returned and Response Code “58” (Invalid Service) is returned in Field 39.

• Amount, Transaction (this field) must be zero. Otherwise, Response Code “30” (Edit error - message format) is returned in Field 39.

Note: Balance Inquiry is only available via the Web Services IP Payments Gateway using a high-speed Internet connection.





Data Field 11 Systems Trace Audit Number


Field Type: Numeric



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.





Data Field 12 Time, Local Transaction


Field Type: Numeric, hh mm ss


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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





Data Field 13 Date, Local Transaction


Field Type: Numeric, MM DD


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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.

Subfield Definition Digits Range MM Month 2 01-12 DD Day 2 01-31





Data Field 14 Date, Expiration


Field Type: Numeric, YY MM


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.

Subfield Definition Digits Range 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.





Data Field 15 Date, Settlement


Field Type: Numeric, MM DD


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — — — — — — — —

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.

Subfield Definition Digits Range 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.





Data Field 22 Point of Service Entry Mode


Field Type: Numeric


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.





Data Field 22 Point of Service Entry Mode (Continued)

Note: Codes shown in -reversed text- (white letters on a black background) are defined by ISO, but are either reserved for future use or not currently defined by American Express. For information on these codes, please contact your American Express representative.

Pos.

1 & 2 Code

Card Data Input Capability — This subfield indicates the maximum capability of the device used to originate this transaction.

00 Unspecified 01 Manual 02 Magnetic stripe 03 Bar code 04 Optical Character Recognition (OCR) 05 Integrated Circuit Card (ICC) 06-60 Reserved

Pos. 3

Code Cardholder Authentication Capability — This subfield indicates the primary 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





Data Field 24 Network International Identifier (NII)


Field Type: Numeric



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” must be padded with a leading zero to create the even-length value “00 03”, and four digits of data are actually transmitted.





Data Field 25 Point of Service Condition Code

Length of Field: 1 byte, fixed

Field Type: Numeric



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





Data Field 35 Track 2 Data


Field Type: Alphanumeric (upper case) & special characters


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.





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.


ANSI X4.16 Track 2 Data (29 digits)

371449635311004D9403910112345

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.






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.


ISO 7813 Track 2 Data (37 digits)

371449635311004=940310191011234567800

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.






Expresspay Pseudo-Magnetic Stripe Format

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


Pseudo-Magnetic Stripe Track 2 Data (37 digits)

371449635311004=111270212342474312345

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.





Data Field 37 Retrieval Reference Number (RRN)


Field Type: Alphanumeric (upper case)


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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.





Data Field 38 Authorization Identification Response


Field Type: Alphanumeric, upper case, left justified, character space filled


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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.

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





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

Note: In the examples on this page, “N” is an alphanumeric character, and the tilde (~) represents a character space.





Data Field 39 Response Code


Field Type: Alphanumeric (upper case)


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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.

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 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 detail30 = Edit error - message format 96 = Misc. processing error 51 = Credit denied AA = Card capture type invalid





Data Field 41 Card Acceptor Terminal Identification





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.

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





Data Field 42 Card Acceptor Identification Code


Field Type: Alphanumeric (upper case) & special characters, left justified, character space filled


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.

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





Data Field 43 Card Acceptor Name/Location


Field Type: Alphanumeric (upper case) & special characters, left justified, character space filled


Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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 as eight bits per byte, with the value for any byte of data varying from hexadecimal “00” to hexadecimal “FF”.

See example on next page.





Data Field 43 Card Acceptor Name/Location (Continued)

Sample Data Comments Card Acceptor Name and/or Location (40 characters)

XYZ~STORE\1234~ABC~ST\PHX\AZ\USA\85054~~

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

Position Bytes Comments 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.





Data Field 44 Additional Response Data


Field Type: Alphanumeric

Field Format: Binary coded decimal (BCD) and hexadecimal

Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 — 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, 0330, 0410, 0430 and 0510 — Response Source Code

For all of these response messages, this field may contain a Response Source Code that indicates the origin of the response message (e.g., Capture Host, GAN, etc.).

Valid Response Source Codes include the following:

00 = Unspecified

01 = Capture Host-generated response

02 = GAN-generated response (for more information on the Global Authorization Network, see page 35)

06 = Off-Line Sale





Data Field 44 Additional Response Data (Continued)

For MTI = 0110 and 0210 — Keyed CID Program

For these response messages only, this field may contain a CID Response Code that indicates the disposition of the CID/4DBC/ 4CSC value forwarded in the corresponding request message. To receive a CID response in this field, a Merchant must be certified for the American Express Keyed CID Program, and Data Fields 47 and 48 must be populated per program 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.






Example — MTI = 0110, 0210, 0220, 0230, 0330, 0410, 0430 and 0510

Response Source Code Only

In the example below, the two-digit VLI is “02”, which is trans-mitted in binary coded decimal (BCD) format; and the digits that follow are the two-digit Response Source Code, which are shown 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.


Response Source Code (2 digits) 01

1 2 3

02 30 31


2-3 2 2-digit Response Source Code shown in hexadecimal format.






Example — MTI = 0110 and 0210

Keyed CID Program Only

In the example below, the two-digit VLI is “01”, which is trans-mitted in binary coded decimal (BCD) format; and the digit that follows is the one-character CID Response Code, which is shown in hexadecimal format.


CID Response Code (1 character) Y

1 2

01 59

Position Bytes Comments 1 1 2-digit VLI in binary coded decimal (BCD) format. 2 1 1-character CID Response Code shown in hexadecimal format.


Response Source Code and Keyed CID Program

In the example below, the two-digit VLI is “02”, which is trans-mitted in binary coded decimal (BCD) format; and the digits that follow are the two-digit Response Source Code and one-character CID Response Code, which are shown in hexadecimal format.


Response Source Code (2 digits) 01

CID Response Code (1 character) Y

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.





Data Field 45 Track 1 Data





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.






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.


ANSI X4.16 Track 1 Data (59 characters)

B3714~496353~11004^FROST/CHARLES~F.JR~~~~~~~~^9403910112345

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.






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.


ISO 7813 Track 1 Data (76 characters)

B371449635311004^FROST/CHARLES~F.JR~~~~~~~~^ 94031019101123456789012345678901

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.






Expresspay Pseudo-Magnetic Stripe Format

In the example below, the two-digit VLI is “60” and the digits that follow are the 60 bytes of Track 1 data shown in ExpresspayPseudo-Magnetic Stripe Format. The character “^” is used to depict the field separator. The total length (VLI plus variable data) is 61 bytes.


Pseudo-Magnetic Stripe Track 1 Data (60 characters)

B371449635311004^VALUED/CARDMEMBER~~~~12345^1211702123424743

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.





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 Length of Variable Data: 29 bytes maximum



Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.





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.






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 Program must use Data Fields 47 (Additional Data - National) and 48 (Additional Data - Private) in the Authorization (0100) or Financial Transaction (0200) Request Message (as applicable) to transport the CID Indicator and CID code (a.k.a., 4DBC or 4CSC). After processing, American Express returns the CID Response Code in Data Field 44 (Additional Response Data) of the corresponding Authorization (0110) or Financial Transaction (0210) 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.






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.






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.






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

• Balance inquiries can only be processed for American Express Prepaid Cards. For all other American Express Card products, Field 54 is not returned and Response Code “58” (Invalid Service) is returned in Field 39.

• Amount, Transaction (this field) must be zero. Otherwise, Response Code “30” (Edit error - message format) is returned in Field 39.

Note: Merchant certification is required to receive Balance Inquiry Responses.

Example — MTI = 0100 & 0200

CID Identifier Code Only

• The three-digit VLI is transmitted in binary coded decimal (BCD) format, and the odd length must be padded. Specifi-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.


CID Identifier Code (1 character) Y

1 2 3

00 04 59

Position Bytes Comments 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.






Example — MTI = 0100 & 0200

Prepaid Card Function Code Only


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


Prepaid Card Function Code (3 digits) 181

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.






Example — MTI = 0100 & 0200

CID Identifier Code and Prepaid Card Function Code

• The three-digit VLI is transmitted in binary coded decimal (BCD) format, and the odd length must be padded. Specific-ally, “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.

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


CID Identifier Code (1 character) Y

Prepaid Card Function Code (3 digits) 181

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.






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.


Prepaid Card Original Transaction Amount


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


Original Transaction Amount (12 digits) 000000010000

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.





Data Field 48 Additional Data - Private





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 Program must use Data Fields 47 (Additional Data - National) and 48 (Additional Data - Private) in the Authorization (0100) or Financial Transaction (0200) Request Message (as applicable) to transport the CID Indicator and CID code (a.k.a., 4DBC or 4CSC). After processing, American Express returns the CID Response Code in Data Field 44 (Additional Response Data) of the corresponding Authorization (0110) or Financial Transaction (0210) Response Message. For more information, see pages 86, 94 and 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 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.


Data Type Definition Code (1 digit) 4

CID/4DBC/4CSC (4 digits) 1234

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





Data Field 49 Currency Code, Transaction


Field Type: Numeric



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 Express representative.





Data Field 54 Additional Amounts




Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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).

Note: At this writing, only transactions in US Dollars and select 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.

Although this is a variable length field, the variable data is always 12 bytes. See example on next page.





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.


Additional Amount (12 digits) 000000000500

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.





Data Field 60 Private Use Data




Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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).

Although this is a variable length field, the variable data is always 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.





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.


Cardmember Billing Postal Code (9 characters) 85054~~~~

Cardmember Billing Address (20 characters) 18850~N~56~ST~PHOENI


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.






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.

Although this is a variable length field, the variable data is always one byte, which is explained below:


• The one-character AVS response code is shown in hexa-decimal format.


Data Type Definition Code (1 character) Y 1

2 3

00 01 59


leading zero. 3 1 1-character AVS response code in hexadecimal format.






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.






For MTI = 0320 & 420 (Continued)


0320 or 0420 Message Type Identifier (MTI) (4 digits) Systems Trace Audit Number (6 digits) 123456

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.






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

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


• The six-digit Batch Identification Number is right justified and zero filled, and shown in hexadecimal format.


Batch Identification Number (6 digits) 001234

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.









Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.

Although this is a variable length field, the variable data is always 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.







Item Descriptor Code #1 (2 digits) 11



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

Position Bytes Comments 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. 5-6 2 2-digit Item Descriptor Code #2 shown in hexadecimal format. 7-8 2 2-digit Item Descriptor Code #3 shown in hexadecimal format. 9-10 2 2-digit Item Descriptor Code #4 shown in hexadecimal format.









Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.

Although this is a variable length field, the variable data is always six bytes. See examples on next page.


• The six-digit Invoice Number is right justified and zero filled.







Invoice/ROC/SOC Number (6 digits) 001234

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.









Field Requirement: 0100 0110 0200 0210 0220 0230 0320 0330 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.






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”, must be padded with a leading zero to create the even-length value “00 40”, and four digits of data are actually transmitted.

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.


Table Identifier Code (2 digits) 07

Check Number (9 digits) 123456789

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.






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


• The two-digit Table Identifier Code, the constant literal “17” (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.






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



SE Reference (ROC/Invoice) Number (9 digits) 123456789

Customer Reference Number (9 digits) 123456789

Ship-To Postal Code (5 digits) 12345

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. 3-4 2 2-digit Table Identifier Code shown in hexadecimal format. 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.






For MTI = 0200, 0220 & 0320 Travel (Sign & Travel) Data Subfields


• The two-digit Table Identifier Code, the constant literal “18” (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.



Payment Method Code (2 digit) 1

Ticket Number (14 characters) 81AB1234567890

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

Position

Bytes Comments 1-2 2 3-digit VLI in binary coded decimal (BCD) format, padded with a

leading zero. 3-4 2 2-digit Table Identifier Code shown in hexadecimal format. 5 1 2-digit Payment Method Code shown in hexadecimal format.

6-19 14 14-character Ticket Number shown in hexadecimal format.






For MTI = 0320 Lodging Data Subfields


• The two-digit Table Identifier Code, the constant literal “10” (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.






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.




Folio Number (9 characters) 1234567AB

Reference Number (9 characters) AB1234567

Arrival Date (4 digits) 0611

Departure Date (4 digits) 0612

Room Rate (12 digits) 000000001000

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. 3-4 2 2-digit Table Identifier Code shown in hexadecimal format. 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.






For MTI = 0320 Auto Rental Data Subfields


• The two-digit Table Identifier Code, the constant literal “19” (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.






For MTI = 0320 Auto Rental Data Subfields (Continued)



Adjustment Indicator (1 character space) ~

Agreement Number (9 characters) 123456789

Rental Date (6 digits) 010106

Return Date (6 digits) 010206


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. 3-4 2 2-digit Table Identifier Code shown in hexadecimal format. 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.






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







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


Batch Debit Count (3 digits) 003

Batch Debit Amount (12 digits) 000000012345

Batch Credit Count (3 digits) 001

Batch Credit Amount (12 digits) 000000001234

Reserved subfield (6 zeros) 000000

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.






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.


Close Batch Response Text Line #1 (20 characters) AP~150000~~~~$100.00

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


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.




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




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

ISO

8583

Bit

Num

ber

Data Field Name Field Length Data Type Field Format 01

00 - A

uth

0100

- Tr

avele

rs C

hequ

e

0100

- Aut

h Vo

id

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.




7.2.2 0110 — Authorization Response


ISO

8583

Bit

Num

ber


10 - A

uth

0110

- Tr

avele

rs C

hequ

e

0110

- Aut

h Vo

id

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





7.2.3 0200 — Financial Transaction Request (Auth & Capture)


ISO

8583

Bit

Num

ber


00 -

Sale

Page – 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 62 Private Use Data 8 bytes, LLLVAR ANS BCD / H* M 116 63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* C 118





7.2.4 0210 — Financial Transaction Response


ISO

8583

Bit

Num

ber


10 -

Sale

Page – Message Type Identifier 2 bytes, fixed N BCD M 56 – Bit Map - Primary 8 bytes, 64 bits B H M 57 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 12 Time, Local Transaction 3 bytes, fixed N BCD M 66 13 Date, Local Transaction 2 bytes, fixed N BCD M 67 24 Network International Identifier (NII) 2 bytes, fixed N BCD M 72 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 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M 82 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





7.2.5 0220 — Financial Transaction Advice Request (Capture)


ISO

8583

Bit

Num

ber


20 -

Sale

Com

plet

ion

0220

- Of

f-Lin

e Sale

0220

- De

bit A

djus

tmen

t/Voi

d

0220

- Cr

edit A

djus

tmen

t/Voi

d

0220

- Of

f-Lin

e Ref

und

Page – 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





7.2.6 0230 — Financial Transaction Advice Response


ISO

8583

Bit

Num

ber


30 -

Sale

Com

plet

ion

0230

- Of

f-Lin

e Sale

0230

- De

bit A

djus

tmen

t/Voi

d

0230

- Cr

edit A

djus

tmen

t/Voi

d

0230

- Of

f-Lin

e Ref

und

Page – 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 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 O O O O O 66 13 Date, Local Transaction 2 bytes, fixed N BCD O O O O O 67 24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M M M 72 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 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M M M 82 44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O O O O O 86





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


ISO

8583

Bit

Num

ber


20 -

Debi

t Upl

oad

0320

- Cr

edit

Uplo

ad

Page – 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 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* C C 118





7.2.8 0330 — Transaction Upload Advice Response


ISO

8583

Bit

Num

ber


30 -

Debi

t Upl

oad

0330

- Cr

edit

Uplo

ad

Page – 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





7.2.9 0400 — Reversal Request


ISO

8583

Bit

Num

ber


00 - A

uth

0400

- Tr

avele

rs C

hequ

e

0400

- Aut

h Vo

id

0400

- Sa

le

0400

- Re

fund

Page – 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 C 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 14 Date, Expiration 2 bytes, fixed N BCD C – C C 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 C 74 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 45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C – C C C 90 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 – 106 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





7.2.10 0410 — Reversal Response


ISO

8583

Bit

Num

ber


10 - A

uth

0410

- Tr

avele

rs C

hequ

e

0410

- Aut

h Vo

id

0410

- Sa

le

0410

- Re

fund

Page – 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 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 24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M M M 72 37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M M M M 78 39 Response Code 2 bytes, fixed AN H M M M M M 81 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M M M 82 44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O O O O O 86





7.2.11 0420 — Reversal Advice Request


ISO

8583

Bit

Num

ber


20 - A

uth

0420

- Tr

avele

rs C

hequ

e

0420

- Aut

h Vo

id

0420

- Sa

le

0420

- Re

fund

Page – 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 C 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 14 Date, Expiration 2 bytes, fixed N BCD C – C C 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 C 74 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 45 Track 1 Data 77 bytes, LLVAR ANS BCD / H* C – C C C 90 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 – 106 60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* M – – M – 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





7.2.12 0430 — Reversal Advice Response


ISO

8583

Bit

Num

ber


30 - A

uth

0430

- Tr

avele

rs C

hequ

e

0430

- Aut

h Vo

id

0430

- Sa

le

0430

- Re

fund

Page – 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 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 24 Network International Identifier (NII) 2 bytes, fixed N BCD M M M M M 72 37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H M M M M M 78 39 Response Code 2 bytes, fixed AN H M M M M M 81 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M M M M M 82 44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O O O O O 86





7.2.13 0500 — Reconciliation Request


ISO

8583

Bit

Num

ber


00 -

Clos

e

Page – Message Type Identifier 2 bytes, fixed N BCD M 56 – Bit Map - Primary 8 bytes, 64 bits B H M 57 3 Processing Code 3 bytes, fixed N BCD M 61 11 Systems Trace Audit Number 3 bytes, fixed N BCD M 65 15 Date, Settlement 2 bytes, fixed N BCD O 69 24 Network International Identifier (NII) 2 bytes, fixed N BCD M 72 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M 82 42 Card Acceptor Identification Code 15 bytes, fixed ANS H M 83 49 Currency Code, Transaction 2 bytes, fixed N BCD M 105 60 Private Use Data 31 bytes, LLLVAR ANS BCD / H* M 108 62 Private Use Data 8 bytes, LLLVAR ANS BCD / H* M 116 63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* M 118





7.2.14 0510 — Reconciliation Response


ISO

8583

Bit

Num

ber


10 -

Clos

e

Page – Message Type Identifier 2 bytes, fixed N BCD M 56 – Bit Map - Primary 8 bytes, 64 bits B H M 57 3 Processing Code 3 bytes, fixed N BCD M 61 11 Systems Trace Audit Number 3 bytes, fixed N BCD M 65 12 Time, Local Transaction 3 bytes, fixed N BCD M 66 13 Date, Local Transaction 2 bytes, fixed N BCD M 67 24 Network International Identifier (NII) 2 bytes, fixed N BCD M 72 37 Retrieval Reference Number (RRN) 12 bytes, fixed AN H O 78 39 Response Code 2 bytes, fixed AN H M 81 41 Card Acceptor Terminal Identification 8 bytes, fixed ANS H M 82 44 Additional Response Data 26 bytes, LLVAR AN BCD / H* O 86 63 Private Use Data 42 bytes, LLLVAR ANS BCD / H* O 118





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




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




8.1 Cardmember Account Number Check Digit Computation (Continued)

Example: Cardmember #373872186011004 The check digit is 4

1. Do not include the check digit (last number to the right) in the calculation.

3 7 3 8 7 2 1 8 6 0 1 1 0 0

2. Starting with the last digit to the right, and working right to left, multiply every other digit by two.

7 x2 14

8 x2 16

2 x2 4

8 x2 16

0 x2 0

1 x2 2

0 x2 0

3. If any product of Step 2 is a two-digit number, add the two digits together.

5 7 4 7 0 2 0

4. Add the products produced in Step 3.

5 + 7 + 4 + 7 + 0 + 2 + 0 = 25

5. Add all the digits not used in Step 2.

3 + 3 + 7 + 1 + 6 + 1 + 0 = 21

6. Add the results of Steps 4 and 5.

25 + 21 = 46

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

50 – 46 = 4

If the calculated check digit matches the given check digit, the Card-member account number is valid.

Given check digit is 4. Calculated check digit is 4. Account Number is valid.

If the check digits do not match, the Cardmember number is invalid and must be flagged as invalid.




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




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 Capture Host will contain code “96” (Miscellaneous Processing Error).

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 Capture Host will contain code “96” (Miscellaneous Processing Error).

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




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.




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.




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.



http://www.americanexpress.com/datasecurity




9.2.1 ANSI X4.16 Standard

Track 1 (Preferred) Track 2

Field Name Digit Field Name Digit

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

9.2.2 ISO 7813 Standard



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


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.




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




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.






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.






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.






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










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.






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.






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 Express representative.





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. 7 = Not available for general interchange. 9 = System test card.

See Special Note for Subfields 8 and 9, on page 162.






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.

01 = No restrictions. 02 = No ATM service. 03 = ATM Service only. 06 = No restrictions; prompt for PIN, if PIN pad is present. 10 = No cash advance. 11 = No cash advance or ATM service. 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.







Subfield 8 — ANSI X4.16 EFFECTIVE DATE Subfield 10 — ISO 7813 EFFECTIVE DATE




Constant: None


Description: This field contains the year and month in which the American Express Card becomes valid.

The card becomes valid on the first day of the month.






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.






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 only. Other values may appear in actual magnetic stripe data for American Express Cards.






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.






Subfield 12 — ANSI X4.16 UNUSED

Length of Field: 17 bytes — ANSI X4.16

Field Type: Binary

Approximate Position: Positions 63-79 — ANSI X4.16

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.




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 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 Track 2.

Message: ; 3 7 1 4 4 9 6 3 5 3 1 1 0 0 4 = 9 4 0Position: 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





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








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.






Subfield 4 — ANSI X4.16 EXPIRATION DATE Subfield 4 — ISO 7813 EXPIRATION DATE




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.






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 Express representative.





Subfield 5 — ISO 7813 INTERCHANGE DESIGNATOR


Field Type: Numeric

Approximate Position: Position 22 — ISO 7813


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. 7 = Not available for general interchange. 9 = System test card.







Subfield 6 — ISO 7813 SERVICE CODE


Field Type: Numeric



Constant: None


Description: This field indicates whether the American Express Card can be used for ATM/Cash Access, or if positive authorization is required.

01 = No restrictions. 02 = No ATM service. 03 = ATM Service only. 06 = No restrictions; prompt for PIN, if PIN pad is present. 10 = No cash advance. 11 = No cash advance or ATM service. 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.







Subfield 5 — ANSI X4.16 EFFECTIVE DATE Subfield 7 — ISO 7813 EFFECTIVE DATE




Constant: None


Description: This field contains the year and month in which the American Express Card becomes valid.

The card becomes valid on the first day of the month.






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.






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.






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 only. Other values may appear in actual magnetic stripe data for American Express Cards.






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





Subfield 9 — ANSI X4.16 UNUSED

Length of Field: 8 bytes — ANSI X4.16

Field Type: Binary

Approximate Position: Positions 33-40 — ANSI X4.16

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.




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.




9.3.1 Expresspay Pseudo Track 1 & Track 2 Subfields



Start Sentinel 1 Start Sentinel 1Format Code 1 Account Number (PAN) 15Account Number (PAN) 15 Field Separator 1Field Separator 1 Expiration Date (YYMM) 4Cardmember Name 21 Interchange Designator 1ATC 5 Service Code 2Field Separator 1 Unpredictable Number 4Expiration Date (YYMM) 4 Cryptogram 5Interchange Designator 1 ATC 5Service Code 2 End Sentinel 1Unpredictable Number 4 Cryptogram 5 Total 39End Sentinel 1 Total 62




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, and Authorization with Balance Return

All 0100 & 0200 auth requests

4 - Amount, Transaction Full transaction amount requested for auth

Full transaction amount requested for authorization

Partial Auth only All 0100 & 0200 auth requests

47 - Additional Data - National

181 Merchant system supports optional Partial Auth response data

Authorization with Balance Return only

All 0100 & 0200 auth requests


182 Merchant system supports optional 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 &

0210 responses 4 - Amount, Transaction Actual amount authorized

(not original amount) Only present for Partial Auth (Field 39 = 06)

Partial Auth only Some 0110 & 0210 responses

39 - Response Code 004 = Partial Auth Indicates response is a Partial Auth



Full transaction amount originally requested

Only present for Partial Auth (Field 39 = 06)


54 - Amounts, Additional Balance remaining on Prepaid Card product

Present if Merchant system supports Partial Auth and Prepaid Card Primary Account Number is valid


All 0110 & 0210 responses

4 - Amount, Transaction Original amount, echo returned

Same value as Field 4 in original auth request


All 0110 & 0210 responses

39 - Response Code Routine values for approve, deny, refer, etc.

No special Response Codes are used for Authorizations with Balance Return.


Some 0110 & 0210 responses

54 - Amounts, Additional Balance remaining on Prepaid Card product

Present if Merchant system supports Authorizations with Balance Return and Prepaid Card Primary Account Number is valid

The premises and scenarios on the following pages further clarify how support for either Partial Authorization or Authorization with Balance Return affects the Merchant’s message content for all American Express products.




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.





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.



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




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




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





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.




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



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





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.



– Field 39, Response Code — Depending upon the Merchant, this value may be “51” indi-cating Credit Denied, or “01” indicating “Referral” (a BAU 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.


– 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




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.

• The Merchant builds the 0100 or 0200 request message with Field 47 set to “182”, which indicates support for Authorization with Balance Return.



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





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.



– Field 39, Response Code = “00”, indicating full approval (a BAU 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.

• The Merchant builds the 0100 or 0200 request message with Field 47 set to “182”, which indicates support for Authorization with Balance return.


– Field 39, Response Code = “51”, indicating Credit Denied (a BAU 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”.





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.





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





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





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





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.



– Field 39, Response Code — Depending upon the Merchant, this may be “51” indicating “Credit Denied”, or “01” indicating “Referral” (a BAU response).


Note: Fields 47 and 54 are not returned for American Express 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 “182”, which indicates support for Authorization with Balance Return.


– 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




9.5 Currency Codes

The following table lists the Currency Codes used by American Express in Currency Name order.

Currencies from countries with which American Express is prohibited from doing business due to USA economic sanctions, or which may be subject to other internal American Express restrictions, are shown in shaded text and should not be used. For more information, please contact your American Express representative.

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.

“Dec” column indicates number of implied decimal places. 3. 4. Maximum Value allowed is “000009999999”, unless otherwise indicated.

Currency Name Country or Entity Name Code Dec (See Note 3)

Notes Maximum Value (See Note 4)

Cuba 1 Iran 1 Myanmar 1 Sudan 1 Afghanistan Afghani Afghanistan 971 2 Albanian Lek Albania 008 2 000999999999Algerian Dinar Algeria 012 2 2 000999999999Angolan Kwanza Angola 973 2 Argentine Peso Argentina 032 2 Armenian Dram Armenia 051 2 000999999999Aruban Guilder Aruba 533 2 Australian Dollar Australia 036 2 000999999999Australian Dollar Christmas Island 036 2 Australian Dollar Cocos (Keeling) Islands 036 2 Australian Dollar Heard and McDonald Islands 036 2 Australian Dollar Kiribati 036 2 Australian Dollar Nauru 036 2 Australian Dollar Norfolk Island 036 2 Australian Dollar Tuvalu 036 2 Azerbaijanian Manat Azerbaijan 944 2 Bahamian Dollar Bahamas 044 2 Bahraini Dinar Bahrain 048 3 000999999999Bangladesh Taka Bangladesh 050 2 000999999999Barbados Dollar Barbados 052 2 Belarusian Ruble Belarus 974 0 Belize Dollar Belize 084 2 Bermudian Dollar Bermuda 060 2 Bhutan Ngultrum Bhutan 064 2 Bolivar Fuerte Venezuela 937 2 000999999999Bolivian Boliviano Bolivia 068 2 Bosnian Mark Bosnia and Herzegovina 977 2 Botswana Pula Botswana 072 2 Brazilian Real Brazil 986 2 Brunei Dollar Brunei Darussalam 096 2 000999999999







economic sanctions. No currency information is shown for these countries. 2. 3.

The American Express designated name, code and/or decimalization for this currency may differ from ISO 4217. “Dec” column indicates number of implied decimal places.

4. Maximum Value allowed is “000009999999”, unless otherwise indicated.


Notes Maximum Value

(See Note 4)

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









Notes Maximum Value

(See Note 4)

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









Notes Maximum Value

(See Note 4)

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









Notes Maximum Value

(See Note 4)

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









Notes Maximum Value

(See Note 4)

Tongan Pa’anga Tonga 776 2 Trinidad and Tobago Dollar Trinidad and Tobago 780 2 Tunisian Dinar Tunisia 788 3 000999999999Turkish Lira Turkey 949 2 000999999999U.A.E. Dirham United Arab Emirates 784 2 000999999999U.S. Dollar American Samoa 840 2 000999999999U.S. Dollar British Indian Ocean Territory 840 2 U.S. Dollar Croatia, Republic of 840 2 000999999999U.S. Dollar Ecuador 840 2 000999999999U.S. Dollar Guam 840 2 000999999999U.S. Dollar Haiti 840 2 U.S. Dollar Marshall Islands 840 2 000999999999U.S. Dollar Micronesia, Federated States of 840 2 000999999999U.S. Dollar Northern Mariana Islands 840 2 000999999999U.S. Dollar Palau 840 2 000999999999U.S. Dollar Panama 840 2 U.S. Dollar Puerto Rico 840 2 000999999999U.S. Dollar Timor-Leste 840 2 U.S. Dollar Turks and Caicos Islands 840 2 U.S. Dollar U.S. Minor Outlying Islands 840 2 U.S. Dollar United States 840 2 000999999999U.S. Dollar Virgin Islands, British 840 2 U.S. Dollar Virgin Islands, U.S. 840 2 000999999999Uganda Shilling Uganda 800 2 Ukraine Hryvnia Ukraine 980 2 000999999999Uzbekistan Som Uzbekistan 860 2 Vanuatu Vatu Vanuatu 548 2 Vietnamese Dong Vietnam 704 2 000999999999Yemeni Rial Yemen 886 2 000999999999Zambia Kwacha Zambia 894 2 2 Zimbabwe Dollar Zimbabwe 716 2


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




9.6.3 Street Abbreviations

Code Length

Street Code

Code Definition

Code Length

Street Code

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




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 A D GAL GEN VISC VIS DEUX 2 SETTIMO 7 AN DER A D GENERAL GRAL VISCONDE VIS ZWEI 2 SEPTIÈME 7 ANTINGUO ANT GENERAL GEN VOR DEN V D DOIS 2 SÉPTIMO 7 AP APT GUILLERMO GMO VOR DER V D DUAS 2 SIEBTER 7 APARTAMENTO APT HACIENDA HDA TERZO 3 SETTE 7 APTO APT IN DEN I D TROISIÈME 3 SIETE 7 AUF DEN A D IN DER I D TERCER(O) 3 SEPT 7 AUF DER A D 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




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.




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.

See Credit Authorization System. CAS

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.




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.

See Global Authorization Network. GAN

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.

See Card Issuer. 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.

See Plural Interface Processing. PIP

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.




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.

See Record of Charge. ROC

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.

See Summary of Charges. SOC

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.




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






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


11.2 EBCDIC & ASCII Code Translation Table — Part B

Instruction Graphics and Controls 7-Track Tape Card Code 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






11.2 EBCDIC & ASCII Code Translation Table — Part B

Instruction Graphics and Controls 7-Track Tape Card Code 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


11.3 EBCDIC & ASCII Code Translation Table — Part C

Instruction Graphics and Controls 7-Track Tape Card Code 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






11.3 EBCDIC & ASCII Code Translation Table — Part C

Instruction Graphics and Controls 7-Track Tape Card Code 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


11.4 EBCDIC & ASCII Code Translation Table — Part D

Instruction Graphics and Controls 7-Track Tape Card Code 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 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






Instruction Graphics and Controls 7-Track Tape Card Code

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

Яяяяяя Amex Pip-Iso Oct2010

Documents

Transcript of Яяяяяя Amex Pip-Iso Oct2010