Bank of America Merchant Services MultiLink Message Specification Authorization Formats for Debit, Credit, EBT, Check Acceptance and POS Check

Transcription

1 Bank of America Merchant Services MultiLink Message Specification Authorization Formats for Debit, Credit, EBT, Check Acceptance and POS Check Version 4.02 Document creation date: March 28, 2002 Last modification date: August 12, 2009 Original document author: Monte D. Shuck Last modified by: Monte D. Shuck

2 BANK OF AMERICA MERCHANT SERVICES CONFIDENTIALITY REQUIREMENTS...7 OVERVIEW TRANSACTIONS SUPPORTED DEBIT TRANSACTIONS... 9 Debit Purchase... 9 Debit Purchase with Cash Back... 9 Debit Preauthorized Purchase and Completion... 9 Debit Preauthorized Purchase and Completion with Cash Back... 9 Debit Return... 9 Debit Balance Inquiry... 9 Debit Bill Payment Debit Reversal EBT TRANSACTIONS EBT Food Stamp Purchase EBT Food Stamp Return EBT Food Stamp Electronic Voucher EBT Cash Benefit Purchase EBT Cash Benefit Purchase with Cash Back EBT Cash Benefit Cash Withdrawal EBT Food Stamp Balance Inquiry EBT Cash Benefit Balance Inquiry EBT Reversal CREDIT TRANSACTIONS Credit Purchase Credit Purchase with Cash Back Credit Merchandise Return Credit Card Verification Credit Balance Inquiry Credit Advice Credit Bill Payment Credit Healthcare Auto-Substantiation Credit Reversal CHECK TRANSACTIONS Check Acceptance POS Check SETTLEMENT TRANSACTIONS Settlement Request/Response NETWORK MANAGEMENT Network Management Dynamic Key Exchange Messages Network Management Health Message ( ECHOTEST ) Network Management LOGON Message Network Management LOGOFF Message CONTACTLESS PAYMENT PROGRAM General Description: Modifications to support contactless payment: Supported transactions: Changes to the Response Message: PIN TRANSLATION TRANSACTIONS TEST TRANSACTIONS Version 4.02 Page 2 Last modified August 12, 2009

3 1.10 REAL TIME CLEARING TRANSACTIONS MESSAGES FORMATS (GENERAL) BIT MAPS MESSAGE HEADER NUMERIC PACKED DATA GUIDE TO TRANSACTION ATTRIBUTES AND FORMATS HEADER FORMAT DEBIT, CREDIT, EBT AND CHECK MESSAGE FORMATS DEBIT AND EBT REQUEST MESSAGE DEBIT AND EBT RESPONSE MESSAGE DEBIT PREAUTHORIZED PURCHASE REQUEST MESSAGE DEBIT PREAUTHORIZED PURCHASE RESPONSE MESSAGE DEBIT PREAUTHORIZED PURCHASE COMPLETION REQUEST MESSAGE DEBIT PREAUTHORIZED PURCHASE COMPLETION RESPONSE MESSAGE DEBIT BILL PAYMENT REQUEST MESSAGE DEBIT BILL PAYMENT RESPONSE MESSAGE DEBIT AND EBT REVERSAL REQUEST MESSAGE DEBIT AND EBT REVERSAL RESPONSE MESSAGE CREDIT REQUEST MESSAGE CREDIT RESPONSE MESSAGE CREDIT BILL PAYMENT REQUEST MESSAGE CREDIT BILL PAYMENT RESPONSE MESSAGE CREDIT REVERSAL REQUEST MESSAGE CREDIT REVERSAL RESPONSE MESSAGE CREDIT ADVICE REQUEST MESSAGE CREDIT ADVICE RESPONSE MESSAGE CHECK ACCEPTANCE REQUEST MESSAGE CHECK ACCEPTANCE RESPONSE MESSAGE POS CHECK REQUEST MESSAGE POS CHECK RESPONSE MESSAGE POS CHECK REVERSAL REQUEST MESSAGE POS CHECK REVERSAL RESPONSE MESSAGE REAL TIME CLEARING REQUEST MESSAGE REAL TIME CLEARING RESPONSE MESSAGE REAL TIME CLEARING PREAUTHORIZED PURCHASE REQUEST MESSAGE REAL TIME CLEARING PREAUTHORIZED PURCHASE RESPONSE MESSAGE REAL TIME CLEARING PREAUTHORIZED PURCHASE COMPLETION REQUEST MESSAGE REAL TIME CLEARING PREAUTHORIZED PURCHASE COMPLETION RESPONSE MESSAGE REAL TIME CLEARING REVERSAL REQUEST MESSAGE REAL TIME CLEARING REVERSAL RESPONSE MESSAGE SETTLEMENT MESSAGE FORMATS SETTLEMENT REQUEST SETTLEMENT RESPONSE NETWORK MANAGEMENT FORMATS NETWORK MANAGEMENT REQUEST NETWORK MANAGEMENT RESPONSE PIN TRANSLATION FORMATS Version 4.02 Page 3 Last modified August 12, 2009

