Amex WS PIP Terminal Interface Spec ISO Apr2011

GLOBAL MERCHANT SERVICES POS020055, v3.2, April 22, 2011

PLURAL INTERFACE PROCESSING (PIP) TERMINAL INTERFACE SPECIFICATION

(ISO 8583 FORMAT) APRIL 2011

Copyright 2006-2011 American Express Travel Related Services Company, Inc. All rights re-served. This document contains sensitive, confidential and trade secret information; and no part of it shall be disclosed to third parties or reproduced in any form or by any electronic or me-chanical means, including without limitation information storage and retrieval systems, without the express prior written consent of American Express Travel Related Services Company, Inc.

American Express Proprietary & Confidential PIP Terminal Interface Spec (ISO 8583)

Revision Log

Version Date | Content Owner | Prepared By | Description 3.2 04/22/11 | J. Cheney | R. Wong | See Below

Cover: Changed title from OCTOBER 2010 to APRIL 2011. Page 63: Changed text, as indicated, American Express limits the maximum allowable value that can be

approved in this field. While most entries must not exceed 000009999999, some locations may submit based on the US Dollar equivalent calculated by American Express. Transmitted transaction amounts in specific currencies up to 000999999999. However, please note that a transaction amount greater than the max-imum allowed will result in an invalid amount edit error. For more information on maximum allowable values, see Currency Codes on page 196.

Page 64 & 99: The available balance is returned in response message Field 54 (Amounts, Additional) of the Authorization Response (0110) message.

Page 80: Added Note 1, All Approval Codes are numeric for American Express Transactions. Pages 196-201: Changed Note 4 text, as indicated, Maximum Value allowed is the equivalent to either

000009999999, unless otherwise indicated. ($99,999.99 USD) or 000999999999 ($9,999,999.99 USD). Also, updated most Maximum Value entries; and added, deleted or changed the following Currency Codes: Changed, as indicated Estonia Kroon Euro | Estonia | 233 978 | 2 Changed, as indicated Malagasy Ariary | Madagascar | 969 | 2 0 Deleted Netherlands Antillian Guilder | Netherland Antilles | 532 | 2 Added Netherlands Antillian Guilder | Curaao | 532 | 2 Added Netherlands Antillian Guilder | Sint Maarten | 532 | 2 Added New Manat | Turkmenistan | 934 | 2 Added Panama Balboa | Panama | 590 | 2 Added U.S. Dollar | Bonaire | 840 | 2 Added U.S. Dollar | Saba | 840 | 2 Added U.S. Dollar St. Eustatius | 840 | 2 |

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.

April 22, 2011 POS020055 i This document contains sensitive, confidential and trade secret information, and must not be disclosed to third parties

without the express prior written consent of American Express Travel Related Services Company, Inc.

PIP Terminal Interface Spec (ISO 8583) American Express Proprietary & Confidential

ii POS020055 April 22, 2011 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 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. 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 Requirement from C/C to M/M.


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


Revision Log

Version Date | Content Ow r | Prepared By | Description ne2.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). Page 4: Revised Expresspay requirements and added Magstripe Mode details. Page 12: Added underlined text Important Note for Web Services IP Payments Gateway Users. Page 20: In bullet for 0330 response, changed from upload batch from terminal to host to response

message contains a processing code Page 24: Merged High-Speed Internet and Dial-Up info in Recommended Time-Out Values section. Pages 49-50: Reduced Max Field Length bytes to reflect binary coded decimal entries. Page 53: Added Important Note for Web Services IP Payments Gateway Users Page 59: Deleted stricken text: The VLI must indicate the exact length of the account number without

padding. Page 63: Deleted or US Dollars, if Field 49 is omitted and added, Merchants must certify for each currency

submitted. Pages 63, 105, 106, 123 & 127: Changed from only US Dollars to US Dollars and select global currencies

and added, For more info please contact your American Express representative. Pages 60-129 Made the following changes to Data Field Descriptions:

In fields with BCD entries, changed VLI and Length of Field, as necessary, to reflect shorter, packed bits/BCD value.

Changed references from bytes to digits or characters, as applicable, when bytes actually refers to 4-bit nibbles.

Replaced Example 1/2 text and diagrams with new Sample Data, which more accurately describes proper field layout.

Page 74: Deleted stricken text: The VLI must indicate the exact length of the Track 2 data actually transmitted without padding. Also, relocated notes 1 & 2 from the page that follows.

