96byte Spec

integrated
va l ue
service
fast
Payment
Processing
enhanced
comprehensive
96-Byte Technical Specification

September 21, 2001 z Revision 1.7.1
growth
leading
flexible
innovative
proven
4 Northeastern Blvd. Salem, NH 03079-1952

Ph: 603/896-6000 z Fax: 603/896-8710
www.paymentech.com
TECHNICAL
SPECIFICATIONS
96-Byte for
Batch Processing
Rev. 01.7.1
Paymentech 2001 - All rights reserved
This document contains confidential and proprietary information of Paymentech Network

Services/Merchant Services. No disclosure or duplication of any portion of these materials may be
made without the express written consent of Paymentech. These materials must be used solely for the
operation of Paymentech programs and for no other use.
4 Northeastern Boulevard
Salem, New Hampshire 03079-1952
603/896-6000
The following updates, additions, corrections have been incorporated in
96-Byte for Batch Processing Rev. 01.7.1

Page No(s)
Through-out
1
Action
Update
Addition
4
5
Addition
Update/Addition
6, 47, 53, 99
Update/Addition
7, 47, 48, 55, 99
Update/Addition
8, 48, 57, 100

9, 49, 59
10, 62
Correction/Additio
n
Update
Update
11, 12
15, 72
16, 73, 75
Update
Addition
Addition
18, 77, 154

20, 79
22, 81
24, 84
Addition
Addition
Addition
Addition
32, 88
Update
35, 90, 155

36, 91
37, 92
Addition
Addition
Addition
50, 101
Addition
48, 68
67
104
115-126
129
134
137
138
Addition
Addition
Update
Update/Addition
Addition
Addition
Update
Addition/Update
Description of Change
Revision change from 1.6.1 to 1.7.1
Added Discover CID, Bill Me Later, Stored Value, Visa
Authentication. Removed Malaysian Ringitt. Added note to
AVS for US and International)
Added carriage return notation
Updated revision number. Added notation to Merchant
Space.
Added notes to Merchants Order Number. Added action
codes: E, K, L, Q for Stored Value. Updated notations on
other action codes.
Added/updated Method of Payments: BL for Bill Me Later,
SV for Stored Value, removed GE Twinpay Debit and
Credit, added additional notes. Updates notes for Account
Number.
Removed Malaysia Ringitt. Added notes to see field
definitions on layouts, and added note for field definitions.
Removed notation for Transaction Type 5.
Updated Comments for Encryption Flag. Made Encryption
Flag 3 bytes. Adjusted positions accordingly.
Updated title
Added Visa 2 record for Visa Authentication Program.
Added ECP Authorization Method. Adjusted positions
accordingly. Updated notes for Preferred Delivery Method.
Added Bill Me Later Record
Added Order Information Record
Added Consumer Information Record
Added additional notes to Customer Reference Number and
Sales Tax Amount as well as overall record notation.
Updated notes for Card Security Value and Card Security
Presence
Added Stored Value Record
Added Various Test Product Record
Updated comments for Address Type, Added E employer,
G Giftee, I IP address, L Email along with applicable
samples.
Added Fraud Indicator, Encryption Flag, Recurring Payment
Code Advice and adjusted positions accordingly.
Added 05, 81, 95 to POS Entry Mode
Added 5
Removed GE samples
Added BML and SV codes, updated as applicable.
Added Intl AVS
Added BML, SV and removed GE Twinpay
Updated AVS notation
Added Discover CID Information
TECHNICAL SPECIFICATIONS
96-BYTE for BATCH PROCESSING
TABLE OF CONTENTS
PRODUCTS SUPPORTED.......................................................................................................................................... 1
FORMAT SPECIFICATIONS ..................................................................................................................................... 2
Introduction .............................................................................................................................................................. 2
Outline ...................................................................................................................................................................... 2
Synopsis.................................................................................................................................................................... 3
Transaction File.................................................................................................................................................... 3
Transaction File Extension Record ...................................................................................................................... 3
Request For Response Files ................................................................................................................................. 3
RECORD LAYOUTS................................................................................................................................................... 4
Introduction .............................................................................................................................................................. 4
Transaction File ........................................................................................................................................................ 5
Header Record...................................................................................................................................................... 5
Detail Record ......................................................................................................................................................... 6
Transaction Extension Record Format - American Express 1 ........................................................................... 11
Transaction Extension Record Format - American Express 2 ........................................................................... 12
Extension Record: MasterCard ......................................................................................................................... 13
Extension Record: Visa 1.................................................................................................................................. 14
Extension Record: Visa 2 Visa Authentication.............................................................................................. 15
Extension Record: Electronic Check Processing .............................................................................................. 16
Extension Record: Switch ................................................................................................................................. 17
Extension Record: Bill Me Later ...................................................................................................................... 18
Order Record: Order Information ..................................................................................................................... 20
Information Record: Consumer Information..................................................................................................... 22
Product Record: Procurement Level 2 .............................................................................................................. 24
Product Record: Procurement Level 2 .............................................................................................................. 25
Product Record: Procurement Level 3 - Visa Order Level Record................................................................... 26
Product Record: Procurement Level 3 - Visa Record #1 .................................................................................. 27
Product Record: Procurement Level 3 - Visa Record #2 .................................................................................. 28
Product Record: Procurement Level 3 - MasterCard Order Level Record ....................................................... 29
Product Record: Procurement Level 3 - MasterCard Record #1....................................................................... 30
Product Record: Procurement Level 3 - MasterCard Record #2....................................................................... 31
Product Record: Fraud ...................................................................................................................................... 32
Product Record: Retail Enable .......................................................................................................................... 34
Product Record: Stored Value........................................................................................................................... 35
Product Record: Various Text........................................................................................................................... 36
Address Record .................................................................................................................................................. 37
Address Record Format Examples ..................................................................................................................... 41
Address Record Format Examples ..................................................................................................................... 42
Batch Totals Record........................................................................................................................................... 43
Totals Record ..................................................................................................................................................... 44
Trailer Record .................................................................................................................................................... 45
Request for Response (RFR) Record ................................................................................................................. 46
S Record Output .............................................................................................................................................. 47
Technical Specifications 96-Byte for Batch Processing Rev. 01.7.1
Page i
09/21/2001
This document contains confidential and proprietary information of Paymentech Network Services/Merchant Services. No disclosure or duplication of
any portion of these materials may be made without the express written consent of Paymentech. These materials must be used solely for the operation
of Paymentech programs and for no other use.
FIELD DEFINITIONS ............................................................................................................................................... 51

Introduction ............................................................................................................................................................ 51
Transaction File ...................................................................................................................................................... 51
Header Record.................................................................................................................................................... 51
Detail Record ..................................................................................................................................................... 52
Extension Record: American Express - 1 & 2 .................................................................................................. 63
Extension Record: MasterCard ......................................................................................................................... 64
Extension Record: Visa 1.................................................................................................................................. 67
Extension Record: Visa 2 Visa Authentication.............................................................................................. 72
Extension Record: Electronic Check Processing .............................................................................................. 74
Extension Record: Switch Card ........................................................................................................................ 77
Extension Record: Bill Me Later ...................................................................................................................... 78
Information Record: Order Information............................................................................................................ 80
Information Record: Consumer Information..................................................................................................... 82
Product Record: Procurement Level 2 and Level 3 - MasterCard and Visa ..................................................... 85
Product Record: Procurement Level 3 - MasterCard and Visa - Order Level Record...................................... 86
Product Record: Procurement Level 3 - MasterCard and Visa - Record #1 ..................................................... 87
Product Record: Procurement Level 3 - MasterCard and Visa - Record #2 ..................................................... 88
Product Record: Fraud ...................................................................................................................................... 89
Product Record: Retail Enable .......................................................................................................................... 90
Product Record: Stored Value........................................................................................................................... 91
Product Record: Various Text........................................................................................................................... 92
Address Record .................................................................................................................................................. 93
Batch Totals Record........................................................................................................................................... 96
Totals Record ..................................................................................................................................................... 97
Trailer Record .................................................................................................................................................... 98
Request for Response (RFR) Record ................................................................................................................. 99
S Record Output ............................................................................................................................................. 100
FORMAT USAGE ................................................................................................................................................... 103
General Information ............................................................................................................................................. 103
Sending Pre-Approval Records ............................................................................................................................ 103
Paymentech Output .............................................................................................................................................. 104
Sample Input and Output Files ............................................................................................................................. 104
TESTING CHECKLIST TABLE ............................................................................................................................. 107
Introduction .......................................................................................................................................................... 107
Procedure.............................................................................................................................................................. 107
Certification Testing Process................................................................................................................................ 109
PRODUCTION PROCEDURES.............................................................................................................................. 111
Introduction .......................................................................................................................................................... 111
Procedure.............................................................................................................................................................. 111
Data Transmission Times ..................................................................................................................................... 112
TRANSMISSION SPECIFICATIONS .................................................................................................................... 113
Introduction .......................................................................................................................................................... 113
Asynchronous Transmission ................................................................................................................................ 113
Synchronous Transmission................................................................................................................................... 114
3780 ...................................................................................................................................................................... 114
APPENDIX A: RESPONSE REASON CODE DESCRIPTION/USAGE.............................................................. 116
Response Reason Codes ....................................................................................................................................... 116
Page ii
09/21/2001
Auth Code Responses........................................................................................................................................... 127

APPENDIX B: ADDRESS VERIFICATION......................................................................................................... 128
Introduction .......................................................................................................................................................... 128
AVS/AAV Process ............................................................................................................................................... 128
AVS Response Codes Example............................................................................................................................ 130
AVS Response Key .............................................................................................................................................. 131
APPENDIX C: ERROR SCREENING ................................................................................................................... 132
Bad Card Number................................................................................................................................................. 132
MOD 10 Check Digit ........................................................................................................................................... 132
Card Prefix Check ................................................................................................................................................ 135
Card Length Check............................................................................................................................................... 135
APPENDIX D: MODEM SET UPS ........................................................................................................................ 136
Introduction .......................................................................................................................................................... 136
Synchronous Modems .......................................................................................................................................... 136
Asynchronous Modems ........................................................................................................................................ 137
APPENDIX E: INTERNATIONAL PROCESSING............................................................................................... 138
Record Layout ...................................................................................................................................................... 138
Contractual Agreement......................................................................................................................................... 138
Division Numbers................................................................................................................................................. 138
Zero Decimal Currencies...................................................................................................................................... 138
Zero Decimal Example......................................................................................................................................... 138
APPENDIX F: AMERICAN EXPRESS AND DISCOVER CARD IDENTIFICATION (CID) PROCESSING.. 139
Introduction .......................................................................................................................................................... 139
Merchant Requirements........................................................................................................................................ 139
APPENDIX G: AMERICAN EXPRESS TRANSACTION ADVICE ADDENDUM (TAA) RECORDS ............ 140
TAA Records........................................................................................................................................................ 140
TAA Sample Input File ........................................................................................................................................ 140
APPENDIX H: VISA PAYMENT SERVICE 2000 (PS2000) PROCESSING ...................................................... 141
Introduction .......................................................................................................................................................... 141
Custom Payment Service/Retail (CPS) ................................................................................................................ 141
Chargebacks ......................................................................................................................................................... 142
CPS/Non Face-to-Face ......................................................................................................................................... 143
APPENDIX I: MASTERCARD INTERCHANGE COMPLIANCE PROGRAM ................................................. 144
Introduction .......................................................................................................................................................... 144
Interchange Rate................................................................................................................................................... 144
APPENDIX J: CVV2 VISA/CVC2 MASTERCARD PROGRAMS ...................................................................... 145
Introduction .......................................................................................................................................................... 145
Fraud Product Fields............................................................................................................................................. 145
APPENDIX K: AUTHORIZATION RECYCLING PROGRAM........................................................................... 147
Introduction .......................................................................................................................................................... 147
To Get Started....................................................................................................................................................... 147
APPENDIX L: PROCUREMENT CARDS ............................................................................................................ 148
Page iii
09/21/2001
Introduction .......................................................................................................................................................... 148

Edit Checks........................................................................................................................................................... 148
BIN Ranges .......................................................................................................................................................... 148
Currency Restrictions ........................................................................................................................................... 148
American Express Level 2/3................................................................................................................................. 149
MasterCard/Visa Level 2...................................................................................................................................... 149
MasterCard/Visa Level 3...................................................................................................................................... 150
Record Sequence .................................................................................................................................................. 150
Record Sequence Example ................................................................................................................................... 151
Sample Input File ................................................................................................................................................. 152
APPENDIX M: RETAIL ENABLE ........................................................................................................................ 153
Introduction .......................................................................................................................................................... 153
Retail Enable Product Record .............................................................................................................................. 153
APPENDIX N: PAYMENTECH FRAUD DETECTION SERVICE ..................................................................... 154
Introduction .......................................................................................................................................................... 154
How it works ........................................................................................................................................................ 154
Supported card types/currencies........................................................................................................................... 154
Authorization Response Codes............................................................................................................................. 154
To Get Started....................................................................................................................................................... 154
APPENDIX O: BILL ME LATER .......................................................................................................................... 155
Introduction .......................................................................................................................................................... 155
How it works ........................................................................................................................................................ 155
Supported currencies ............................................................................................................................................ 155
To Get Started....................................................................................................................................................... 155
APPENDIX P: PAYMENTECH STORED VALUE .............................................................................................. 156
Introduction .......................................................................................................................................................... 156
How it works ........................................................................................................................................................ 156
Supported currencies ............................................................................................................................................ 156
To Get Started....................................................................................................................................................... 156
INDEX....................................................................................................................................................................... 157

Page iv
09/21/2001
PRODUCTS SUPPORTED
The following Paymentech products are supported in the
Technical Specifications 96-Byte for Batch Processing - Rev 1.7.1
CREDIT CARD PROCESSING (Non-face-to-face and Point of Sale)
Address Verification Service/Automated Address Verification (US and Visa International)
American Express CID, Discover CID, MasterCard CVC2, and Visa CVV2
Authorization Recycling
Bill Me Later
Card Types:
American Express/Optima
Carte Blanche
Diners Club
Discover (Novus)
JCB (Japanese Debit Card)
MasterCard
Private Label Cards (please contact your Paymentech representative)
Purchasing Cards including levels 2 and 3
Switch/Solo (United Kingdom Debit Card)
Visa/Delta
Australian Dollars
Austria Schilling
Belgium Francs
British Pounds Sterling
Canadian Dollars
Danish Krone
French Francs
Euro
Finnish (Finland) Markka
Encryption Transaction Processing
Currencies:
German Deutsche Marks

Greece Drachma
Hong Kong Dollars
Irish Punt
Italian Lira
Japanese Yen
Netherlands Dutch Guilders
New Zealand Dollars
Norwegian Krone
Portugal Escudo
Singapore Dollars
South African Rand
Spanish Peseta
Sweden Krona
Swiss Franc
United States Dollars
Paymentech Fraud Detection Service

Retail Enable
Soft Merchant Descriptors (requires an addendum specification and approval of Paymentech Risk Department)
Stored Value Card Program
Transaction
Types:
Authorizations
(Batch only)
Deposits
Refunds
Visa Authentication
Visa Payment Service 2000 and Customer Payment Service (Retail and Card Not Present)
ELECTRONIC CHECK
Transaction
Types:
Validation
Verification
Refunds
Pre-Notes
Deposits
FLEXIBLE PAYMENT OPTIONS (FPO) for Credit Card or Electronic Check Transactions
(required FPO specification)
Payment
Options:
Installment
Deferred

Continuity
Page 1
09/21/2001
FORMAT SPECIFICATIONS
Introduction
The Paymentech format was developed for Merchants and vendors who
want to use our payment processing services and do not already have a
format of their own. This format was designed to give great flexibility to
users when transmitting data by using extension and product records
related to specific methods of payments and products.
This format allows merchants to use only the records which are needed for
their business. It accepts multiple merchant divisions and transaction types
(authorizations, refunds, sales/deposits, pre-notes, ACH debits, ACH
credits, etc.) within a single submission. (The format contains several
layers of record count and dollar amount verification to ensure proper data
validation.) It is batch oriented. It also supports the sending of name and
address information, which is required from all Merchants and vendors for
the proper handling of certain interchange programs, Electronic Check
Processing (ECP) transactions, Chargebacks and Returns.
Outline
The general outline for the Paymentech format is as follows:

Header Record
S
U
B
M
I
S
S
I
O
N
T
R
A
N
S
A
C
T
I
O
N
B
A
T
C
H
Batch Totals Record
F
I
L
E
R
E
Q
U
E
S
T
O
R
D
E
R
F
O
R
R
E
S
P
O
N
S
E
Detail Record
Optional Extension Record
Optional Product Record
Optional Address 1
.
.
.
Optional Address 20
ORDER
ORDER
ORDER
BATCH
BATCH
BATCH
.
.
.
Totals Record
Trailer Record
RFR Record

Page 2
09/21/2001
FORMAT SPECIFICATIONS
Synopsis of Format
for Transaction Files
All transaction files received by Paymentech must contain a Header

Record, which identifies the source of the submission. Each transaction
file(which must contain at least 1 transaction record) must also contain
one or more batches accompanied by a Batch Totals Record. A Totals
Record MUST follow the last Batch Totals Record, even if there is only
one batch in the file.
The limit of records in a single file is 999,999,999 records. Batching is for
Merchant and vendor convenience, and may be used in any way deemed
appropriate.
Notes: Maximum US dollar amount per individual transaction is
$99,999.99. Individual transactions that exceed $25,000 (or established
international currency equivalent or previously established Merchant limit)
must have limit increased in order for transaction not to reject. Contact
Paymentech Merchant Services at 603-896-8333 prior to processing
transaction.
It is against the card organization regulations to sort a batch by the
Account Number.
The Trailer Record marks the end of the transaction file and is an end of
transmission indicator.
Synopsis of Format
for Transaction File
Extension Record
The Transaction File Extension Record is utilized to support account

specific transaction data that is not included in the Transaction File Detail
Record. The MasterCard and Visa Extension Records are not required
unless the authorization is obtained from a source other than Paymentech.
Synopsis of Format
for Request For
Response Files
The RFR Record is a Request For Response record that enables our
Merchants and vendors to dial into our system at their convenience and
retrieve the results of previously processed transaction files.
Note: The RFR is a separate file sent to Paymentech and it should not be
sent as part of your data file.

Page 3
09/21/2001
RECORD LAYOUTS
Introduction
The following pages define the physical layouts of the various record types.
Each record definition is preceded by an example. The example

includes a ruler line to show column positions. The record chart
following the example contains all necessary field information.
The position column defines the starting and ending positions of the
field.
A length and a data type follow the position column. The data type is
either A (alpha-numeric) or N (numeric only).
The field name listed is used in the Field Definitions section of the
manual.
The comments column gives the values of constants or a short

description of the fields meaning. A more detailed description may
be found in the Field Definition section of this manual.
Notes: Fields that are labeled (Optional) should be blank filled if they are
not utilized.
Each record should have a carriage return (CR) in position 97.

Page 4
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Header Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAAANNNNNNAAAAAAAAAAAAAANNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
PID=123456 ABCCO
SID=123456 ABCCO
START 971231 01.7
11111111
Position
Length
Data
Type
Field Name
Comments
1,4
Constant
PID=
5,10
Presenters ID (PID)
Assigned by Paymentech
11
Filler
Blank
12,19
PID Password
20
Filler
Blank
21,24
Constant
SID=
25,30
Submitters ID (SID)
31
Filler
Blank
32,39
SID Password
40
Filler
Blank
41,45
Constant
START
46,47
Filler
Blanks
48,53
Creation Date
YYMMDD Format (Optional)
54
Filler
Blank
55,58
Revision Number
01.7, Left justified/zero-filled
59
Filler
Blank
60,70
11
Submission Number
This is Paymentechs Submission #

(Leave Blank as Paymentech will
populate in output.)
71, 88
18
Filler
Blanks
89,96
Merchant Space
Unique file id identifier supplied by

merchant (Optional). This data is not
stored at Paymentech, but is returned
with the reply file.

Page 5
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Detail Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
ANNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNNNNNNNNNNNNNNNNNAANNNNNNAAAAAAAAAAAAAAAAAAAA
S1234569876543219876543 BVI4123456789012345
1299000000004995840
1
Position
Length
Data
Type
Field Name
Comments
Constant
"S"
2, 7
Division Number
Assigned and provided to Merchant by

Paymentech (Required)
8, 23
16
Merchant's Order Number
A number composed of any alpha, blank, digit

or punctuation (*) combination that will be
returned in the transaction response. This field
will tie the request on your end to the response
we provide you.
Paymentech looks at the entire 16-byte order
number, however, the first eight digits should
be unique to the transaction. The order
number should be stored and supplied in the
deposit file. (Required) Left justified/blank
filled
Note: Merchants should pass the same order
number on their authorization and deposit
transactions.
*DO NOT USE: pipe (|), caret (^), percent
symbol (%) or backslash (\)
24, 25
Action Code
Action Requested
Right justified/blank filled
A - Authorize (Credit Card, Stored Value)
B - Conditional Deposit (Credit Card)
D - Deposit (Credit Card, Stored Value)
E - Authorization Reversal (Stored
Value)
G - Verify Only (ECP US)
(dollar amount should be $0.00)
H - Validate and Deposit
(ECP US & CAN)
I - Verify and Deposit (ECP US)
J - Pre-note Only - Credit (ECP)
K - Issuance (Stored Value)
L - Add Value (Stored Value)
N - Refund (ECP)
O - Forced Validate (ECP)
P - Pre-note Only - Debit (ECP)
Q - Stored Value Current Balance Inquiry
(Stored Value)
R - Refund (Credit Card, Stored Value)
V - Validate Only (ECP US & CAN)
Y - Verify and Pre-note (ECP)

Page 6
09/21/2001
RECORD LAYOUTS
Transaction File Detail Record