4 6.1 PIN TRANSLATION REQUEST MESSAGE PIN TRANSLATION RESPONSE MESSAGE REJECTED MESSAGES MESSAGE FLOWS TRANSACTION MESSAGE FLOWS Debit & EBT Transaction Message Flows Credit Transaction Message Flows Check Acceptance Transaction Message Flows Settlement Transaction Message Flows NETWORK MANAGEMENT MESSAGE FLOWS PIN TRANSLATION MESSAGE FLOWS SUBMISSION & RESUBMISSION PROCESSING OVERVIEW BANK OF AMERICA MERCHANT SERVICES SUPPORTED TRANSACTIONS MESSAGE ELEMENTS BANK OF AMERICA MERCHANT SERVICES NETWORK RULES APPENDIX A BIT INFORMATION APPENDIX A BIT INFORMATION MESSAGE TYPE SECONDARY BIT MAP (BIT 1) PRIMARY ACCOUNT NUMBER (BIT 2) PROCESSING CODE (BIT 3) AMOUNT 1 (BIT 4) TRANSMISSION DATE AND TIME (BIT 7) SYSTEM TRACE AUDIT NUMBER (BIT 11) LOCAL TIME (BIT 12) LOCAL DATE (BIT 13) EXPIRATION DATE (BIT 14) MERCHANT TYPE (BIT 18) ACQUIRING INSTITUTION COUNTRY CODE (BIT 19) POS ENTRY MODE (BIT 22) POS CONDITION CODE (BIT 25) POS PIN CAPTURE CODE (BIT 26) TRANSACTION FEE AMOUNT (BIT 28) ACQUIRING INSTITUTION ID CODE (BIT 32) FORWARDING INSTITUTION ID (BIT 33) TRACK 2 DATA (BIT 35) RETRIEVAL REFERENCE NUMBER (BIT 37) AUTH ID RESPONSE (BIT 38) RESPONSE CODE (BIT 39) CARD ACCEPTOR TERM ID (BIT 41) CARD ACCEPTOR ID CODE (BIT 42) CARD ACCEPTOR NAME / LOCATION (BIT 43) ADDITIONAL RESPONSE DATA (BIT 44) TRACK 1 DATA (BIT 45) ADDITIONAL DATA PRIVATE (BIT 48) POS Check usage Version 4.02 Page 4 Last modified August 12, 2009

5 TRANSACTION CURRENCY CODE (BIT 49) PIN DATA (BIT 52) SECURITY-RELATED CONTROL INFORMATION (BIT 53) ADDITIONAL AMOUNT (BIT 54) EBT Transactions Credit Healthcare Auto-Substantiation Purchase Transactions Involving Partial Authorization Debit and Credit Balance Inquiries Debit and Credit Financial Transactions EM AND CHIP DATA (BIT 55) NATIONAL POS GEOGRAPHIC DATA (BIT 59) ADDITIONAL POS INFORMATION (BIT 60) OTHER TRANSACTION AMOUNT (BIT 61.1) PAYMENT SERVICE FIELDS (BIT 62) PRIVATE-USE FIELD (BIT 63) TERTIARY BIT MAP (BIT 65) SETTLEMENT CODE (BIT 66) NETWORK MANAGEMENT INFORMATION CODE (BIT 70) CREDITS, NUMBER (BIT 74) CREDITS, REVERSAL NUMBER (BIT 75) DEBITS, NUMBER (BIT 76) DEBITS, REVERSAL NUMBER (BIT 77) CREDITS, AMOUNT (BIT 86) CREDITS, REVERSAL AMOUNT (BIT 87) DEBITS, AMOUNT (BIT 88) DEBITS, REVERSAL AMOUNT (BIT 89) ORIGINAL DATA ELEMENTS (BIT 90) REPLACEMENT AMOUNTS (BIT 95) MESSAGE SECURITY CODE (BIT 96) AMOUNT, NET SETTLEMENT (BIT 97) SETTLEMENT INSTITUTION ID CODE (BIT 99) RECEIVING INSTITUTION ID CODE (BIT 100) ACCOUNT ID 1 (BIT 102) TRANSACTION DESCRIPTION (BIT 104) DOUBLE-LENGTH DES KEY (BIT 105) ADDITIONAL PRIVATE DATA (BIT 111) TRANSPORT DATA (BIT 114) INTERCHANGE REFERENCE NUMBER (BIT 115) ADDRESS VERIFICATION DATA (BIT 123) SUPPORTING INFORMATION (BIT 125) Unformatted or parsed MICR data for POS Check transactions (usage 9) VISA PRIVATE USE FIELDS (BIT 126) PRIVATE USE DUKPT (BIT 127) NTIA COUPON DATA (BIT 163) LARGE PRIVATE DATA 1 (BIT 164) LARGE PRIVATE DATA 2 (BIT 165) LARGE PRIVATE DATA 3 (BIT 166) LARGE PRIVATE DATA 4 (BIT 167) ACQUIRER TRACE DATA (BIT 168) PAYEE PHONE (BIT 169) PRIVATE USE CARD ACCEPTOR STREET ADDRESS (BIT 170) PRIVATE USE GENERAL (BIT 171) POINT OF SERVICE DATA CODE (BIT 172) SETTLEMENT DATA (BIT 173) SUPPLEMENTAL DATA (BIT 177) PROMOTIONAL PROGRAM DATA (BIT 178) Version 4.02 Page 5 Last modified August 12, 2009

6 MESSAGING DATA (BIT 179) APPENDIX B KEY CHANGE MESSAGE OVERVIEW APPENDIX C PROTOCOLS SUPPORTED APPENDIX D TLV-FORMAT PROCESSING APPENDIX E CHANGES TO THIS VERSION OF THE SPECIFICATION Version 4.02 Page 6 Last modified August 12, 2009

7 This document contains information that is proprietary to Bank of America Merchant Services. This document may not be duplicated, used, or disclosed by the recipient for a purpose other than to evaluate the specifications described herein for the explicit purposeof transmitting authorizations to Bank of America Merchant Services MultiLink. The recipient must obtain written approval from Bank of America Merchant Services before disclosing the contents of this document to any third parties. Version 4.02 Page 7 Last modified August 12, 2009