Pages 74, 90 & 150: Added references to Expresspay Pseudo-Mag Stripe Formats Pages 77 & 93 (Fields 35 & 45): Added Expresspay Pseudo-Mag Stripe Format descriptions and Sample Data. Page 79: Combined Auth Code and Referral Queue Field Requirement tables, and revised/added notes C1, C2

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

transaction thru end of Field 44 Description, including Sample Data. Page 90: Relocated notes 1 & 2 from a page that follows. Page 105: Changed all Field Requirements from C1 to M and deleted Note C1. Page 108: Deleted stricken text: (USA ZIP or international Postal code) Pages 108-129, Private Use Data Fields 60-63: Extensively revised/expanded detailed descriptions and Sam-

ple Data to clarify MTI-specific layouts. Pages 131-144: Updated tables to reflect changes in Field Descriptions. Pages 183-184: Added Expresspay Pseudo-Mag Stripe Formats section. Pages 196-201: Deleted Country Codes (not used in this spec) and added global currencies (previously, US

Dollars only). Pages 211-218: Added EBCDIC & ASCII Code Translation Table.


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


Revision Log


Page 15: Changed Note from Lodging and Auto Rental applications to Lodging, Auto Rental and eCommerce/Mail Order applications

Pages 114 & 116: In Fields 61 and 62, changed from C to C2 and added C1. Page 115 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 & g91-92: Corrected ma netic 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 Magneti Stripe Form ts Section: Added LRC to ANSI X4.16 Track 1 and Track 2 Formats. c a

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. Page 63: Added Note 2 For Void transactions Page 65: Added Note 2 This field is Page 68: Changed from 0220=C to =C2, from 0320=C to =C3, added Notes C2 and C3, and

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

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

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

Pages 152-181: Updated Mag Stripe Formats.

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


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


Revision Log


Page 9: Added second example to Invalid Card Capture Type. Page 62: Added paragraph beginning Note: 92 00 0X is entered in this field Pages 108-109: Changed from For MTI=0100, 0200 & 0220 to For MTI=0100 & 0200 and from

Examples of 0100, 0200 & 0220 Request to ...0100 & 0200 Request Pages 110: Changed from For MTI=0110, 0210 & 0230 to For MTI=0110 & 210 and from Examples of

0110, 0210 & 0230 AVS to 0110 & 0210 AVS Page 117: Changed from Batch Identification to Invoice/ROC/SOC (number), two places. Page 127-128: Added (previously omitted) 6-byte Reserved (zeros) subfield, two places. Pages 130-144: Changed format of Data Field/ Message Usage Tables to improve readability.

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 equivalentmust not exceed $99,999.99 USD. Page 103: Changed requirement for 0100, 0200 & 0220 from to C1; and added sentence beginning C1 =

Cond. Merchants transmitting. Page 108: Changed requirement for 0220 from to O, and 0230 from to C1. Changed For

MTI=0100 & 0200 to 0100, 0200 & 0220. Page 109: Changed from For MTI=0110 & 0210 to 0110, 0210 & 0230, and Example of 0110 &

0210 to 0110, 0210 & 0230; and added above changes to Message Usage Table.

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

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



Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



Table of Contents

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



xii POS020055 April 22, 2011 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 Hosts batch balances with the terminals reconciliation, then the shadow file is submitted for payment. If the terminal does not balance with the Capture Host, then the shadow file is replaced with the terminals batch.

Store and forward processing is used for Lodging, Purchasing Card, Travel (Sign & Travel) and Auto Rental applications, and is a typical, terminal-based capture system. This method of processing allows the establishment to perform authorizations as needed, and then settle the batch later.

1.2 Shadow File Processing

The Capture Host maintains a copy of the batch by recording each transaction that is processed by the terminal. When transactions are approved, they are recorded and may be used for settlement, when the terminal has successfully reconciled with the Capture Host. The terminal is responsible for updating the Capture Host of all financial transactions including off-line sales, adjustments and voids.

Retail minimum transaction set:

Close Batch Off-Line Sale Refund Sale Void

Restaurant minimum transaction set:

Close Batch Debit Adjustment Off-Line Sale Refund Sale Void

April 22, 2011 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 April 22, 2011 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 Merchants system supports capture of both Track 1 and Track 2, both tracks should be forwarded. If only one track is captured, Track 1 is preferred (see page 90). For systems that capture only Track 2, this less desirable alternative may be supplied in lieu of Track 1 (see page 74). American Express security requirements prohibit the storage of track data within Merchant or processor systems. Character spaces should not be stripped. In addition, data should not be padded to standardize track lengths, and it should be transmitted as read.