1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
1299000000004995840
1
Position
26,27
Length
2
Data
Type
Field Name
Comments
A
Method of Payment (MOP) Methods of Payment
AX - AmericanExpress/Optima
BL - BillMeLater
CB - CarteBlanche
DC - Diners Club
DI - Discover (Novus)
EC - Electronic Check
EN - Encryption (see notes below)
JC - JCB
MC - MasterCard
SV - Stored Value
SW - Switch/Solo
VI - Visa/Delta
Note: For additional methods of payment
processing, please contact your
Paymentech representative.
The encryption (EN) MOP must be used in
conjunction with the encryption flag in the
transaction file.
28, 46
19
Account Number
Credit card, bank account number, or

Bill Me Later account number. Left
justified/blank filled
Note: For ECP transactions, the account
number is 17 positions only. Encrypted
credit card numbers are 16 to 19 positions.
For Bill Me Later transactions, this field
should contain the BML account number,
or the BML bin number (504990)
followed by ten zeros (16 byte account
number).
47,50
Expiration Date
MMYY (Optional field leave blank if

unknown)
51,62
12
Amount
2 decimal implied/right justified/zerofilled

(See Field Definition)
Continued on next page

Page 7
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Detail Record (Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
1299000000004995840
1
Position
63,65
66,68
Length
3
Data
Type
N
Field Name
Currency Code
Response Reason Code
Comments
Allowable values include:
036 - Australian Dollars
040 - Austria (Austrian) Schilling
056 - Belgium Francs
826 - British Pounds Sterling
124 - Canadian Dollars
208 - Danish Krone (Krona)
978 - Euro
246 - Finland (Finnish) Markka
250 - French Francs
280 - German Deutsche Marks
300 - Greece Drachma
344 - Hong Kong (Dollars)
380 - Italian Lira
372 - Irish Punt
392 - Japanese Yen
528 - Netherlands Dutch Guilders
554 - New Zealand Dollars
578 - Norwegian Krone (Krona)
620 - Portugal (Portuguese) Escudo
702 - Singapore Dollar
710 - South African Rand
724 - Spanish Peseta
752 - Sweden (Swedish) Krona
756 - Swiss (Switzerland) Franc
840 - U.S. Dollars
(see field definitions)
Result of action requested
Note: If action code is Authorization (A) or

Conditional Deposits (B), this field should be
blank. It will be populated by Paymentech
when returning the response. For Deposit (D)
transactions, this field should be populated
with the information provided from the
authorization response.

Page 8
09/21/2001
RECORD LAYOUTS
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
1299000000004995840
1
Position
Length
Data
Type
Field Name
Comments
69
Transaction Type
R - Retail Merchant
1 - Single Transaction mail/telephone
order
2 - Recurring Transaction
3 - Installment Payment
4 - Deferred Transaction
5 - Secure Electronic Commerce
Transaction
6 - Non-authenticated SET Transaction
(for future use)
7 - Non-SET Transaction Channel
Encrypted
8 - Non-Secure Electronic Commerce
Transaction (will not qualify for best
interchange rate)
70
71,76
1
6
A
N
Reserved
Response Date
Reserved (Do Not Use)

YYMMDD format
Authorization/Verification
Code

when returning the response. For Deposit
(D) transactions, this field should be
populated with the information provided
from the authorization response.
Left justified
77,82

when returning the response. For Deposit
(D) transactions, this field should be
populated with the information provided
from the authorization response.

Page 9
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
1299000000004995840
1
Position
83,84
Length
2
Data
Type
A
Field Name
AVS/AAV Response Code
Comments
AVS/AAV result (Optional)
Conditional Deposits (B) this field should be
when returning the response.
85
86
1
1
A
A
Reserved
Fraud Indicator
87, 89
Encryption Flag
The encryption flag will be either a one-byte

value or a three-byte value. Contact your
Paymentech representative for the
appropriate value.
YBlank -
Partial Participants
Non-Participants/Full Participants
If assigned as a one-byte value, value should

be left justified/blank filled.
FFUSA Program
CCitibank Program
Three byte encryption flags will be assigned
by your Paymentech representative.
MOP type must be populated with either EN
for encryption, or the actual card method (i.e.
VI for Visa).
Note: the encryption flag is case sensitive.
Leave encryption flag blank for no
encryption.
90, 91
92
93,96
2
1
4
A
A
A
Reserved
Filler
Merchant Space

To begin using encryption, please contact

your Paymentech representative for the
appropriate value.
Blanks
For Merchant use (Optional)
Page 10
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction Extension Record Format: American Express 1
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EAX001ABC COMPANY ADDITIONAL DESCRIPTOR 1
ABC COMPANY ADDITIONAL DESCRIPTOR 2
Position
Data
Length Type
Field Name
Comments
Extension Record Identifier "E" Constant
2,3
Extension Record
MOP Type
4,6
Extension Record Sequence 001 Constant

Number
7,46
40
TAA 1
Transaction Advice Addendum #1
47,86
40
TAA 2
87,96
10
Filler
Blanks
"AX" Constant
Notes: TAA fields are not supported in International currency processing

AS record must be sent in after the extension record

Page 11
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction Extension Record Format American Express 2
1
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
EAX002ABC COMPANY ADDITIONAL DESCRIPTOR 3
ABC COMPANY ADDITIONAL DESCRIPTOR 4
Position
Length
Data
Type
2,3
Extension Record
MOP Type
"AX" Constant
4,6
Extension Record
Sequence Number
002 Constant
7,46
40
TAA 3
47,86
40
TAA 4
87,96
10
Filler
Blanks
Field Name
Comments
Notes: TAA fields are not supported in International currency processing

AS record must be sent in after the extension record

Page 12
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: MasterCard
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNANANNNNNNNNNAAAAAAAAAANNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EMC00190104 123456789
00000000199912995964
Position
Length
Data
Type
Extension Record Identifier
"E" Constant
2,3
Extension Record MOP Type
"MC" Constant
4,6
Extension Record Sequence

Number
001 Constant
POS Capability Code
Required field for retail deposit

transactions (See Field Definition)
8,9
POS Entry Mode

10
POS Authorization Source

Code

11
POS Card ID Method

12
Filler
Blank
13,21
Banknet Reference Number
Reference Number assigned by the

MasterCard authorization system
22,31
10
Filler
Blanks
32,43
12
Authorized Amount
Implied decimal/right justified/zerofilled. Use the amount of the

original authorization
44,47
Banknet Date
Authorization date assigned by the

MasterCard authorization system
MMDD
48,51
MCC
Merchant Category Code used for

the authorization (see field
definition)
52,96
45
Filler
Blanks
Field Name

Comments
Page 13
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Visa 1
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNANANNNNNNNNNNNNNNNAAAANNNNNNNNNNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EVI0O190104V123456789012345MCX50000000019995964000000001999
Position
Length
Data
Type
"E" Constant
2,3
Extension Record
MOP Type
"VI" Constant
4,6

Number
001 Constant
POS Capability Code

8,9
POS Entry Mode

10
POS Authorization Source

Code

11
POS Card ID Method

12
Authorization Characteristic
Indicator
Indicates PS2000 transaction
13,27
15
Transaction
Identifier
TID value is assigned by the VISA

authorization system
28,31
Validation Code
Validation code value is assigned by

the VISA authorization system
32,43
12
Authorized Amount
Implied decimal/right justified/zerofilled. Use the authorized amount of

the original transaction
44,47
MCC Code
MCC Code used when the

authorization was obtained (see field
definition)
48,59
12
Total Authorized Amount
Implied decimal/right justified/zerofilled. Current amount authorized for

deposit
60,96
37
Filler
Blanks
Field Name

Comments
Page 14
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Visa 2 Visa Authentication
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNANANNNNNNNNNNNNNNNAAAANNNNNNNNNNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EVI002EARF234521Y
452315643286389
Position
Length
Data
Type
"E" Constant
2,3
Extension Record
MOP Type
"VI" Constant
4,6

Number
002 Constant
7,46
40
Transaction ID (XID)
Unique Tracking Number
47, 86
40
Cardholder Authentication
Verification Value
Derived Cryptographic Value
87
CAVV Response Code
This field should remain blank on

input. Paymentech will populate with
response code received from Visa.
CAVV
Description
Result
Code
Blank
CAVV not validated
0
CAVV not validated due
to erroneous data
submitted
1
CAVV failed validation
2
CAVV passed validation
3
CAVV validation could
not be performed
Field Name
Comments
A 3-D secure
authentication value of 5
from ACS indicates
attempt, but not able to
complete
CAVV validation could
not be performed
A 3-D secure
authentication value of 6
from ACS indicates
system error or failure
by ACS
87,96
10
Filler

Blanks
Page 15
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Electronic Check Processing
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EEC001123456789
CB
Position
Length
Data
Type
"E" Constant
2,3
Extension Record MOP Type
"EC" Constant
4,6

Number
001 Constant
7,15
RDFI/Bank ID
16,20
Filler
Blanks
21
Account Type
Bank Account Type
Field Name
Comments
C - Consumer Checking Account

(U.S. and Canada)
S - Consumer Savings Account
(U.S. only)
X - Corporate Checking Account
(U.S. only)
22
Preferred Delivery Method
Payment Delivery Method

A - ACH (US & CAN)
See Field Definition
B - Best Possible Method
(U.S. only)
F - Facsimile Draft (U.S. only)
23, 38
16
Reserved
39
ECP Authorization Method

W - Written
I - Internet (Web)
T - Telephone
Notes: U.S. ECP only. Account
type must be C.
40,96
57
Filler
Blanks
Note: AM record for Electronic Check Processing is required for deposit

Page 16
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Switch (UK) Debit Card
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ESW001109601
Position
Data
Length Type
Field Name
Comments
2,3
Extension Record MOP
"SW" Constant
4,6
Extension Record
Sequence Number
001 Constant
7,10
Card Start Date
MMYY Format
11,12
Card Issue Number

13,96
84
Filler
Blanks

Page 17
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Bill Me Later
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAANNNNNNNNNNNNNNNNNNNNNAANNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EBL001000001981234500011225N7400
NNNN
Position
Length
Data
Field Name
Type
A
Extension Record
Identifier
2,3
Extension Record
MOP Type
BL Constant
4,6
Extension Record
Sequence
001 Constant
7, 14
Shipping Cost
Total shipping cost of consumer purchase.

2 decimal implied/right justified/zero filled.
15,19
T&C Version
The Terms & Conditions version number

the consumer agreed to.
20,27
Customer
Registration Date
Date customer registered with Merchant.

Format CCYYMMDD.
28,29
Customer Type Flag
New or existing customer with Merchant.

Left justified/blank filled.
30,33
Item Category
34,49
16
Pre-approval
Invitation Number
Comments
E Constant
N = New
E = Existing
Product description code assigned by Bill
Me Later. (required)
Indicates whether or not consumer has been
pre-approved.
Pre-approval from credit bureau
should include the 16 digit preapproval number.
Internal pre-approval should include
the leftmost digit as a 1.
No pre-approval should include all
zeros or blank filled.

Page 18
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Extension Record: Bill Me Later, (Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAANNNNNNNNNNNNNNNNNNNNNAANNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
EBL001000001981234500011225N7400
NNNN
Position
Length
Data
Field Name
Type
N
Merchant
Promotional Code
Comments
50,53
54
Customer Password
Change
Indicates if customer has changed password

at merchant site.
Y = password has been change
N = no change to password
(optional)
55
Customer Billing
Address Change
Indicates is customer has updated billing

address at merchant site.
Y = billing address has been updated
N = no change to billing address
(optional)
56
Customer Email
Change
Indicates if customer had updated email

address at merchant site.
Y = customers email address has been
updated
N = no change to customers email
address
(optional)
57
Customer Phone
Change
Indicates if customer has updated phone

number at merchant site.
Y = customers phone number has
changed
N = no change to customers phone
number
(optional)
58,96
39
Filler
Blanks
Merchant promotional code. Left

justified/blank filled. (optional)

Page 19
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Information Record: Order Information
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNNNNNNNNNNNNNNNAAANNNNNNNNNNANNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
IOISVC
011226015700
Position
Length
Data
Field Name
Type
A
Information Record
Identifier
Comments
2,3
Information Record
OI Constant
Order Information
4,6
Product Delivery
Type Indicator
7,8
Shipping Carrier
Delivery type of product

CNC - Cash & Carry (BML)
DCT - Digital Content/text or images
(PTI Fraud)
DIG - Digital Goods
(BML/PTI Fraud/Visa)
DNP - Digital and Physical (PTI Fraud)
GFT - Gift Certification (PTI Fraud)
PHY - Physical Delivery Required
REN - Renewals and Recharges
(PTI Fraud)
SHW - Shareware (PTI Fraud)
SVC - Service (BML)
TBD - To Be Determined (BML)
(required for BML transactions)
Shipment carrier for an item. Note:
applicable for use with Paymentech Fraud
Detection Service only. Valid values are as
follows:
DH DHL
FE Federal Express
GH Greyhound
OH Other
PL Purolator
PS USPS
UP United Parcel Service
(optional)
I Constant
continued on next page

Page 20
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Information Record: Order Information
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
IOISVC
011226015700
Position
Length
Data
Field Name
Type
A
Shipping Method
Comments
Method of shipment for an item. Note:
applicable for use with Paymentech Fraud
Detection Service only. Valid values are as
follows:
C D I M N O P T W (optional)
Lowest Cost
Carrier Designated by Customer
International
Military
Next Day/Overnight
Other
Store Pickup
Two Day Service
Three Day Service
10,15
Order Date
Date of order. Format YYMMDD.
16,21
Order Time
Time of order. Format HHMMSS.
22,96
75
Filler
Blanks

Page 21
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Information Record: Consumer Information
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
IPI00101700318
8400075000000O1005YY
Position
Length
Data
Type
A
2,3
4,6
7,14
15,23
8
9
N
N
24,26
Field Name
Information Record
Identifier
Information Record
Information Record
Sequence
Customer Date of Birth
Customer Social
Security Number
Currency Type of
Gross Household
Annual Income
Comments
I Constant
PI Constant
Consumer Personal Information
001 Constant
Customer date of birth. CCYYMMDD format.
Customer social security number.
(optional)
Currency type of gross household annual
income. Allowable values include: (optional)
978 - Euro
250 - French Francs
380 - Italian Lira
372 - Irish Punt
392 - Japanese Yen
752 - Sweden(Swedish)Krona
756 - Swiss (Switzerland)
840 - U.S. Dollars

Page 22
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Information Record: Consumer Information, (Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
IPI00101700318
8400075000000O1005YY
Position
Length
Data
Type
Field Name
Comments
27,36
10
Gross Household
Annual Income
Gross household annual income. 2 decimal

implied/right justified/zero filled.
37
Customer Residence
Status
Status of customer residence. Allowable

values include: (optional)
O=Own
R=Rent
X=Other
38,39
Customer Years at
Residence
Number of years at current residence. Left

justify/blank filled. (optional)
40,41
Customer Years at
Employer
Number of years customers has worked

with current employer. Left justified/blank
filled. (optional)
42
Customer Checking
Account
Allowable values: (optional)

Y = Yes customer has checking account.
N = No customer does not have checking
account.
43
Customer Savings
Account
Allowable values; (optional)

Y = Yes customer has savings account.
N = No customer does not have savings
account.
44,96
53
Filler
Blanks

Page 23
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Procurement Level 2
NOTE: Level 2 Procurement Product Record is also required to process Level 3 data
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAAAAAAAAAAAAAAAANNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
PPC001ABC12300000000000000000000101
Position
Data
Length Type
Field Name
Comments
Product Record Identifier
"P" Constant
2,3
Product Record Type
"PC" Constant
4,6
Product Record Sequence

Number
001 Constant
7,23
17
Customer Reference
Number
Purchase Order or other

number used by the
Merchants customer to track
the order. Left
justified/blank filled.
Note: For level 2 processing,
this field is not required,
however, must be filled in to
qualify for lower rate.
For level 3 processing, this
field is required. If this field
is not filled in, transaction
will reject.

Page 24
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Procurement Level 2 (continued)
NOTE: Level 2 Procurement Product Record is also required to process Level 3 data
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAAAAAAAAAAAAAAAANNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
PPC001ABC12300000000000000000000101
Position
24,35
Data
Length Type
Field Name
12
N
Sales Tax Amount
Comments
Amount of sales tax assessed
to the transaction, 2 decimal
implied/right justified/zerofilled.
Note: For level 2 processing,
this field is not required,
however, must be filled in to
qualify for lower rate.
For level 3 processing, this
field is required. If this field
is not filled in, transaction
will reject.
36,96
61
Filler
Blanks
Note: Method of payments that can process level 2 are Visa, MasterCard and American Express

Page 25
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Procurement Level 3 - Visa
Order Level Record (must be preceded by Product Record Procurement Level 2)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNNNNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAANNNNNNNNNNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAAAAA
PP000100000000159900000000159903079-1952USD03079-1952
10
30000010
Data
Position Length Type
Field Name
Comments
Product Record ID
"P" Constant
2,3
Product Record Type
"P0" Constant
4,6

Number
001 Constant
7,18
12
Freight Amount
Two decimal implied/right

justified/zero-filled or blanks
19,30
12
Duty Amount

31,40
10
Destination Zip Code
Left justified/blank filled
41,43
Destination Country Code
44,53
10
Ship From Zip Code
54,65
12
Discount Amount Applied to

Order

justified/zero-filled/numeric or blanks
66,77
12
VAT/Tax Amount

justified/zero-filled or blanks if nonapplicable
78,81
VAT/Tax Rate

justified/zero-filled or blanks if nonapplicable
82,96
15
Filler
Blanks

Page 26
09/21/2001
RECORD LAYOUTS
(Continued)
Record #1 - Line Item Level Data (must match to corresponding Line Item Level Data Record 2)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNNNNNNNNNNNAAAAAAAAAAAANNNNNNNNNNNNANNNNAA
PP1002FILE CABINET
SKU123456789000000030000QTY
000000009000 0010
Data
1
1
A
Field Name
Product Record ID
Comments
"P" Constant
2,3
Product Record Type
"P1" Constant
4,6

Number
002 to 099
Right justified/leading zeros
Used to uniquely identify a line item
within a product record. A line item
must consist of a matching P1 and P2
record submitted in sequential order and
would increase in increments of one (1)
Note: See Appendix L for Record
Sequence Number Example
7,32
26
Description
33,41
Filler
Blanks
42,53
12
Product Code
54,65
12
Quantity
Four decimal implied/right

justified/zero-filled
Cannot be all zeroes
66,77
12
Unit of Measure
78,89
12
Tax Amount

justified/zero-filled/blank if tax nonapplicable
90
Filler
Blanks
91,94
Tax Rate

95,96
Filler
Blanks

Page 27
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNNNNNNNNNNNNNNNNNNNNNNNNNAAAAAAAAAAAANNNNNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
PP20020
10000
9000FURNITURE 000001000000
Position Length
1
1
Data
Type
A
Field Name
Product Record ID
"P" Constant
Comments
2,3
Product Record Type
"P2" Constant
4,6

Number
002 to 099. Sequence number is required

to match that of the accompanying P1
record; right justified/leading zeros
Note: See Appendix L for Record Sequence
Number Example
7,18
12
Line item total
Two decimal implied/right justified/zerofilled
19,30
12
Discount Amount for Line

Item
Two decimal implied/right justified/zerofilled/blank if no discount is applied
31,42
12
Item Commodity Code
43,54
12
Unit Cost
Four decimal implied/right justified/zerofilled

Example: 01000000 = $100.00
55,96
42
Filler

Blanks
Page 28
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Procurement Level 3 - MasterCard
Order Level Record (must be preceded by Product Record Procurement Level 2)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAANNNNNNNNNAAANNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNNNNNNNNNAAAAAAAAAAAAAAA
PP0001
000001599
00000159903079-1952USD03079-1952130131132133134
000001999
Data
Field Name
Comments
Product Record ID
"P" Constant
2,3
Product Record Type
"P0" Constant
4,6

Number
001 Constant
7,9
Filler
Blanks
10,18
Freight Amount
Two decimal implied/right justified/zerofilled or blanks
19,21
Filler
Blanks
22,30
Duty Amount
31,40
10
41,43
44,53
10
Ship From Zip Code
54,68
15
Alternate Tax ID

Note: required if there is an amount in
Alternate Tax Amount
69,71
Filler
Blanks
72,80
Implied decimal/right justified/zero-filled

or blanks if non-applicable
Note: if this is filled in Alternate Tax ID
required
81,96
16
Filler
Blanks

Page 29
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAANNNNNAAAAAAAAAAAAAAANNNNNNNNNNNNNNAA
PP1002FILE CABINET
SKU123456789
00300QTY
00000900001000
Positio
n
1
Length
Data
Type
Product Record ID
"P" Constant
2,3
Product Record Type
"P1" Constant
4,6

Number
002 to 099
Field Name
Comments
Right justified/leading zeros

Used to uniquely identify a line item
within a product record. A line item must
consist of a matching P1 and P2 record
submitted in sequential order and would
increase in increments of one (1)
Note: See Appendix L for Record
Sequence Number Example
7,41
35
Description
42,53
12
Product Code
54,60
Filler
Blanks
61,65
Quantity
Right justified/zero-filled or blanks
66,68
Unit of Measure
Left justified/blanks
69,80
12
Filler
Blanks
81,89
Tax Amount
Two decimal implied/right justified/zerofilled or blanks if non-applicable
90,94
Tax Rate
Five decimal implied/right justified/zerofilled or blanks

Example: 01000 = 1%
95,96
Filler
Blanks

Page 30
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAANNNAAANNNNNNNNNAAANNNNNNNNNAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
PP2002
000003000
000000010
NFED Y
Data
Positio Length Type
n
1
1
A
Field Name
Product Record ID
Comments
"P" Constant
2,3
Product Record Type "P2" Constant
4,6
Product Record Seq

Nbr
002 to 099. Sequence number is required to

match that of the accompanying P1 record;
right justified/leading zeros
7,9
Filler
Blanks
10,18
Line Item Total
19,21
Filler
Blanks
22,30
Discount Amount
31,54
24
Filler
Blanks
55
Gross/Net Indicator
Values are:
Y = item amount includes tax amount
N = item amount does not include tax amount
Note: Y or N must be uppercase (Required)
56,59
Tax Type Applied
60
Discount Indicator
Values are:
Y = amount is discounted
N = amount is not discounted
Note: Y or N must be uppercase (Required)
61,96
36
Filler
Blanks

Page 31
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Fraud
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PFR001827 1
Position
Length
Data
Type
P Constant
2, 3
Product Record Type
FR Constant
4, 6
001 Constant
7, 10
Card Security Value
Amex CID, Discover CID,

MasterCard CVC2, or Visa CVV2
number. Left justified/blank filled.
Field Name
Comments
If not doing Amex CID, Discover

CID, MasterCard CVC2, or Visa
CVV2, leave blank. It is against
regulations to store this value.
Amex value is 4 bytes in length.
Discover CID, MasterCard CVC2
and Visa CVV2 are 3 bytes in
length.

Page 32
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Fraud
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PFR001827 1
Position
Length
Data
Type
11
Field Name
Card Security Presence
Comments
Supported by Discover and Visa
only
1 - Value is present
2 - Value is on card, but illegible
9 - Card holder states that the card
has no card security value
Note: If not a Discover or Visa
transaction, leave blank. If a value
is sent in for MasterCard, it will be
ignored since it is not supported at
this time.
If customer does not indicate either
a 1, 2, or 9, leave blank.
12,96
85
Filler
Blanks
Note: This fraud record used for authorizations and conditional deposits only

Page 33
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Retail Enable
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PRR001
9876543
29
Position
Length
Data
Type
P Constant
2,3
Product Record Type
RR Constant
4,6
001 Constant
7,22
16
Terminal Identification
23,36
14
Batch Identification
37,96
60
Filler
Blanks
Field Name

Comments
Page 34
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Stored Value
Note: Product record must be sent in the input file in order to receive reply in the output file.
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PSV001
Position
Length
Data
Type
P Constant
2,3
Product Record Type
SV Constant
4,6
001 Constant
7,18
12
Current Balance
Current balance. Two decimal

implied/right justified/zero-filled.
Blank fill for input. Paymentech
will populate in the reply file.
19,30
12
Previous Balance
Previous balance prior to sale. Two

decimal implied/rightjustified/zero-filled. Blank fill for
input. Paymentech will populate in
the reply file.
31,96
66
Filler
Blanks
Field Name
Comments
Notes:
Any information sent in the input file will be overwritten in the reply file. Paymentech does not store any data send
in input file.
Method of Payment (MOP) must equal SV when sending this product record.

Page 35
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Product Record: Various Text
Note: PVT001 is for future use
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PVT001
Position
Length
Data
Type
P Constant
2,3
Product Record Type
VT Constant
4,6
001 Constant
7,96
90
Text Message
Text message
Field Name

Comments
Page 36
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Address Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
ABJOE *BAGADONUTS
W60355512128321US
A21 MAIN STREET
H6035558854
A3SALEM, NH 03079-9099
Position
Data
Length Type
Field Name
Comments
"A" Constant
Address Type
Address Types:
Note: below types followed by any necessary
Extension Records
Type
Description
B
ZIP only or Consumers

name (asterisk should
precede last name)
BML,
CC, SV
Consumer employer
information
BML,
CC
Person receiving gift
CC, SV
Consumer IP address
(see specific format)
BML,
CC
Consumer email address

(see specific format)
BML,
CC, SV
Name (asterisk should

precede last name) as it
appears on the check
followed by any
necessary extension
records.
ECP
Ship to address
(asterisk should precede
last name)
BML,
CC, SV
BML Bill Me Later

CC
Credit Card
ECP
Electronic Check Processing
SV
Paymentech Stored Value
Note: Type B and S are recommended but not
required for American Express procurement
record level II and is not used for AAV
verification.
Extension Record Indicators:
Extension Record
2 - 1st
3 - 2nd
Extension Record
4 - 3rd
Extension Record
Extension Record
5 - 4th
Note: see field definitions and address samples

Page 37
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Address Record, (continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
ABJOE *BAGADONUTS
W60355512128321US
A21 MAIN STREET
H6035558854
A3SALEM, NH 03079-9099
Note: below format applicable for the following address types: B, E, G, M, S

Position
3,32
Data
Length Type
Field Name
30
A
Address Line
33
Telephone Type
34,47
14
Telephone Number
Comments
Uppercase only
D - Day Phone Number
H - Home Phone Number
N - Night Phone Number
W - Work Phone Number
AAAEEENNNNXXXX
AAA
EEE
NNNN
XXXX
=
=
=
=
Area Code
Exchange
Number
Extension
Blank fill if not used

48,49
Country Code
Country code. Current values are:

US United States
CA Canada
GB Great Britain
50,96
47
Filler
Blanks

Page 38
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AIB012.200.095.085
Note: below format applicable for the following address type: I

Data
Position
3
Length Type
1
Field Name
Address Subtype
Comments
Type of address. Valid values are as
follows:
B = Bill To/Buyer Address
4,46
45
Customer IP Address
Customers IP address
47,96
50
Filler
Blanks
Note: Characters are acceptable (i.e. dots)

Page 39
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
[email protected]
Note: below format applicable for the following address type: L

Data
Position
3
Length Type
1
Field Name
Address Subtype
Comments
Type of address. Valid values are as
follows:
B = Bill To/Buyer Address
G = Giftee Email Address
4,51
50
Customer Email
Address
Customers email address
52,96
45
Filler
Blanks
Note: Characters are acceptable (i.e. dots)

Page 40
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Address Format Examples
NOTE: PAYMENTECH RECOMMENDS SENDING FULL ADDRESS
The following are three (3) separate examples of valid Address Record combinations for Credit Card
Transactions (address types B, G, S):
0
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
#1 - ZIP only
AB03052
US
#2 - Full Name and Billing Address

ABJOE *BAGADONUTS
A21 MAIN ST
A3SALEM, NH 03079
W60355512128321US
#3 - Full Name and Billing Address plus Ship-to Address

ABJOE *BAGADONUTS
A21 MAIN ST
A3SALEM, NH 03079
ASJOE *BAGADONUTS
A213 LAKEVIEW DR
A3PLYMOUTH, NH 03062
W60355512128321US
H6035558854
The following are two (2) separate examples of valid address record combinations for ECP
transactions (address type M):
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
#1 Name only
AMJOSEPH M. *BAGADONUTS
#1 Full Name and Address
AMJOSEPH M. *BAGADONUTS
A21 MAIN ST
A3SALEM, NH 03079
W60355512128321US

Page 41
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Address Format Examples
0
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
(address type E)
#1 Employer Address
AEPAYMENTECH
W60355512128321
(address type L)
#2 Email Address
[email protected]
(address type I)
#3 IP Address
AIB10.10.1.2

Page 42
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Batch Totals Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAAAAAANNNNNNNNNAAAAAANNNNNNNNNAAAAAANNNNNNNNNNNNNNAAAAAAANNNNNNNNNNNNNNAAAAAAAAANNNNNNNNNNNNNNA
B RECS=000000006 ORDS=000000005 $TOT=00000000027347 $SALE=00000000021549 $REFUND=00000000000000
Position
Length
Data
Type
Field Name
Comments
1,7
Constant
B RECS=
8,16
Batch Record Count
Total Count of all Records prior to

the Batch Totals Record
17
Filler
Blank
18,22
Constant
ORDS=
23,31
Batch Order Count
All Detail Records
32
Filler
Blank
33,37
Constant
$TOT=
38,51
14
Batch Amount Total
Gross Amount Total

(ABSOLUTE AMOUNT sales +
ABSOLUTE AMOUNT refunds +
ABSOLUTE AMOUNT
authorizations)
52
Filler
Blank
53,58
Constant
$SALE=
59,72
14
Batch Amount Sales
All sales transactions
73
Filler
Blank
74,81
Constant
$REFUND=
82,95
14
Batch Amount Refunds
All refund transactions
96
Filler
Blank

Page 43
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Totals Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
AAAAAAANNNNNNNNNAAAAAANNNNNNNNNAAAAAANNNNNNNNNNNNNNAAAAAAANNNNNNNNNNNNNNAAAAAAAAANNNNNNNNNNNNNNA
T RECS=000000006 ORDS=000000005 $TOT=00000000027347 $SALE=00000000021549 $REFUND=00000000000000
Position
Length
Data
Type
Field Name
Comments
1,7
Constant
T RECS=
8,16
File Record Count
Total of all Records prior to the

Totals Record
17
Filler
Blank
18,22
Constant
ORDS=
23,31
File Order Count
All Detail Records
32
Filler
Blank
33,37
Constant
$TOT=
38,51
14
File Amount Total
Gross Amount Total

(ABSOLUTE AMOUNT sales +
ABSOLUTE AMOUNT refunds +
ABSOLUTE AMOUNT
authorizations)
52
Filler
Blank
53,58
Constant
$SALE=
59,72
14
File Amount Sales
All sales transactions deposited
73
Filler
Blank
74,81
Constant
$REFUND=
82,95
14
File Amount Refunds
All refund transactions deposited
96
Filler
Blank

Page 44
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Trailer Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PID=123456 ABCCO
SID=123456 ABCCO
END 971231
Position
Length
Data
Type
Field Name
Comments
1,4
Constant
PID=
5,10
Presenters ID (PID)
11
Filler
Blank
12,19
PID Password
20
Filler
Blank
21,24
Constant
SID=
25,30
Submitters ID (SID)
31
Filler
Blank
32,39
SID Password
40
Filler
Blank
41,43
Constant
END
44,45
Filler
Blanks
46,51
Creation Date
52,96
45
Filler
Blanks

Page 45
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File Request for Response (RFR) Record
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
PID=123456 ABCCO
SID=123456 ABCCO
RFR 971231
Position
Length
Data
Type
Field Name
Comments
1,4
Constant
PID=
5,10
Presenters ID (PID)
11
Filler
Blank
12,19
PID Password
20
Filler
Blank
21,24
Constant
SID=
25,30
Submitters ID (SID)
31
Filler
Blank
32,39
SID Password
40
Filler
Blank
41,43
Constant
RFR
44,45
Filler
Blanks
46,51
Creation Date
52,96
45
Filler
Blanks
Note: If a RFR record is received by Paymentech, however, there is no file available for pick up, the following
message will be given:
YY-MM-DD HH:MM:SS No data to send back at this time.
EOFEOFEOF
- Message is sent in text file format without header or pid information and begins in position 2
- Async and TCPIP merchants will receive entire message noted above, with the EOF line
- Bsync and FTP merchants will receive message above, without the EOF line
- RFR is a separate file sent to Paymentech. It should not be sent as part of your data file.

Page 46
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File S Record Output
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
12990000000049958401001M981109123456I1Y
H243
Position
Length
Data
Type
1
2,7
8,23
1
6
16
A
N
A
Constant
Division Number
Merchant's Order Number
"S"
Assigned by Paymentech (Required)
Number composed of any alpha, blank, digit or
punctuation combination that will be returned when
we respond. This field will tie the request on your
end to the response we provide you. It should be
unique to the transaction and should be stored and
supplied in the deposit file. (Required)
24,25
Action Code
Action Requested
Field Name
Comments
A
B
D
E
G
H
I
J
K
L
N
O
P
Q
R V Y -
26,27
Method of Payment (MOP)
Authorize (Credit Card, Stored Value)

Conditional Deposit (Credit Card)
Deposit (Credit Card, Stored Value)
Authorization Reversal (Stored Value)
Verify Only (ECP US)
Validate and Deposit (ECP US & CAN)
Verify and Deposit (ECP US)
Pre-note Only - Debit (ECP)
Issuance (Stored Value)
Add Value (Stored Value)
Refund (ECP)
Forced Validate (ECP)
Pre-note Only - Credit (ECP)
Stored Value Current Balance Inquiry (Stored
Value)
Refund (Credit Card, Stored Value)
Validate Only (ECP US & CAN)
Verify and Pre-note (ECP)
Methods of Payment
AX - AmericanExpress/Optima
BL - Bill Me Later
CB - Carte Blanche
DC - Diners Club
EN - Encryption (see field definition)
JC - JCB
MC - MasterCard
SV - Stored Value
SW - Switch/Solo
VI - Visa/Delta

Page 47
09/21/2001
RECORD LAYOUTS
(Continued)
Transaction File S Record Output (Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
12990000000049958401001M981109123456I1Y
H243
Position
Length
Data
Type
28, 46
19
Account Number
47, 50
Expiration Date
Credit card number, encrypted credit card

number, BML account number or blank for
ECP. Left justified/blank filled. Returned for
all credit card transactions.
Note: ECP transaction do not return account
number and expiration date.
Approved Bill Me Later transactions will return
16 digit Bill Me Later account number.
MMYY
51,62
12
Amount
Two decimal implied/right justified/zero-filled
63,65
Currency Code
66,68
Response Reason Code
Allowable values include:

978 - Euro
250 - French Francs
380 - Italian Lira
372 - Irish Punt
392 - Japanese Yen
840 - U.S. Dollars
Result of Action Requested
Field Name
Comments

Page 48
09/21/2001
RECORD LAYOUTS
(Continued)
1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
12990000000049958401001M981109123456I1Y
H243
Position
Length
Data
Type
69
Transaction Type Used
R
1
2
3
4
5
70
Card Security Value Response
MN P S -
Field Name
(Discover, MasterCard, Visa

Only)
71,76
Response Date
Comments
-
Retail Merchant
Single Transaction mail/telephone order
Recurring Transaction
Installment Payment
Deferred Transaction
Secure Electronic Commerce
Transaction (for future use)
6 - Non-authenticated SET Transaction
(for future use)
7 - Non-SET Transaction Channel
Encrypted
8 - Non-Secure Electronic Commerce
Transaction (will not qualify for the best
interchange rate)
(See Field Definitions)
Value matched
Value not matched
Not processed
Should be on the card (Discover/Visa
only)
U - Unsupported by the issuer
I - Invalid (MasterCard, Visa only)
- Blank if not Discover, MasterCard, Visa
YYMMDD format. It should be stored and
supplied in the deposit file.

Page 49
09/21/2001
RECORD LAYOUTS

1
2
3
4
5
6
7
8
9
123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456
S1234569876543219876543 BVI4123456789012345
12990000000049958401001M981109123456I1Y
H243
Position
Length
Data
Type
77,82
Authorization/Verification
Code
Issued by the bank or service establishment. It

should be stored and supplied in the deposit file
83,84
AVS/AAV Response Code
AVS/AAV result
85
Deposit Flag
Payment Deposited Y/N
86
Fraud Indicator
Fraud Indicator
87,89
Encryption Flag
Encryption Flag
90,91
Recurring Payment Advice

Code
Code Values:
Field Name
(MasterCard Only)
Comments
01 New account information available

02 Try again later
03 Do not try again
92
Filler
Blank
93,96
Merchant Space
For Merchant Use (Optional)

Page 50
09/21/2001
FIELD DEFINITIONS
Introduction
Transaction File
Header Record
The following pages contain the exact definition of each field for each
record type that is to be filled in by the Merchant or vendor when sending
to Paymentech. See Record Layouts for information on how the fields are
to be arranged and for constant values for each record.
Field Name
Field Description
Presenters ID (PID) The PID is a number assigned to the location that

physically sends the data file (Presenter).
PID Password
Assigned by Paymentech.
Submitters ID
(SID)
SID Password
Creation Date
Fill this field with the date the file was created in
the YYMMDD format. (Optional)
Revision Number
Revision # of the Technical Specification used (for

example, 01.7), left justified, zero-filled.
Submission Number
Paymentechs Submission #. Populated by

Paymentech in output. Leave blank on incoming
submission.
Merchant Space
For merchant use. (Optional)

Page 51
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
Field Name
Field Description
Constant
Specifies this record as a detail record of the Paymentech

Standard format. S Constant.
Division Number
Merchant Order
Number
This field is for Merchant identification of transactions.

The first eight digits of the number should be unique*. The
number is referenced during problem resolution. This field
must be left justified.
*DO NOT USE: pipe (|), caret (^), percent symbol (%)
or backslash (\)
In processing MasterCard/Visa chargebacks, all 16
characters are utilized. American Express (AMEX) utilizes
the first 9 characters of this field. Discover utilizes the first
8 numerical characters. Therefore, the unique characters of
this number should be contained within the first 8 positions
of the field.
Note: Merchants should pass the same order number on
their authorization and deposit transactions.
Action Code
The action field tells Paymentech what service to perform

on the transaction. Values are:
A-
Authorize
Only
Authorize this transaction and fill

the Response Reason Code, Auth
Date, Auth Source, Auth Code
and AVS/AAV field, if
applicable, with the authorization
results. {Credit Card, Stored
Value}
B-
Conditional
Deposit
Deposit this transaction ONLY if

a valid authorization is obtained.
{Credit Card}
D-
Deposit Only
Deposit this transaction

REGARDLESS of authorization
status. The Merchant should send

a prior approval; otherwise
Paymentech may deposit a
declined transaction. {Credit
Card, Stored Value}

Page 52
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Action Code
(continued)
Authorization
Reversal
Reversal of authorization obtained

for PTI Stored Value card.
G-
Verify Only
Verify this transaction against 3rd

party negative file. (U.S. only)
{ECP}
H-
Validate and
Deposit
Validate this transaction can be

processed. Deposit this transaction
if it passes front-end validation.
(U.S. and Canada) {ECP}
I-
Verify and
Deposit
Deposit this transaction if it passes

front-end verification and
validation. (U.S. only) {ECP}
J-
Pre-note Only
- Credit
Pre-note this transaction if it

passes front-end validation. (U.S.
only) {ECP}
Issuance
Activate and add dollar value to

PTI Stored Value card. Physical
card can or cannot be present
Add Value
Add dollar value to a PTI Stored

Value card. Physical card can or
cannot be present
N-
Refund
Issue a credit to this account. (U.S.

and Canada) {ECP} (See Field
Definition, Extension Record,
ECP, Preferred Delivery Method
note)
O-
Forced
Validate
Depositable transaction bypasses

account number validation routine.
(Canada only) {ECP}
P-
Pre-note Only
- Debit
Pre-note this transaction if it

passes front-end validation. (U.S.
only) {ECP}
Q-
Stored Value
Current
Balance
Inquiry
Used to obtain the current balance

on a Paymentech Stored Value
card
R-
Refund
Issue a credit to this account

number. {Credit Card, Stored
Value}

Page 53
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Action Code
(continued)
Validate Only
Validate this transaction against

front-end edit checks at
Paymentech. (Mod 10, Thompson
File, Internal Negative File, etc.)
(U.S. and Canada) {ECP}
Y-
Verify and
Pre-note
Verify this transaction against 3rd

party negative file. If it passes,
send a pre-note to the customers
bank. (U.S only) {ECP}

Page 54
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Method of Payment
This field defines the MOP associated with this order.

Valid entries include:
AX - American Express/Optima
BL - Bill Me Later
CB - Carte Blanche
DC - Diners Club
EN - Encryption (see below notation)
JC - JCB
MC - MasterCard
SV - Stored Value
SW - Switch/Solo
VI - Visa/Delta
Note: For additional methods of payment processing,
please contact your Paymentech representative.
The encryption (EN) MOP must be used in
conjunction with the encryption flag in the transaction
file detail record.
Account Number
The account number must be left justified and blank

filled. This number is used to either identify the credit
card or the checking account used at the financial
institution for ECP transactions.
Note: For ECP transactions, the account number is 17
positions only. Encrypted credit card numbers are 16
to 19 positions.
For Bill Me Later transactions, the account number
field should be populated with either the consumers
Bill Me Later account number or Bill Me Later bin
number of 504990 followed by ten zeros (16 byte
number). Left justified/zero filled. For bin
number/zero fill, the consumers 16-digit account
number will be sent on the return record.

Page 55
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Expiration Date
MMYY format. Send blanks if the card has expired

since the order was placed or if the true expiration
date is not known. Paymentech assigns the appropriate
default value (dependent on the card type) that
indicates to the issuer that the true expiration date of
the card is unknown to the merchant. (Optional)
Note: Omitting the expiration date on a card-notpresent transaction, while acceptable to Visa and
MasterCard, may result in a decline code from the
issuer.
Amount
Fill this field with the amount of the charge. All

currencies imply two (2) decimal places.
For MasterCard, Visa and JCB transactions, the
amount must be greater than or equal to $0.01US
dollars*, but not greater than $25,000.00 US dollars*.
For American Express, Discover Card and
Diners/Carte Blanche transactions, the amount must
be greater than or equal to $1.00 US dollars*, but not
greater than $25,000.00 US dollars*.
*or established international currency equivalent
Note: Maximum US dollar amount per individual
transaction is $99,999.99. Individual transactions that
exceed $25,000 (or established international currency
equivalent or previously established Merchant limit)
must have the default limit increased in order for
transaction not to reject. Contact Paymentech
Merchant Services at 603-896-8333 prior to
processing transaction.

Page 56
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Currency Code
This is the currency code for the transaction. Allowable

values include:
040 - Austria (Austrian) Schilling**
056 - Belgium Francs**
978 - Euro
246 - Finland (Finnish) Markka**
250 - French Francs**
280 - German Deutsche Marks**
300 - Greece Drachma**
380 - Italian Lira**
372 - Irish Punt**
392 - Japanese Yen
528 - Netherlands Dutch Guilders**
620 - Portugal (Portuguese) Escudo**
724 - Spanish Peseta**
840 - U.S. Dollars
**Effective 12/27/01, the following currencies will reject
as they have converted to 978 Euro.

Page 57
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Response Reason
Code
Filled with the result of a transaction attempt. May be

filled by the Merchant if prior approval has been
obtained.
If this field is given, then the approval code must be
given; otherwise the information is ignored. Paymentech
returns the most recent approval or decline obtained.
See Appendix A for response reason code listings.
Note: If action code is Authorization (A) or Conditional
Deposits (B) this field should be blank. It will be
populated by Paymentech when returning the response.
These fields should not be populated on authorization or
conditional deposit transactions.

Page 58
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Transaction Type
Describes the circumstances under which the transaction

takes place:
R - Retail Merchant: designates a transaction where the
cardholder was present at a merchant location.
1 - MOTO Indicator - Single Transaction
mail/telephone order: designates a transaction
where the cardholder is not present at a merchant
location and consummates the sale via the phone or
through the mail. The transaction is not for
recurring services or product and does not include
sales that are processed via an installment plan.
2 - MOTO Indicator - Recurring Transaction:
designates a transaction that represents an
arrangement between a cardholder and the
merchant where transactions are going to occur on a
periodic basis.
3 - MOTO Indicator - Installment Payment: designates
a group of transactions that originated from a single
purchase where the merchant agrees to bill the
cardholder in installments.
4 - MOTO Indicator Deferred Transaction:
designates a transaction that represents an order
with a delayed payment for a specified amount of
time.
5 - ECI Indicator - Secure Electronic Commerce
Transaction: designates a transaction between a
cardholder and a merchant consummated via the
Internet where the transaction includes the
management of a cardholder certificate (SET).
6 - ECI Indicator - Non Authenticated SET (Secure
Electronic Transaction): designates a transaction
between a cardholder and a merchant consummated
via the Internet where the transaction does not
include the management of a cardholder certificate
(SET), but does include the management of a
merchant SET certificate. (for future use)

Page 59
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Transaction Type
(continued)
Describes the circumstances under which the

transaction takes place:
7 - ECI Indicator - Non SET (Secure Electronic
Transaction) Channel Encrypted: designates a
transaction between a cardholder and a merchant
consummated via the Internet where the
transaction does not include the management of
any SET certificates, but does include the use of
transaction encryption such as SSL.
8 - ECI Indicator - Non Secure Electronic
Commerce Transaction: designates a transaction
between a cardholder and a merchant
consummated via the Internet where the
transaction does not include the management of
any SET certificates and does not include the use
of any transaction encryption such as SSL.
(will not qualify for best interchange rate)
Note: Transaction Type may be defaulted at the
processing division level. If the default is set, all
transactions processed through the division will carry
the default Transaction Type value unless this field is
sent in the data field for processing (population of this
field overrides the division level default).

Page 60
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
Response Date
The date the response was obtained.

For credit card transactions, Paymentech
determines (using the most current Visa/MC rules)
whether or not the authorization should be retried
to improve discount rates and potentially reduce
chargebacks.
If a decline is received on the retry, yet the
Merchant has provided an earlier approval here
along with Authorization Code, Paymentech
ignores the decline and bases decisions on the
Merchant information.
See Sending Pre-Approved Records under Format
Usage for more information.
Conditional Deposits (B) this field should be blank.
It will be populated by Paymentech when returning
the response. For Deposit (D) transactions, these
fields should be populated with the information
provided from the authorization response. This
field should not be populated on authorization or
Authorization/
Verification Code
This is the authorization or verification code that is

obtained from the bank or proprietary card system.
If using separate authorization and deposit files,
this field must be populated in a deposit (D) action
code transaction, with the response obtained in the
authorization (A) transaction.
ECP transactions will return 123456.
the response. For Deposit (D) transactions, these
fields should be populated with the information
provided from the authorization response. These
fields should not be populated on authorization or

Page 61
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Detail Record
(continued)
Field Name
Field Description
AVS/AAV
Response Code
This is the code returned in response to an

AVS/AAV request.
the response. This field should not be populated on
authorization or conditional deposit transactions.
Fraud Indicator
Enter Y for partial participants. Leave blank for

full participants (division defaults to scoring) or if
no scoring is desired for a transaction.
Encryption Flag
The encryption flag will be either a one-byte value or a

three-byte value. Contact your Paymentech
representative for the appropriate value.
If assigned as a one-byte value, value should be left
FFUSA Program
CCitibank Program
Three byte encryption flags will be assigned by your
Paymentech representative.
MOP type must be populated with either EN for
encryption, or the actual card method (i.e. VI for Visa).
Note: the encryption flag is case sensitive. Leave
encryption flag blank for no encryption.
To begin using encryption, please contact your
Paymentech representative for the appropriate value.
Merchant Space
This is space reserved for the merchants use.

(optional). This data is not stored at Paymentech, but
is returned with the reply file.

Page 62
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
American Express 1&2
Field Name
Field Description
Extension Record
Identifier
Specifies this record as an extension record of the

Paymentech standard format. E Constant.
Extension Record
MOP Type
Identifies American Express (AX) as the specific

card type utilized for this transaction.
Extension Record
Sequence Number
001 Constant or
002 Constant.
Transaction Advice
Addendum Record
The TAA record is used to further identify the

purchase that is associated with the charge to the
cardholder. It is also used in Purchasing/
Procurement card transactions to provide specific
details about the transaction to the cardholder for
tracking purposes. TAAs should be as concise as
possible. A TAA of MERCHANDISE for
example, would not be acceptable.
The TAA must be in upper case. If a TAA in the
sequence is left blank, any TAA that follows will
be ignored.
Note: TAA fields are not supported in International currency processing

AS records must be sent in after the extension record

Page 63
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
MasterCard
Field Name
Field Description
Extension Record
Identifier

Extension Record
MOP Type
Identifies MasterCard (MC) as the specific card type

utilized for this transaction.
Extension Record
Sequence Number
001 Constant.
POS Capability
Code
This field defines the ability of the POS terminal or

cash register. Note: The value of 9 will not qualify
for the lowest interchange rate. Valid values include:
259-
POS Entry Mode
Magnetic strip reader. (Only valid for best

retail interchange rate).
Chip capable terminal
Keyed entry only.
Note: If this information is unavailable, this field

must contain blanks.
This field indicates how the transaction was entered.
Valid values include:
01 - Manually keyed.
02 - Magnetic stripe read. (General or Track 2)
05 - Initiated by a chip card; CVV data may be
reliable
06 - Magnetic stripe read. (Track 1)
81 - Manually keyed E-Commerce
(MasterCard Only)
90 - Entire magnetic stripe read and transmitted
95 - Initiated by a chip card; CVV data may be
unreliable
Note: If the value is unknown, the field may be
left blank.
The value 90 is required to qualify for the lowest
interchange rate.

Page 64
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
MasterCard
(continued)
Field Name
Field Description
POS Authorization
Source Code
This field indicates the source of the authorization.

Most POS Source Code terminals and electronic
cash registers (ECR) capture this information when
it is returned from the authorizing Vendor. Valid
values for this field are:
0-
Source Code unavailable.
1-
Stand-in processor(STIP), time out response.
2-
LCS response (amount below floor limit).
3-
STIP (issuer in suppress inquiry mode).
4-
STIP (issuer unavailable).
5-
Issuer provided.
7-
Acquire approval (BASE I down).
8-
Acquired approval of a referral.
D-
Referral (auth code manually keyed).
E-
Offline approval (auth code manually

keyed).
Note: If the value is unknown, the field may be left

blank.

Page 65
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
MasterCard
(continued)
Field Name
Field Description
POS Card ID
Method
This field indicates the method utilized for

identifying the cardholder at the point of sale. Valid
1-
Signature obtained (only valid value for best

2-
Personal Identification Number (PIN)

utilized.
3-
Unattended terminal, no PIN pad.
4-
Mail order (not valid for retail interchange).

must contain spaces.
Banknet Reference
Number
Unique identifier, assigned by MasterCard to

identify all related messages and records used to
authorize and settle the transaction through the
MasterCard system.
Authorized Amount Should reflect the amount of the original authorized

transaction.
Banknet Date
Date assigned by MasterCard to indicate when the

auth was provided by the MasterCard authorization
system. (MMDD format)
Merchant Category
Code (MCC)
The Merchant Category Code (MCC) is a four-digit

number that corresponds to a description of the
merchants primary business.
Note: MCC code for authorization and deposit per
transaction must match.

Page 66
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 1
Field Name
Field Description
Extension Record
Identifier

Extension Record
MOP type
Identifies Visa (VI) as the specific card type utilized

for this transaction.
Extension Record
Sequence Number
001 Constant.
POS Capability
Code
This field defines the ability of the POS terminal or

cash register. Note: The value of 9 will not
qualify for the lowest interchange rate. Valid values
include:
2-
Magnetic strip reader. (Only valid for best

5-
Chip capable terminal.
9-
Keyed entry only.

blank.

Page 67
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 1 (continued)
Field Name
Field Description
POS Entry Mode
This field indicates how the transaction was entered.

Valid values include:
01 -
Manually keyed.
02 -
Magnetic stripe read. (General or Track 2)
05 -
Initiated by a chip card; CVV data reliable
06 -
Magnetic stripe read. (Track 1)
81 -
Manual entry via Electronic Commerce

(MasterCard Only)
90 -
Entire magnetic stripe read and transmitted.

(Only valid value for best retail interchange
rate).
95 -
Initiated by a chip card; CVV data unreliable
Note: The value 90 is required to qualify for the

lowest interchange rate.

Page 68
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 1 (continued)
Field Name
Field Description
POS Authorization
Source Code
This field indicates the source of the authorization.

Most POS Source Code terminals and electronic
cash registers (ECR) capture this information when
it is returned from the authorizing Vendor. Valid
0-
Source Code unavailable.
1-
Stand-in processor (STIP), time out

response.
2-
LCS response (amount below floor limit).
3-
STIP (issuer in suppress inquiry mode).
4-
STIP (issuer unavailable).
5-
Issuer provided.
7-
Acquire approval (BASE I down).
8-
Acquired approval of a referral.
D-
Referral (auth code manually keyed).
E-
Offline approval (auth code manually

keyed).

blank.

Page 69
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 1 (continued)
Field Name
Field Description
POS Card ID
Method
This field indicates the method utilized for

identifying the cardholder at the point of sale. Valid
1-
Signature obtained (only valid value for best

2-
Personal Identification Number (PIN)

utilized.
3-
Unattended terminal, no PIN pad.
4-
Mail order (not valid for retail interchange).

must contain spaces.
Authorization
Characteristic
Indicator
This value specifies that this transaction is intended

to qualify for PS2000 processing and has the
following characteristics:
A-
Card swiped Retail transaction indicated.
E-
Card swiped Retail transaction indicated

and includes transmission of
Merchant Name & Location:
a requirement for Visa
Check Card interchange
qualification.
K-
Key entered
Card present with Key Entry.
R-
Bypass
AVS
Card not present. (AVS not

required).
U-
E-commerce E-Commerce 3-D secure.


Page 70
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 1 (continued)
Field Name
Field Description
V-
Card not
present
Card not present. AVS

requested.
W-
E-commerce E-commerce non 3-D secure
Transaction
Identifier
An identifier, assigned by Visa, used to uniquely

identify and link all related messages and records
used to authorize and settle the transaction through
Visa.
Validation Code
A code calculated by Visa, utilized to determine the

accuracy of the authorization data contained in the
settlement record.
Authorized Amount This field should reflect the amount of the original
authorized transaction.
MCC Code
The Merchant Category Code (MCC) is a four-digit

number that corresponds to a description of the
merchants primary business.
Note: MCC code for authorization and deposit per
transaction must match.
Total Authorized
Amount
This reflects the current amount authorized for

deposit. If any partial reversals were performed, this
would be the replacement amount. If this amount is
zero, the auth data is invalid.

Page 71
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 2 Visa
Authentication
Field Name
Field Description
Extension Record
Identifier

Extension Record
MOP type
Identifies Visa (VI) as the specific card type utilized

for this transaction.
Extension Record
Sequence Number
002 Constant.
Transaction ID
(XID)
Unique tracking number set by the Merchant and

sent to the Issuer Authentication Server in the
Authentication Request message.
Cardholder
Authentication
Verification Value
Cryptographic value derived with an algorithm that

applies the Issuers private key to the combination
of the Cardholder Account number, the Transaction
Identifier (XID), and other data.

Page 72
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Visa 2 Visa
Authentication,
continued
Field Name
Field Description
CAVV Response
Code
This field should remain blank on input.

Paymentech will populate with response code
received from Visa.
CAVV
Result
Code
Description
Blank
CAVV not validated
CAVV not validated due to erroneous data

submitted
CAVV failed validation
CAVV passed validation
CAVV validation could not be performed

A 3-D secure authentication value of 5 from
ACS indicates attempt, but not able to
complete
CAVV validation could not be performed

A 3-D secure authentication value of 6 from
ACS indicates system error or failure by
ACS

Page 73
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Electronic Check
Processing
Field Name
Field Description
Extension Record
Identifier

Extension Record
MOP type
EC Constant.
Extension Record
Sequence Number
001 Constant.
RDFI (U.S.) / Bank

ID (Canada)
Paymentech uses this number to determine to which

financial institution the transaction will be sent.
The RDFI (Receiving Depository Financial
Institution) number is nine characters, utilizing the
entire field. (U.S. only)
The Bank ID number is only 8 characters. The
number is left justified, blank filled. (Canada only)
Note: Also referred to as ABA# or Transit
Routing #.
Account Type
Indicates if this account is a checking or savings

account. Values are:
C - Checking. (U.S. and Canada)
S - Savings. (U.S. only)
X - Corporate. (U.S. only)
Note: AM record for ECP is required for deposit and refunds

Page 74
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Electronic Check
Processing
(continued)
Field Name
Field Description
Preferred Delivery
Method
This field indicates the preferred manner to deposit the

transaction. Your preferred method is also stored on our
master file for default purposes. Valid values are:
A-
ACH
Deposit the transaction by ACH only.

If the RDFI is not an ACH
participant, the transaction is rejected.
(US & CAN)
Note: ECP Refunds (Action N)
require a preferred delivery method of
ACH.
B-
Best
Possible
Default value - When the preferred

delivery method field is B, we
utilize the method which best fits the
situation. If the RDFI is not an ACH
participant, a Facsimile Draft will be
created. (U.S. only)
F-
Facsimile
Draft
Deposit the transaction by facsimile

draft. (U.S. only)

Page 75
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Electronic Check
Processing
(continued)
Field Name
Field Description
Preferred Delivery
Method
This field indicates the preferred manner to deposit the

transaction. Your preferred method is also stored on our
master file for default purposes. Valid values are:
ECP Authorization
Method
Code used to identify the method used by consumers to

authorize debits to their accounts for all U.S. transactions.
The authorization must be obtained prior to the debit
entry.
Code
Authorization
Method
Requirements
Written
Written document assuring

consumers identity and assent to
debit their account.
Internet (Web)
Telephone

Digital signature or 4-digit minimum

code previously supplied to the
consumer by the merchant.
Consumer must call the merchant.
Merchant must validate or verify the
consumer through a code (min. 4digit) previously supplied to the
consumer by the merchant. The
consumer must clearly state their
acceptance and understanding of the
payment terms (single or recurring).
Page 76
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Extension Record:
Switch Card
Field Name
Field Description
Extension Record
Identifier

Paymentech Standard format. E Constant.
Extension Record
Card type
SW Constant.
Extension Record
Sequence Number
001 Constant.
Card Start Date
MMYY format.
The day the card becomes active.
Note: The Card Start Date field should be
submitted only when the card does not have an
Issue Number. If the card displays ONLY a Start
Date and no Issue Number, the Card Start Date field
should contain a value and the Card Issue Number
field must be blank. If the card displays both a Start
Date and an Issue Number, the Card Start Date
should be left blank and the Card Issue Number
field must be filled.
Card Issue Number
01 - 99 or Blank if not on the card.

An incremental counter of either 1 or 2 characters
defined by the issuing bank. If a card is lost, the
bank issues a replacement card with the issue
number being increased by one.
Note: The Card Issue Number must be submitted
even when a Card Start Date exists. In addition, the
Card Issue Number must be submitted exactly as
shown on the card.
Example:
If the card displays 01, submit 01- NOT 1.
If the card displays 1, submit 1.

Page 77
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction
Extension Record
Format: Bill Me
Later
Field Name
Field Description
Extension Record
Identifier

Paymentech Standard format. E Constant.
Extension Record
BL Constant.
Method of Payment
Extension Record
Sequence Number
001 Constant.
Shipping Cost
Total shipping cost of consumer purchase. Right

justified/zero filled.
The Terms & Conditions version number the
consumer agreed to.
Date customer registered with Merchant. Format
CCYYMMDD (century, year, month, date)
T & C Version
Customer
Registration Date
Customer Type Flag
New or existing customer with Merchant. Left

N = New
E = Existing

Page 78
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction
Extension Record
Format: Bill Me
Later, (continued)
Field Name
Field Description
Item Category
Product description code assigned by Bill Me

Later.
Indicates whether or not consumer has been preapproved. Pre-approval from the credit bureau
(Equifax) should include the 16 digit pre-approval
number. This will allow the pre-approval to be
matched with the first consumer order. Internal
merchant pre-approval should include a 16-digit
number where the leftmost digit must be a 1. No
pre-approval would be indicated with blanks or
zero filled.
Merchant promotional code. (optional)
Pre-approval
invitation number
Merchant
Promotional Code
Customer Password
Change
Customer Billing
Address Change
Customer Email
Change
Customer Home
Phone Change
Indicates if customer has change password at

merchant site. Y indicates that the consumer has
changed their password. N or blanks indicate that
no change had been made.
Indicates if customer has changed their billing
address with the merchant. Y indicates a change
has been made. N or blanks no change.
Indicates is customer has changed their email
address with the merchant. Y indicates that a
change has been made. N indicates that no change
has been made.
Indicates if customer has changed their home
phone number with the merchant. Y indicates that
a change has been made. N indicates that no
change has been made.

Page 79
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Information Record:
Order Information
Field Name
Field Description
Information Record
Identifier
I Constant. Specifies this record as an

information record of the Paymentech Standard
format. .
Information Record
OI Constant. Order Information

Delivery type of product
CNC - Cash & Carry (BML)
DCT - Digital Content/text or images
(PTI Fraud)
DIG - Digital Goods
DNP - Digital and Physical (PTI Fraud)
GFT - Gift Certification (PTI Fraud)
PHY - Physical Delivery Required
REN - Renewals and Recharges
(PTI Fraud)
SHW - Shareware (PTI Fraud)
SVC - Service (BML)
TBD - To Be Determined (BML)
Product Delivery
Type Indicator
Shipping Carrier
Shipment carrier for an item. Note: applicable for

use with Paymentech Fraud Detection Service
only. Valid values are as follows:
DH DHL
FE Federal Express
GH Greyhound
OH Other
PL Purolator
PS USPS
UP United Parcel Service

Page 80
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Information Record:
Order Information
Field Name
Field Description
Shipping Method
Method of shipment for an item. Note: applicable

for use with Paymentech Fraud Detection Service
only. Valid values are as follows:
C
D
I
M
N
O
P
T
W
Lowest Cost
Carrier Designated by Customer
International
Military
Next Day/Overnight
Other
Store Pickup
Two Day Service
Three Day Service
Order Date
Date of order. Format YYMMDD.
Order Time
Time of order. Format HHMMSS.

Page 81
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Information Record:
Consumer
Information
Field Name
Field Description
Information Record
Identifier
I Constant. Specifies this record as an

information record of the Paymentech Standard
format. .
Information Record
PI Constant. Personal Information
Information Record
Sequence Number
001 Constant.
Customer Date of
Birth
Customer date of birth. CCYYMMDD format

(century, year, month day).
Customer Social
Security Number
Customer social security number.

Page 82
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Information Record:
Consumer
Information,
(Continued)
Field Name
Field Description
Currency Type of
Gross Household
Annual Income
Currency type of gross household annual income. Right

justified/zero filled. Allowable values include: (optional)
978 - Euro
372 - Irish Punt**
392 - Japanese Yen
840 - U.S. Dollars
**Effective 12/27/01, the following currencies will

reject as they have converted to 978 Euro.

Page 83
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Information Record:
Consumer
Information,
(Continued)
Field Name
Field Description
Gross Household
Annual Income
Gross household annual income.

(optional)
Customer Residence
Status
Status of customer residence. Allowable values

include: (optional)
O=Own
R=Rent
X=Other
Number of years at current residence. Round up
to nearest year. For example, 6 months would be
submitted as 1 year. Left justify/blank filled.
(optional)
Number of years customers has worked with
current employer. Round up to nearest year. For
example, 6 months would be submitted as 1 year.
Left justified/blank filled. (optional)
Allowable values: (optional)
Y Yes customer has checking account.
N No customer does not have checking account.
Allowable values; (optional)
Y Yes customer has savings account.
N No customer does not have savings account.
Customer Years at
Residence
Customer Years at
Employer
Customer Checking
Account
Customer Savings
Account

Page 84
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Procurement Level 2
and Level 3 MasterCard and
Visa
Field Name
Field Description
Product Record
Identifier

Paymentech Standard format. P Constant.
Product Record
Type
PC Constant.
Product Record
Sequence Number
001 Constant.
Customer Reference
Number
Purchase Order or other number used by the Merchants

customer to track the order. Left justified/blank filled.
Note: For level 2 processing, this field is not required,
however, must be filled in to qualify for lower rate.
For level 3 processing, this field is required. If this field
is not filled in, transaction will reject.
Sales Tax Amount
Amount of sales tax assessed to the transaction.

Required field. Two decimal implied /right
justified/zero filled.
Note: For level 2 processing, this field is not required,
however, must be filled in to qualify for lower rate.
For level 3 processing, this field is required. If this field
is not filled in, transaction will reject.

Page 85
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Procurement
Level 3 - MasterCard
and Visa Order
Level Record
Field Name
Field Description
Product Record ID

Paymentech Standard format. "P" Constant.
"P0" Constant.
Product Record Type

Number
Freight Amount
001 Constant.
Duty Amount
Total charges for any import and/or export duties

included in this transaction.
The postal/zip code of the ship to location. This
field is equal to the ship from postal/zip code
when the customer takes possession of the items at
the merchants site.
The ISO-assigned code of the country to which
the goods were shipped.
The postal/zip code of the location from which the
goods were shipped.
The total amount of discount applied to the
transaction by the merchant. Used by the
merchant when a price break is given on an
entire transaction rather than on unit prices.
Typically, this is shown as a credit on a detailed
invoice.

Ship From Zip Code
Discount Amount Applied
to Order
Total freight or shipping and handling charges.
VAT/Tax Amount
The total amount of VAT or other tax included in

this transaction.
VAT/Tax Rate
The rate of VAT or other tax (expressed in

percentage terms) for this line item.
Alternate Tax ID
Tax ID number for the alternate tax associated

with this transaction.
The total amount of alternate tax associated with

this transaction.

Page 86
09/21/2001
FIELD DEFINITIONS
(Continued)
Note: Record #1 - Line Item Level Data must match to corresponding Line Item Level Data Record 2
Transaction File
Product Record:
Procurement
Field
Description
Product Record ID

"P1" Constant.
Level 3 - MasterCard
and
Product Record Type
Visa Record #1 Line Item Level Data
Product Record
Sequence Number
002 to 099
Used to uniquely identify a line item within a P0 record.
A line item must consist of a matching P1 and P2 record
submitted in sequential order and would increase in
increments of one (1).
Note: See Appendix L for Record Sequence Number
Example
Description
Text Description of the item purchased.
Product Code
Product Code of the item purchased.
Quantity
Number of units of the item purchased.
Unit of Measure
The unit of measure, or unit of measure code used for

this item.
The tax amount for this item.
Tax rate applied to the item.
Blanks
Tax Amount
Tax Rate
Filler

Page 87
09/21/2001
FIELD DEFINITIONS
(Continued)
Note: Record #2 - Line Item Level Data must match to corresponding Line Item Level Data Record #1
Transaction File
Product Record:
Procurement Level 3
- MasterCard and
Visa Record #2 Line Item Level Data
Field
Description
Product Record ID

Product Record Type "P2" Constant.

Product Record
Sequence Number
002 to 099. Sequence number should match that of the

accompanying P1 record.
Line item total
The amount of the item that is normally calculated as price

times quantity.
Discount Amount for Amount of discount applied to the line item.

Line Item
Item Commodity
Code
The commodity code used to classify the item purchased.
Unit Cost
Unit cost of the item purchased.

Note: This is a pass through field. Paymentech, Visa, and
MasterCard do not perform any edit checks on the Unit
Cost at this time.
Net/Gross Indicator
Values are:
Y = item amount includes tax amount.
N = item amount does not include tax amount.
Tax Type Applied
Type of tax being applied.
Discount Indicator
Values are:
Y = amount is discounted.
N = amount is not discounted.

Page 88
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Fraud
Field Name
Field Description
Product Record
Identifier
Specifies this record as a product record of the

Paymentech standard format. P Constant.
Product Record
Type
FR Constant.
Product Record
Sequence Number
001 Constant.
Card Security Value
Use this field to identify the American Express

CID, Discover CID, Visa CVV2, or MasterCard
CVC2 value provided to you by the cardholder. If
not doing American Express CID, Visa CVV2, or
MasterCard CVC2 leave blank.
Note: Card security values are 3-4 digits and it is
against regulations to store this value.
Please reference Appendix for information on
American Express CID, Discover CID, Visa CVV2
and Master CVC2.
Card Security
Presence
This indicator is used to validate the presence of a

card security value on a Discover or Visa card.
Note: If a code 1, 2, or 9 is not sent, this field must
be left blank. Paymentechs system will reject the
transaction if this field is filled in with any other
code than 1, 2, or 9.
If customer does not indicate either a 1, 2, or 9, leave
blank.
Note: This fraud record used for authorizations and conditional

deposits only. The PFR record replaces the EAX003 record found in
version 1.3 of the batch specification manual.

Page 89
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Retail Enable
Field Name
Field Description
Product Record
Identifier

Product Record
Type
RR Constant.
Product Record
Sequence Number
001 Constant.
Terminal
Identification
The field is used to uniquely identify a processing

device associated to a Point of Sale division. If this
field does not contain data and the merchant is
setup to use Paymentechs detail reporting product,
Paymentech will populate the report with a value of
9999999999999999.
Batch Identification
The batch identification represents a unique

identifier to a logical group of transactions on a
given terminal. If this field does not contain data
and the merchant is setup to use Paymentechs
detail reporting product, Paymentech will populate
the report with a value of 99999999999999.

Page 90
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Stored Value
Field Name
Field Description
Product Record
Identifier

Product Record
Type
SV Constant.
Product Record
Sequence Number
001 Constant.
Current Balance
This field reflects what the current balance is of the

stored value card. This field should be blank filled
on the input file. The output file will populate the
current balance.
Previous Balance
This field reflects the previous balance prior to the

sale. This field should be blank filled on the input
file. The output file will populate the previous
balance.
Notes: In order to obtain current or previous balance, an input file must be sent. If the fields are
populated in the input file, that information will be overwritten in the output file. Paymentech does not
store any information in input file for this record.
When sending the Stored Value record, method of payment must equal SV.

Page 91
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Product Record:
Various Text
Field Name
Field Description
Product Record
Identifier

Product Record
Type
VT Constant.
Product Record
Sequence Number
001 Constant.
Various Text
The text field is used for merchants who offer

Paymentech Stored Value certificates to their
consumers. Merchants have the ability to send a
customized text message to recipients with email
certificates.
Note: For future use

Page 92
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Address Record
Field Name
Field Description
Constant
Specifies this record as an address record of the

Paymentech standard format. A Constant.
Address Type
Indicates the type of address that follows:

B - Used for Credit Card transactions. For Address
Verification purposes. If verifying ZIP Code only,
use the AB record (i.e., AB12345). If verifying full
address use the AB record to send the cardholders
name, followed by the necessary extension records
for the address information.
E - Used for consumer employer information.
G - Used for consumer gift recipient information.
I - Used for consumer IP address
(Subtype B only).
L - Used for consumer email address.
M - Used for ECP only. consumers name as it appears
on the check. All ECP transactions must be
accompanied by the consumers name at a
minimum.
S - Ship to address. Please note that Ship To records
are for information only and are not screened for
AVS.
Note: Recommended but not required for
American Express procurement record
2/3/4/5 - Valid identifiers for extension records.
Any of the above address record types may be followed
by up to 4 extensions. Extensions start with the letter
(A) and the first extension number is 2.

Page 93
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Address Record
(continued)
Field Name
Field Description
Address Line
Contains the actual address text. The first line should

contain the name (or ZIP if that is the only address
information sent). A name contains up to five separate
pieces: Prefix, First Name, Middle Name, Last Name and
Suffix. Please precede a Last Name with an asterisk (*) to
help differentiate it from the others (i.e., MR. ROBERT
JAY *WHITE. Also, please precede a suffix with the
string , (i.e., PATRICK P. *OCONNOR, MD).
Address extension records should be used as necessary to
send the full address information. The last address record
sent should contain City, State, Zip information. Any
State sent should be a valid U.S. Postal Service
Abbreviation. If the ZIP +4 is sent, you must separate the
four-digit suffix with a hyphen (-).
Note: All Alpha characters in these records must be
UPPERCASE only.
Telephone Type
Valid values are:

(D)
(H)
(N)
(W)
Telephone Number
Day
Home
Night
Work
In the format AAAEEENNNNXXXX where:

AAA
EEE
NNN
XXXX
=
=
=
=
Area Code
Exchange
Number
Extension
Blank fill this field if it is unused.

Country Code
Country code. Current values are:

US United States
CA Canada
GB Great Britain

Page 94
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Address Record
(continued)
Field Name
Field Description
Address Subtype
Type of address for email and IP address formats. Valid

values are as follows:
B Bill To/Buyer Address (IP and email format)
G Giftee Email Address (email format)
Customer IP
Address
Customers IP address. Can accept characters such as

dots.
Customer Email
Address
Customers email address. Can accept characters such as

dots, @, etc.

Page 95
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Batch Totals Record
Field Name
Field Description
Constant

Paymentech Standard format. B RECS=
Constant.
Batch Record Count
Total number of records in the batch up to, but NOT

including, the Batch Totals Record.
Constant
ORDS= Constant.
Batch Order Count
Total number of all orders within this batch. (S

Records)
Constant
$TOT= Constant.
Batch Amount Total
Total amount of all Detail Records in this batch,

which contains an amount in, positions 51,62.
Note: This is a gross total (ABSOLUTE
AMOUNT sales + ABSOLUTE AMOUNT refunds
+ ABSOLUTE AMOUNT authorizations).
Constant
$SALE= Constant.
Batch Amount Sales
Total amount of all sale records in the batch. Do not

include authorization, verification, and validation or
promote records.
Constant
$REFUND= Constant.
Batch Amount
Refunds
Total amount of all refund records in the batch.

Note: All fields in this record are right justified
and zero-filled.

Page 96
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Totals Record
Field Name
Field Description
Constant

Paymentech Standard format. T RECS=
Constant.
File Record Count
Total number of records in the file up to, but NOT

including, the current record.
Constant
ORDS= Constant.
File Order Count
Total number of all orders within this file. (S

Records)
Constant
$TOT= Constant.
File Amount Total
Total amount of all Detail Records in this file that

contains an amount in positions 51,62.
Note: This is a gross total (ABSOLUTE
AMOUNT sales + ABSOLUTE AMOUNT refunds
+ ABSOLUTE AMOUNT authorizations). If this
total is not correct, the submission processing fails.
Constant
$SALE= Constant.
File Amount Sales
Total amount of all sale records in the file. The

merchant should not include authorization,
verification, and validation or promote records.
Constant
$REFUND= Constant.
File Amount
Refunds
Total amount of all refund records in the file.

Note: All fields in this record are right justified
and zero-filled.

Page 97
09/21/2001
FIELD DEFINITIONS
(Continued)
Transaction File
Trailer Record
Field Name
Field Description
Presenters ID (PID) The PID is a number assigned to the location that

physically sends the data file (Presenter).
PID Password
Submitters ID
(SID)
SID Password
Creation Date
Fill this field with the date the file was created in
the YYMMDD format. (Optional)

Page 98
09/21/2001
FIELD DEFINITIONS
(Continued)
Request for
Response File (RFR)
Record
Field Name
Field Description
Presenters ID (PID)
The PID is a number assigned to the location that

physically sends the data file. (Presenter)
PID Password
Submitters ID
(SID)
SID Password
Creation Date
Fill this field with the date the file was created in the
YYMMDD format. (Optional)
Note: If a RFR record is received by Paymentech, however, there is no file available for pick up, the following
message will be given:
YY-MM-DD HH:MM:SS No data to send back at this time.
EOFEOFEOF

Page 99
09/21/2001
FIELD DEFINITIONS
(Continued)
S Record Output
Field Name
Field Description
Constant

Paymentech Standard format. S Constant.
Assigned by Paymentech. (Required)
Division Number
Merchants Order
Number
Action Code
Method of Payment
(MOP)
Unique Order Number supplied by merchant. (Required)

Action Requested:
A
B
D
E
G
H
I
J
K
L
N
O
P
Q
R
V
Authorize (Credit Card, Stored Value)

Conditional Deposit (Credit Card)
Deposit (Credit Card, Stored Value)
Authorization Reveral (Stored Value)
Verify Only (ECP US)
Validate and Deposit (ECP US & CAN)
Verify and Deposit (ECP US)
Pre-note Only - Credit (ECP)
Issuance (Stored Value)
Add Value (Stored Value)
Refund (ECP)
Forced Validate (ECP)
Pre-note Only - Debit (ECP)
Stored Value Current Balance Inquiry (Stored
Value)
Refund (Credit Card, Stored Value)
Validate Only (ECP US & CAN)
Verify and Pre-note (ECP)
Methods of Payment:
AX - American Express/Optima
BL - Bill Me Later
CB - Carte Blanche
DC - Diners
EN - Encryption (see below notes)
JC - JCB
MC - MasterCard
SV - Stored Value
SW - Switch/Solo
VI - Visa/Delta
Note: For additional methods of payment processing,
please contact your Paymentech representative.
The encryption (EN) MOP must be used in conjunction
with the encryption flag in the transaction file detail record.

Page 100
09/21/2001
FIELD DEFINITIONS
(Continued)
S Record Output
(continued)
Field Name
Field Description
Account Number
The account number must be left justified and blank filled.

This number is used to either identify the credit card, the
BML account number, or the bank account used at the
financial institution for ECP transactions.
Note: Encrypted credit card numbers are 16 to 19
positions. An ECP transaction, the account number is 17
positions only. ECP transactions not send back account
number and expiration date.
Expiration Date
MMYY (Optional)
Amount
Implied decimal/right justified/zero-filled. All

currencies imply two (2) decimal places.
Currency Code
Currency of the transaction

978 - Euro
372 - Irish Punt**
392 - Japanese Yen
840 - U.S. Dollars
**Effective 12/27/01, the following currencies will
reject as they have converted to 978-Euro.

Page 101
09/21/2001
FIELD DEFINITIONS
(Continued)
S Record Output
(continued)
Field Name
Field Description
Response Reason
Code
Transaction Type
Result of Action Requested.
Card Security Value

Response
Response Date
Authorization/
Verification Code
AVS/AAV
Response Code
This describes the circumstances under which the

transaction takes place.
Use this for Discover CID, MasterCard CVC2, or
Visa CVV2 value for fraud detection.
YYMMDD format.
Code issuer uses to show an authorization request
was approved (must retain this), or a text message
used by Paymentech to indicate status of a
transaction submitted for deposit. (See Appendix A:
Response Reason Code Description Usage)
AVS/AAV result. (Optional)
Deposit Flag
Defines whether or not the transaction has been

deposited.
Fraud Indicator
Defines scoring for Paymentech Fraud Detection.
Encryption Flag
Utilized for encryption.
Recurring Payment
Advice Code
Code values are:

01 New account information available. Obtain
new account information.
02 Try again later. Recycle transaction in 72
hours
03 Do not try again. Obtain another type of
payment from customer.
Note: MasterCard recurring transactions only.
Transaction type must be 2.
For Merchant use. (Optional)
Merchant Space

Page 102
09/21/2001
FORMAT USAGE
General Information
The Paymentech format is flexible and may be used in several different ways
based on Merchant or vendor needs. There are two general methods that fit
most needs.
A Merchant or vendor that knows items are in stock before sending
transactions to Paymentech usually benefits the most from using conditional
deposits (B Action Code). A conditional deposit is one that requests that
Paymentech deposit the transaction if it passes authorization/verification.
When received, a conditional deposit transaction is sent out for
authorization/verification. Any approved transactions are automatically
deposited in Paymentech's next deposit window (Paymentech deposits
several times per day).
The output returned to the Merchant or vendor contains the
authorization/verification results with only approved transactions having
been deposited. Refunds can be mixed in with other transactions and are
returned with an authorization/verification status as well.
The other most popular method of handling transactions is for the Merchant
or vendor to send Paymentech a file of only authorization/verification
requests. Then, based on Paymentech's responses and available stock, the
transactions are sent back to us for deposit at a later time. These deposits
may be mixed in with the next authorization/verification file or sent in a
separate file.
Authorization may be obtained online in real time with the use of
Paymentechs Specification for On-Line Authorization. Please request this
specification from your Account Manager.
Sending PreApproved Records
When a transaction has been previously approved (via Paymentech, voice

authorization, or a point-of-sale terminal) and is sent for deposit, it is
extremely important that the Merchant or vendor accurately provide the
authorization/verification information previously obtained.
The authorization response reason code should have a value of 100
(approved), and the authorization date and code must be accurately filled in.
For credit card transactions, Paymentech decides, based on the authorization
date, whether or not to retry the authorization. This decision is based on
MasterCard/Visa regulations and interchange rate qualifications. If
appropriate, the authorization is tried again. If an approval is gained, the
output reflects the new authorization result. If the authorization is declined,
Paymentech uses the approval information provided by the Merchant or
vendor in their input file, thus forcing the deposit of the transaction.

Page 103
09/21/2001
FORMAT USAGE
(Continued)
Sending PreApproved Records

(continued)
If any portion of the authorization/verification information is invalid or

missing, Paymentech treats the transaction as if it was never approved and
will reauthorize it.
If a merchant includes an authorization code and authorization date in the
detail of a conditional deposit (B action code), Paymentech will deposit
the transaction regardless of the result of any re-authorization attempt.
Pre-approved records should be deposited with a D action code.
Paymentech Output
Paymentech does not return any Address Records in the output file unless
requested by the Merchant or vendor. All Header, Trailer, Batch Totals, and
Totals Records are echoed in the output file exactly as they are received. All
Detail Records are returned in the output file with the most recent
authorization information being supplied in the proper fields, if so requested
by the merchant. Merchants may request output that contains only
transactions that have not been deposited.
Sample Input and

Output Files
An example of a sample file has been provided to demonstrate the format of

input files sent by the merchant and the format of the output returned by
Paymentech. The input and output samples shown on the following pages
show different types of methods of payment, action types, Extension Record
and Product Record usage. Below each example, a line-by-line item
description is supplied.
Note: The numbers in brackets [n] at the end of each line in the file
examples indicate the line number corresponding to the line item description.
These numbers are not part of the input or output file samples.

Page 104
09/21/2001
FORMAT USAGE
(Continued)
Input File:
PID=575100 PASSWORD SID=575100 PASSWORD START 970701 01.6
S1234569898981234AUTH
AVI4012147230156013
0797000000000100840
1
PFR001161 1
ABJOE *BAGADONUTS
A21 MAIN STAPT 22
H6035553333
A3SALEM, NH 03079-9099
S1234569898981234DEP
DMC5419843331777778
0797000000001000840100R 970630877865
EMC00129051 MCC123456
00000000100006305999
S1234569898981234REFUND RAX373235387881007
07970000000001008401001 970701
ABSAM WHATSHISNAME
A223 NORTH POLICY RD
D6035554444
A3SALEM, NH 03079-9099
S1234569898981234ECP
GEC123443217656
000000000000840
1
EEC001123456789
CB
AMJOHN *DOE
S1234569898981234PURCH BVI4012147230156013
0797000000015797840
1
PPC001MGMNAT000187564 000000000153
ABTHE BIG COMPANY
A254 NORTHWEST RD
W60355588880810
A3SALEM, NH 03079-9099
AS03053
PID=575100 PASSWORD SID=575100 PASSWORD END 970701
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
[11]
[12]
[13]
[14]
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
Input File Line Item Description

Line 1:
Header Record
Line 2:
Detail Record [Visa authorization requested with address verification]
Line 3:
Product Record [Fraud record for American Express CID, Discover CID, MC CVC2, or
Visa CVV2]
Line 4-6:
Address Record [With billing address]
Line 7:
Detail Record [MasterCard deposit requested, auth info. included, retail transaction]
Line 8:
Extension Record: MasterCard
Line 9:
Detail Record [American Express refund]
Line 10-12: Address Record [With billing address]
Line 13:
Detail Record [Verify only requested for a ACH (ECP) transaction]
Line 14:
Extension Record: Electronic Check Processing
Line 15:
Address Record [With consumers checking account name]
Line 16:
Detail Record [Visa conditional deposit requested for a Procurement Card]
Line 17:
Product Record: Procurement (Level 2)
Line 18-20: Address Record [With bill-to-address]
Line 21:
Address Record [With ship-to-address zip code]
Line 22:
Batch Totals Record
Line 23:
Totals Record
Line 24:
Trailer Record
Line 25:
EOFEOFEOF (Note: only Async & TCPIP Merchants)

Page 105
09/21/2001
FORMAT USAGE
(Continued)
Output File:
PID=575100 PASSWORD SID=575100 PASSWORD START 970701 01.6 70701.0001h
S1234569898981234AUTH
AVI4012147230156013
07970000000001008401001M970701012345I3N
S1234569898981234DEP
DMC5419843331777778
0797000000001000840100R 970630877865 Y
S1234569898981234REFUND RAX373235387881007
07970000000001008401001 970701
Y
S1234569898981234ECP
GEC123443217656
0000000000008401021 970701123456 N
S1234569898981234PURCH BVI4012147230156013
07970000000157978401001 970701543421I7Y
S1234569898981234RCYCLE BVI4012147230156013
07970000000001008405307 970701rcycleI4N
PID=575100 PASSWORD SID=575100 PASSWORD END 970701
[1]
[2]
[3]
[4]
[5]
[6]
[7]
[8]
[9]
[10]
Output File Line Item Description

Line 1:
Header Record
Line 2:
Detail Record [Visa authorization and address verification result]
Line 3:
Detail Record [MasterCard deposit result]
Line 4:
Detail Record [American Express refund result]
Line 5:
Detail Record [Verify only result for a ACH (ECP) transaction]
Line 6:
Detail Record [Visa conditional deposit and address verification result for
Procurement Card]
Line 7:
Detail Record [Authorization Recycle]
Line 8:
Batch Totals Record
Line 9:
Totals Record
Line 10:
Trailer Record
Line 11:
EOFEOFEOF (Note: only Async & TCPIP Merchants)
Note: If a RFR record is received by Paymentech, however, there is no file available for pick up, the
following message will be given: YY-MM-DD HH:MM:SS No data to send back at this time.
EOFEOFEOF

Page 106
09/21/2001
TESTING CHECKLIST TABLE
Introduction
Procedure
This section relates only to the technical setup of Paymentech programs.

The Merchant Certification Analyst (MCA) will provide you with the
Testing Guidelines document that details everything that will be covered
during the testing process. Please review this document thoroughly
before scheduling your first testing appointment. The following gives a
general overview of what will be covered during the testing process.
Step
Action
Call your MCA before attempting test transmissions, as testing

is usually done on a scheduled basis. First, the MCA will
work with you to establish communications with Paymentech.
This may involve the help of the NCC (Network Command
Center) to put a data scope/sniffer on the line to help resolve
any communication issues.
After communication has been established, the MCA will

request sample files that contain all of the various Paymentech
Products/Services that you will utilize in production. These
sample files will include authorizations/deposits, conditional
deposits, refunds, and address records for all of the various
card types and currencies that your divisions have been setup
to process. The MCA will ask you to send in additional files
if you wish to test ECP, Bill Me Later, Stored Value,
Paymentech Fraud Detection Service, Retail Enabling, Soft
Merchant Descriptors, Amex CID, Discover CID, MasterCard
CVC2, Visa CVV2, Visa Payment Service 2000, Customer
Payment Service, and FPO. Several tests may be required
depending on the Merchant/Vendor needs until both
Paymentech and the Merchant/Vendor are satisfied with the
data flow.

Page 107
09/21/2001

(Continued)
Procedure
(Continued)
Step
Action
If the processing involves separate authorization and deposit

files, this process is repeated for a sample deposit file. More
turn around tests may be run depending on Merchant or vendor
needs until both Paymentech and the Merchant or vendor are
satisfied with the data flow. The MCA will also ask you to
perform a communications test with a large file of at least
1000 lines of data (records). During this test the MCA will
simulate line drops and make sure that your software is able to
recover properly from this error state. (If you have trouble
creating this file please speak with your MCA who can create
a sample file for you to send in to Paymentech to accomplish
this test). Note: Please refer to the Testing Checklist Table
for more detailed information on testing.
The MCA will request operations contacts, phone numbers

etc. before you send in your first production files. These
contacts are used by the Operations Center to contact you in
the event there is a problem with a production file. Note: If
you do not start processing production transactions within 30
days after Certification, you will be required to re-certify.

Page 108
09/21/2001

(Continued)
Certification Testing Process:
-
Testing requirements can vary dependent on your software and/or protocol.

Files may include any or all of the following transaction types:
Authorizations; Conditional Deposits; Deposits
- All transactions are processed in our test environment - they do not go to an authorization center
or to a bank.
- The responses are program generated. A credit card will always produce the same response code
even if other fields are changed (amount, etc).
O: Online Authorization
A: Authorization Batch
B: Conditional Batch
D: Deposit Batch
FORMAT REQUIREMENTS
Order numbers: left justified AND 1st eight digits are unique
Amount format matches currency code
Transaction type should NOT BE a 5, 6, or 8
If 5, 6 or 8 are used, you will not get the best interchange rate
At a minimum the Zip Code should be included.
If using full AVS information should be upper case

X
Action Code = A
Totals balance
Action Code = B
Fields: Response Reason Code, Response Date, Auth/Verification Code,

AVS/AAV Code should be blank.
X
Action code = D
Order numbers, authorization date and authorization code should match
authorization data.
M records (soft descriptors) must be pre-approved by our risk department and

conform to specifications. Merchant Certification will need a hard copy of all soft
descriptors that will be sent into production.

Page 109
09/21/2001

(Continued)
O: Online Authorization
A: Authorization Batch
B: Conditional Batch
D: Deposit Batch
PROCESSING REQUIREMENTS
Send credit card type(s) for each division
Recognize valid/invalid responses
Recognize whether transactions are for a $1.00 (account approval) or for the
full amount
X
X
Include 2 Refund transactions

Favorable interchange rate
Send only authorized transactions

Connectivity test:
The Analyst will bring socket down get a timeout message recover when socket
is brought back up
X
Send 1000 lines of data (records)

Recognize line drop when sending and receiving a batch
Send RFR (Request For Response) get No Data Is Available At This Time
Message
Send RFR (Request For Response) receive response file

Page 110
09/21/2001
PRODUCTION PROCEDURES
Introduction
This section describes the procedures as they relate to modem-to-modem

transmissions.
Procedure
Paymentech utilizes a rotary hunt group to insure that computer

connections can be made with a single phone call and to avoid busy
signals. These phones are available 24 hours a day, seven days a week.
Step
Action
The Merchant or vendor calls the data line and, upon modem
connection, begins sending the input file.
After the file has been processed, the Merchant or vendor has
two methods available to retrieve their file. These are:
The Instant Authorizationsm feature allows a Merchant

or vendor to send and receive data files with a single phone
call with no line disconnection taking place during the file
processing. Data is returned to the Merchant or vendor as
soon as the last record is sent and the first record is ready
for return.
The Merchant or vendor utilizing the Request for

Response (RFR) feature dials into Paymentech and by
sending an RFR record receives either the earliest
processed and QCd transaction file available or a No
Data message.
Once a file has been returned, that file is not returned again
unless the Merchant or vendor calls Paymentech
Operations and requests to have the file re-queued.
Note: If a file fails for a Quality Assurance Reason, an output

file will not be created unless the Paymentech operator
resolves and processes the file.

Page 111
09/21/2001
PRODUCTION PROCEDURES
(Continued)
Data Transmission
Times
Paymentech accepts files at any time, 24 hours per day, every day of the
year. Our daily financial deposit window closes at 10:00 PM ET for
processing of data. Any deposit file received after 10:00 PM is processed as
the next days data. This also applies to deposit files that began transmitting
before 10:00 PM, but did not complete the transmission until after 10:00
PM ET. Files received after Fridays 10:00 PM ET window are processed
along with Saturdays data.
If there are any issues, such as poor response rate, long turn around time, or
any other concerns, please contact the Account Manager responsible for
your account. We pride ourselves on the service we provide and need your
input to ensure that our high service levels are maintained.

Page 112
09/21/2001
TRANSMISSION SPECIFICATIONS
Introduction
Paymentech can receive submission files from multiple sources:

asynchronous (modem) transmission, synchronous (IBM 3780 protocol)
transmission, FTP and TCP/IP.
The parameters described below are merely Paymentech defaults and
preferences, not requirements. If the suggestions below can be
implemented prior to communications testing, it may reduce the amount of
time it takes to complete testing. Paymentech's programs are very flexible,
and we try to accept any set up according to Merchant or vendor needs.
Asynchronous
Transmission
Paymentech supports the following modem configuration for asynchronous

communications:
Modem
Protocol
BPS
Any modem
supporting
MNP
(level 4 or 5 protocol
(required))
2400 to 9600
Paymentech supports ASCII and Kermit for asynchronous transmissions.

The Data Terminal Equipment (DTE) flow control for each configuration
is xon/xoff (Required).
After the connection (DCD=High), but before the transmission of data, a
pause of five seconds is required to ensure that the communications path
has been established. Data is to be transmitted as 96-byte records with a
[CR] (hex OD) as a record separator.
Following the last record transmitted, the character string
EOFEOFEOF[CR] or (hex 45 4F 46 45 4F 46 45 4F 46 OD) must be sent
to notify the system of the completion of the current submission.

Page 113
09/21/2001
(Continued)
Asynchronous
Transmission
(continued)
Following the EOFEOFEOF[CR], a pause of two minutes is

recommended prior to issuing the hang up command. Paymentech
terminates the connection two minutes after the receipt of the EOFEOFEOF
record. When utilizing RFR, the two-minute delay is unnecessary.
Synchronous
Transmission
Paymentech supports synchronous transmissions using BSC/3780 protocol.

If you are not familiar with 3780, please contact the individual or firm who
supplies your hardware or software. They generally know the capabilities
of your machine, what you would have to order and how much it would
cost. Also, if your machine supports the 2780 protocol, you should not
need any modification to communicate with Paymentech. The differences
between 2780 and 3780 are relatively small and easily resolved.
3780
There are several options in the 3780 protocol which are common to
almost any machine and setup. The values listed below reflect
Paymentechs default setup and preferences. If you have other options in
your software package, which you deem important to proper
communication, or if the defaults listed below do not fit your needs, please
discuss them with the MCA with whom you are testing.
The options generally used are:
1. HOST
This option defines which computer system leads the file transfer
session. One side must lead; otherwise both computers could try to
send at the same time. Usually if this setting is incorrect, the two
modems connect but no activity occurs. Paymentech is the HOST
during transmissions.
2. TRANSPARENCY (mandatory)
In the 3780 protocol, unprintable (control) characters are used by the
two computers to talk to each other. Therefore, if your file contains
unprintable characters, you cannot normally send the file using the
3780 protocol. Paymentech uses NON-TRANSPARENT as the default.

Page 114
09/21/2001
(Continued)
3780 (continued)
3. COMPRESSION
This option controls whether or not the computer is allowed to
compress the data being sent. With compression ON, any occurrence of
more than two spaces in a row is replaced with a special two-character
sequence telling the other computer how many spaces should actually
be put in the file. Paymentech expects to send and receive compressed
data as a default.
When transmitting to Paymentech, compression is not required, as our
computer system can accept non-compressed data. A problem occurs if
Paymentech tries to transmit compressed data to a system that is not
expecting it. It is easy to tell when this setting is incorrect. Wherever
there should be more than two spaces in a row in the received file, you
instead see one or more garbage characters.
4. BLOCK SIZE
This option defines the maximum number of characters the computer
can send out in a block. In the 3780 protocol, transmitted characters are
packaged into blocks. Then the computer performs some error
checking on the block before transmitting it. When the other computer
receives a block, the same error checking is again performed to assure
a perfect transmission. Blocks that do not pass this test are transmitted
again.
Paymentechs default for block size is 512 characters, the generally
accepted maximum. This option is not critical when sending to
Paymentech, as any smaller block size fits within our 512-character
block.

Page 115
09/21/2001
APPENDIX A: RESPONSE REASON CODE DESCRIPTION/USAGE

Paymentech
Response Reason
Codes
The following list reflects all currently defined Paymentech response

reason codes. Many of these codes will never be returned in your output.
For the most common codes returned by Paymentech, the list includes an
action field that suggests the best probable course of action to take based
on the code returned. If you are receiving codes not listed here, please
contact your Account Manager.
For ECP transactions, please refer to the Electronic Check Processing
User Guide for additional information including return codes, dishonor
codes and response actions.
The following KEY describes the Column Headings and the values
appearing in the columns.
KEY
Column Heading
Description
Type
= Successful Response Codes
= Reject Response Codes
= Decline Response Codes
Code
3-digit response code
Name
Description of the response code
Action
Resend
= Send this transaction back at any time
Wait
= Wait 2-3 days before sending back, or

try to resolve with your customer
Cust.
= Try to resolve with customer or get an

alternate method of payment
Fix
= There is an invalid field being sent. Fix

and resend
Voice
= Perform a voice authorization per

Paymentech instructions
Call
= Call Paymentech
BML
= Bill Me Later Cards
CC
= All Credit Cards
ECP
= Electronic Check Processing
SV
= Stored Value
Payment Method

Page 116
09/21/2001
APPENDIX A: RESPONSE REASON CODE/AUTH CODE RESPONSES

(Continued)
Response
Type
Code
Name
Action
Payment
Method
Comments
000
No Answer
Resend
CC
100
Approved
N/A
101
Validated
N/A
ECP
102
Verified
N/A
ECP
103
Pre-noted
N/A
ECP
104
No Reason to
Decline
N/A
Successfully approved
105
Received and
Stored
N/A
(for FPO transactions)
106
Provided Auth
N/A
107
Request
Received
N/A
110
BIN Alert
N/A
111
Approved for
Partial
N/A
112
Approved Low
Fraud
N/A
CC
Successfully approved.
Note: used for eFalcon
fraud scoring only
113
Approved
Medium Fraud
N/A
CC
fraud scoring only
114
Approved High
Fraud
N/A
CC
fraud scoring only
115
Approved Fraud
Service
Unavailable
N/A
CC
Fraud service unavailable.

fraud scoring only
Paymentech received no
answer from auth network
BML,
CC,ECP,
SV

Account passed Paymentech

negative file and data edit
checks
Account passed external
negative file
Passed pre-note
Page 117
09/21/2001

(Continued)
Response
Type
Code
Name
120
Approved New
Account Number
121
R
R
Action
Payment
Method
Comments
N/A
BML
Approved - Amount Exceeds

Limits
N/A
BML
201
Invalid CC
Number
Cust.
CC
Successfully approved. BML

account number needs to be
updated on the merchants
system for any future
transactions.
Successfully approved. The
transaction has been approved,
but the amount exceeds agreed
to limits. If the merchant
processes the sale, the
merchant will assume liability
for the transaction.
Bad check digit, length, or
other credit card problem
202
Bad Amount
Fix
CC, ECP Amount sent was 0, unreadable

or over ceiling limit
Non-Numeric
Amount
R
203
Zero Amount
Fix
CC, ECP Amount sent was zero
204
Other Error
Call
CC, ECP Unidentifiable error
205
Bad Total Auth

Amount
CC
225
Invalid Field Data Fix
CC
227
Missing
Companion Data
Fix
CC
229
Percents Do Not
Total 100
230
Payments Do Not
Total Order
231
Invalid Division
Number
Reversal for total authorization

amount (i.e. action D with
the deposit amount lower the
original auth amount whos
as action E in OHDB).
Data within transaction is
incorrect
Specific and relevant data
within transaction is absent
CC, ECP FPO monthly payments do not

total 100
ECP
Fix
FPO monthly do not total

order
CC, ECP Division number incorrect

Page 118
09/21/2001

(Continued)
Response
Type
Code
Name
233
234
235
FPO Locked
236
237
Auth Recycle
Resend
Host System
Down
FPO Not Allowed Call
238
Invalid Currency
Fix
239
Fix
240
241
Invalid MOP for

Division
Auth Amount
Wrong
Illegal Action
243
Invalid Purch.
Level III
Fix
CC
Data is inaccurate or missing
244
Invalid
Encryption
Format
Fix
CC
Invalid encryption flag. Data

is inaccurate or missing.
Does Not Match

MOP
Duplicate Order
No.
Action
Fix
Fix
Payment
Method
Comments
CC
Credit card number does not

match method of payment type
Unique to Authorization
CC
Recycle transactions. Order
number already exists in
system
CC, ECP FPO change not allowed
CC
Authorization recycle host

system temporarily unavailable
N/A
CC, ECP Division does not participate in

FPO. Contact your
Paymentech representative for
information on getting set up
for Flexible Payment Options
(FPO)
CC, ECP Currency does not match
Paymentech Member
parameter table
CC, ECP Method of payment is invalid
for the division
CC, ECP Used by FPO
N/A
CC, ECP Used by FPO

Page 119
09/21/2001

(Continued)
Response
Type
Code
Name
Action
251
Invalid Start Date
Fix
252
Invalid Issue
Number
Fix
253
Fix
260
Invalid
Transaction type
Soft AVS
Cust.
Payment
Method
Comments
CC
Incorrect start date or card may

require an issue number, but a
start date was submitted
(Switch/Solo ONLY)
1-digit number submitted when
CC
a 2-digit number should have
been sent (Switch/Solo
ONLY)
CC, ECP Invalid transaction type for this
order
Card was authorized, but AVS
CC
did not match. The 100 was
overwritten with a 260 per the
merchants request
(conditional deposits only)
301
Issuer
Unavailable
Resend
BML,
CC, SV
Auth network couldnt reach

the bank which issued the card
302
Credit Floor
Wait
BML,
CC, SV
Insufficient funds
303
Processor Decline Cust.
CC, SV
Generic decline - No other

information is being provided
by the issuer
304
Not On File
Cust.
BML,
CC
No card record, or,

invalid/non-existent to account
specified
332
Floor Low Fraud
Wait
CC
302 authorization response

low fraud. Reference 302
Insufficient Funds.
fraud scoring only

Page 120
09/21/2001

(Continued)
Response
Type
Code
Name
333
Floor Medium
Fraud
334
Floor High Fraud
Action
Payment
Method
Comments
Wait
CC

medium fraud. Reference 302
Insufficient Funds
fraud scoring only
Wait
CC

high fraud. Reference 302
Insufficient Funds
fraud scoring only
335
Floor Unavailable Wait

Fraud
CC

fraud service unavailable.
Reference 302 insufficient
funds
fraud scoring only
401
Call
Voice
BML,
CC
402
Default Call
Voice
CC
Approve/Decline
432
Call Low Fraud
Voice
CC
433
Call Medium
Fraud
Voice
CC
434
Call High Fraud
Voice
CC
401 authorization response low

fraud. Reference 401 Issuer
wants voice contact with
cardholder
fraud scoring only
Issuer wants voice contact with
cardholder
fraud scoring only
cardholder
fraud scoring only


cardholder
Page 121
09/21/2001

(Continued)
Response
Type
Code
Name
Action
Payment
Method
435
Call Unavailable
Fraud
Voice
CC
442
Default Call Low

Fraud
Voice
CC
443
Default Call
Medium Fraud
Voice
CC

Issuer wants voice contact
with cardholder
fraud scoring only
444
Default Call High Voice

Fraud
CC
445
Default Call
Unavailable
Fraud
Voice
CC

cardholder
fraud scoring only
Reference 401 Issuer wants
voice contact with cardholder
fraud scoring only
501
Pickup
Cust.
CC
Card issuer wants card

returned
502
Lost/Stolen
Cust.
CC
Card reported as lost/stolen
505
Negative File
Cust.
BML
508
Excessive Pin
Try
Cust.
CC

Comments
Reference 401 Issuer wants
voice contact with cardholder
fraud scoring only
low fraud. Reference 401
Issuer wants voice contact
with cardholder
fraud scoring only
On negative file
Allowable number of PIN tries
exceeded
Page 122
09/21/2001

(Continued)
Response
Type
Code
Name
Action
Payment
Method
Comments
Try
D
509
Over Limit
Cust.
CC, SV
510
Over Freq Limit
Cust.
CC, SV
519
On Negative File
Cust.
ECP
521
Insufficient Funds Cust.
CC,
ECP, SV
Exceeds withdrawal or activity

amount limit
Exceeds withdrawal or activity
count limit
Account number appears on
negative file
Insufficient funds/over credit
limit
522
Card is Expired
Cust.
CC, SV
Card has expired
530
Do Not Honor
Cust.
BML,
CC
531
CVV2/CVC2
Failure
Cust.
CC
532
Do Not Honor
Low Fraud
Cust.
CC
533
Do Not Honor
Medium Fraud
Cust.
CC
534
Do Not Honor
High Fraud
Cust.
CC
535
Do Not Honor
Unavailable
Fraud
Cust.
CC
540
Declined Under Cust.

18 Years Old
BML

Generic decline - NO other

information is being provided
by the issuer
Issuer has declined auth
request because CVV2 or
CVC2 edit failed
530 authorization response low
fraud. Reference 530 Do not
honor
fraud scoring only
Do not honor
fraud scoring only
high fraud. Reference 530 Do
not honor
fraud scoring only
Reference 530 Do not honor
fraud scoring only
The date of birth indicates
customer is less than 18 years
of age
Page 123
09/21/2001

(Continued)
Response
Type
Code
Name
Action
Payment
Method
541
Declined
Possible
Compromise
Cust.
BML
Customer reported possible

compromise and blocked
account
542
Declined Bill
To Not Equal
Ship To
Cust.
BML
Bill to address does not match

ship to address. Note: BML
first purchase must match
543
Declined
Invalid Preapproval Number
Cust.
BML
Pre-approval number not

recognized
544
Declined
Invalid Email
Address
Cust.
BML
Email address failed standard

validation rules
545
PA ITA Number
Inactive
Cust.
BML
Pre-approval number no longer

valid
546
Declined
Blocked
Agreement
Cust.
BML
Billing system account status
560
Declined Reauthorization
Fix
BML
Re-authorization request is
declined. Original
authorization could not be
found.

Comments
Page 124
09/21/2001

(Continued)
Response
Type
Code
Name
Action
Payment
Method
Comments
561
Declined Reauthorization No
Match
Fix
BML
562
Decline Reauthorization
Amount
Exceeded
Fix
BML
563
Declined Reauthorization
Declined
Timeframes
Fix
BML
declined. The timeframes for
re-authorization have been
exceeded
591
Invalid CC
Number
Cust.
CC
592
Bad Amount
Fix
BML,
CC
Bad check digit, length or

other credit card problem.
Issuer generated
Amount sent was 0 or
unreadable. Issuer generated
594
Other Error
Call
BML,
CC, SV
Unidentifiable error. Issuer

generated
602
Invalid Inst. Code
Cust.
CC
Card is bad, but passes Mod

10 check digit routine
603
Invalid Institution
Cust.
CC
Institution no longer valid
declined. The customer
account number, merchant id,
or amount did not match the
original authorization
declined. The amount
significantly exceeds the
original request amount
(i.e. possible merger)

D
605
Invalid Exp. Date Cust.
606
Invalid Tran Type Cust.
607
Invalid Amount
Fix
610
BIN Block
Cust
704
Stored
N/A
CC
Card has expired or bad date

sent. Confirm proper date
CC, ECP, Issuer does not allow this type
SV
of transaction
CC, SV Amount not accepted by
network
CC
Merchant has requested
Paymentech not process credit
cards with this BIN
CC, ECP FPO

Page 125
09/21/2001

(Continued)
Response
Type
Code
750
751
752
753
R
R
754
755
756
757
Payment
Method
Comments
Fix
ECP
Fix
ECP
Fix
ECP
ABA transit routing number is

invalid, fails check digit
Transit routing number not on
list of current acceptable
numbers
Pertains to deposit transactions
only
Invalid Account
Type
Fix
ECP

only
Account Closed
No Account/
Unable to Locate
Account-Holder
Deceased
Beneficiary
Deceased
Cust.
Cust.
ECP, SV
ECP
Cust.
ECP
Cust.
ECP
Bank account has been closed

Does not match any account
for the customer at the bank
Customer or account holder
has died
Beneficiary on account has
died
758
Account Frozen
Cust.
ECP, SV
759
Customer Opt-out
Cust.
ECP
760
ACH Nonparticipant
No Address
Cust.
ECP
Cust.
ECP
Cust.
ECP, SV
Cust.
ECP
Cust.
ECP
Fix
ECP
762
R
763
764
765
766
767
Name
Invalid Transit
Routing Number
Transit Routing
Number
Unknown
Missing Name
Invalid Account
Number
Authorization
Revoked by
Consumer
Customer
Advises Not
Authorized
Invalid CECP
Action Code
Invalid Account
Number Format
Action
Fix
ECP

Transaction posting to account

prohibited
Customer has refused to allow
transaction
Banking institution does not
accept ACH transactions
only
Account number is incorrect
Customer has notified their
bank not to accept these
transactions
Customer has not authorized
bank to accept these
transactions
Pertains to Canadian ECP
transactions only
Formatting of account number
is incorrect
Page 126
09/21/2001

(Continued)
Response
Type
Code
768
Name
Action
Payment
Method
Comments
Fix
ECP
802
Bad Account
Number Data
Positive ID
Voice
CC
806
Restraint
Cust.
CC, SV
811
Invalid Sec Code
813
Invalid PIN
Cust.
CC
825
No Account
Cust.
CC, SV
833
Invalid Merchant
Fix
BML,
CC,
ECP, SV
834
Unauthorized
User
Fix
CC, ECP Method of payment is invalid

for the division
902
Process
Unavailable
903
Invalid
Expiration
CC
Invalid or expired expiration

date
904
Invalid Effective
CC
Card not active
905
Declined Stand
In Rules
Auth Code
Responses
Fix
Resent
Resend
Invalid characters in account

number
Issuer requires further
information
Card has been restricted
CC, ECP Amex CID is incorrect
CC, SV
BML
PIN for online debit

transactions is incorrect
Account does not exist
Division number incorrect
System error/malfunction with

issuer
Declined authorization using

stand-in rules. Note:
authorization may be obtained
when systems are available
The following Auth Code responses may be generated by Paymentech to

indicate the status of a authorized transaction based on your processing
parameters.
Code
Description
notdep
not deposited
rcycle
not deposited in Paymentech recycle
sofdep
deposited transaction
tntCxx
test only (do not send in production)

Page 127
09/21/2001
APPENDIX B: ADDRESS VERIFICATION
Introduction
The Visa, MasterCard, Diners and Discover Address Verification Service

(AVS) and American Express's Automated Address Verification (AAV)
are intended to reduce the fraudulent use of credit cards for mail,
telephone, and other card not present transactions. AVS and AAV
presently verify U.S. issued credit cards only.
AVS/AAV Process
Each verification process is executed by comparing the transmitted billing

address with the billing address data that is kept on file for the cardholder.
The AVS/AAV request is routed from the Merchant through the
Paymentech system, directly to the specific credit card organization. The
address information is then compared to the cardholder billing address on
file.
The result of the AVS/AAV comparison is included in the authorization
response message returned to the Merchant. The AVS response is reflected
as a two-character code (e.g., I3 or ID).
In each of the card organizations address verification formats, the
AVS/AAV fields consist of 29 bytes of data: 9 bytes for the 9-digit Zip
Code and 20 bytes for the alphanumeric street address. Visa verifies the
first five numeric up to the first space or alpha character of the street
address.
In the Paymentech address format, Merchants may transmit either the zip
code only or multiple lines of address information.
Note: Extension records are used to verify full addresses. When
transmitting multiple lines of address information, the address line
immediately preceding the city, state, and zip code should always contain
the billing address to be verified since this line is the only line that we
transmit to Visa, MasterCard, American Express, and Discover. All data
must be in UPPER case.
The number in the street address and any numeric street name must be sent
in numeric form. For example, 123 FIRST STREET should be sent as 123
1ST STREET and ONE MAIN STREET as 1 MAIN STREET.
Any apartment number associated with the address should follow directly
after the street address on the same line.

Page 128
09/21/2001

(Continued)
AVS/AAV Process
(continued)
Multiple street address lines should use the following guidelines:
If the first line is 20 or more bytes of data, send the entire first line.
If the first line is less than 20 bytes of data, send the entire first line
followed immediately by as many bytes from the second line as it
takes to make a total of 20 bytes.
Below are 3 examples demonstrating how address information may appear

on cardholder billing statements, how it should be transmitted to
Paymentech, and then how Paymentech transmits it to the card
organizations.
Example 1:
Example 2:
Example 3:
Example
Full address with apartment number

Full address without an apartment number
Zip code only
Customer Provides
Merchant Sends and

Paymentech Stores in
Order History
Database
Paymentech Sends to
Visa/MC/AMEX/Disc
over
JOE BAGADONUTS
ABJOE *BAGADONUTS
0307990991 MAIN STAPT 22
1 MAIN ST
A21 MAIN STAPT 22
APT 22
A3SALEM, NH 03079-9099
SALEM, NH 03079-9099
SALLY JONES
ABSALLY JONES
7592 WEST BRIDGE AVE
A27592 WEST BRIDGE AVE
SUITE 73 B
A3SALEM, NH 03079-8956
0307989567592 WEST
BRIDGE AVE
SALEM, NH 03079-8956
03079-8956
AB03079-8956

03079-8956
Page 129
09/21/2001

(Continued)
AVS Response
Codes Example
Response
N1
N2

IG
IU
ID
IE
IS
Explanation
No address given with order
Bill-to address did not pass PTI edit checks (i.e., may be foreign)
AVS not performed (Blanks returned)
Issuer does not participate in Global AVS (International Issuer)
(International address information not provided, or provided and
issuer does not participate)
Issuer does not participate in Global AVS (Domestic Issuer)
Issuer does not participate in AVS
Edit Error- AVS data is invalid
System unavailable or time-out
Note: International AVS codes listed below are for VISA ONLY
IA
IB
IC
IP
I1
I2
I3
I4
I5
I6
I7
I8
International street address and postal code match

International street address match. Postal code not verified due to
incompatible formats (both were sent)
International street address and postal code not verified due to
incompatible format (both were sent)
International postal code match. Street address not verified due to
incompatible formats (both were sent)
Zip
Match
Match
Match
Match
No Match
No Match
No Match
No Match
Plus-4
Match
Match
No Match
No Match
Match
Match
No Match
No Match
Locale
Match
No Match
Match
No Match
Match
No Match
Match
No Match
Shaded codes in the AVS table shown above are no longer provided by
Visa. Visa eliminated the distinction between Zip and Zip+4 and
consolidated the response codes previously provided.

Page 130
09/21/2001

(Continued)
AVS Response Key
Item
Definition
ZIP
5-digit code.
Plus-4
4-digit portion of the 9-digit zip code.
Locale
Street address, PO Box, or other local delivery destination.
Responses from the Issuer or Network.
Responses from Paymentech.
Match
Information presented in the record field matches the

information stored on the card issuers file.
No Match
Information presented in the record field does not match the

information stored on the card issuers file.

Page 131
09/21/2001
APPENDIX C: ERROR SCREENING
Bad Card Number

Check
There are three common edits which catch the greatest majority of bad card
numbers:
MOD 10 check digit
Credit card prefix check
Credit card length validation
A discussion of these edits follows.

MOD 10 Check Digit
The MOD 10 check digit calculation validates the credit card by

calculating the last digit of the card number from all the other numbers in
the card.
The last digit of a credit card can be calculated based on a calculation
performed upon all the digits preceding it. This operation is called a MOD
10-check digit routine.

Page 132
09/21/2001

(Continued)
The general idea of this calculation is as follows:
MOD 10 Check
Digit (continued)
Example:
5 2
9 1
0 1
Card number 5240159910151573

5
1 5 7
Start from the right and proceed to the

left until all digits are multiplied by
weight
7 * 2 = 14
sum = 1 + 4
=5
5*1=5
sum = sum (5)
+5
=10
1*2=2
sum = sum(10)
+2
=12
5*1=5
sum = sum(12)
+5
=17
1*2=2
sum = sum(17)
+2
=19
0*1=0
sum = sum(19)
+0
=19
1*2=2
sum = sum(19)
+2
=21
9*1=9
sum = sum(21)
+9
=30
9 * 2 = 18
sum = sum(30)
+1 + 8 =39
5*1=5
sum = sum(39)
+5
=44
1*2=2
sum = sum(44)
+2
=46
0*1=0
sum = sum(46)
+0
=46
4*2=8
sum = sum(46)
+8
=54
2 * 1 =2
sum = sum(54)
+2
=56
5 * 2 =10
sum = sum(56)
+1 +0
=57
Remove the check digit, 3, which is already present in this example

sum = 57
sum MOD 10 > 57 MOD 10 = 7
10-7 = 3
check digit of 5240159910151573 is 3.

Page 133
09/21/2001

(Continued)
MOD 10 Check Digit

(continued)
The following routine is a check digit routine written in the C

programming language.
/* The operator for mod in C is % */
long mod10 (card,card_len-1)
/* module 10 check digit function */
char *card;
/* credit card number */
short card_len
/* card length */
{
register int count;
/* a counter */
register int weight;
/* weight to apply to digit being checked */
register int sum;
/* sum of weights */
register int digit;
/* digit being checked*/
long mod;
weight=2;
sum =0;
/*
compute the sum */
for (count = card_len - 1; count >=0; count = count -1)
{
digit = weight * (card[count] - 0);
/* add both the tens digit and the ones digit to the sum */
sum = sum + (digit / 10) + (digit % 10);
if (weight ==2)
weight = 1;
else
weight = 2;
}
/* subtract the ones digit of the sum from 10 and return the ones digit of
that result */
mod = (10 - sum%10) % 10;
return (mod)
}

Page 134
09/21/2001

(Continued)
Card Prefix Check
Card Length Check
The prefix check is the comparison of the first few digits of each card
number to a list of known prefixes.
Card Type
Prefix
American Express
Bill Me Later
Carte Blanche
Carte Blanche International
Diners Club
Discover (Novus)
Encrypted
JCB
MasterCard
Optima
Stored Value
37, 34
504990
94, 95, 389
9
30, 36, 381 - 388
60110, 60112, 60113, 60114, 60119
Unknown
3528 - 3589
51 55 with the exception of 504490
37*7, where * is any single digit
603571
Switch/Solo
49, 56, 6*, 7*where * is any single digit
Visa
The number of digits for each card is constant, allowing a validation to

be performed by verifying the number of digits for each card number.
Card Type
Length
American Express
Bill Me Later
15
16
Carte Blanche
Carte Blanche International
Diners Club
Discover (Novus)
Encrypted
JCB
MasterCard
Optima
Stored Value
Switch/Solo
14
10
14
16
16 to 19
16
16
15
19
16,18 or 19
Visa
13 or 16

Page 135
09/21/2001
APPENDIX D: MODEM SET UPS
Introduction
This appendix lists settings for synchronous and asynchronous modems.
Synchronous
Modems
Occasionally, synchronous modems need settings altered to communicate

with each other. Listed below are some Paymentech settings that may be
useful if trouble is encountered during communications testing.
Setting Choices
Paymentech Settings
Conditioned/Unconditioned Lines
Set for unconditioned
Carrier Detect Level
- 44 dB
Chassis/Signal Ground
Set for signal ground
Transmit Clock
Internal (modem) Clock
Digital Pre-equalization
Set to ON
Signal Quality Retrain
Auto retrain on poor quality
Line Current Disconnect
Disconnect on 8ms break

Page 136
09/21/2001
APPENDIX D: MODEM SET UPS
Asynchronous
Modems
Settings for the Telebit Trailblazer Plus and Telebit T2000 follow:
Setting Choices
Paymentech Settings
Interface Speed
1,200 bps to 19,200 bps
DTR Interpretation
Telebits option #2
DTE Flow Control
Telebits option #4
Prompt Character
$ (ascii 36)
Interface Speed
Locked, flow control
Data Compression Enabled
Option #1

Page 137
09/21/2001
APPENDIX E: INTERNATIONAL PROCESSING
Record Layout
The standard Paymentech Technical Specification record layouts are

utilized to process international transactions.
Notes: Address Verification processing is not available for any
international transactions with the exception of Visa.
There are specific formats used for international On-Line
Authorizations of credit and debit cards.
Contractual
Agreement
The Merchant is required to establish a separate contractual agreement

with Paymentech. Contractual agreements vary by country.
Division Numbers
Paymentech assigns a unique Division Number to process each

international currency. A single Division Number can support different
transaction types and methods of payment in the same currency. All
transaction types and currencies may be submitted in the same file for
authorization or settlement, but the correct Division Number and currency
code must accompany the corresponding transaction.
Zero Decimal
Currencies
Certain International currencies have zero decimals. Those currencies are

as follows:
Belgium Francs
Italian Lira
Greece Drachma
Japanese Yen
Portugal (Portuguese) Escudo
Spanish Peseta
Zero Decimal
Example
Since the amount field is two decimal implied:

-to represent one Japanese Yen, (1=000000000100)
-to represent one hundred Japanese Yen, (100=000000010000)

Page 138
09/21/2001
APPENDIX F: AMERICAN EXPRESS AND DISCOVER CARD

IDENTIFICATION (CID) PROCESSING
Introduction
Merchant
Requirements
American Express and Discover, in an effort to improve fraud control and

increase security, has implemented a process that verifies the Card
Identification (CID) value at the point of authorization.
American Express The CID number is printed, not embossed
on the laminated surface of all America Express Cards. Appears on
the right border of the card. (4 byte)
Optima Cards The CID number is printed, not embossed on the
laminated surface. Appears on the left border of the card. (4 byte)
Discover The CID number appears on the right side of signature
panel. (3 byte)
It is the goal of American Express and Discover to have Merchants
accepting card-not-present transactions to request the CID from the
cardholder at the point of sale and include the CID in the transaction
authorization request. The CID is then passed onto American Express and
Discover and validated by their systems. In situations where the CID value
is invalid, American Express responds with a decline for the auth request.
The following are Merchant requirements to support one or both of these
programs.
1. For American Express, the merchant must contact their American
Express Client Manager in order to have their service establishment
numbers set up for the CID program.
2. For Discover, the merchant does not need to contact Discover prior
to accepting CID values.
3. The merchant must obtain the CID number from the cardholder at
the point of sale. The CID number must be captured and
transmitted to Paymentech along with the transaction authorization
request.
4. The merchant must have the ability to support the product format
(PFR record), which contains the CID field. This record must be
placed immediately after the Transaction File Detail Record of the
corresponding authorization request.
5. The CID must not be stored in the merchants internal database.

Page 139
09/21/2001
APPENDIX G: AMERICAN EXPRESS TRANSACTION ADVICE

ADDENDUM (TAA) RECORDS
TAA Records
American Express allows the use of four Transaction Advice Addendum

(TAA) records with each settlement item so that an American Express
Merchant has the ability to provide an American Express cardholder with
additional detailed descriptive transaction information.
Typically these four, forty byte fields are maintained within Paymentechs
Merchant database at an American Express Service Establishment level and
if present, are appended by Paymentech to each settlement transaction
submitted by a Merchant. The implementation outlined in the American
Express Extension Records allows a Merchant to submit the four TAAs
with each and every transaction. This allows a Merchant flexibility at a
transaction level rather than a Service Establishment level. If the TAAs are
not submitted, Paymentech will utilize the defaults within our Merchant
database.
This is extremely helpful in a Purchasing Card scenario where a cardholder
is using an American Express Purchasing card. Businesss that rely on
Purchasing cards to fulfill purchase order needs have unique data
requirements. When a cardholder has specific requirements for data
disclosure, the Merchant can support those requirements through the use of
this Extension Record.
Note: TAA records are only supported for U.S. dollar transactions.
Sample Input
File
S1234569898981234SALE
BAX373235387881007
EAX001SAM WHATSHISNAME
EAX002XYZ WIDGETS
PPC001ABC1230000000000000000000000000000101
ABSAM WHATSHISNAME
A223 NORTH POLICY RD
D6035554444
A3SALEM, NH 03079-9099
AS03079-9099
07970000000001008401001
SALES DEPARTMENT
QUANTITY 542
970701 (1)
(2)
(3)
(4)
(5)
(6)
(7)
(8)
Input File Line Item Description

Line 1:
Line 2:
Line 3:
Line 4:
Line 5-7:
Line 8:
Detail Record [American Express conditional deposit with address

verification requested for a Corporate Purchasing Card]
Extension Record: American Express - 1
Extension Record: American Express - 2
Product record: Procurement (Level 2)
Address Record [With bill-to-address]
Address Record [With ship-to-address zip code]

Page 140
09/21/2001
APPENDIX H: VISA PAYMENT SERVICE 2000 (PS2000) PROCESSING
Introduction
The Visa Payment Service 2000 Program (PS2000) was created to improve
the electronic authorization and settlement of Visa credit card transactions
by uniquely linking all aspects of a transaction authorization, original
presentments, retrieval requests, chargebacks, representments, and
mediation. The PS2000 program was rolled out in three phases: Custom
Payment Service/Retail, Chargebacks, and Custom Payment Service/Non
Face-to-Face.
Custom Payment
Service/Retail (CPS)
The initial market segment targeted by Visa was retail. To encourage

merchant participation in Custom Payment Service (CPS), Visa introduced
a new interchange rate for qualified transactions, Custom Payment
Service/Retail (CPS/Retail).
Qualification for CPS/Retail requires that the following criteria be met for
the authorization:
The credit card must be present at the time the transaction takes
place.
The magnetic stripe on the card must be read electronically and the
entire contents of Track 1 or Track 2 must be submitted with the
authorization request.
The transaction must be approved through the Vital (VisaNet)

system.
Only one authorization may be requested per transaction.
The transaction must be submitted for clearing within two business

days from the original transaction date.
A signature must be obtained.
The deposit amount must be within 15% of the original authorized

amount.

Page 141
09/21/2001

(Continued)
Custom Payment
Service/Retail (CPS)
(continued)
Qualification for CPS/Retail requires that the following information be

carried from the authorization process through to clearing:
Authorization Characteristics Indicator
Transaction Identifier
Validation Code
Response Code
Authorized Amount
Total Authorized Amount
Merchant Category Code (MCC)
Descriptions of the above fields are included in the Field Definition for the
Transaction File Extension Record: Visa.
Chargebacks
The second phase of CPS, implemented in August of 1993, focuses on the

Chargeback system: chargebacks, retrieval requests, and representments.
Visa requires that Transaction Identifiers (TIDs), which are assigned at
authorization time, follow a transaction through the entire Chargeback
system. This means:
A chargeback on a transaction must have the same TID as in the

initial presentment.
A representment of that chargeback must also have the TID.
All subsequent activity must also include that same TID.
Mail order transactions that do not have a TID at original presentment are
assigned one by Visa. This TID follows the transaction through its life
cycle from that point on.

Page 142
09/21/2001

(Continued)
CPS/Non Face-toFace
The third phase of CPS deals with many different market segments and
includes Direct Marketing. As with Retail, Direct Marketing transactions
within the CPS program have their own interchange rate, CPS/Non Faceto-Face.
Qualification for CPS/Non Face-to-Face requires that the following criteria
be met:
A request for Address Verification (AVS) must be performed (a 5digit zip code at minimum).
The Merchant must use their Customer Service phone number in the
City field. This is included in the account set-up procedure.
The authorization and settlement dollar amounts must match (this

can be accommodated through authorization reversal).
The transaction must be approved through the Vital (VisaNet)

system.
Only one authorization may be performed per settlement item.
The shipping date must be within seven days of the authorization.
The settlement transaction must include an order number.
The TID and all other associated CPS enhanced data from the
authorization must be included with the settlement item; these are
the same items as listed earlier for clearing CPS/Retail transactions.

Page 143
09/21/2001
APPENDIX I: MASTERCARD INTERCHANGE COMPLIANCE PROGRAM
Introduction
The MasterCard Interchange Compliance Program was designed to

improve data integrity in the authorization and settlement process
specifically as it relates to interchange and MasterCard regulation
compliance.
The primary function of the MasterCard Interchange Compliance Program
is to match daily settlement transactions with their appropriate
authorizations. The fields used to match the settled transaction with the
corresponding authorization are:
Interchange Rate
Account Number
Banknet Reference Number
Banknet Date
To ensure participation in this Program, MasterCard downgrades the

interchange rate for transactions when certain data elements of the settled
item are different than those of the authorization.
The data elements to be verified during this matching process are as
follows:
POS Entry Mode
Response Date (Authorization Date)
MCC (Merchant Category Code)
Authorized Amount (Retail only)
Response Code (Authorization Code)
In addition, MasterCard downgrades transactions that do not meet certain

authorization to settlement timeliness criteria.

Page 144
09/21/2001
APPENDIX J: CVV2 VISA/CVC2 MASTERCARD PROGRAMS

Introduction
Paymentech supports Visas CVV2 (Card Verification Value 2) and

MasterCards CVC2 (Card Validation Code 2) fraud reduction programs.
CVV2 and CVC2 is a security feature required to appear on all Visa cards
issued after December 31, 1999 and all MasterCards issued after
December 1998. This numeric (3-digit) is located on the signature panel
on the reverse side of the credit card and is represented by the three digits
following the account number. This is captured from the magnetic stripe in
a retail environment.
The use of this numeric provides an important security check due to the
fact that only the individual in possession of the actual credit card will be
able to provide the value to the merchant. Statistics validate that
individuals who may know the account number but are not in possession of
the actual credit card perpetrate much of the fraud occurring in the nonface-to-face environment.
When a merchant collects this value and passes it in the authorization
request to Paymentech, Paymentech passes this data through the
authorization system to the card issuer. In the authorization response, the
card issuer validates the accuracy of the CVV2/CVC2 value for that
specific card. Used in conjunction with the valid expiration date, this
service provides a valuable tool in assessing that the true cardholder has
placed the order with you for your services or product.
This value must not be stored.
Fraud Product Fields
Paymentech supports this product through the usage of the Fraud Product
Fields.
Positions 7-10 are where the 3-digit value should be placed.
Position 11 indicates the presence of the value and may include:

1 = Value is present
2 = Value is on the card but illegible
9 = Cardholder states that the 3-digit value is not present on
the card
Note: If not a Visa transaction, leave blank


Page 145
09/21/2001
APPENDIX J: CVV2 VISA/CVC2 MASTERCARD PROGRAMS

(Continued)
Fraud Product Fields

(continued)
Expected Responses are:

M = CVV2/CVC2 matched
N = CVV2/CVC2 not matched
P = Not Processed (issuer or authorization network failed to
process)
S = Should be on Card (Merchant passed a 9 in position 11)
Note: Visa only
U = Unsupported by Issuer
I = Invalid (Value failed Paymentech edits). Edits validate 3-digit
numeric or that positions 7 through 10 are blank if position
11 is filled with a 2 or 9.
Notes: Merchants should be cautious in their processing of transactions

where the CVV2/CVC2 response is an N or S.
CVV2/CVC2 responses are separate from the authorization response. For
example: it is possible to get an approved authorization response and a No
Match on the CVV2/CVC2 data.

Page 146
09/21/2001
APPENDIX K: AUTHORIZATION RECYCLING PROGRAM
Introduction
Authorization recycling is a tool developed by Paymentech to allow our

merchants the ability to maximize sales dollars. This tool allows
Paymentech, on your behalf, to re-attempt to obtain a valid authorization
code in certain circumstances when the Card Issuer declines the original
authorization attempt. Our research indicates that the use of this product
can increase your approval rate and therefore serves to maximize your
sales.
If the result of the original authorization request is a decline, the Merchant
or vendor has limited options. The decision regarding how to react to a
non-approved authorization may have a significant impact on customer
service and sales.
Paymentech recommends that merchants take advantage of our
Authorization Recycle Product that will automatically recycle transactions
for authorization when the original attempt results in a soft decline.
Paymentech has the ability to store and automatically recycle soft declines
with minimal merchant intervention. The Authorization Recycle Product
allows merchants to specify parameters for scheduled authorization reattempts. Recycling of authorizations typically results in a lift in approval
rates, recovering valuable sales. Authorization Recycle is available only to
merchants who present conditional deposit transactions (B action code).
To Get Started
If you are interested in pursuing Paymentechs Authorization Recycle

opportunities please contact your Account Manager for more information
regarding the technical requirements as well as business impact.

Page 147
09/21/2001
APPENDIX L: PROCUREMENT CARDS

Introduction
Paymentech supports the processing of procurement cards by fully

supporting the enhanced data required by Visa, MasterCard for level 2 and
level 3 data. Level 2 and enhanced TAA for American Express.
Purchasing cards with level 3 data are typically used in a business-tobusiness environment providing merchants with a mechanism to eliminate
the costly paper process of providing and collecting funds for outstanding
invoices. Merchants have the ability to collect their funds in conjunction
with the settlement of their credit card transactions and still provide their
customer with the necessary line item detail. Thus, providing a cleaner
process for both the merchant and consumer.
Notes: Purchasing Card product records will only be conveyed during the
deposit process. If submitting purchasing card transactions with action
code A (Auth only), it is not necessary to send additional product records
as additional costs will be incurred for processing of these records.
Edit Checks
Paymentech performs edit checks on incoming data to ensure necessary

information is present. In the event necessary information is missing from a
transaction with level 2 data, the interchange rate for the transaction will be
downgraded accordingly and passed on to the respective card association.
However, if necessary information is missing from a transaction with
level 3 data, the transaction will be rejected by Paymentech and a
response code of 243 will be returned indicating required level 3 data
was missing. Data fields that are edited by Paymentech have been marked
required in the record layout section of this document.
BIN Ranges
The BIN range assigned by the card associations can identify purchasing
Cards. Commercial Card BIN Ranges (Business, Corporate, Purchasing)
are available via Paymentech Online. Active BINS can be downloaded.
This listing is updated on or around the 15th of each month.
Note: BIN Ranges are subject to change at the discretion of the card
associations.
Currency
Restrictions
A few foreign issuers support level 2 purchasing card transactions processed

in US currency through US Interchange.
Currently, level 2 and 3 is not supported in any international currency.

Page 148
09/21/2001

(Continued)
American Express
Level 2/3
American Express currently supports level 2 and enhanced TAA

processing with Paymentech. In order to send American Express
Purchasing Card transactions, the Merchant must contact American
Express first to be set up.
Note: Prior to submitting American Express purchasing card transactions,
please contact American Express and your Paymentech representative to
have your account set up.
Required Records for American Express Level 2/3
MasterCard/Visa
Level 2
Card Type
Required Record
Description
Comments
Amex
S Record Output
EAX
TAA record for Amex
TAA1 and TAA2
EAX
TAA record for Amex
TAA3 and TAA4
PPC
Product record for

procurement
Can be sent without EAX records
Level 2 is used for Corporate/Business Cards

-
Corporate/Business cards are issued to a Corporation for travel,

entertainment and other expenses. MasterCard previously used the term
business card and now uses corporate card. Visa uses both
business card and corporate card terms.
Required Records for Level 2

Card Type
Required Record
Description
Visa/MC
S Record Output
PPC
Product Record for

Procurement
Address Record(s)

Comments
Not required for level 2 processing,

however, required for level 3
processing
Page 149
09/21/2001

(Continued)
MasterCard/Visa
Level 3
Level 3 is used for Purchasing Cards (also known as Business to Business)

-
Consider this as a replacement for a Purchase Order
In order to provide the necessary enhanced data, Paymentech requires four (4)
records to be submitted per transaction. These records are:
Product Record:
Product Record:
Product Record:
Product Record:
Procurement Level 2
Procurement Level 3 Order Level
Procurement Level 3 Record #1 Line Item Detail Record
Procurement Level 3 Record #2 Line Item Detail Record
Required Records for Level 3
Record Sequence
Card Type
Required Record
Description
Comments
Visa/MC
S Record Output
PPC
Product Record for

Procurement
PP0
Product Record for

Procurement level 3
Order level record. See spec for

specific record for Visa and for
MasterCard
PP1
Product record for

Procurement level 3
Line item level data one for each

line item. See spec for specific record
for Visa and for MasterCard
PP2
Product record for

Procurement level 3
Line item level data one for each

line item. See spec for specific record
for Visa and for MasterCard
Address Record(s)
Transactions must be submitted using this record sequence. A record may

have up to 99 line item detail records.
Note: Line item detail records #1 and #2 must both be present in sequential
order increasing by one (1) to meet processing requirements.

Page 150
09/21/2001

(Continued)
Record Sequence
Example
Proper sequence for sending an order with 100 line items:

S
Detail record with the total amount for the first 98 line items is
generated
PPC001
Level 2 order level with the sales tax amount for the first 98 line items
PP0001
Level 3 order level with the freight amount for the first 98 line items
PP1002
Level 3 record for line item #1 First line item
PP2002
Level 3 record for line item #1
PP1003
Level 3 record for line item #2 Second line item
PP2003

PP1099
Level 3 record for line item #98 Ninety-eighth line item
PP2099
Detail record with the total amount for lines 99-100
PPC001
Level 2 order level with the sales tax amount for line items 99-100
PP0001
Level 3 order level with the freight amount for the line items 99-100
PP1002
PP2002
PP1003
PP2003
Detail record for the next order to be processed

Page 151
09/21/2001

(Continued)
Input File
PID=118208 pti_sub SID=118208 reg test START
01.6
S900365NMMCPUR900365CPD DMC5405107000070873
1299000000100000840100
PPC0013462265554KMG3650000000000100
PP0001
000050000
00000000001844
USD03079-1952001-348765
000004000
PP1002CADILLAC COUPE DEVILLE
016625033000
00001CAR
00000000000000
PP2002
003500000
000000000
Y
N
S900365NMMCPUR900365CPD BVI4246040020389229
1299000000100000840100
PPC0013462265554KMG3650000000000100
PP000100000005000000000000000001844
USD03079-19520000000000000000000000000000
PP1002CADILLAC COUPE DEVILLE
016625033239000000010000CAR
00000000000000000
PP2002000003500000000000000000AUTO
000350000000
PID=118208 pti_sub SID=118208 reg test END
[ 1]
[ 2]
[ 3]
[ 4]
[ 5]
[ 6]
[ 7]
[ 8]
[ 9]
[10]
[11]
[12]
[13]
[14]
Sample Input File: MasterCard and Visa

Line 1:
Line 2:
Line 3:
Line 4:
Line 5:
Line 6:
Line 7:
Line 8:
Line 9:
Line 10:
Line 11:
Line 12:
Line 13:
Line 14:
Header Record
Detail Record (MasterCard)
Product Record: Procurement Level 2 (MasterCard)
Product Record: Procurement Level 3 Order Level Record (MasterCard)
Product Record: Procurement Level 3 Record #1 (MasterCard)
Product Record: Procurement Level 3 Record #2 (MasterCard)
Detail Record (Visa)
Product Record: Procurement Level 2 (Visa)
Product Record: Procurement Level 3 Order Level Record (Visa)
Product Record: Procurement Level 3 Record #1 (Visa)
Product Record: Procurement Level 3 Record #2 (Visa)
Batch Totals Record
Totals Record
Trailer Record

Page 152
09/21/2001
APPENDIX M: RETAIL ENABLE
Introduction
Paymentechs Retail Enable program is designed to provide a single

processor for the merchant with both Point of Sale and Direct processing
needs. This includes single settlement and reporting for Point of Sale and
Direct transactions.
Merchant
Requirements
The following are the merchant requirements to support the Retail Enable
program:
Retail Enable
Product Record
The merchant must have a Retail Enable (Point of Sale) division for
processing.
To obtain detail POS reporting, the merchant must have the ability to
support the Product Record format (P record), which contains the
Terminal and Batch Identification. This record must be placed
immediately after the Transaction File Detail Record (or extension
record that follows) for the corresponding Point of Sale deposit
transaction. (See Format Specifications for a general outline of the
Paymentech format).
Paymentech supports this product through the use of the Retail Enable
Product Record. The product record will need to appear within the
settlement file.
Positions 7,22 - designate location of the Terminal Identification value
Positions 23,36 - designate the location of the Batch Identification value
Note: Retail Enable Product Record is necessary for special detail level
reporting.

Page 153
09/21/2001
APPENDIX N: PAYMENTECH FRAUD DETECTION SERVICE
Introduction
How it works
Paymentech Fraud Detection Service is designed to reduce a merchants

risk of approving fraudulent transactions in the card-not-present
environment while minimizing the number of false positives (good orders)
that may have been detected as potential fraud.
Paymentech Fraud Detection Service uses predictive analysis tools based on
HNC's industry-leading eFalcon fraud scoring neural network technology.
eFalcon maintains and constantly updates an extensive database of
transaction and card account information gathered from card issuers and
merchants around the globe.
Paymentech Fraud Detection Service analyzes the relationships between
various data items to identify suspicious orders and to distinguish in real
time the probability of fraudulent transactions. As each transaction is
analyzed against cardholder and merchant data to detect patterns of fraud, a
fraud-risk score is computed. Paymentech has further enhanced the system
by making it very simple to deploy.
Merchant
Requirements
Paymentech Fraud Detection Service is easily integrated into your current

authorization and order management process, significantly reducing
development time and costs. Merchants may choose to be partial
participants (score some transactions), or full participants (score all
transactions).
For full participation, a merchant must process transactions using the 96byte version 1.6.1 Batch or higher or the Batch 80-byte (tjl) format
specification. Merchants processing online require the Online version 3.0
or higher. Paymentech will modify specific Merchant processing
division(s).
For partial participation, merchants must process transactions using the 96byte, version 1.6.1 Batch or higher, or the Online, version 4.0 or higher
format specifications.
Supported card
types/currencies
Paymentech Fraud Detection Service supports both domestic and

international currencies and includes credit and debit based products for
many major credit cards including: MasterCard, Visa/Delta, American
Express, JCB, Diners and Discover Cards.
Authorization
Response Codes
See Appendix A
To Get Started
Please contact your Paymentech representative to begin screening your

transactions for potential fraud.

Page 154
09/21/2001
APPENDIX O: BILL ME LATER

Introduction
Bill Me Later is an innovative and secure payment solution for card-nopresent merchants. The Bill Me Later method of payment is a non-plastic
issued credit vehicle that manages the consumer payment function by
providing a transactional credit decision in lieu of the standard
predetermined credit line and associated authorization process. Bill Me
Later allows consumers to make online/mail order purchases without
inputting credit card information.
How it works
Using proprietary credit scoring and fraud detection capabilities, GoPin

screens each Bill Me Later transaction in real time, instantly decisioning all
BML requests made by customers.
Merchant
Requirements
To offer the Bill Me Later payment option to consumers, merchants must be

processing Online version 6.0 or higher or 96 Byte Batch version 1.7.1 or
higher.
Supported currencies
U.S. Currency
Authorization
Response Codes
See Appendix A
To Get Started
Contact your Paymentech representative.

Page 155
09/21/2001
APPENDIX P: PAYMENTECH STORED VALUE

Introduction
Paymentechs stored value program provides an electronic stored value

payment instrument through the use of plastic cards encoded with a
magnetic stripe or e-mail certificate. The stored value card or e-mail
certificate is used by the Merchant to issue spending credit to their
customers. Popular uses for this stored value program include, but are not
limited to, an electronic version of paper gift certificates, merchandise
return cards, and prepaid cards.
How it works
The Merchants customers are given a magnetic stripe card or an e-mail

certificate by the Merchant in exchange for money received, merchandise
returned or other considerations. The card/certificate represents a dollar
value that the Merchants customer can either use or give to another
individual. The actual record of the balance on the account is maintained
on Paymentechs Stored Value Card database.
The card or e-mail certificate, the design and use of which is proprietary
to the Merchant, is designed to be swiped through a POS terminal or have
the account number keyed using transaction processing software interface.
In a physical store, when the customer gives the magnetic stripe card to
the cashier, the cashier will press the appropriate keys, dependent upon
the transaction type, swipe the card into the terminal and key in the
amount to be applied against the cards balance. If the card or e-mail
certificate is being used at a storefront that is not a physical location, then
the customer or an employee of Merchant enters the card account number,
transaction amount, and other relevant data into Merchants transaction
processing software. This information will be transmitted to Paymentech,
and the appropriate approval response will be routed to the Merchant.
Merchant
Requirements
For full participation, a merchant must process transactions using the 96byte version 1.7.1 Batch or higher. Merchants processing online require the
Online version 6.0 or higher.
Supported currencies
Paymentech Stored Value supports domestic currencies.
Authorization
Response Codes
See Appendix A
To Get Started
Please contact your Paymentech representative to begin accepting

Paymentech Stored Value Transactions

Page 156
09/21/2001
INDEX
Procurement Level 3 - Mastercard and Visa Record #1 ..................................................................... 87
Procurement Level 3 - Mastercard and Visa Record #2 ..................................................................... 88
Retail Enable .................................................................... 90
Stored Value ..................................................................... 91
Various Text ..................................................................... 92
Request for Response File (RFR) Record .................... 99
3
3780 ...............................................................................................114
A
Address Verification ......................................................................128
Address Verification Response Codes ..............................131
American Express and Discover Card Identification (CID) Processing
..................................................................................................139
American Express Transaction Advice Addendum (TAA) Records140
Asynchronous Modems..........................................................136, 137
Asynchronous Transmission ..........................................................113
Authorization Recycling ................................................................147
Authorization Recycling Program ......................................147
AVS Error Screening ..............................................................132
AVS Response Codes .............................................................130
AVS Response Key........................................................................131
AVS/AAV Process ..................................................................128
Totals Record ............................................................................. 97

Trailer Record ....................................................................... 98
Format Specifications
Request for Response Files .......................................................... 3
Transaction File
Extension Record .................................................................... 3
Format Usage
General Information ................................................................. 103
Paymentech Output .................................................................. 104
Sending Pre-Authorized Records ............................................. 103
Fraud Product Fields .............................................................. 145
Card Length Check .................................................................135

Card Prefix Check ...................................................................135
Chargebacks ..............................................................................142
CPS/Non Face-to-Face ...........................................................143
Credit Card Information.................................................................132
MOD 10 check digit .................................................................132
MOD 10 check digit C source code example ............134
CVC2 - MasterCard Program ..............................................145
CVV2 - Visa Program ............................................................145
D
Data Transmission Times...............................................................112
F
Field Definitions
Address Record .....................................................................93

Batch Totals Record ............................................................96
Detail Record
Credit Card ........................................................................52
Extension Record
American Express - 1 & 2 .....................................................63
Bill Me Later .........................................................................78
Electronic Check Processing .......................................74
MasterCard ............................................................................64
Switch Card ...........................................................................77
Visa 1 ..................................................................................67
Visa 2 Visa Authentication .......................................72
Header Record ............................................................................51
Information Record
Consumer Information...........................................................82
Order Information..................................................................80
Input File Sample .......................................................................... 105

Instant Authorization ..................................................................... 111
International Processing ........................................................ 138
Contractual Agreeement........................................................... 138
Division Numbers .................................................................... 138
Record Layout.......................................................................... 138
Introduction ....................................................................................... 2
Mastercard Interchange Compliance Program

Interchange Rate ................................................................. 144
MasterCard Interchange Compliance Program.............................. 144
Merchant Certification Analyst ..................................................... 107
MOD 10 Check Digit .................................................................... 132
C' Source Code example .......................................................... 134
Modems
Asynchronous........................................................................... 136
Set Up....................................................................................... 136
Synchronous............................................................................. 136
Output File Sample ................................................................. 106

P
Phones, Calling Paymentech ......................................................... 111
Problems........................................................................................ 112
Procurement Cards ........................................................................ 148
Production Procedures................................................................... 111
Products Supported ..................................................................... 1
PS2000........................................................................................... 141
Product Record
Record Layout
Fraud ...................................................................................89
AMEX TAA 1 Field ..................................................... 11, 12
Procurement Level 2 and Level 3 - MasterCard and
International Processing ........................................................... 138
Visa .................................................................................85 Request for Response (RFR) ............................................................. 3
Procurement Level 3 - Mastercard and Visa - Order Response Reason Code Description/Usage ................................... 116
Level Record ...............................................................86
Page 157
09/21/2001
INDEX
S
Synchronous Modems....................................................................136
Synchronous Transmission ............................................................114
T
Testing Checklist Table .................................................................107
Transaction Extension Record Format

- American Express 1 ..........................................................11
- American Express 2 ..........................................................12
Transaction File
S Record Output ...............................................................47
Address Record .....................................................................37
Address Record Examples ...........................................41, 42
Batch Totals Record ............................................................43
Detail Record .............................................................................6
Extension Record
Bill Me Later.....................................................................18
Electronic Checks............................................................16
MasterCard ........................................................................13
Switch .................................................................................17
Visa 1 ..................................................................................14
Visa 2 Visa Authentication .......................................15
Header Record .........................................................................5
Information Record
Consumer Information ...................................................22
Order Record
Order Information ...........................................................20
Product Record
Fraud ...................................................................................32
Procurement Level 2 ................................................24, 25
Procurement Level 3 - MasterCard Order Level
Record............................................................................29
Procurement Level 3 - MasterCard Record #1 ......30
Procurement Level 3 - MasterCard Record #2 ......31
Procurement Level 3 - Visa Order Level Record ..26
Procurement Level 3 - Visa Record #1 ....................27
Procurement Level 3 - Visa Record #2 ....................28
Retail Enable.....................................................................34
Stored Value .....................................................................35
Various Text .....................................................................36
Request for Response (RFR) Record .............................46
Totals Record .........................................................................44
Trailer Record.............................................................................45
Transmission Specifications...........................................................113
Visa Custom Payment Service 2000 (PS2000) Processing

..................................................................................................141

Page 158
09/21/2001
END OF THE TECHNICAL SPECIFICATIONS

96-BYTE for BATCH PROCESSING
Rev. 01.7.1
09/21/2001

Page 159
09/21/2001

96byte Spec

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

96byte Spec

Uploaded by

Copyright:

Available Formats

integrated

96-Byte Technical Specification

4 Northeastern Blvd. Salem, NH 03079-1952

Paymentech 2001 - All rights reserved

This document contains confidential and proprietary information of Paymentech Network

The following updates, additions, corrections have been incorporated in

96-Byte for Batch Processing Rev. 01.7.1

7, 47, 48, 55, 99

8, 48, 57, 100

18, 77, 154

35, 90, 155

FIELD DEFINITIONS ............................................................................................................................................... 51

Auth Code Responses........................................................................................................................................... 127

Introduction .......................................................................................................................................................... 148

Paymentech 2001 - All rights reserved

German Deutsche Marks

Paymentech Fraud Detection Service

Paymentech 2001 - All rights reserved

The general outline for the Paymentech format is as follows:

Batch Totals Record

Paymentech 2001 - All rights reserved

All transaction files received by Paymentech must contain a Header

The Transaction File Extension Record is utilized to support account

Paymentech 2001 - All rights reserved

Each record definition is preceded by an example. The example

The comments column gives the values of constants or a short

Paymentech 2001 - All rights reserved

YYMMDD Format (Optional)

01.7, Left justified/zero-filled

This is Paymentechs Submission #

Unique file id identifier supplied by

Paymentech 2001 - All rights reserved

Assigned and provided to Merchant by

Merchant's Order Number

A number composed of any alpha, blank, digit

Paymentech 2001 - All rights reserved

Transaction File Detail Record

Credit card, bank account number, or

MMYY (Optional field leave blank if

2 decimal implied/right justified/zerofilled

Continued on next page

Response Reason Code

Note: If action code is Authorization (A) or

Continued on next page

Paymentech 2001 - All rights reserved

Reserved (Do Not Use)

Note: If action code is Authorization (A) or

Note: If action code is Authorization (A) or

Continued on next page

Paymentech 2001 - All rights reserved

Reserved (Do Not Use)

The encryption flag will be either a one-byte

If assigned as a one-byte value, value should

Paymentech 2001 - All rights reserved

To begin using encryption, please contact

Extension Record Identifier "E" Constant

Extension Record Sequence 001 Constant

Transaction Advice Addendum #1

Transaction Advice Addendum #2

Notes: TAA fields are not supported in International currency processing

Paymentech 2001 - All rights reserved

Extension Record Identifier "E" Constant

Transaction Advice Addendum #3