8 Overview Bank of America Merchant Services is pleased to introduce you to the Bank of America Merchant Services MultiLink Authorization System. Bank of America Merchant Services MultiLink has been developed in the same quality fashion as Bank of America Merchant Services s entire family of products. Bank of America Merchant Services MultiLink authorization processing along with Bank of America Merchant Services s time-tested acquirer processing provides merchants with a complete Debit card, Credit card, EBT (Electronic Benefits), Check Acceptance and POS Check solution. This message specification outlines the requirements for Debit, Credit and EBT, Check Acceptance and POS Check authorization through the Bank of America Merchant Services MultiLink System. Several items will be covered: definitions of transaction types and how they are used, the Bank of America Merchant Services MultiLink format for synchronous communication, message types, message flows and data elements (bits), and appendices which give further details about the message types, individual fields and supported protocols. This manual makes use of the Microsoft Word Hyperlink feature to help you find information. If you are viewing an electronic copy of the manual with standard Word options set, hyperlinked data will appear underlined and in blue. Clicking on the hyperlinked text will take you to an area in the manual that will provide more information about the data. Also, the page numbers in the table of contents can be clicked on to go directly to that page (although the table of contents function of Word does not show these numbers in blue or underlined). If you have clicked on a hyperlink to take you to a particular place in the manual, you can return to where you came from by holding down the alt key and pressing the left-arrow key. If you are using a paper copy of the manual, data for which you can find additional information elsewhere will generally appear as underlined text. The most common use of this feature is the various bits in the detail message formats that are hyperlinked to Appendix A. Notice Bank of America Merchant Services reserves the right to make changes to specifications at any time and without notice. The information furnished in this publication is believed to be accurate and reliable; however, no responsibility is assumed by Bank of America Merchant Services for its use. See Appendix E for specific changes made to this version of the specification. Version 4.02 Page 8 Last modified August 12, 2009

9 1.0 Transactions Supported 1.1 Debit Transactions Debit Purchase The Purchase (or Sale) transaction is the most basic and common transaction, used for the purchase of goods or services. In a Purchase, the authorizing agent s system compares the cardholder s funds availability to the amount specified in the transaction. If the amount is available, the card issuer transmits an approval message to Bank of America Merchant Services. Bank of America Merchant Services sends the approval message to the point of sale (POS) device. If the amount is not available, Bank of America Merchant Services forwards the denial response from the card issuer to the merchant host. Bank of America Merchant Services also transmits error messages, time-outs or invalid PIN messages when received from the card issuer. These messages are relayed in the form of a two position response code. These response codes are listed in detail in Appendix A. This is a mandatory Debit transaction. Debit Purchase with Cash Back The Debit Purchase with Cash Back transaction allows a cardholder to purchase goods and receive cash through a single debit transaction. If a merchant chooses to offer this option, the merchant must prompt the cardholder for the desired cash back amount and allow the cardholder to verify the total amount being debited from their account. The cash back amount must be included in the transaction amount being approved and stored separately in an additional amount field per debit network regulations. This is an optional Debit transaction. Debit Preauthorized Purchase and Completion The Preauthorized Purchase transaction allows retailers to put a hold on a customer s funds for a specified amount that is preset by the merchant s POS. The Preauthorized Purchase Completion transaction completes the transaction for which funds have previously been placed on hold. The completion amount specified can be any amount up to that specified in the approved preauthorization. The preauthorization holds the funds; the completion is the act of removing the funds up to the preauthorization amount from the customer's account. This is an optional Debit transaction, but if the merchant chooses to support the transaction, all conditions listed above must be met. Debit Preauthorized Purchase and Completion with Cash Back The Debit Preauthorized Purchase and Completion with Cash Back transaction allows a cardholder to purchase goods and receive cash back. If a merchant chooses to offer this option, the merchant must prompt the cardholder for the desired cash back amount and allow the cardholder to verify the total amount being debited from their account. The cash back amount must be included in the transaction amount being approved and stored separately in an additional amount field per debit network regulations. This is an optional Debit transaction, but if the merchant chooses to support the transaction, all conditions listed above must be met. Debit Return By entering a return transaction the merchant electronically refunds the cardholder s debit account. It would be used, for example, when a customer returns merchandise or if a Purchase transaction was completed in error. Debit card returns must be performed on-line and requires the entry of the cardholder PIN. Note: Not all networks allow this type of transaction. Please contact your Bank of America Merchant Services Relationship Manager for specifics. This is an optional Debit transaction. Debit Balance Inquiry The issuer has the option of returning multiple balances in the balance inquiry transaction (e.g. current ledger and/or available balances for checking, savings, etc.). It is entirely up to the issuer as to what and how many balances are returned. There type of balance and account are indicated in the response message. Version 4.02 Page 9 Last modified August 12, 2009

10 Debit Bill Payment The Debit Bill Payment transaction is a 3 rd -party payment, such as a utility or other bill. This transaction is unique among debit transactions in that it does not include a PIN. It is always a manual entry transaction (either VRU or Internet). There are several fields that are required for Debit Bill Payment that are not used for other Debit transactions. This is an optional Debit transaction and is only available by prior arrangement with your Bank of America Merchant Services representative. Debit Reversal Debit Purchase Debit Purchase with Cash Back Debit Preauthorized Purchase Debit Preauthorized Purchase with Cash Back Debit Preauthorized Completion Debit Preauthorized Completion with Cash Back Debit Return Debit Bill Payment System or communication reversals are generated due to a problem in successfully delivering the response to the merchant host, either because of a device or line problem or a late or missing response from the back-end authorizer. Debit card reversal requests are immediately switched back to the issuer. A debit purchase transaction immediately followed by a successful debit reversal should have no net financial effect on the cardholder account. This is a mandatory Debit transaction. Version 4.02 Page 10 Last modified August 12, 2009