The Authorization Request Message contains the Point of Service Entry Mode (Field 22) that describes point-of-service processing capabilities (see page 70). Merchants, and terminal and software vendors, are strongly advised to ensure that authorization data is accurate.

For more information, please contact your American Express representative.




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 0110 or 0210 response message. Field 47 (Additional Data - National) of the 0100 or 0200 message is used to identify an Authori-zation with Balance Return request. The available balance is returned to the Merchant in Field 54 (Amounts, Additional) in the 0110 or 0210 response message, even if the transaction is denied. Trans-actions that are denied for insufficient funds can be resubmitted for an amount equal to or less than the remaining balance provided in the 0110 or 0210 response message.

Merchants should develop internal instructions for using the Prepaid Card Partial Authorization or Authorization with Balance Return Programs at their point of sale. American Express will allow authorized Merchants that conform to this specification and pass our certification tests to access the American Express network to acquire Partial Authorization or Authorization with Balance Return.

Terminal and software vendors must develop support for both Partial Authorization and Authorization with Balance Return functionalities in order to provide the ability for their Merchants to utilize either program. Additional information may be obtained from your American Express representative.

Note: Prepaid Card Balance Inquiry may also be performed utilizing either the Partial Authorization or the Authorization with Balance Return program. This can be done by simply entering an amount of zero in the Field 4 (Amount, Transaction). The transaction will be approved, and the available balance is returned in Field 54 (Amounts, Additional). A new authorization request can then be created for an amount equal to or less than the remaining balance.




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 Merchants terminal. If the Capture Host is unavailable, the American Express Global Authorization Network (GAN) system may substitute for the Capture Host and respond to the terminal. For more information on the American Express GAN, see page 35.

The Capture Host performs several interface activities:

Approves or refers authorization requests.

Maintains a transaction shadow file for the terminal.

Adds and updates terminal problems to a trouble list.

Reconciles and closes batches from the terminal.

Supports suspended batches.

Settles batches with the financial settlement and payment systems.

2.2.1 Authorization Requests

The terminal transmits authorization requests to the Capture Host. The Capture Host performs a check digit computation on the account number to verify that the number is a valid American Express account number. (For check-digit computation instructions, see page 146).

2.2.2 Transaction Shadow Files

The Capture Host maintains and stores a shadow file that contains all transactions processed through American Express for each terminal. All the transactions stored in a terminal at any one time are called a batch of transactions. The shadow file plays an active role when closing a terminals batch.

When a terminals batch is closed, the terminal transaction count, and sales and refund totals must match the Capture Host shadow file totals. If the totals do not match, the Capture Host transmits a request for the terminal to upload all transactions stored in the terminal, and it places them in a new shadow file, thus overwriting the original shadow file.




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 terminals request to those in the shadow file. If the figures agree, the batch in the Capture Host is marked as closed, and a close batch response is sent to the terminal. A text message is also sent from the Capture Host to the terminals display.

If the figures do not agree, the terminal will be placed on the trouble list. On the next attempt to 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 terminals memory.

If the uploaded details do not balance with the totals sent from the terminal in the original request, the Capture Host automatically blocks any activities for that batch. In addition, any errors received during the entire settlement process will result in the Capture Host blocking out terminal activities and 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 Merchants terminal/system.

The ISO 8583 standard defines a bit-mapped message format. The first ten bytes of a message are composed of a four-byte message type code that identifies the type of transaction being transmitted and an eight-byte bit map that indicates the data fields that immediately follow. These two fields always precede the transaction data in each message.

Each digit of the message type code identifies a message attribute. Definitions of the attributes are:

First position / Version Number This number is always 0 (zero).

Second position / Message Class The message classes used by the American Express PIP interface are:

1 = 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 terminals transactions balance properly with the Merchant/ Service Establishment, but not with the Capture Hosts 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 Merchants terminal, device or system is responsible for not transmitting any transactions to the Capture Host until the reversal is processed and cleared.

If the Capture Host is unavailable when a reversal is transmitted from the terminal, the reversal message is transmitted to the American Express GAN system, which stands in for the Capture Host. When the Capture Host becomes available, the terminal sends a reversal advice message to the Capture Host, as notification that one or more transactions stored in the terminal were processed through the GAN.

For more information on the American Express Global Authorization Network (GAN), see page 35.





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

Transaction Initiated (Card Swipe)

Reversal Request (0400) Reversal Response (0410) 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 provid

Amex WS PIP Terminal Interface Spec ISO Apr2011

Documents

Transcript of Amex WS PIP Terminal Interface Spec ISO Apr2011