ECHO ISO 8583 Technical Specification V1.6.5
ECHO ISO 8583 Technical Specification V1.6.5
August 2008
Copyright Notice
Copyright 2007 Electronic Clearing House, Inc (ECHO), 730 Paseo Camarillo, Camarillo, California 93010 U.S.A. All rights reserved.
Revision History
1.0 1.1 1.2 1.3 1.4 1.5 1.5.1 1.6 1.6.1 1.6.2 1.6.3 1.6.4 1.6.5 04/08/05 04/19/05 04/21/05 04/25/05 04/27/05 01/18/06 02/01/06 08/21/06 08/28/06 12/12/06 08/01/07 10/31/07 08/07/08 08/19/08
Customer Support
Support Line: (800) 262-3246, ext. 1 E-mail Address: [email protected]
ii of iii
Contents
1.
1.1 1.2 1.3
Introduction...........................................................................................................................1
Summary of Changes..................................................................................................................... 1 Purpose ........................................................................................................................................... 1 Definitions....................................................................................................................................... 1
2.
2.1 2.2
2.3
3.
3.1 3.2
4.
iii of iii
ECHO ISO 8583 Technical Specification v1.6.5 Field 44 Additional Data..............................................................................................................................27 Field 45 Track 1 Data ..................................................................................................................................27 Field 49 Transaction Currency Code ...........................................................................................................27 Field 52 Personal Identification Number (PIN) Data...................................................................................28 Field 53 Security Related Control Information............................................................................................28 Field 54 Additional Amounts.......................................................................................................................28 Field 59 Transport Data ...............................................................................................................................29 Field 60 Check Information .........................................................................................................................29 Field 61 ID Information ...............................................................................................................................30 Field 62 Application Information ................................................................................................................32 Field 63 Private Data....................................................................................................................................38 Field 70 Network Management Information Code ......................................................................................39 Field 90 Original Data Elements..................................................................................................................39 Field 95 Replacement Amounts ...................................................................................................................40 Field 123 POS Data Code ............................................................................................................................40
5. 6. 7. 8. 9.
9.1
Traditional ECC Standard Entry Class (SEC) Codes .......................................................48 Raw TOAD Requirements ..................................................................................................52 State Code Tables ................................................................................................................53 Terminal Response Codes...................................................................................................54 Communications .................................................................................................................68
Using TCP/IP for Message Processing ....................................................................................... 68
10. 11.
12.
Use Cases.............................................................................................................................85
12.1 Types of Responses to Transaction Requests ............................................................................ 86 12.2 Payment Card Use Cases............................................................................................................. 86
12.2.1 12.2.2 Credit and Signature-based Debit ...................................................................................................86 PIN-based Debit..............................................................................................................................87
iv of iii
13.
Certification.......................................................................................................................109
v of iii
vi of iii
1. Introduction
This document describes a protocol which may used for passing credit card, debit card and/or check information to and from ECHO. This document is designed to be a part of a suite of documents intended to assist the Business Partner with implementing a complete transaction processing service. This document does not address how the data are used for authorizing consumers accounts, clearing funds, settling funds to the appropriate parties, or reporting. Neither does this document describe in any detail the communications or security layer between the ECHO host and the Business Partners client. Please contact your ECHO representative for the complete package of documents.
1.1
Summary of Changes
This release replaces release 1.6.3 dated August 7, 2007. The changes for 1.6.4 are described below. As of January 2008, a new Federal Reserve Board amendment to Regulation E, which implements the Electronic Funds Transfer Act, requires that a customer be notified of the amount of any applicable returned item fee for a check at the time of customer authorization. Two amount field types have been added to Field 54 to comply with this requirement.
1.2
Definitions
ACH Automatic Clearing House AVS Address Verification System. A system supported by certain Card Networks for Credit Card transactions. This information is used when the cardholder is not present. CVV2 Visa Credit card security code CVC2 Master Card Credit card security code CIN American Express Credit Card security code Commercial Card A specific credit card that during transaction capture sales tax and purchase order number are required. ECC Electronic Check Conversion MICR Magnetic Ink Character Recognition. Magnetic codes are found on the bottom of checks, deposit slips, and general ledger debit and credit tickets that allow a machine to scan (capture) the information. MICR encoding on a check includes the account number, the routing number, the serial number of the check and the amount of the check. The amount of the check is encoded when the proof department processes the check. MCC Merchant Category Code MID Merchant Identification MOTO Mail Order/Telephone Order NACHA National Automated Clearing House Association NCN National Check Network OTP Online Transaction Processing, an ECHO proprietary gateway
Introduction 1 of 109
PAN Primary Account Number POS Point-of-Sale RCC Remotely Created Check RDFI Receiving Depository Financial Institution Risk Protect System ECHOs proprietary fraud detection system which is part of ECHOs authorization system. SET Secure Electronic Transaction SIC Standard Industrial Classification SSL Security Socket Layer STAN Systems Audit Trace Number UCAF Universal Cardholder Authentication Field
Introduction 2 of 109
2. System Basics
2.1 ECHO ISO 8583 Overview
The ECHO ISO platform is a part of the ECHO transaction processing network. The term applies to all components of the network, from the hardware, software, and communications facilities that connect the ECHO network with Business Partners systems and with other networks, to the systems that perform all transaction processing and system services. The ECHO ISO8583 platform routes transactions between Acquirers and Issuers through its global transaction processing network. The ECHO ISO platform supports: Credit and signature-based debit card transactions. PIN-based debit card transactions. Traditional electronic check conversion (ECC) transactions. Visa POS Check electronic check conversion transactions. Check verification only transactions.
These transactions are processed through ECHO ISO 8583s authorization, clearing, and settlement services. ECHO defines these basic services as follows: Authorization is when the Issuer approves or declines a sales transaction before a purchase is finalized or cash is disbursed. Clearing is when a transaction is delivered from an Acquirer to an Issuer for posting to the Cardholders or Checkwriters account. Settlement is the process of calculating and determining the net financial position of each merchant for all transactions that are cleared. The actual exchange of funds is a separate process.
Transactions can be authorized, cleared, and settled either as dual-message or single-message transactions. A dual-message transaction is sent twice, the first time with only the information needed for an authorization decision, and again later with additional information required for clearing and settlement. Typically, authorization is performed online while clearing and settlement occur later offline. Examples include credit card and traditional ECC check transactions. A single-message transaction is sent once for authorization and contains clearing and settlement information as well as authorization information. These transactions are also called full financial transactions. Typically, authorization and clearing occur online, while settlement occurs later offline. Examples include PIN-based debit and Visa POS Check transactions.
2.2
single merchant is operating with a consistent business model which can be defined/identified by a single Merchant Category Code (MCC)/Standard Industrial Classification (SIC) code). If both Payment Card Services and Check Services are used, merchant funding will occur at separate times for each service. Each service supports its own settlement reporting interface. Please contact ECHO customer support for assistance on funding timing and reporting.
3.
4.
5.
6.
protection that usually translates into a lower transaction fee for the merchant due to the reduced risk to the Issuer. 7. eCommerce based services such as MasterCards UCAF and Visas Visa3D program may contain more data in the transactions (and/or processing steps). This provides additional levels of protection that usually translate into lower transaction fees for the merchant due to the reduced risk to the Issuer.
Any mix of these transactions can all be done on one transaction, e.g. an Authorization Only transaction along with Address Verification and CVV Verification. The ECHO ISO Platform does not support the following credit or signature-based debit card transactions: 1. 2. 3. 4. 5. 6. Void of a deposit or authorization Reversal of a deposit or authorization Cash back (or Cash over purchase) Split tender Balance inquiry on pre-paid cards Batching The ECHO ISO platform does not keep a record of batch numbers or batch totals. The Point-of-Sale device may keep a record of this information internally and forward it to ECHO who will then echo it back. However; the platform does not validate the batch data. Neither batch inquiry, settlement-by-batch, nor reporting-by-batchnumber are supported.
Credit Card & Signature-Based Debit Y N N Y N Y N Y N Y N N N N Y N
Message Description 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 Authorization Only Void Authorization Only Payroll Verification Only Address Verification Service (AVS) Void Address/ID Verification Service (AVS) CVV2 Verification Void CVV2 Verification Authorization and Deposit (Purchase) Void Authorization and Deposit (Purchase) Purchase Return Void Purchase Return Purchase with Cash Back Authorization and Deposit w/Guarantee Void Authorization and Deposit w/Guarantee Deposit/Conversion Only (Forced Deposit) Void Deposit/Conversion Only (Forced Deposit)
Message Type (Field 0) 0100 0420 0100 0100 0420 0100 0420 0200 0420 0200 0420 0200 0200 0420 0220 0420
ECHO does not support the follow interbank networks: Credomatic, Interac, RED, Red Total, SHAZAM, The Exchange or other international interbank networks such as 4B, Altn Nokta, BankAxept, BKM, CB, DIAS, Eufiserv, Euronet, Multibanco, Ortak Nokta, Otto, ServiRed, StarNet. The ECHO ISO Platform supports most PIN-based debit transactions including: 1. Normal Purchase transactions where the total amount of the sale is taken from the Card Holders bank account and deposited in the merchants bank account all in one transaction. The PIN-based debit network is a single message system which means that the transaction is both authorized and cleared in one request unlike signature-based debit in which an authorization must be done followed by a separate clearing process. Purchase with Cash Back transactions where the total amount of the sale plus the cash back amount is taken from the Card Holders bank account and deposited in the merchants bank account Void transactions where the original transaction if effectively cancelled out. Money movement is cancelled before it occurs. The Card Holder should see no record of the transaction on his end-of-month normal account statement however this varies by company. This transaction type has limited time windows in which it can be performed (measured in minutes to hours) as well as special rules about the timing and storage of Card Holder data. The cardholder need not be present to perform a Void transaction. Purchase Return transactions where amount of the transaction is debited and taken from the merchants bank account and credited to the Card Holders account in effect giving funds to the cardholder. This transaction is not a Void of an original transaction. The Card Holders account statement will show two transactions, one transaction debiting his account for the Purchase and a second transaction showing the credit for the Purchase Return. The Cardholder must be present to enter his PIN to perform this transaction. This transaction type has traditionally been used for consumers returning merchandise or being over charged and requesting a credit. However, this transaction type is not limited to this usage. Unless otherwise prohibited, this transaction type may be used any time a merchant wishes to give funds to a consumer.
2.
3.
4.
5.
The ECHO ISO Platform does not support the following PIN-based debit card transactions: 1. 2. 3. Authorization Only Split Tender Balance Inquiry
4.
Batching The ECHO ISO platform does not keep a record of batch numbers or batch totals. The point-of-sale device may keep a record of this information internally and forward it to ECHO who will then echo it back however; the platform does not validate the batch data. Neither batch inquiry, settlement-by-batch nor reporting-by-batch-number are supported.
Message Description x 2 3 4 5 6 7 8 9 10 11 Authorization Only Address/ID Verification Service (AVS) CVV2 Verification Authorization and Deposit (Purchase) Void Authorization and Deposit (Purchase) Purchase Return Void Purchase Return Purchase with Cash Back Void Purchase with Cash Back Authorization and Deposit w/Guarantee Deposit/Conversion Only (Forced Deposit) Message Type (Field 0) 0100 0100 0100 0200 0420 0200 0420 0200 0420 0200 0220 PIN-Based Debit N N N Y Y Y Y Y Y N N
2.3
2.
A Verification With Conversion Override allows the Business Partner to override a warning response issued by the ECHO Risk Protection System if the Risk Protection System has been configured to issue warnings. Declined and Authorized transactions may not be overridden. When a warning response is overridden by the Business Partner, the ECHO platform turns the warning into a de facto authorization and will move money regardless of the warning. Overriding a Conversion Warning indicates that the Merchant or Business Partner is assuming all risk for the transaction. Guarantee w/Conversion transactions are equivalent to Verification With Conversion with the addition of being guaranteed by ECHO (or other partner as defined by the arrangement with ECHO). Special processing conditions may apply such as the types of transactions supported and the dollar amounts of the transactions as described in the processing agreement. Please contact your sales representative or customer support should the Business Partner have any questions about the qualifications for guaranteed transactions. If the Guarantee w/Conversion service is used by the merchant, then no other check service may usually be used. Void transactions effectively cancel the original transaction. No record of the transaction will show on the Checkwriters statement. This transaction is usually performed within ten minutes from the time of the original transaction though exceptions may apply. Voids (also know as Reversals) to correct erroneous credit transactions are allowed on all Standard Entry Class codes. Please contact ECHO customer support for additional information. Purchase Return is defined as a transaction that debits the merchants bank account and credits the Checkwriters account in effect giving funds to the consumer. It is important to note that this transaction is not a void of an original transaction. This transaction may be performed whenever funds need to be placed in a Checkwriters account (subject to any restrictions by the class of check transaction being performed and the processing agreement with ECHO). The only SEC codes that support crediting a Checkwriters bank account are PPD and CCD.
3.
4.
5.
Traditional electronic check conversion has classes of check services. These classes identify payment types as categorized usually by the consumers interaction at the point of sale/purchase. There are legal ramifications and requirements the Business Partner will consider for each of the classes as described in the processing agreement with ECHO and by ACH Network Rules (as published by the National Automated Clearing House Association (NACHA)). The ECHO ISO Platform supports the most popular electronic check service classes including: 1. 2. 3. 4. 5. 6. POP Point-of-Purchase Entry ARC Accounts Receivable Entry PPD Prearranged Payment and Deposit Entry TEL Telephone-Initiated Entry WEB Internet-Initiated Entry CCD Cash Concentration or Disbursement.
For WEB and TEL check services, NACHA Rules require that the Checkwriters first and last name be included in the transaction. The ECHO ISO Platform does not support the following Traditional Electronic Check Conversion transactions: 1. Conversion Only This service is not supported as the ECHO ISO platform validates each check though its authorization system (Risk Protection System). If the authorization
system declines the check, then the check will not be converted. The authorization system may not be bypassed like it can be in the Visa POS Check service. 2. Verification Only for Paper-Deposited Checks The ECHO ISO platform performs only one check service per ECHO ID (MID). If the Traditional Electronic Check Conversion is being used, then the Verification Only check service may not. The Verification Only service is traditionally used when a merchant plans to process the consumers check by driving the paper check to his local bank instead of electronically converting it. The Verification Only service is performed only to validate that the checking account does not have outstanding debt associated with it. However, Traditional Electronic Check Conversion service both validates outstanding debt and validates that the consumers check is eligible for participation in the electronic check conversion network (ACH Network). For this reason, Verification Only for Paper-Deposited Checks service is not supported while using the Traditional Electronic Check Conversion service. Visa POS Check The ECHO ISO platform performs only one check service per ECHO ID (MID). If the Traditional Electronic Check Conversion is being used, then the Visa POS Check service may not.
3.
4.
The ECHO ISO Platform does not support the following electronic check service classes: 1. 2. 3. 4. 5. 6. 7. 8. 9. CIE - Customer Initiated Entry MTE - Machine Transfer Entry PBR - Consumer Cross-Border Payment POS/SHR - Point of Sale Entry/Shared Network Transaction RCK - Re-presented Check Entry CBR - Corporate Cross-Border Payment CTX - Corporate Trade Exchange ACK/ATX - Acknowledgment Entries ADV - Automated Accounting Advice
10. COR - Automated Notification of Change or Refused Notification of Change 11. DNE - Death Notification Entry 12. ENR - Automated Enrollment Entry 13. TRC/TRX - Truncated Entries 14. XCK - Destroyed Check Entry 15. BOC - Back Office Conversion.
The following operations are available for ECHO ECC Merchants: Payroll Acct Auth Payroll Override
Payroll ID Auth
ID Only Auth
ID Only Void
Payroll Auth
Payroll Void
Override
Auth
ECHO supports all features of the POS Check Service (except for the Telephone and Web initiated message types, which are seldom used). As noted below, checks are authorized or declined by either a financial institution (the drawee bank or Visa participating bank or issuing bank) or by ECHO. If the response to the transaction is issued by ECHO, then Field 63, subfield 12 is populated. If the response comes from a Visa participating bank, then Field 63, subfield 12 is empty. The POS Check service provides flexible options for managing check risk. Transactions can be authorized utilizing different levels of authorization criteria. Three options are available: 1. Conversion Only The customers financial institution or a third-party authorizer (ECHO) verifies if a check is eligible for conversion. If the check belongs to a participating bank, the bank will verify whether the account is open or closed. Regardless of the authorizer, an authorization response will be returned electronically. The merchant retains the risk.
Void
Log
2.
Verification with Conversion Based on available risk-management data, the financial institution or the third party (ECHO) makes an "accept" or "decline" recommendation, and returns the authorization response. When a decline response is received, the merchant will ask for another form of payment. (It is possible, but not recommended, for the merchant to accept the check regardless on the decline response.) Guarantee with Conversion In addition to the above, the customer's financial institution or third-party authorizer (ECHO) will also decide if the check can be guaranteed for payment based on available funds and other information. Provided all point-of-sale acceptance criteria have been met, the customer's financial institution or the third-party authorizer returns the authorization response and accepts the risk for approved transactions. If the Guarantee With Conversion service is used by the merchant, then no other check service may usually be used. Void transactions effectively cancel the original transaction. No record of the transaction will show on the Checkwriters statement. This transaction must be performed within ten minutes from the time of the original transaction per Visa USA regulations. Please contact ECHO customer support for additional information.
3.
4.
The Visa POS Check product and/or the ECHO ISO Platform do not support the following transactions: 1. Purchase Return type transactions are not a service offered in the Visa POS Check product. The Visa POS Check service does not allow money to be put into (credited to) the Checkwriters account from the point of sale. If a transaction was entered in error, please either find an in store solution (e.g. issue a store credit) or contact ECHO customer support for resolution. Override transactions are not a service offered in the Visa POS Check product. The Visa POS Check service does not issue warnings that can be overridden. Once a transaction is declined, the clerk at the point of sale should ask the consumer for another form of payment. The Verification Only service as described above may not be used at the same time as the Visa POS Check product. The Traditional Electronic Check Conversion service as described above may not be used at the same time as the Visa POS Check product (unless special conditions apply). The Telephone and Web initiated message types are not supported by ECHO based on the limited support offered by Visa-participating banks for these services.
2.
3. 4. 5.
The following operations are available for the VISA POS Check service: Payroll Acct Auth
Payroll Override
Payroll ID Auth
ID Only Auth
ID Only Void
Payroll Auth
Payroll Void
Auth
Void
Log
2.
3.
4.
5.
6.
The ECHO ISO Platform does not support the following Verification Only transactions: 1. Void ID Authorization An ID Authorization transaction may not be voided or reversed. The ECHO authorization system does not support this service.
2. 3. 4.
Payroll Authorization A Payroll Authorization transaction may not be voided or reversed. The ECHO authorization system does not support this service. Payroll Account Authorization This transaction type is not supported. Payroll ID Authorization This transaction type is not supported.
Payroll Override
Payroll ID Auth
ID Only Auth
ID Only Void
Payroll Auth
Payroll Void
Override
Auth
Void
Log
3.1
0110 0120
Authorization Advice Response Financial Request Financial Transaction Response Financial Transaction Advice
Financial Transaction Advice Response Void Void Response Network Management Request Network Management Response
3.2
Code C C+ M M+ O
Description Conditional The field/value is present in the message under certain conditions, which are explained in Section 4. The field/value is conditionally added. Mandatory The field/value must be present in the message. The field/value is always added. Optional The field/value presence in the message is up to the message initiator or the recipient. The field/value is passed through as it is received.
+ blank space
The field/value is passed through and other subfields are added. The field/value is always removed. A field or value must not be present.
The remaining tables in this section provide a reference showing how fields should be used when coding transaction types.
3.2.1 Credit Card and Signature-Based Debit Card Transaction Message and Response Fields
The following table indicates the fields used for Credit Card and Signature-Based Debit Card Transactions.
0100
0110
0200
0210
0220 M M O M M M M O O O O C O C O
Field 0 1 2 3 4 7 11 12 13 14 18 25 32 35 37 38 39 41
Description Message Type Identifier Bit Map Primary Account Number Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Expiration Date Merchant Type Message Reason Code Acquiring Institution Identification Code Track 2 Data Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID
M M O M M M M O O O
M M
M M O M M M M O O O
M M
M M
C O C M O
C O C M O
0230
0100
0110
0200
0210
Field 42 43 44 45 49 52 53 54 59 60 61 62 63 70 90 95 123
Description Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Track 1 Data Transaction Currency Code Personal Identification Number (PIN) Data Security Related Control Information Additional Amounts Transport Data Check Information ID Information Application Information Private Data Network Management Information Code Original Data Elements Replacement Amounts POS Data Code
M O C O
M O C O
C O
C O
C O
C O
If the request is not manually entered then either the Track 1 or Track 2 data must be present. Track 1 data is preferred.
0200
Field 0 1 2 3 4 7 11 12 13 14
Description Message Type Identifier Bit Map Primary Account Number Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Expiration Date
M M M M M M M O O O
M M
0210
M M M M M M M
0230
0200
0210
0420
Field 18 25 32 35 37 38 39 41 42 43 44 45 49 52 53 54 59 60 61 62 63 70 90 95 123
Description Merchant Type Message Reason Code Acquiring Institution Identification Code Track 2 Data Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Track 1 Data Transaction Currency Code Personal Identification Number (PIN) Data Security Related Control Information Additional Amounts Transport Data Check Information ID Information Application Information Private Data Network Information Management Code Original Data Elements Replacement Amounts POS Data Code
M O C M O M C
O O C O M O O C M
O M M C O
O O
C O
M C M M
0100
0110
0120
0130
0200
0210
0220
0230
0430 0420 M M M
Field 0 1 2 3
Description Message Type Identifier Bit Map Primary Account Number Processing Code
M M
M M
M M
M M
M M
M M
M M
M M
M M
0430
0100
0110
0120
0130
0200
0210
0220
0230
0420 M M M O O O O C O M O M C O O M C C O M M
Field 4 7 11 12 13 14 18 25 32 35 37 38 39 41 42 43 44 45 49 52 53 54 59 60 61 62 63 70 90 95 123
Description Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Expiration Date Merchant Type Message Reason Code Acquiring Institution Identification Code Track 2 Data Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Track 1 Data Transaction Currency Code Personal Identification Number (PIN) Data Security Related Control Information Additional Amounts Transport Data Check Information ID Information Application Information Private Data Network Management Information Code Original Data Elements Replacement Amounts POS Data Code
M M M O O
M M M O O
M M M O O
M M M O O
O C M O M O C
O C M O M O C
O C M O M O C
O C M O M
C M
O C -
O C -
O C -
M C -
C O M C C O
C O M C C O
C O M C C O
C O M C C C O
0430
Field 0 1 7 11 39 41 42 44 70
Description Message Type Identifier Bit Map Transmission Date and Time Systems Trace Audit Number Response Code Card Acceptor Terminal ID Card Acceptor ID Code Additional Data Network Management Information Code O M M M M M
0800 M M
0810
M, must be 00
4. Field Definitions
The following section provides a detailed description for each data field.
0110 0120
0130 0200
0210 0220
0230 0420
Financial Advice Request Response Carries the answer to a deposit only request Void Request
Variable Length Indicator: 2 Bytes, right justified with leading zeros Field Type: Numeric
Field Values/Usage: The from account is the consumers account while the to account is the Business Partner or merchants account. This field is formatted as follows:
Positions 1-2 3-4 5-6 Length 2 2 2 Data Element Describe a specific transaction (see the following table below for codes) From account To account
09 16 17 18 20
The codes to describe the From Account Types (Positions 3-4) and the To Account Types (Positions 5-6) are:
Code 00 10 20 30 40 50 Description (Positions 3-4, 5-6) Default, not specified Savings Account Checking Account Credit Facility Universal Account Investment Account
Please refer to Chapter 12. Use Cases for examples of how these codes are used.
Field Value/Usage: Example: $100.00 in US currency is entered as 000000010000. Note: This field should be zero filled for AVS only transactions (Processing Code 18).
Field Values/Usage: Example: March 2, 1:15:00 p.m. Pacific Standard Time is entered as 0302211500, since Pacific Standard Time is 8 hours behind UTC. The format is MMDDhhmmss:
Field MM DD hh mm ss Definition Month Day Hour Minute Second Length 2 2 2 2 2 Range 01-12 01-31 00-23 00-59 00-59
Note:
The Transmission Date and Time and the Systems Trace Audit Number (Field 11) are used to uniquely identify transactions.
Field Values/Usage: A suggested use of this field is as follows: An audit number starting at 1 which will increment for each subsequent transaction from 000001 to 999999. Note: The Systems Trace Audit Number and the Transmission Date and Time (Field 7) are used to uniquely identify transactions.
Field hh mm ss
Length 2 2 2
Field Value/Usage: An MCC code will be agreed on between ECHO and the Merchant as part of the merchant underwriting and boarding process. Please refer to that documentation for an appropriate MCC Code to place in this field.
This code provides the Issuer with the reason or purpose of the 0420 Reversal Advice Request Messages. Reserved for future use. 2 Bytes, fixed length Numeric The following codes indicate the specific purpose of the message:
Definition Customer Cancellation Unspecified; No Action Taken Timed-Out Waiting for Response
Field Type:
Alphanumeric
Field Value/Usage: The suggested format of this field is to combine elements from Field 7 the transmission date and time, and Field 11 the STAN:
Position 1 2-4 5-6 7-12 Definition The last-digit-of-the-year-equivalent of the date in Field 7. The Julian day equivalent of the month and day in Field 7. The hours from the time in Field 7. The value from Field 11.
Field Type:
Variable Length Indicator: 2 Bytes, right justified with leading zeros Field Type: Alphanumeric & Special Characters
Field Value/Usage: This field will mainly be used when a client message cannot be parsed. It will convey information about what is wrong with the message.
Variable Length Indicator: 2 Bytes, right justified with leading zeros Field Type: Alphanumeric & Special Characters
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: Note: Alphanumeric This data can be repeated up to four times within this Field. Example: If the data in this field was repeated twice, the length of the field would be 40 bytes in length. Field Value/Usage: If cash back is used, then Field 4 (the transaction amount) must equal the total of the purchase amount plus Field 54 (the cash back amount).
In other words, the amount of the goods or services sold can be found by subtracting Field 54 from Field 4. This field is formatted as follows:
Positions 1-2 3-4 Length 2 2 Definition Account type is a two-digit code as defined for positions 3 and 4 or 5 and 6 of Processing Code (Field 3) Amount Type 01 Ledger Balance 02 Available Balance 03 Amount Owing 04 Amount Due 05 Amount Cash Back 06 For CHECK Only: Returned Item Fee Amount including applicable tax on the fee 07 For CHECK Only: Applicable Tax on the Fee (just the tax portion of Amount Type 06) Currency Code (see Chapter 3.2.4) Format of this data element is C (for credit amount) or D (for debit amount) Amount is 12 numeric digits, right-justified with leading zeros
5-7 8 9-20
3 1 12
Field Length:
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: Alphanumeric & Special Characters
Field Value/Usage: Field may be used in any manner. At this time, this field is not captured by ECHO and thus will not be available to the Business Partner in Reports.
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: An 8 byte binary bitmap, and alphanumeric & special characters.
Field Value/Usage: If subfields 60.11 or 60.12 are present, then subfield 60.10 is required. If electronic check conversion (Check Verification w/Conversion) service is requested, subfield 60.12 is required unless prior special arrangements are made with ECHO.
Field 61 ID Information
Description: This field contains information regarding the identification presented by the consumer.
Field Length:
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: An 8 byte binary bitmap, and alphanumeric & special characters.
Field Value/Usage: If identification information is provided in this field, then subfields 61.1 61.9 are required. Swiped (magnetically read) DL information should be populated in Field 61.14 (Track 2 of the drivers license contains the information ECHOs authorization system is expecting) Canadian Drivers license are not a supported ID Type (02) at this time. If provided, the ID will be stripped and forwarded on to the appropriate authorization system. For Visa POS Check, the following ID Types are supported: drivers license and ID from the 50 U.S. states, District of Columbia, Puerto Rico plus ID numbers from: U.S. Military Base (embassy, traveling merchant) courtesy card, Military ID, Social Security Number and proprietary cards. For Traditional Electronic Check Conversion and Check Verification Only, the following ID Types are supported: drivers license (United States and United States Territories only), Department of State, Military ID, Social Security number, and Resident Alien. For WEB and TEL check transactions, NACHA rules require that a Checkwriters first and last name must be included in the transaction. If subfield 123.5 indicates that the customer is not present with a value of either 3 (not present telephone order) or 9 (not present eCommerce), subfield 61.5 must contain at least one alpha character for first name and one alpha character for last name separated by either a space or comma or both. Additional name information, such as middle name, middle initial, title, etc., are also allowed. If the name format does not meet NACHA criteria, the transaction will be rejected as invalid. Examples of acceptable WEB and TEL check transaction first and last names include but are not limited to: John Smith John R Smith John R. Smith John Smith III JS JRS Smith, John Smith, John R Smith III, John
Subfield 8 9 10 11 12 13 14 15
Format ans..20, LLVAR an2 an9 an2 n..20, LLVAR ans..107, LLLVAR z..40, LLVAR z..107, LLLVAR
Definition ID City ID State/Province Alpha Code from the State Code Table in Section 7. ID Postal Code, left justified pad filled ID Country Code using US for the United States of America , MX for Mexico or CA for Canada ID Phone Number ID Track 1 ID Track 2 ID Track 3
Subfield 1 ID Type:
Code 00 01 02 03 04 05 06 07 08 09 10 11 12 Definition Unknown U.S. Drivers License Canadian Drivers License Mexican Drivers License State ID Card Canadian Identification Mexican Identification Military Identification Law Enforcement U.S. Government ID (Social Security Number) Passport Alien Registration Card Immigration Card
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: An 8 byte binary bitmap and alphanumeric & special characters.
Subfield 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23
Format ansp..31, LLVAR a1 np5 a1 ansp..33, LLVAR ans..99, LLVAR ans..99, LLVAR ans..22, LLVAR ans..51, LLVAR ans..99, LLVAR ans..73, LLVAR ansp..41, LLVAR ans28 ans28 ans28 ans1 ans2 n4
Definition AVS Data AVS Response Data CVC2, CVV2 Data CVC2, CVV2 Response Data Commercial Card Data Operator ID Supervisor ID Cash Register Data Lodging Data Restaurant Data Service Station Data DMA Data MasterCard UCAF Data, contains the UCAF data obtained from the consumer. Visa 3D CAVV, contains the CAVV data obtained from the consumer. Visa 3D XID, contains the XID data obtained from the consumer. Visa 3D Response Data Recurring Payment Response Data Auxiliary Response Code, see Chapter 8.
2-5
2-14 12-31
14-19
ans6
Positions
Format
Definition Non-Visa/MC: Set to default 0 Default Lodging: 0 No extra charges 2 Restaurant 3 Gift Shop 4 Mini Bar 5 Telephone 6 Other 7 Laundry Auto Rental: 0 No extra charges 1 Gas 2 Extra mileage 3 Late Return 4 One Way 5 Parking Violation (non-US)
20
np1
Visa No Show Indicator Not Applicable 0 Not Applicable 1 No Show Room Rate Lodging Trace Number
21-26 27-51
n6 ansp..25, LLVAR
Format n8 n12
15-41
ansp..25, LLVAR
Positions 1-28
Positions 1-28
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: An 8 byte binary bitmap and alphanumeric & special characters.
Note:
If the response to the transaction is issued by ECHO, then Field 63, subfield 12 will be populated. If the response comes from a Visa participating bank, then Field 63, subfield 12 will be empty.
13
ans..255, LLLVAR
14
ans16
42 Bytes, fixed length Numeric Field 90, while required on void or other message types, is not used by the Traditional Electronic Check Conversion service to match the void message to its original message. When a transaction like a void must be matched to its original message (on the Traditional Electronic Check Conversion service), just the check route number, checking account number, check serial number and transaction amount are used Field 90 is not used per se. On the PIN-based Debit service and VISA POS Check service, Field 90 is used to match the void to its original message.
Example: Field 4 (Transaction Amount) Field 95 (Replacement Amount) = Amount to be credited to the card member.
Required in all messages except for 0800 messages. 15 Bytes Maximum, LLLVAR
Variable Length Indicator: 3 Bytes, right justified with leading zeros Field Type: Alphanumeric
Field Value/Usage: Many of the values in this field are essentially constants for any one combination of POS device and method of payment. The values set in this field impact the how the transaction is settled. In the credit and signature tender types, the values in this field impact the interchange fee program that the transaction will qualify for. For example, if the transaction is unattended (there is no clerk watching the consumer swipe the card) then the cost to the Business Partner to process this transaction (transaction fee) could double. The combinations of how these data impact the transaction fees in this tender type are exhaustive and beyond the scope of this document. It is crucial to accurately represent the point of sale environment when setting the values in this field. In the ECC tender type, the values in this field impact which SEC code the transaction will settle under and the transaction fee. Certain regulations must be followed by the Business Partner depending on these settings. For example, if the settings in this field indicate that the transaction will be assigned a SEC code of TEL, then the merchant is obligated to have either recorded the conversation with the consumer or have notified them of the transaction writing by fax, U.S. mail, or email. Other regulations apply. Please refer to Chapter 5 Electronic Check Standard Entry Class (SEC) Code for more information. This field is formatted as follows:
Position 1 2 3 4 5 6 7 8 9 10 11 12 13 14-15 Length 1 1 1 1 1 1 1 1 1 1 1 1 1 2 Definition Card Data Input Capability Authentication Capability Capture Capability Operating Environment Cardholder Presence Indicator Card Presence Data Input Method Authentication Method Authentication Entity Card Data Output Capability Terminal Output Capability PIN Capability Terminal Operator Terminal Type
3 4 5 6 S T
2 3 4 5 6
S T U
1 2 3 4 5 9
Code S T
Definition Password with digital certificate/certification (eCommerce) Password without digital certification (Chip cryptogram, eCommerce authentication via smart card chip cryptogram) Certificate and cryptogram
Code 2 3 4
Definition Printing Display (no printer attached) Printing and display (printer attached)
1 4 5 6 7 8 9 A B C
Code 04 05 06 07 08 09 10 11 96 97 98
Definition ECR Dial Terminal Travelers Check Machine Fuel Machine Script Machine Coupon Machine Ticket Machine Point-of-Banking Machine ECHOfax ECHOtel ECHOnline
Electronic Check Standard Entry Class (SEC) Codes SECC NACHA Processing Code Type Authorization System ECHO Settlement Code MLORDRV ARC 1 Traditional ECC MLORDRG Guarantee w/ Conversion 03 Field 3 Positions 1-2 Permitted Values 16 Field 123 Position 5 Permitted Values 2 2 2 2 0 0 0 0 VPOPC Conversion Only 04 0 0 0 Visa POS 0 0 0 VPOPV POP
1
Service
Verification w/ Conversion
Verification w/ Conversion
16
0 0 0
VPOPG
Guarantee w/ Conversion
03
0 0 0 0
POPV
Verification w/ Conversion
16
0 0 0 0 0
POPG
03
0 0 0
If there is an Auxiliary On-Us in the MICR (which indicates that the check is a business check), the transaction will be automatically converted from POP or PPD into a Remotely Created Check or paper draft (RCC) transaction. If the ECHO Settlement Code is a type of Mail Order (MLORDR), the electronic check will be converted by ECHO from an electronic check back into an RCC or paper draft and hand deposited. Electronic item will be printed out on paper check stock and settled as a paper draft.
Electronic Check Standard Entry Class (SEC) Codes SECC NACHA Processing Code Type Authorization System ECHO Settlement Code Field 3 Positions 1-2 Permitted Values Field 123 Position 5 Permitted Values 2 MLORDRV Verification w/ Conversion 16 2 2 2 2 MLORDRG Guarantee w/ Conversion Verification w/ Conversion Guarantee w/ Conversion 03 2 2 2 POPV POPG 16 03 0 0 1 1 1 1 1 PPD1 Traditional ECC Verification w/ Conversion 16 4 4 4 4 4 4 NREFT 1 1 1 1 1 Guarantee w/ Conversion 03 1 4 4 4 4 4 4 Field 123 Position 7 Permitted Values 0 1 6 U 0 1 6 U U U 0 1 6 S U 0 1 6 S T U 0 1 6 S T U 0 1 6 S T U
Service
Electronic Check Standard Entry Class (SEC) Codes SECC NACHA Processing Code Type Authorization System ECHO Settlement Code Field 3 Positions 1-2 Permitted Values Field 123 Position 5 Permitted Values 3 3 TELV Verification w/ Conversion 16 3 3 3 TEL Traditional ECC 3 3 3 TELG Guarantee w/ Conversion 03 3 3 3 3 9 9 WEBV Verification w/ Conversion 16 9 9 9 WEB Traditional ECC 9 9 9 WEBG Guarantee w/ Conversion 03 9 9 9 9 Field 123 Position 7 Permitted Values 0 1 6 S T U 0 1 6 S T U 0 1 6 S T U 0 1 6 S T U
Service
MICR Symbol
Textual Representation t or T o or O a or A d or D
An On-Us field (a series of digits enclosed by two On-Us symbols) appearing to the left of the Transit field is called the Auxiliary On-Us field, and indicates a business check, which will be treated differently in settlement. See Chapter 5 Traditional ECC Standard Entry Class (SEC) Codes for more information.
The clerk should ask the customer for an identification card and either swipe or key in the ID in order to complete the transaction. The clerk should review positive identification (such as an unexpired passport or drivers license) to validate the Cardholders identity. Verify both of the following: Signature on the Card matches the signature on the Transaction Receipt and identification presented. This signature may be different from the name embossed or printed on the Card. Cardholder resembles the person described, or depicted in any photograph intended for identification on the Card. Card Print authorization receipt and ask customer to sign if applicable. Keep merchant copy, give receipt to customer and complete tender. Please see Chapter 11 for authorization receipt requirements. Verification of Cardholder identity using the steps in Workflow Code E reduces fraud and is required for certain transactions such as quasi-cash, cash advance and other transactions except where prohibited by law. Print authorization receipt, tear off and ask customer to sign if applicable. Confirm customer has completed and signed the paper check in addition to the receipt if applicable. Keep merchant copy, give receipt to customer and complete tender. Please see Chapter 11 for authorization receipt requirements. Verification of Checkwriter identity using the steps in Workflow Code E reduces fraud and may be required except where prohibited by law. Example: The point of sale device locks up when printing the receipt and cannot complete the transaction. Or, the terminal runs out of ink and cannot print an authorization receipt. Solution: The clerk should call the 24-hour, first level, merchant support hot line at the merchant services provider for direction on how to proceed.
F Check
Hardware Error
There is a merchant service configuration error or the merchants account has been temporarily put on hold. The clerk should call the 24-hour, first level, merchant support hot line at the merchant services provider for direction on how to proceed. Terminate this tender type and ask for another form of payment.
ECHO ISO Workflow Action Based On Response Codes Workflow Code Action The clerk should use their best efforts to recover and retain the customers card by reasonable and peaceful means. After recovering a card, the merchant must notify ECHO to receive instructions for returning the card. ECHO may pay the person caputing the card and merchant a reward of up to $100 for capturing a card in accordance with local practices. And under certain circumstances, ECHO is required to pay the Merchant a reward of at least $100 for example if the clerk notices the first four digits of the embossed or printed Account Number (if applicable) do not match the four digits printed above or below the Account Number on a Visa Card or Visa Electron Card and captures the card. This check has already been authorized and cannot be authorized a second time. Please call the 24-hour, first level, merchant support hot line at the merchant services provider to confirm that this transaction has been authorized. Do not ask for another form of payment or scan a new check unless merchant support indicates that it is necessary Credit card and signature-based debit services: If the business partner does not receive a response from the ECHO host then ECHO recommends that the point of sale device immediately send a 0800 network management message to confirm the connection to ECHO is active. Then the point of sale device should either prompt the clerk if he wants to resend the message or automatically resend the message using the same transaction trace values in fields 11 (STAN), 59, etc. If an authorization message is received, the merchants copy of the receipt should be marked and reported to the store manager for research. The manager should call 24-hour, first level, merchant support hot line at the merchant services provider to confirm the transaction only occurred once. If the transaction happened twice (but the business partner didnt receive ECHOs authorization response the first time) the merchant services provider will be able to cancel one of the transactions so that the consumer is not debited twice. The store manager should call the merchant services provider by midnight or the transaction cannot be cancelled. PIN-based debit services: If the business partner does not receive a response from the ECHO host then ECHO recommends that the point of sale device immediately first send a 0800 network management message to confirm the connection to ECHO is active. Second, the point of sale should immediately send a void message, cancelling the previous message that might have been received by ECHO. Third, the point of sale should resend the original request using new transaction trace values in fields 11 (STAN) and if appropriate Field 59, etc. These three steps should be done automatically and should be transparent with no input or intervention needed by the clerk. Visa POS Check and Traditional ECC services: If the business partner does not receive a response from the ECHO host then ECHO recommends that the point of sale device immediately first send a 0800 network management message to confirm the connection to ECHO is active. Second, the point of sale should immediately send a void message, cancelling the previous message that might have been received by ECHO. Third, the point of sale should resend the original request using new transaction trace values in fields 11 (STAN) and if appropriate Field 59, etc. These three steps should be done automatically and should be transparent with no input or intervention needed by the clerk.
I/J
Card L
Check
Not used.
Tender Type
Card Check
Workflow Code
F F
Comments
CALL VISA CALL MASTER CARD CALL CARTE BLANCHE CALL DINERS CLUB CALL AMEX CALL DISCOVER CALL JCB N A An authorization number from the Issuers Voice Center is required to approve this transaction.
Refer to Card Issuer 01 Card The Card must be referred to the Issuer before the transaction can be approved.
None
ACCOUNT CLOSED INVALID TERM ID UNKNOWN ACQ UNKNOWN MER INVALID TERM ID BAD TERMINAL ID SITE NOT SETUP UNDEF RULE SET AGENCY UNKNOWN AGENCY DATA ERR AGENCY PROBLEM SERVICE CUT OFF NO ROOM FOR AUTH I/J H
03
04
Pick Up Card
Card Check
The card number has been listed on the Warning Bulletin File for reasons of counterfeit, fraud, or other.
Tender Type
Card
Workflow Code
Comments
The transaction was declined by the Issuer without definition or reason.
0017
UNPAIDS ON ACCT
The customers checking account appears to have outstanding unpaid check debt. The customers identification information submitted with the transaction is associated with apparent outstanding unpaid check debt on an alternate checking account. ECHO and its partners have determined that the customers checking account appears to have outstanding unpaid check debt. ECHO and its partners have determined that the customers checking account appears to have been closed. ECHO and its partners have determined that the customers checking account appears to have been closed. ECHO and its partners have determined that the customers checking account appears to have been closed. ECHO and its partners have determined that the customers checking account appears to not be in good standing. Used in Visa POS. This response occurs only on Visa Conversion Only transactions where ECHO has determined that this checking account has been listed as a STOPPED account. ECHO and its partners have determined that the customers checking account appears to not be in good standing. Used in Visa POS, Unpaid items, fail negative file check (T4). H H I/J N Capture card.
0018
ID IS FLAGGED
0019
DECLINE CHECK SC
0020
ACCOUNT CLOSED SC
05
0021
ACCOUNT CLOSED B
0022
ACCOUNT STOPPED
0055
DECLINE CHECK SN
0056
0057 0060 06 07 Error Pick Up Card Special Conditions Card Check Card Check
Tender Type
Card Check Card Check Card Check Card Check
Workflow Code
F N N N F N N N
Comments
The host computer received an invalid transaction code. The transaction request presented is not supported or is not valid for the card number presented. For example, this will occur if client sends in a 0220 (Override) or 0100 (Verification Only) message while configured for the Visa POS Check service. The Visa POS Check service does not support these message types. The dollar amount was less than 1.00 or greater than the maximum allowed for this card. The credit card number that was sent to the host computer was invalid. The Issuer number is not valid.
13
Card Check
1017
INVALID AMOUNT
D N
14
Card Check
1015
D N D N N N N N N N
15 16 17 18
Tender Type
Card
Workflow Code
Comments
0002
ERROR IN MICR
The requested service requires correctly formatted check MICR data to complete the transaction however the data received does not match normal MICR formatting standards. The requested service requires check MICR data to complete the transaction however none was received. The requested service requires check MICR data to complete the transaction however none was received. The requested service requires that a check number be provided in the transaction however none was received. The requested service requires swiped/magnetically read check data but the MICR data provided in the transaction was hand-keyed/keyboard entered. The identification provided is either an unsupported type of ID or the ID is incorrectly formatted. The requested service requires a type of identification be provided as part of the transaction as dictated by the risk protection program. The requested service requires a type of identification be provided as part of the transaction as dictated by the risk protection program. Used in Visa POS, MICR Error (T6).
0003
NO MICR GIVEN
NO MICR
19
NO CHECK NUMBER
D D E
0011 0058 20 21 22 23 Invalid Response No Action Taken Suspected Malfunction Unacceptable Transaction Card Check Card Check Card Check Card Check
E D N N N N N N N N
Tender Type
Card Check Card Check Card Check Card Check Card Check Card Check Card Check Card Check Card Check Card Check
Workflow Code
N N N N N N N N N N N N A A N N N N I N Capture card.
Comments
Tender Type
Card
Workflow Code
I Capture card.
Comments
An ECHO-participating Collection Service Agency has requested that all checks with this account be stopped. The merchant has requested that all checks with this account be stopped. B Someone has reported that checks with this account have been stolen or forged. The check sequence number matches a range stopped by the account owner (used in the case of lost checks). The account owner has requested that transactions on this account be stopped. This is likely because checks have been lost. I N I N I N I N N N Capture card. Capture card. Capture card. Capture card.
0016 Card Acceptor Contact Acquirer, Pickup Restricted Card, Pickup Card Acceptor Call Acquirer Security, Pickup PIN Tries Exceeded, Pickup No Credit Account Card Check Card Check Card Check Card Check Card Check Card Check 41 42 43 Lost Card No Universal Account/Decline Stolen Card Card Check Card Check Card Check 1021
CUSTOMER STOP
35 36 37 38 39
INVALID SERVICE
40
The merchant or Card Holder is not allowed to perform that kind of transaction. This card has been reported lost.
Tender Type
Card Check Card Check
Workflow Code
N N B B B B B B
Comments
51
NSF
The transaction will result in an over credit limit or insufficient funds condition.
52 53
Card Check Card Check Card Check Card None Check Card Check Card INVALID PASSWORD 1016 INVALID EXPIRATION DATE
D N D B N N
54
Expired Card
55
Invalid PIN
The requested service requires a password and the manager password provided in the request packet does not match that specified in the rule set.
56
No Card Record
57
Transaction Not Permitted Check 0001 INVALID SERVICE G/H G/H G/H N N 2078 2079 Check CALL ECHO CALL XPRESSCHEX H H N
This card does not support the type of transaction requested. The point of sale device is requesting a service which the merchant services provider has not allowed.
58 59
60
Card
The merchant must call ECHO Customer Support for approval or because there is a problem with the merchants account.
Tender Type
Card
Workflow Code
B
Comments
The cardholder has requested a withdrawal amount in excess of the daily defined maximum. The face amount of the check is greater than the limit imposed by the merchant. The amount of cash returned with the purchase exceeds the limit imposed by the merchant. This message will only appear if both sale and check amount are included in the request packet and cash back limits have been imposed by the merchant. The merchant set limit on payroll checks has been exceeded.
0024
0025 0029 0030 Exceeds Approval Amount 61 The cardholder has requested a withdrawal amount in excess of the frequency limit. 0031 0032 0033 Check* 0034 0038 0039 0040 0041 0042 0043 0045
PAY CHK TOO BIG DAY LOC/AMT=%d DAY GRP/AMT=%d DAY ALL/AMT=%d DAY LOC/CASH=%d DAY GRP/CASH=%d DAY ALL/CASH=%d WIN LOC/AMT=%d WIN GRP/AMT=%d WIN ALL/AMT=%d WIN LOC/CASH=%d WIN GRP/CASH=%d WIN ALL/CASH=%d AMT PAYCHKS=%d B B
These report that the cumulative face amount of checks has been exceeded for the day where %d is the dollar amount of the checks. These report that the cumulative of cash returned from checks has been exceeded for the day.
These report that the cumulative face amount of checks has been exceeded for the time window.
These report that the cumulative of cash returned from checks has been exceeded for the time window. The rule set limit on the cumulative face amount of payroll checks has been exceeded. Used in Visa POS, Amount greater than established service limit (T3). * These check declines may be usually be overridden with a Check Override Request if ECHOs ECC program is being used and the risk protection program permits it.
0061
N/A
Tender Type
Card
Workflow Code
Comments
The card has been restricted.
0046 0047
Canadian checks are not permitted by the risk protection program. This banking route number is outside the Federal Reserve Districts permitted by the risk protection program. On a Visa POS program, ECHO has determined that the check cannot be electronically converted. No risk services were performed. ECHO and its partners have determined that the check cannot be electronically converted. B On a Visa POS program, ECHO has determined that the check cannot be electronically converted. No risk services were performed. ECHO has determined that the check cannot be electronically converted. No risk services were performed. Payroll checks are not permitted by the risk protection program. The payroll check submitted is not listed in the risk protection program as a Checkwriter account permitted to use this service. The identification information provided with the transaction is not listed in the risk protection program as an allowed ID to use this service. B N N N The card has been restricted.
Check
63 64
Tender Type
Card
Workflow Code
Comments
The allowed number of daily transactions has been exceeded.
0026 0027 0028 0035 0036 65 Exceed Withdrawal Frequency Check* 0037 0044
DAY LOC/NCHKS=%d DAY GRP/NCHKS=%d DAY ALL/NCHKS=%d WIN LOC/NCHKS=%d WIN GRP/NCHKS=%d WIN ALL/NCHKS=%d NUM PAYCHKS= %d B
These report that the number of checks limit has been exceeded for the day where %d is the number of checks. This reports that the number of checks limit has been exceeded for the time window. The rule set limit on the number of payroll checks that can be cashed on a given ID in a given period of time has been exceeded. Used in Visa POS, Too many checks (over merchant or bank limit) (T7).
0062
None
* These check declines may be usually be overridden with a Check Override Request if ECHOs ECC program is being used and the risk protection program permits it. A N I N N N B N D D D D The from (debit) account does not exist or is not associated with the card number presented. The to (credit) account does not exist or is not associated with the card number presented. The allowed number of PIN retries has been exceeded. Capture card. The merchant must call ECHO customer support.
66 67 68
Card Acceptor Call Acquirer/Decline Hard Capture ATM Response Received Too Late
75
76
Unsolicited Reversal
Card Check
79
Already Reversed
Card Check
Tender Type
Card Check Card Card Check Card
Workflow Code
L D D F
Comments
Credit Issuer Unavailable Invalid date Not declined. No reason to decline a request for account number verification, address verification, or CVV2 verification. Usually seen on AVS transactions. The authorization system is not available to authorize this transaction at this time. The authorization system is not available to authorize this transaction at this time. The transaction does not contain enough information to be routed to the authorizing agency. Transaction cannot be completed; violation of law The host has detected a duplicate transmission. This message appears when ECHO attempts to authorize a check which it has authorized in a previous transaction. This payroll check has been presented before for cashing.
85
No Reason to Decline
L L D D B N K 0008 RE-PRESENTED CHK K 0009 NULL 1000 1014 UNRECOVERABLE ERROR. INVALID CARD-PVT INVALID STATE INVALID AUTH CODE INVALID REFERENCE NUMBER INVALID RESPONSE DISCONNECT DUPLICATE CHECK L L D D D D L L
91
92
93
Cannot Complete
94
Duplicate Transaction
Check
A system error has occurred or the files required for authorization are not available. An unrecoverable error has occurred. Generally applies to VISA private label. The state code was invalid. The authorization number presented with this transaction is incorrect. (deposit transactions only) The reference number presented with this transaction is incorrect or is not numeric. The host returned an invalid response. The host unexpectedly disconnected.
96
System Error
Card
Tender Type
Workflow Code
L L L L L L L L L L L
Comments
Timeout waiting for host response. The host did not receive an ACK from the terminal after sending the transaction response. The host disconnected after the terminal replied 3 times to the host response with a NAK. The line dropped before the host could send a response to the terminal. The line dropped while the host was sending the response to the terminal. The host received an ACK from the terminal but the line dropped before the host could send the EOT. The line was up and carrier detected, but the terminal did not respond to the ENQ. The line disconnected while the host was receiving data from the terminal. The host disconnected after receiving 3 transmissions with incorrect LRC from the terminal. The line disconnected during input data wait in MultiTrans Mode. The host encountered a full queue and discarded the input data. These are system errors that may be corrected by resending the transaction again.
Check
97
Card Check
L L
9. Communications
9.1 Using TCP/IP for Message Processing
The Business Partner is responsible for providing and supporting the client portion of the TCP/IP connection in sending and receiving ISO8583 requests and responses. This document assumes that the Business Partner has a thorough knowledge of the TCP/IP protocol. The client software should establish and maintain the active socket-to-socket connection for as long as it is likely to be used. In other words, the connection should be kept up between messages to minimize the overhead caused by repeatedly establishing and breaking the connection. In addition, the client software should include logic to periodically check for a break in the connection and automatically re-establish it. It is recommended that request messages be sent asynchronously for improved efficiency; that is, the client software need not wait for a response to a prior request before sending another. The client software must provide logic to match responses with their corresponding requests. It is also recommended that the easiest way to implement request/response matching is for the client to populate Field 59, transport data, with a unique value per request. Field 59 will be returned unaltered in the corresponding response. Messages are sent as variable length byte streams (65,533 bytes, maximum). Request messages must be preceded by a two byte, unsigned integer, field length indicator, in binary, network short/big-endian format (i.e. most significant byte, followed by least significant byte). Response messages (returned by the server) will contain a similarly formatted field length indicator that reflects the length of the response message data field. ECHO supports multiple sockets listening on the same port; therefore the client may establish multiple TCP connections simultaneously to that one port. The format of the data is in two parts, a Data Length header indicating the length of the Data Packet followed by a Data Packet, which contains the bulk of the transaction information. The Data Length header is a two-byte, unsigned integer and the Data Packet is variable length field up to 65,533 bytes. This might be graphically represented as
Data Length
Data Packet. . . . . . . . . . . . . . . . . . . . . . .
The following screen captures show how TCP/IP requests and responses are framed. In Figure 9-1, the highlighted data in the bottom panel displays a 0100 request.
Note
These screen images were taken from packet sniffer software available at http://www.ethereal.com/.
Communications 68 of 109
The first two bytes, hex(00aa) = decimal(170), represent the length of the request, and the data that follows is the actual request. The middle pane displays the 172 bytes, which is the 2 length bytes plus the 170 bytes of data.
Communications 69 of 109
The highlighted data in the bottom panel is the request. The first two bytes, hex(00dd) = decimal(221), represent the length of the response and the rest of the data is the actual response. The middle pane shows 223 bytes, which is the 2 length bytes plus the 221 bytes of data.
Communications 70 of 109
3 ..17
B Z
11.1.1
WEB Transactions
An Internet-initiated entry is called a WEB transaction. This is used for a single-entry debit to a consumer account that is the result of an authorization received by the merchant from the Internet. The requirements for a WEB transaction are: 1. 2. 3. 4. 5. Merchant must have a commercially reasonable method of authenticating the identity of the Checkwriter. Transactions must be encrypted or transmitted via a secure session (ECHOs internet application provides this). Transactions must be drawn on Consumer Accounts. Credits cannot be issued unless needed for a reversal. Both Single Entry and Recurring Entry transactions are allowed. a) Single Entry Transactions: (1) Revocation language is NOT required to be included in consumer authorizations.
(2) RDFIs are not permitted to return Single Entry transactions based on a consumers claim that his/her authorization has been revoked (Reason Code 07). (3) Consumers are allowed to complete a stop payment order on Single Entry transactions at their financial institution within certain time frames. b) Recurring Entry Transactions: (1) Revocation language is required to be included in consumer authorizations for Recurring Entries. (2) Consumers have the right to place a stop payment on Recurring Entry transactions. However, it must be done at least three days prior to the scheduled settlement date of the transaction. 6. Originators of WEB transactions are required to obtain the consumers authorization prior to initiating a debit entry. a) The Checkwriter must be able to read the authorization language displayed on a computer screen or other visual display, which may be authenticated by the Checkwriter.
b) Authorization must be readily identifiable as an ACH debit authorization. c) Authorization must clearly and conspicuously state its terms.
11.1.2
11.1.3
11.1.4
The requirements for a POP transaction are: 1. Receipt: A Merchant must provide to each Checkwriter a receipt containing the following information with respect to each POP entry to the Checkwriters account: a) Merchant name;
d) Transaction amount; e) f) Source document check serial number; Merchant number (or other unique number that identifies the location of the transaction);
g) Terminal City; h) Terminal State; and i) Returned Item Fee (if collection service fee is greater than zero). See Field 54 Amount Type 06 for details.
The National Association strongly recommends, but these rules do not require, that the Merchant also provide the following information on the receipt provided to the Checkwriter: a) Merchant address;
d) Checkwriters truncated account number; e) f) Checkwriters truncated identification number; and Transaction reference number.
The Checkwriters complete account number and complete identification number are not permitted to be placed on the receipt. a) Source document:
For a POP entry, a check or sharedraft provided by the Checkwriter at the point-ofpurchase must be used by the Merchant as a source document for the Checkwriters routing number, account number, and check serial number. The source document must be voided by the Merchant and returned to the Checkwriter at the point-of- purchase. Only a check or sharedraft that meets the follow requirements may be used as a source document for a POP transaction: The following requirements for the source document for a POP transaction: b) Contains a pre-printed serial number c) Does not contain an Auxiliary On-Us Field in the MICR line
The following source documents are not permitted for a POP transaction: a) Demand drafts and third- party drafts that do not contain the signature of the Checkwriter
b) Checks provided by a credit card Issuer for purposes of accessing a credit account or checks drawn on home equity lines of credit c) Checks drawn on an investment company as defined in the Investment Company Act of 1940
d) Obligations of a financial institution (e.g., travelers checks, cashiers checks, official checks, money orders, etc.); e) f) Checks drawn on the Treasury of the United States, a Federal Reserve Bank, or a Federal Home Loan Bank Checks drawn on a state or local government that are not payable through or at a Participating DFI
g) Checks or sharedrafts payable in a medium other than United States currency. f) Capture of MICR Information:
The Merchant may not key-enter the routing number, account number, or check serial number from the Checkwriters source document. ECHO has an optional feature to provide research on returned items, and, if items are returned for certain of the above reasons, we can attempt to clear the items via paper draft. The Merchant must provide a reasonable method to allow Checkwriters to opt out of check conversion if they wish to.
11.1.5
b) There is no existing relationship between the Checkwriter and the merchant, but the Checkwriter has initiated the phone call. The merchant and consumer are considered to have an existing relationship when either: a) There is a written agreement in place between the Checkwriter and the merchant for the provision of goods and services, or
b) The Checkwriter has purchased goods or services from the Originator within the last two years. 2. Merchants must obtain the Checkwriters explicit authorization to do a TEL transaction. This may be obtained orally, but merchants must do one of the following (and the Checkwriter must be told which of the following methods will be used): a) Tape record the consumers oral authorization. Tape recordings must be retained for two years from the date of the authorization. Oral authorizations must include: (1) The merchant clearly stating during the conversation that the consumer is authorizing a debit entry to his account; (2) Terms of the authorization; and (3) Checkwriter must express consent.
b) Provide, in advance of the Settlement Date of the entry, written notice to the consumer that confirms the oral authorization (such as a postcard or fax). This must include: (1) Date on which the account will be debited; (2) Amount of debit; (3) Name of Checkwriter; (4) Customer service telephone number that Checkwriter may call for questions; (5) Date of Checkwriters oral authorization; and (6) Statement that the authorization obtained from Checkwriter will be used to debit the checking account.
11.2
Receipt Requirements
The Business Partner must insure that the POS/purchase device prints an appropriate Transaction Receipt based on the tender type, type of merchant, and type of transaction. A Transaction Receipt is an electronic or paper record of a Transaction (or a copy), generated at the Point-of-Transaction.
11.2.1
2.
3.
Each formset must bear a sequential number consisting of at least five digits.
Transaction Receipt Prohibitions: 1. Preprinted legends designating space for supplementary Cardholder information (e.g., address, telephone number) or ancillary charges to be added after completion of the Transaction areprohibited, except as specified below: a) Supplementary Cardholder information may be designated on formsets also designed for use as: Mailing or delivery slips Guest registration forms Car rental contracts
2.
3.
Wire Transfer Money Orders. b) Space for ancillary charges is permitted on T&E Document formsets used by Lodging or Cruise Line Merchants, or Car Rental Companies. Use of promotional, advertising, or similar language that conveys preference of a nonVisa payment card on Transaction Receipts that bear the Visa Program Marks is prohibited. The use of language that conveys any limitation of a Cardholders rights to dispute the Transaction with the Issuer is prohibited.
Transaction Data Requirements Self-Service Terminal Transactions Effective October 1, 2005, Transactions under $25 completed Point-of-Transaction Terminal with Contactless Payment capability Effective through April 7, 2006, Express Payment Service Transactions Small Ticket Transactions Effective April 8, 2006, No Signature Required Transactions Effective April 8, 2006, a legend identifying the party to whom it will be delivered (e.g., Member copy, Merchant copy, Cardholder copy), except for Small Ticket and No Signature Required Transactions. Authorization Code, if applicable *For a Quasi-Cash Transaction completed in a Face-to-Face Environment, the Transaction Receipt must provide space for Cardholder identification and the four digits printed above or below the Account Number.
Transaction Data Requirements Transaction Date Transaction Payment Type (i.e., Visa). Effective November 1, 2005, the payment brand used to complete the Transaction must be identified on the Cardholders copy of the Transaction Receipt.
Transaction Data Requirements Space for Cardholder identification Space for clerks signature or identification Authorization Code Space for four printed digits above or below Account Number
11.2.2
d) Transaction amount; e) f) Source document check serial number; Merchant number (or other unique number that identifies the location of the transaction);
g) Terminal City h) Terminal State; and i) Returned Item Fee (if collection service fee is greater than zero). See Field 54 Amount Type 06 for details. The National Association strongly recommends, but these rules do not require, that the Merchant also provide the following information on the receipt provided to the Checkwriter: a) Merchant address;
d) Checkwriters truncated account number; e) f) Checkwriters truncated identification number; and Transaction reference number.
be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution. If your payment is returned unpaid, you authorize us to collect the returned item fee described elsewhere on this receipt by presenting a demand draft against your account or by making a one-time electronic fund transfer from your account.
11.2.2.1.3.1
Your check cannot be accepted for the Electronic Check Conversion service at this time. The decision to deny your check is based on the information provided to us by: COMPANY NAME 1-800-XXX-XXXX You have the right to request a free copy of this information from the company listed above, if you request it from the company within 60 days. You also have the right to dispute directly with the company listed above about the accuracy or completeness of any information they provide to you. The merchant did not make the decision to deny your check and is not able explain why the decision was made.
The font in CAPITALIZED letters is obtained from Field 63.12 in sixteen character rows using the following workflow: Search the first three characters of the sixteen character rows. There may be more than one row that matches. Use the first existence. If a row begins with PHN then print that row in the place of the phone number. Print the row immediately following it in the place of the Company Name. For example, the text string DECLINE CHECK 3 UNPAIDS (ALL)UNPAID AMT= 197PHN 888-340-9205CYBRCOLLECT PHN 800947-3604CHECK WISE would be formatted as: CYBRCOLLECT PHN 888-340-9205 Field 63.12 will only contain the text string PHN if Field 39 in the response message contains a value of 05.
11.2.2.1.3.2
Your check cannot be accepted for the Electronic Check Conversion service at this time. The decision to deny your check is based on the information provided to us by: COMPANY NAME 1-800-XXX-XXXX You have the right to request a free copy of this information from the company listed above, if you request it from the company within 60 days. You also have the right to dispute directly with the company listed above about the accuracy or completeness of any information they provide to you. The merchant did not make the decision to deny your check and is not able explain why the decision was made.
The company name and the toll-free phone number in CAPITALIZED letters above must be obtained from entity that is responsible for configuring the merchants rule set and Risk Protection System parameters. For more information as to who this entity is please review the Business Partners agreement with ECHO, contact your sales representative or ECHO customer support. At the Business Partners discretion, the first three 16-character rows may be printed under the company name and telephone number as long as there are no rows beginning with the text string PHN For example, the text string MANAGER NEEDED YOUNG ACCOUNT CHECK TOO LARGE DAY LOC/AMT=1119 would be formatted as: JOHN DOE COMPANY PHN 888-340-9203 MANAGER NEEDED YOUNG ACCOUNT CHECK TOO LARGE
On an authorized transaction the following text should be printed above the signature line: When you provide a check as payment, you authorize us to (1) use information from your check to make a one-time electronic fund transfer from your account, (2) process the payment as a check transaction, or (3) create and process a demand draft against your account for the amount of the transaction. When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution. If your payment is returned unpaid, you authorize us to collect the returned item fee described elsewhere on this receipt by presenting a demand draft against your account or by making a one-time electronic fund transfer from your account. A sample receipt is below:
Merchant Name Merchant Address Merchant Phone Terminal City and State Date: 04/04/00 Time 11:56 Lane #99 Cashier #7777 AMOUNT OF TRANSACTION: $82.35 RETURN ITEM FEE: $25.00 Routing # 122101191 Account # XXXXXX4587
Check # 1234 Auth: 203500 Ref# 001002 AUTHORIZATION AGREEMENT: When you provide a check as payment, you authorize us to (1) use information from your check to make a one-time electronic fund transfer from your account, (2) process the payment as a check transaction, or (3) create and process a demand draft against your account for the amount of the transaction. When we use information from your check to make an electronic fund transfer, funds may be withdrawn from your account as soon as the same day you make your payment, and you will not receive your check back from your financial institution. If your payment is returned unpaid, you authorize us to collect the returned item fee described elsewhere on this receipt by presenting a demand draft against your account or by making a one-time electronic fund transfer from your account. X_______________________________________ Authorization Signature Customer Service Number
For authorized transactions where Field 54 Amount Type 06 contains an amount value, starting January 2008, any check service fee must be disclosed on the receipt. Any time this value is greater than zero, it should be printed on the receipt as above. When a third-party authorizer (ECHO) declines an authorization request, it is necessary to provide the customer with a Decline Disclaimer in order to comply with the Fair Credit Reporting Act. Visa USA recommends using the generic language below for a declined transaction. On a declined transaction where Field 63, subfield 12 of the response is populated (indicating the decline was issued by ECHO) the following text should be printed above the signature line. The font in CAPITALIZED letters is obtained from Field 63.13.
Your check cannot be accepted for the POS Check Service at this time. The decision to deny your check is based on information provided to us by: COMPANY NAME COMPANY ADDRESS 1-800-XXX-XXXX You have the right to request a free copy of this information from the company listed above, if you request it from the company within 60 days. You also have the right to dispute directly with the company listed above about the accuracy or completeness of any information they provide to you. The merchant did not make the decision to deny your check and is not able explain why the decision was made.
The Business Partner may also print the first 32 characters of Field 63.12 at their discretion under the toll free phone number. Receipt text is in 16-character width lines. When a participating drawee bank declines an authorization request, it is necessary to inform the customer that their respective financial institution declined the transaction. Visa
recommends using the generic language below for a declined transaction. On a declined transaction where Field 63, subfield 12 of the response is not populated (indicating the decline was issued by the Checkwriters bank (aka drawee or Visa participating bank ) the following text should be printed above the signature line:
Your check cannot be accepted [for the check conversion program] at this time. The decision to deny your check is based on information provided to us by: The consumers financial institution ABA: 123456789 DDA: xxxxx1234 Please contact your financial institution for an explanation of why the request was declined.
Unlike the non-participating receipt, Field 63.12 will not be populated so there is no additional text that can be printed.
11.3
NOTE: Every decal at the point of sale must contain either the exact amount of the returned check fee or the calculation used in determining the fee in order to maintain compliance with Reg E.
Actions 1 and 2 are relatively straight forward. However, actions 3, 4 and 5 require some additional responses at the Point of Sale. Based on these five actions, the following capabilities will be needed at the Point of Sale: 1. 2. 3. 4. 5. Information from the ECHO host will need to be displayed to clerk. A receipt will be printed. The clerk will need to be instructed how and when to call the Issuer for a voice authorization. The clerk will need to be instructed how and when to reinitiate/retry the transaction, and the Point of Sale system will need to capacity to perform this function. The clerk will need a way of backing out of a scenario where the clerk mistakenly attempts to run the same transaction twice. The second transaction may result in an error condition represented transaction and the clerk will need a way of completing the tender. The clerk will need to be instructed how and when a system error has occurred and who to call for help. Authorization logging and reporting. Update local records.
6. 7. 8.
12.2
12.2.1
AVS Only
{0100}2[400555000000****]3[003000]4[000000000000]7[0623010426]11[1617] 14[0606]42[1234567890] 59[050CREDIT CARD AVS ONLY ]62.6[12345678920ADDRESSS_DATA_HERE__]123[260101664040101]
Generic Purchase
{0200}2[400555000000****]3[003000]4[000000000100]7[0623010426]11[1617] 14[1206]42[1234567890] 59[050CREDIT CARD PURCHASE ]123[260101664040101]
Purchase Return
{0200}2[400555000000****]3[200030]4[1000]7[0623010426]11[1617]14[1206] 14[0106]42[1234567890] 59[050CREDIT CARD PURCHASE RETURN ]123[260101664040101]
Forced Deposit
Note that the authorization number returned in the 0100 message should be placed into field 38 of the below 0220 message unless special conditions apply.
12.2.2
PIN-based Debit
Purchase
Purchase Void
{0420}2[400555000000****]3[000000]4[000000000100]7[0622175500]11[90000 0]14[0806]42[1234567890]59[050PIN-Based Debit Test VOID ]90[0200_STAN_DATE&&TIME00000000000000000000000]123[210101214118101]
Purchase Return
{0200}3[200000]4[000000000100]7[0622175500]11[900000]35[30400555000000 ****=001210110000?]42[7022223318]52[8BYTEPIN]53[DUKPTKSN_BINARY_FIXED_
Use Cases 87 of 109
Generic Void
{0420}3[000000]4[000000000100]7[0622175500]11[900000]14[0806]35[304005 55000000****=001210110000?]42[7022223318]59[050PIN-Based Debit Test VOID ]90[0200_STAN_DATE&&TIME00000000000000000000000]123[210101214118101]
12.3
12.3.1
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
0100 M M M M M O O O O
Res p
0110 M
Comment
C+ M+ O M O C+ O C C O M C + -
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response Populate for Cashback only
Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this
C C C C C
Field
Description
Re q
C O M
Res p
Comment
should be Track 2 data from the DL
62 63 123
NOTES: 1. SWIPED vs KEYED MICR: a) If Fields 60.10 and 60.12 are present, the transaction will be a SWIPED MICR transaction.
b) If Fields 60.10 and 60.11 are present, the transaction will be a KEYED MICR transaction. 2. Affect of Check Type: a) If Field 60.10 types 1, 3, 4, 5, 6, 7, 9 all yield a personal check (type 7) transaction.
b) If Field 60.10 is set to type 2, then the check will be processed as a payroll (type 9) transaction, and an ID is required in 61 regardless of how ECHOs risk protection systems are configured (Ruleset). c) 3. 4. If Field 60.10 is set to type 8, then the check will be processed as a ThirdParty (type 8) check transaction.
If a valid swiped ID is submitted in Field 61.14, the State code is returned in Field 61.9 and the ID number is returned in Field 61.2. If cash back is used, then Field 4 (the transaction amount) must equal the total of the purchase amount plus Field 54 (the cash back amount). In other words, the amount of the goods or services sold can be found by subtracting Field 54 from Field 4.
Example: Verification Only, No ID, No Cashback {0100}3[042000]4[00101]7[0627182747]11[7747]37[617818007747]42[1 233301100]60.10[01]60.12[t12345****t809123****0o1003]123[S60101S 64040101] {0110}3[042000]4[000000000101]7[0627182747]11[007747]37[61781800 7747]38[187341]39[00]42[1233301100 ]60.10[01]60.11[0912345****10809123****0041003]60.12[t12345****t 809123****0o1003]63.12[ISO TEST 200 AUTH NUM 187341]123[S60101S64040101]
Req
Resp
12.3.2
Description
Message Type BitMap Processing Code Transaction Amount
Re q
0100 M M M
Res p
0110 M
Comment
Field
7 11 12 13 18 37 38 39 41 42 43 44 49 52 54 59 60.10 60.11 60.12 61.1 61.2 61.9 61.14 62 63 123
Description
Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data POS Data Code
Re q
M M O O O O
Res p
Comment
C+ M+ O M O C+ O C O O M -
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response Populate for Cashback only
MUST NOT BE POPULATED MUST NOT BE POPULATED C C C C C O M + 63.12 will contain the response text If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL
NOTES: 1. 2. 3. MICR must NOT be populated in either Fields 60.11 or 60.12. Even though NCN supports an optional Check Number, this cannot be used in the ISO gateway. Affect of Check Type: Field 60.10 is IGNORED. If a valid swiped ID is submitted in Field 61.14, the State code is returned in Field 61.9, and the ID number is returned in Field 61.2.
Example: ID-Based Verification Only, Keyed U.S. DL {0100}3[042000]4[105]7[0616225311]11[9352]12[165311]13[0616]37[6 16722009352]42[1233301017]59[9352]61.1[01]61.2[123123]61.9[NC]62 .5[05]123[S60101S64040101] {0110}3[042000]4[000000000105]7[0616225311]11[009352]12[165311]1 3[0616]37[616722009352]38[185500]39[00]42[1233301017 ]59[9352]61.1[01]61.2[123123]61.9[NC]62.5[05]63.12[NCN VERIFY AUTH NUM 185-500]123[S60101S64040101]
Req
Resp
12.3.3
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
0120 M M M M M O O O O
Res p
0130 M
Comment
C+ M+ O M O C+ O C C O M C + -
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response Populate for Cashback only
Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL
C C C C C
Field
62 63 123
Description
Application Information Private Data POS Data Code
Re q
C O M
Res p
+
Comment
NOTES: 1. 2. See notes for MICR Verification Only as they all apply. Only warnings are eligible for override. An override request on a decline will still yield a decline.
Example: Verification Override, No ID, No Cashback {0120}3[042000]4[00101]7[0627182747]11[7747]37[617818007747]42[1 233301100]60.10[01]60.12[t12345****t809123****0o1003]123[S60101S 64040101] {0130}3[042000]4[000000000101]7[0627182747]11[007747]37[61781800 7747]38[187341]39[00]42[1233301100 ]60.10[01]60.11[0912345****10809123****0041003]60.12[t12345****t 809123****0o1003]63.12[ISO TEST 200 AUTH NUM 187341]123[S60101S64040101]
Req
Resp
12.3.4
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data
Re q
0420 M M M M M O O O O
Res p
0430 M
Comment
C+ M+ O M O C+ O C -
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response
Field
54 59 60.10 60.11
Description
Additional Amounts Transport Data Check Type Keyed MICR
Re q
O O M
Res p
Comment
Populate for Cashback only
Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required C C C C C O M M + 63.12 will contain the response text If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data Original Data Elements POS Data Code
NOTES: 1. 2. 3. See notes for MICR Verification only, except that Field 60.10 payroll (type 2) is NOT ALLOWED. Field 90 MUST be added to provide the reference to the original transaction. This void message type must is done within at least the same 24-hour day. However, special conditions may apply and best practice is to perform any voids within 10 minutes of the original message. Additionally, the amount, check serial number, account number and route number must all match the original values used on the authorized transaction. Only transactions that have received a response code of 00 can be voided.
4.
Example: ID-Based Verification Only VOID, Keyed U.S. DL {0420}3[162000]4[124]7[0616225321]11[9363]12[165321]13[0616]37[6 16722009363]42[1233301018]59[9363]60.10[01]60.12[T12345****T 809 123****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]90[020000876910 28220326 ]123[S60101S64040101] {0430}3[162000]4[000000000124]7[0616225321]11[009363]12[165321]1 3[0616]37[616722009363]39[00]42[1233301018 ]59[9363]60.10[01]60.11[0912345****08809123****44051]60.12[T1234 5****T 809123****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]63.12 [ECHO TEST ACCNT VOID ACCEPTED ]90[000000000000000000000002000087691028220326]123[S60101S640401 01]
Req
Resp
12.3.5
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
0200 M M M M M O O O O
Res p
0210 M
Comment
C+ M+ O M O C+ O C C O M C + +
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response Populate for Cashback only.
Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data POS Data Code
C C C C C C O M +
NOTES: 1. SWIPED vs KEYED MICR: a) If Fields 60.10 and 60.12 are present, the transaction will be a SWIPED MICR transaction.
b) If Fields 60.10 and 60.11 are present, the transaction will be a KEYED MICR transaction. If this happens, a response code of 19, transaction not allowed will be issued in the response message unless special arrangements have been made otherwise. 2. Affect of Check Type: a) If Field 60.10 types 1, 3, 4, 5, 6, 7, 9, then the check will be processed as personal check (type 7) transaction.
b) Field 60.10 must not be set to payroll (type 2), this transaction type is not allowed. c) 3. 4. Field 60.10 must not be set to two-party (type 8), this transaction type is not allowed.
If a valid swiped ID is submitted in Field 61.14, the State code is returned in Field 61.9, and the ID number is returned in Field 61.2. In Field 54, returned item fee and returned item fee tax may be added for ECC transactions.
Example: Verification w/Conversion, No ID, No Cashback {0200}3[042000]4[00101]7[0627182747]11[7747]37[617818007747]42[1 233301100]60.10[01]60.12[t12345****t809123****0o1003]123[S60101S 64040101] {0210}3[042000]4[000000000101]7[0627182747]11[007747]37[61781800 7747]38[187341]39[00]42[1233301100 ]60.10[01]60.11[0912345****10809123****0041003]60.12[t12345****t 809123****0o1003]63.12[ISO TEST 200 AUTH NUM 187341]123[S60101S64040101]
Req
Resp
12.3.6
12.3.7
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code
Re q
0220 M M M M M O O O O
Res p
0230 M
Comment
C+
Present if 39 = 00
Field
39 41 42 43 44 49 52 54 59 60.10 60.11
Description
Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
O M O
Res p
M+
Comment
This is the merchant ID C+ If present, generally indicates some sort packet format error Removed from response + Populate for Cashback only 02 (payroll) indicates a different transaction type. + Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL + 63.12 will contain the response text
O C C O M C -
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data POS Data Code
C C C C C C O M
NOTES: 1. 2. 3. Refer to notes for Verification w/Conversion. They all apply here. Only warnings are eligible for override. An override request on a decline will still yield a decline. In Field 54, returned item fee and returned item fee tax may be added for ECC transactions.
Example: Verification w/Conversion Override, No ID, No Cashback {0220}3[042000]4[00101]7[0627182747]11[7747]37[617818007747]42[1 233301100]60.10[01]60.12[t12345****t809123****0o1003]123[S60101S 64040101] {0230}3[042000]4[000000000101]7[0627182747]11[007747]37[61781800 7747]38[187341]39[00]42[1233301100 ]60.10[01]60.11[0912345****10809123****0041003]60.12[t12345****t 809123****0o1003]63.12[ISO TEST 200 AUTH NUM 187341]123[S60101S64040101]
Req
Resp
12.3.8
Same as Verification w/Conversion Override except: Field 3, Processing Code must be 03200 or 03000.
12.3.9
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
0420 M M M M M O O O O
Res p
0430 M
Comment
C+ M+ O M O C+ O C O O M +
Present if 39 = 00
This is the merchant ID If present, generally indicates some sort packet format error Removed from response Populate for Cashback only 02 (payroll) indicates a different transaction type. Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data Original Data Elements POS Data Code C C C C C O M M +
If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL 63.12 will contain the response text
NOTES:
1. 2. 3.
See notes for MICR Verification w/Conversion, except that Field 90 MUST be added to provide the reference to the original transaction. All other transaction-related fields (MICR, ID, Amount, etc) should be identical to the original transaction. This void message type must is done within at least the same 24-hour day. However, special conditions may apply and best practice is to perform any voids within 10 minutes of the original message. Additionally, the amount, check serial number, account number and route number must all match the original values used on the authorized transaction. Only transactions that have received a response code of 00 can be voided. In Field 54, returned item fee and returned item fee tax may be added for ECC transactions.
4. 5.
Example: Verification w/Conversion VOID {0420}3[042000]4[124]7[0616225321]11[9363]12[165321]13[0616]37[61 6722009363]42[1233301018]59[9363]60.10[01]60.12[T12345****T 80912 3****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]90[020000876910282 20326 ]123[S60101S64040101] {0430}3[042000]4[000000000124]7[0616225321]11[009363]12[165321]13 [0616]37[616722009363]39[00]42[1233301018 ]59[9363]60.10[01]60.11[0912345****08809123****44051]60.12[T12345 ****T 809123****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]63.12[E CHO TEST ACCNT VOID ACCEPTED ]90[000000000000000000000002000087691028220326]123[S60101S6404010 1]
Req
Resp
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number
Re q
0200 M M M M M O O O O
Res p
0210 M
Comment
Field
38 39 41 42 43 44 49 52 54 59 60.10 60.11
Description
Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
Res p
C+ M+
Comment
Present if 39 = 00
O M O C+ O C C O M C + Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL + 63.12 will contain the response text 63.13 will contain the Callback Information Removed from response Ignored If present, generally indicates some sort packet format error This is the merchant ID
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data POS Data Code
C C C C C C O M
NOTES: 1. SWIPED vs KEYED MICR: a) If Fields 60.10 and 60.12 are present, the transaction will be a SWIPED MICR transaction.
b) If Fields 60.10 and 60.11 are present, the transaction will be a KEYED MICR transaction. If this happens, a response code of 19, transaction not allowed will be issued in the response message unless special arrangements have been made otherwise. 2. Affect of Check Type: a) If Field 60.10 types 1, 3, 4, 5, 6, 7, 9, then the check will be processed as a personal check (type 7) transaction.
b) Field 60.10 must not be set to payroll (type 2), this transaction type is not allowed. c) 2. 3. 4. Field 60.10 must not be set to two-party (type 8), this transaction type is not allowed.
If a valid swiped ID is submitted in Field 61.14, the State code is returned in Field 61.9, and the ID number is returned in Field 61.2. If a valid swiped ID is submitted in 61.14, the State code is returned in 61.9, and the ID number is returned in 61.2 The Visa POS Check service does not permit cash back therefore cash back is not allowed in Field 54. (If Field 54 is populated, it will be ignored.)
Example: VISA POS Check Verification w/Conversion, No ID, No Cashback {0200}3[042000]4[00101]7[0627182747]11[7747]37[617818007747]42[1 233301100]60.10[01]60.12 [t12345****t809123****0o1003]123[S60101S64040101] {0210}3[042000]4[000000000101]7[0627182747]11[007747]37[61781800 7747]38[187341]39[00]42[1233301100 ]60.10[01]60.11[0912345****10809123****0041003]60.12[t12345****t 809123****0o1003]63.12[ISO TEST 200 AUTH NUM 187341]123[S60101S64040101]
Req
Resp
Description
Message Type BitMap Processing Code Transaction Amount Transmission Date and Time Systems Trace Audit Number Local Transaction Time Local Transaction Date Merchant Type Retrieval Reference Number Approval Code Response Code Card Acceptor Terminal ID Card Acceptor ID Code
Re q
0420 M M M M M O O O O
Res p
0430 M
Comment
C+ M+ O M
Present if 39 = 00
Field
43 44 49 52 54 59 60.10 60.11
Description
Card Acceptor Name/ Location Additional Data Transaction Currency Code PIN Data Additional Amounts Transport Data Check Type Keyed MICR
Re q
O
Res p
C+
Comment
If present, generally indicates some sort packet format error Removed from response Populate for Cashback only 02 (payroll) indicates a different transaction type. Either 60.11 or 60.12 is required. If valid raw MICR sent in 60.12, parsed MICR in 60.11 is added Either 60.11 or 60.12 is required
O C O O M -
Swiped MICR ID type ID Number ID State Code ID Track 2 data Application Information Private Data Original Data Elements POS Data Code C C C C C O M M +
If an ID is submitted, this is REQUIRED Required for keyed ID Required for keyed Drivers license or other State-issued IDs Required for swiped Drivers License this should be Track 2 data from the DL 63.12 will contain the response text 63.13 will contain the Callback Information
NOTES: 1. 2. 3. See notes for MICR Verification w/Conversion, except that Field 90 must be added to provide the reference to the original transaction. All other transaction-related fields (MICR, ID, Amount, etc) should be identical to the original transaction. This void message type must is done within 10 minutes of the original message. Additionally, the amount, check serial number, account number and route number must all match the original values used on the authorized transaction. Only transactions that have received a response code of 00 can be successfully voided.
4.
Example: VISA POS Check Verification w/Conversion VOID {0420}3[042000]4[124]7[0616225321]11[9363]12[165321]13[0616]37[61 6722009363]42[1233301018]59[9363]60.10[01]60.12[T12345****T 80912 3****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]90[020000876910282 20326 ]123[S60101S64040101] {0430}3[042000]4[000000000124]7[0616225321]11[009363]12[165321]13 [0616]37[616722009363]39[00]42[1233301018 ]59[9363]60.10[01]60.11[0912345****08809123****44051]60.12[T12345 ****T 809123****O4051]61.1[01]61.2[123123]61.9[NC]62.5[05]63.12[E CHO TEST ACCNT VOID ACCEPTED ]90[000000000000000000000002000087691028220326]123[S60101S6404010 1]
Req
Resp
3.
3.
12.4
Request Examples
The examples below explain the convention for representing binary data in ASCII text. This allows the document to show these data in an easily readable format. In the example below, Field 3 is shown in brackets and the field number precedes the leading bracket.
3[162000]
{0800}7[0331142322]11[999009]41[
999] 42[1234567890
]70[301]
Field 0 is shown in curly braces as {0800} and Field 7 is shown as 7[0331142322], and so on. The following provides several use cases to describe the process from the Point of Sale:
CC Authorization/Verification Only
{0100}2[400555000000****]3[003000]4[000000000100]7[0623010426]11[1617] 14[0806]42[1234567890]59[050"CREDIT CARD AUTHORIZATION ONLY "]123[260101664040101]
CC CVV2 Verification
{0200}2[400555000000****]3[003000]4[000000000100]7[0623010426]11[1617] 14[1007]42[1234567890] 59[050"CREDIT CARD CVV2 AUTHORIZATION ONLY "]62.8[10233]123[260101664040101]
"]90[0200_STAN_DATE&&TIME00000000000000000000000]123[210101214118101]
CC Purchase Return
{0200}2[400555000000****]3[200030]4[1000]7[0623010426]11[1617]14[1206] 14[0106]42[1234567890] 59[050"CREDIT CARD PURCHASE RETURN "]123[260101664040101]
Card-Based Transaction Swiped Card Authorization Only Plus AVS and 16 Character Window
{0100}2[400555000000****]3[003000]4[103]14[0606]42[1233301030]61.1[01] 61.2[A123456]61.9[CA]62.5[05]62.6[91377 ]63.11[16]123[260101664040101]
Card-Based Transaction Swiped Card Authorization Only Plus CVV and 16 Character Window
{0100}2[400555000000****]3[003000]4[103]14[0505]42[1233301030]61.1[01] 61.2[A123456]61.9[CA]62.5[05]62.8[19876]63.11[16]123[260101664040101]
Card-Based Transaction Authorization Only Plus CVV and AVS and 16 Character Window
{0100}2[400555000000****]3[003000]4[103]14[0505]42[1233301030]61.1[01] 61.2[A123456]61.9[CA]62.5[05]62.6[91377 ]62.8[19876]63.11[16]123[260101664040101]
{0200}3[162000]4[100]42[1233301030]60.10[01]60.11[0948000001808809123* ***41001]61.1[01]61.2[A123456]61.9[CA]62.5[05]123[S60101S64040101]
Keyed ECC:
{0200}3[162000]4[100]42[1233301030]60.10[01]60.11[0948000001808809123* ***41001]61.1[01]61.2[A123456]61.9[CA]62.5[05]123[S60101664040101]
{0100}3[042000]4[100]42[1233301030]123[S60101S64040101]
Missing POS info:
13. Certification
Protocol compliance will be performed by ECHO together with the Business Partner to assure successful processing of the various transaction types. ECHO maintains a Quality Assurance Simulator that generates specific responses based on the values sent in Field 60.7. A table will also be provided with the appropriate values and their corresponding responses as part of the simulation testing. The Business Partner will be required to certify for both Payment Card and Check services unless previous arrangements have been made otherwise. At the completion of the exercise, either the Business Partner will be certified as an ECHO ISO Business Certified Partner or additional protocol development will be requested of the Business Partner.