11 1.2 EBT Transactions EBT Food Stamp Purchase In a food stamp purchase transaction, the cardholder presents his state-issued electronic benefits card for the eligible purchase of merchandise. The merchant swipes (or key enters) the card and the cardholder enters his PIN number. The transaction is switched through the Bank of America Merchant Services MultiLink network to the EBT provider processor. The EBT provider processor makes the approval/decline decision and forwards the response back to Bank of America Merchant Services. The Bank of America Merchant Services MultiLink system in turn sends the response to the merchant host. The balance remaining on the account may be present in the response message and printed on the cardholder receipt for approved transactions. This is a mandatory EBT transaction. EBT Food Stamp Return By entering a food stamp return transaction the merchant electronically refunds the cardholder s EBT account. It would be used, for example, when a customer returns merchandise or if a Purchase transaction was completed in error. Food Stamp returns must be performed on-line and the original card must be present to complete this transaction. This transaction requires the entry of the cardholder s PIN number. This is a mandatory EBT transaction. EBT Food Stamp Electronic Voucher If an EBT card is presented for a purchase and the merchant host is temporarily unable to connect with the EBT network, a voice approval may be obtained. Some states require that the manual draft be mailed in, while others require that the transaction be sent electronically (similar to a credit card force transaction, however, it will dial out to the EBT network.) This transaction is mandatory if a voice approval is obtained. Please contact your Bank of America Merchant Services Relationship Manager for details on states' requirements. EBT Cash Benefit Purchase This transaction operates in the same manner as the EBT Food Stamp Purchase, however, the cardholder has less restrictions on the merchandise purchased. This is a mandatory EBT transaction. EBT Cash Benefit Purchase with Cash Back This transaction operates in the same manner as the EBT Cash Benefit Purchase, however, the cardholder may purchase goods and receive cash through a single transaction. The cash back option must be prompted on each transaction, similar to debit. In the message to the Bank of America Merchant Services MultiLink system, the cash back amount must be segregated from the merchandise amount. This is a mandatory EBT transaction. EBT Cash Benefit Cash Withdrawal This transaction operates in the same manner as the EBT Cash Benefit Purchase, except that no goods are purchased. This is an optional EBT transaction. EBT Food Stamp Balance Inquiry The EBT Food Stamp Balance Inquiry transaction allows the cardholder to request information on the amount of funds available in the account that funds the EBT card. This is an optional EBT transaction. EBT Cash Benefit Balance Inquiry The EBT Cash Benefit Balance Inquiry transaction allows the cardholder to request information on the amount of funds available in the account that funds the EBT card. This is an optional EBT transaction. Version 4.02 Page 11 Last modified August 12, 2009

12 EBT Reversal EBT Food Stamp Purchase EBT Food Stamp Return EBT Cash Benefit Purchase EBT Cash Benefit Purchase with Cash Back EBT Cash Benefit Cash Withdrawal System or communication reversals are generated due to problems in successfully delivering the response to the merchant host, either because of a device or line problem or a late or missing response from the back-end authorizer. EBT reversal requests are immediately switched back through the EBT network. An EBT transaction immediately followed by a successful EBT system reversal should have no net financial effect on the cardholder account. This is a mandatory EBT transaction. Version 4.02 Page 12 Last modified August 12, 2009

13 1.3 Credit Transactions Credit Purchase The Purchase (or Sale) transaction is the most basic and common transaction, used for the purchase of goods or services. In a Purchase, the authorizing agent s system compares the cardholder s remaining credit limit to the amount specified in the transaction. If the amount is available, the card issuer transmits an approval message to Bank of America Merchant Services. Bank of America Merchant Services sends the approval message to the point of sale (POS) device. If the amount is not available, Bank of America Merchant Services forwards the denial response from the card issuer to the merchant host. Bank of America Merchant Services also transmits error messages or time-outs when received from the card issuer. These messages are relayed in the form of a twoposition response code. These response codes are listed in detail in Appendix A. This is a mandatory Credit transaction. Credit Purchase with Cash Back The Credit Purchase with Cash Back transaction allows a cardholder to purchase goods and receive cash through a single credit transaction. If a merchant chooses to offer this option, the merchant must prompt the cardholder for the desired cash back amount and allow the cardholder to verify the total amount being debited from their account. The cash back amount must be included in the transaction amount being approved and stored separately in an additional amount field per credit network regulations. This is an optional Credit transaction. Credit Merchandise Return The Merchandise Return transaction is a standalone transaction resulting from the return of merchandise to the point of purchase. The net result of a completed Merchandise Return will be to increase the customer s available credit by the amount of the return (after settlement). It should not be confused with a reversal, which is generated as a result of an inability to generate a timely approval or an immediate cancellation of the transaction at the merchant host. See below for a description of reversal transactions. This is a mandatory Credit transaction. Credit Card Verification The Card Verification transaction gives the merchant a means of verifying the validity of a card without performing a financial transaction. This is an optional Credit transaction. Credit Balance Inquiry The issuer has the option of returning multiple balances in the balance inquiry transaction (typically, credit amount available to customer open to buy and credit limit). It is entirely up to the issuer as to what and how many balances are returned. The type of balance is indicated in the response message. Credit Advice The Credit Advice transaction allows merchants utilizing Bank of America Merchant Services 's Host Capture product to submit transactions for settlement that have been authorized via another means other than MultiLink. These offline transactions were performed either by voice authorization or through an alternative authorization platform. No further authorization processing is performed on Credit Advice transactions. This is an optional Credit transaction. Credit Bill Payment The Credit Bill Payment transaction is a 3 rd -party payment, such as a utility or other bill. It is always a manual entry transaction (either VRU or Internet). There are several fields that are required for Credit Bill Payment that are not used for other Credit transactions. This is an optional Credit transaction and is only available by prior arrangement with your Bank of America Merchant Services representative. Version 4.02 Page 13 Last modified August 12, 2009

14 Credit Healthcare Auto-Substantiation Auto-Substantiation is the real-time process of verifying that purchase transactions are for expenses permitted and eligible under IRS regulations for Flexible Spending Accounts (FSA) and Health Reimbursement Arrangements (HRA). It provides a cost effective way of substantiating purchases of over-the-counter (OTC) qualified healthcare products made with FSA/HRA cards, improving efficiency for benefit administrators and reducing requests for paper documentation. The Healthcare Auto-Substantiation Transaction permits employers and their third-party benefit administrators to approve qualified healthcare expenses at the time of purchase at participating merchants. Auto- Substantiation is supported for Purchase, Merchandise Return and Reversal transactions. Additional fields needed for Auto-substantiation are included within the Credit Purchase, Credit Merchandise Return and Credit Reversal message format sections. Use of these transactions requires prior arrangement with your Bank of America Merchant Services representative. Credit Reversal Credit Purchase Credit Merchandise Return Credit Bill Payment System or communication reversals are generated due to problems in successfully delivering the response to the merchant host, either because of a device or line problem or a late or missing response from the back-end authorizer. Credit reversal requests are immediately switched back through the Credit network. A Credit transaction immediately followed by a successful Credit system reversal should have no net financial effect on the cardholder account. A reversal of a partially-authorized Credit transaction is mandatory, but all other Credit reversals are optional transactions. Version 4.02 Page 14 Last modified August 12, 2009

15 Check Transactions Check Acceptance Bank of America Merchant Services s MultiLink processing platform supports a form of check verification and guarantee called check acceptance. When a merchant receives payment in the form of a check, the checking account number and the transaction amount, along with some customer identification information, is passed to the MultiLink platform for authorization. The information is reformatted and passed to the appropriate check acceptance vendor for authorization and the response is sent back to the merchant. POS Check The VISA POS Check Service offers merchants the ability to accept consumer and business checks as source documents and convert the paper checks to electronic transactions at the point of sale, and from mail, telephone or electronic commerce merchants. When a customer pays for a purchase with a paper check, the sales clerk informs the customer that the check is being used as a source document to convert it to an electronic transaction by passing the check through a check reader. It captures checking account information from the Magnetic Ink Character Recognition (MICR) line of data encoded on a customer s check. The service offers three options for converting checks at the point of sale: Conversion only, in which the authorization request is routed to the participating drawee financial institution or a third-party authorizing agent, which approves or declines the transaction by checking the status of the account. The merchant retains the risk of loss. Verification with conversion, in which the authorization request is routed to the participating drawee financial institution or a third-party authorizing agent for verification of the probability that the transaction will be paid by the customer. The participating drawee financial institution makes an approval or decline decision based on access to the demand deposit account and information on funds availability at the time of the request. The third-party authorizing agent makes an approval or decline decision based on its risk management database. The merchant retains the risk of loss. Guarantee with conversion, in which the authorization request is routed to the participating drawee financial institution or a third-party authorizing agent to guarantee the transaction. If the transaction is approved, the risk of loss is transferred to the participating drawee financial institution or third-party authorizing agent, provided all merchant acceptance criteria have been met. The guarantor bears the risk of loss. The VISA POS Check Service is a separate service with different message formats and processing requirements from the Check Acceptance, service described previously. Informaton in this manual will be specifically referenced by check acceptance or POS Check to differentiate between the services. Please contact your Bank of America Merchant Services representative for more information on either of these services. Version 4.02 Page 15 Last modified August 12, 2009

16 1.4 Settlement Transactions Settlement Request/Response The Settlement Request transaction is an optional transaction that the merchant may send to indicate that end-ofday has occurred for a store or for their system. This transaction may be used in conjunction with Bank of America Merchant Services s fixed end-of-day processing time or it may replace that time. The merchant may choose to send end-of-day transaction totals in the Settlement Request. The Settlement Request transaction is acknowledged by a Settlement Response transaction from Bank of America Merchant Services. The Settlement Response transaction echoes any totals sent by the Settlement Request transaction back to the merchant. Use of these transactions requires special arrangement with Bank of America Merchant Services. Contact your account representative for more information about the use of this transaction. Version 4.02 Page 16 Last modified August 12, 2009

17 1.6 Network Management Network management processing aids in ensuring that maximum connectivity is maintained between all network end points. Network management is an essential function, allowing the network to quickly identify and resolve communication problems as they may arise. Bank of America Merchant Services supports the following Network Management messages: Key Change Echotest Logon Logoff Network Management Dynamic Key Exchange Messages If the merchant chooses to utilize Dynamic Key Exchange, there are several options for initiating the key exchange and more than one option may be utilized. Bank of America Merchant Services can send a new PIN Encryption key after a LOGON message has been processed, after a specified number of minutes/hours/days has elapsed and/or via an operator command. The merchant can request a new PIN encryption key at any time. If the merchant initiates the request, a Network Management Dynamic Key Exchange Request message is sent by the merchant to request a new PIN Encryption Key. This message is acknowledged by Bank of America Merchant Services with a Network Management Dynamic Key Exchange Request Response message, followed by a Network Management Dynamic Key Exchange message containing the new key. The merchant acknowledges receipt of the key with a Network Management Dynamic Key Exchange Response message. If the key exchange is initiated by Bank of America Merchant Services (either at logon, by timer or operator command), Bank of America Merchant Services will send the Network Management Dynamic Key Exchange message and the merchant will acknowledge receipt of the key with a Network Management Dynamic Key Exchange Response message. Please refer to the Network Management Formats section (Section 4.0) for further information on the message details, Appendix A Bit Information for specific field values and Appendix B Key Change Message Overview for additional information. Network Management Health Message ( ECHOTEST ) The Network Management Health message or echotest is sent by Bank of America Merchant Services and is answered by the merchant to determine connectivity status. The receipt of a response validates that the connection is still active and the lack of traffic is not the result of a communication problem. At the merchant s option, the merchant may also send a Network Management Health message and have it answered by Bank of America Merchant Services. Bit 070, the Network Management Information identifies which type of task is required. Please refer to Appendix A Bit Information for further information on the values which may be sent in this bit. The Bank of America Merchant Services-initiated Health message and merchant response is a mandatory transaction. Network Management LOGON Message The Network Management Logon message is sent by either Bank of America Merchant Services or the merchant to indicate the beginning of transaction processing. Functionally, a logon message is identical to an echo test message. The receipt of a response validates that the connection is active and processing of traffic is ready to commence. Bit 070, the Network Management Information identifies which type of task is being requested. Please refer to Appendix A Bit Information for further information on the values which may be sent in this bit. The Bank of America Merchant Services-initiated Logon message and merchant response is a mandatory transaction. Version 4.02 Page 17 Last modified August 12, 2009

18 Network Management LOGOFF Message The Network Management Logoff message is sent by either Bank of America Merchant Services or the merchant to indicate that transaction processing is ending or being suspended. Typically a Logoff message is sent when the network or merchant plan on stopping their applications for any reason. This reduces unnecessary concerns over communication issues arising as a result of the application not being available. The receipt of a response validates that the processing of traffic is suspended. Bank of America Merchant Services will decline transaction traffic received when the merchant is not logged onto the network. Bit 070, the Network Management Information identifies which type of task is being requested. Please refer to Appendix A Bit Information for further information on the values that may be sent in this bit. The Bank of America Merchant Services-initiated Logoff message and merchant response is a mandatory transaction. Version 4.02 Page 18 Last modified August 12, 2009

19 1.7 Contactless Payment Program General Description: Bank of America Merchant Services is pleased to provide support for contactless payment (also referred to as RFID or proximity payments). This method of payment is one where a wireless technology is used to transmit data from the payment device (usually a chip card) to a contactless payment terminal. There are two forms of transmission from the payment device one that processes Track2 data that is normally retrieved from the magnetic stripe (magnetic stripe data rules), and one that supports an enhanced process that utilizes the computer embedded on the chip card to improve the security of the transaction (chip data rules). This initial implementation will support the magnetic stripe data rules where Track2 data is processed. Future implementations will support the chip data rules (i.e. Visa Smart Debit Visa Smart Credit (VSDC) cards). Contactless payments support both credit or debit transactions. A standard Multilink message is utilized to support the payment with some minor modifications. Modifications to support contactless payment: First and foremost, new POS entry mode values are required. Two new values are supported 91 and 07. (The value 07 is reserved for use with the enhanced smart cards and is not part of this initial implementation.) The values of the POS entry mode have the following meanings: 07 - Contactless chip transaction using chip data rules; 91 - Contactless transaction originated using magnetic stripe data rules; CVV or dcvv check is possible. A complete Track2 must be sent on the transaction in field 35. A contactless payment transaction utilizes a dynamic Track2. It includes issuer discretionary data (IDD) and an account transaction counter (ATC). The payment device may also generate a dynamic card verification value (dcvv) that is included in the Track2 data. This data must be provided on the authorization request in its entirety and without modification. The contactless payment device generates the dcvv by using a Unique Derived Key (UDK) which was generated by using the account number (PAN) and the PAN sequence number along with a unique cryptographic key embedded on the chip. This method provides a different key for calculating the dcvv for each transaction, enhancing the security of the card. The merchant must identify that a terminal is capable of processing contactless payments even if the payment from a contactless payment device is processed using a magnetic stripe read. This is indicated by entering a value of 8 in Terminal Entry Capability (Bit 60.2). Supported transactions: Contactless payment is supported in credit authorizations (0100), advices (0120) and reversals (0400). It is also supported in debit preauthorizations (0100), original financial requests (0200), purchase with cash back (0200), balance inquiry (0200), preauthorization completions (0220), and authorization reversals (0400). Changes to the Response Message: The issuer is responsible for verifying the dcvv in a transaction where the Track2 data contains the contactless indicator. CVV results code (Bit 44.5) will contain a 2 (passed) if the dcvv is correct. This field will contain a 1 (failed) if the dcvv does not pass. The response code (Bit 39) for a failure to authenticate dcvv is a general decline (05). Version 4.02 Page 19 Last modified August 12, 2009

20 1.8 PIN Translation Transactions PIN Translation transactions provide the ability for the merchant to have the transaction s PIN block encrypted under the merchant s standard key translated by Bank of America Merchant Services to encryption under a different key and returned to the merchant. No authorization is performed when using this transaction. Please contact your Bank of America Merchant Services representative for more information on this service. Version 4.02 Page 20 Last modified August 12, 2009

21 1.9 Test Transactions The test transaction is a facility by which the merchant can initiate a transaction that will validate the capabilities of a card. Although the amount field is set to $1.00, this is a non-financial transaction that will have no settlement impact. The only currently-supported implementation of the test transaction is the MasterCard recurring payment test transaction. An approved recurring payment test transaction response indicates that the card is capable of accepting recurring payments. Version 4.02 Page 21 Last modified August 12, 2009

22 1.10 Real Time Clearing Transactions Real Time Clearing is a signature-based processing model to support the unique needs of fuel merchants, designed to enhance the consumer and merchant experience at Automated Fuel Dispensers. This product will potentially reduce chargebacks and increase average purchase amounts through lower incidence of pump shut-offs. It provides extended chargeback protection and interchange qualification for fuel transactions. Transactions supported under this service are: Real Time Clearing Purchase (in-store at fuel merchant) Real Time Clearing Merchandise Return Real Time clearing Preauthorization and Completion Real Time Clearing Reversal for each transaction listed above Merchants will indicate their desire to have a particular transaction processed as real time clearing by setting a field in the request message. If the transaction is eligible for real time clearing, Bank of America Merchant Services will indicate this with an entry in the same field, as well as indicating the entity (VISA, etc. that performed the real time clearing). If the transaction is not eligible for real time clearing, this will also be indicated in the response. Note: Not all authorizers support real time clearing at this time. If Bank of America Merchant Services indicates in the response that a transaction is not eligible for real time clearing, then the merchant must include this transaction in their offsite settlement file (if they do not participate in Bank of America s Host Draft Capture program). Version 4.02 Page 22 Last modified August 12, 2009

23 2.0 Messages Formats (GENERAL) Bank of America Merchant Services MultiLink supports Bank of America Merchant Services s bit-mapped message format for all messages. This message format maximizes efficiency of transaction data by the use of bit mapping. The bit map or maps define the presence of data fields within a message. Data fields not applicable to a particular transaction are simply not sent and their corresponding bit in the bit map is turned off (set to zero). There is no need to delimit the fields not present with a string of field separators. The fields within a message may be fixed or variable in length. If fixed, numeric fields must be right-justified, zero-filled and alphanumeric fields leftjustified and space-filled, unless specifically noted. If variable, the length of the field is defined by a length field before the data field itself.. All fields are designated in the tables below as req (required for this message), cond (conditional may be required, depending on the specifics of the transaction. See details in the description column and/or in Appendix A), opt (optional may be sent at the discretion of the merchant or if available. See details in the description column and/or in Appendix A) or N/A (not applicable Not currently used, but included in this document so that merchant processors can at least code for the length of the field, should it ever be present). IMPORTANT: Not all fields defined in the tables below are in current use. However, it is very important that merchant processors be capable of receiving all listed fields in any message sent by Bank of America Merchant Services. Bank of America Merchant Services MultiLink messages use the EBCDIC character set. 2.1 Bit Maps This message format utilizes bit maps to define which data fields are present in a message. If a bit is set to on, the data element corresponding to that bit number is present in the message. If a bit is set to off, the data element corresponding to that bit number is not present in the message. Bit maps are made up of 64 binary characters, with a 0 indicating the bit is off and a 1 indicating the bit is on. For example, if the first 8 bits, depicted in binary, of the bit map are , this signifies that bits, 1,5,6 and 8 are present and bits 2,3,4 and 7 are not utilized. Bank of America Merchant Services MultiLink utilizes primary, secondary and tertiary bit maps. The primary bit map represents data fields 2 through 64. The secondary bit map represents bits 66 through 128. The tertiary bit map represents bits 130 through 192. Data fields 1, 65 and 129 can not exist, as these bits are used to indicate presence of subsequent bit maps. In the message formats below, the secondary bit map is listed as bit number 001, since its presence is indicated by bit 1. The tertiary bit map is listed as bit number 065, since its presence is indicated by bit 65 (bit 1 of the secondary bit map). The secondary bit map is only required if data elements represented by bits 66 through 128 or the tertiary bit map are to be used in a particular message. Likewise, the tertiary bit map is only required if data elements represented by bits 130 through 192 are to be used in a particular message. Bit 1 of the primary bit map indicates the presence or absence of the secondary bit map. Bit 1 of the secondary bit map indicates the presence or absence of the tertiary bit map. Bit 1 of the tertiary bit map indicates the presence or absence of the (currently unused) quaternary bit map. Version 4.02 Page 23 Last modified August 12, 2009

24 2.2 Message Header All messages are made up of two parts: the header and the actual message (unique format and variable length for each message type). The header does not have a bit map associated with it, as all fields are required. The only exception to this is the case of a rejected message, which will contain two additional fields in the header. See Section 2.5 (Header Format) and Section 5 (Rejected Messages) for details on rejected messages. 2.3 Numeric Packed Data In order to minimize the size of transmitted messages, some numeric fields are designated as Numeric Packed (also referred to as Binary d Decimal). This technique consists of using 4 bits for each numeric character or hex character A through F (as field separator). Odd-length fields are padded with a leading zero. For example, the numeric field 1234 would be represented in Numeric Packed format as %H12 34 (binary ), 678 would be represented as %H06 78 (binary ), while 23F1 would be represented as %H23 F1 (binary ). Version 4.02 Page 24 Last modified August 12, 2009

25 2.4 Guide to Transaction Attributes and Formats Attribute Description Explanation Anx Alpha-numeric (x indicates number of bytes). Nx Numeric (x indicates number of bytes) NPx Numeric packed (Binary d Decimal) (x indicates number of characters, not bytes). An odd number will be padded with a leading zero. NSx Numeric with special characters (x indicates number of bytes) ANSx Alpha-numeric with special characters (x indicates number of bytes) Bx Binary (x indicates number of bytes) TLV(xy)zzz Tag-Length-Value format. (x indicates length of each tag, y indicates length of each each tag length field and z indicates the total number of bytes). Note there are also some non-standard TLV-format fields supported. These are indicated by TLV(**)zzz. See individual field descriptions in Appendix A for more information. Format Description Fixed LLVAR LLLVAR BBVAR BBBVAR Explanation Fixed length field. Variable length field where the maximum size of the field is 255 characters and LL represents a one-byte binary field indicating the length of the data to follow, expressed as the number of characters. If a field contains subfields, regardless of the attributes of each subfield, the length is instead expressed as the number of bytes. Variable length bit where the maximum size of the field is 999 characters and LLL represents a two-byte binary field indicating the length of the data to follow, expressed as the number of characters. If a field contains subfields, regardless of the attributes of each subfield, the length is instead expressed as the number of bytes. Variable length field where the maximum size of the field is 255 characters and BB represents a one-byte binary field indicating the length of the data to follow, expressed as the number of bytes. Variable length field where the maximum size of the field is 999 characters and BBB represents a two-byte binary field indicating the length of the data to follow, expressed as the number of bytes. Version 4.02 Page 25 Last modified August 12, 2009

26 Notes: NPx (numeric packed) fields with an odd length (e.g. NP3) will be padded with a leading zero. For example, an NP3 field with a value of 246 would be represented as hexadecimal NPx (numeric packed) fields of variable length with length expressed as number of characters (format LLVAR or LLLVAR) will have the length field containing the actual number of packed characters. In the case of an odd actual number of characters, the length field will contain this odd number (it will not include the leading zero in the count). Version 4.02 Page 26 Last modified August 12, 2009

27 2.5 Header Format All messages begin with a fixed-length and fixed-format header, as follows: Field Data Element Description Format Attr Presence Number Name 1 Header Length Specifies the number of bytes in this header. Fixed B1 Req Value: 16 (hex) for normal messages; 1A (hex) for rejected messages. See Section 5 for details on rejected messages. 2 Header Flag Specifies the presence or absence of a Fixed B1 Req and Format message header following this header, and the format of this message header, if present. Value: 1 (hex) if no header following this header; 81 (hex) if another header following this one (indicates a rejected message). 3 Text Format Specifies message data field format. Value: 2 Fixed B1 Req 4 Total Message Length 5 Destination Station ID 6 Source Station ID 7 Round Trip Control Information (hex). Specifies the total length of this message in bytes, from the start of the header to the end of the message. The station number to which this message is routed. Must be a defined station number on the Bank of America Merchant Services network. The station number used to send this message (generally, the same as header field 5). Must be a defined station number on the Bank of America Merchant Services network. Fixed B2 Req Fixed NP6 Req Fixed NP6 Req Reserved. Value: 0 (hex). Fixed B1 Req 8 BASE I Flags Reserved. Value: 0 (hex). Fixed B2 Req 9 Message Used to control processing of message. Fixed B3 Req Status Flags Value: 0 (hex). 10 Batch Number Reserved. Value: 0 (hex). Fixed B1 Req 11 Reserved Reserved. Value: 0 (hex). Fixed B3 Req 12 User Information A value defined by the acquirer that can be used as needed to facilitate processing. Fixed B1 Req Value: 0 (hex). 13 Bit Map Only present in rejected messages. The high-order bit will be = 1, indicating the presence of field 14. See Section 6 for details on rejected messages. 14 Bit Map Reject Data Group Only present in rejected messages. Contains a 4-digit reject code. See Section 6 for details on rejected messages and valid reject codes. Fixed B2 Cond Fixed B2 Cond Version 4.02 Page 27 Last modified August 12, 2009

28 3.0 Debit, Credit, EBT and Check Message Formats 3.1 Debit and EBT Request Message Debit Purchase Debit Purchase with Cash Back Debit Return Debit Balance Inquiry EBT Food Stamp Purchase EBT Cash Benefit Purchase EBT Cash Benefit Purchase with Cash Back EBT Cash Benefit Cash Withdrawal EBT Food Stamp Return EBT Food Stamp Balance Inquiry EBT Cash Benefit Balance Inquiry EBT Food Stamp Electronic Voucher This message is used to send a request message from the POS to Bank of America Merchant Services MultiLink for a Debit, EBT Food Stamp or EBT Cash Benefit transaction. The Debit and EBT Cash Benefit transactions may be with or without cash back. The Processing field (bit 3) differentiates the transaction type. The chart below describes: Bit Numbers and Names of all possible data elements for this message If constant, the value to be placed in the field A description of how each data element is used The format and attributes of each data element Required, Optional, Conditional or Not Applicable status of each data element Bit Number Data Element Name Message Type Description Format Attr Presence Value to represent the type of message Value: See Appendix A. Fixed NP4 Req Represents the presence of secondary bit Fixed B8 Req map and data elements in bits 2 through 64. Represents the presence of tertiary bit map Fixed B8 Cond and data elements in bits 66 through 128. Represents the presence of data elements in Fixed B8 Cond bits 130 through 192. Contains the cardholder account number. LLVAR NP19 Req Primary Bit Map 001 Secondary Bit Map 065 Tertiary Bit Map 002 Primary Account Number 003 Processing Defines the type of transaction. See Appendix A. 004 Amount 1 Transaction Amount. Assumes a 2 position decimal, right-justified, zero filled. This field contains the total amount including the purchase amount and cash back if indicated. Transactions settled through Bank of America Merchant Services s settlement system are limited to 7 characters ($99,999.99). Fixed NP6 Req Fixed NP12 Req Version 4.02 Page 28 Last modified August 12, 2009