7#!y rmrmsmsmsms{vvvv@v_wwwxvxQ xqx*xsm xxxxx=xxxxxx Direct Dial Credit Card Interface Specifications VISA PROTOCOL TERMINAL CAPTURE 28 July, 1994 Revision 2.9 First Data Corporation 301 Plus Park Boulevard Suite 500 Nashville TN 37217 (615) 316-1600 Note: The information contained in this document is considered proprietary to First Data Corporation. This document or any portion thereof may not be published, reproduced, copied, or disclosed without the express written permission of a duly authorized officer of First Data Corporation. TABLE OF CONTENTS INTRODUCTION Overview Payment Service Programs PS2000 and ICP CPS/94 Vendor Certification Procedures Vendor Support INTERFACE LEVEL PROTOCOL Communication Level Protocol Message Level Protocol Host Error Concept Terminal Identification Block Field Credit Card Authorizations Authorization Request Incremental Authorization Request Partial Reversal Credit Card Settlement Summary ID Request Summary ID Examples Credit Card Transaction Detail Credit Card Totals Request Telephone Tests Telephone Test Request COMMUNICATION SESSION SCENARIOS Single Transaction Multiple Transactions Errors Due to Non-verified LRC Timeout Errors Additional Error Scenarios PROCESSING STANDARDS Appendix A: Credit Card Validation Luhn MOD-10 Verification Card Type Identification Appendix B: LRC Calculation Appendix C: Sample Host Error Codes Appendix D: Extended Data Overview Examples Payment Service Data Authorization Settlement CPS/94 Data Auxiliary Data Overview Lodging Data Format Auto Rental Data Format Fleet Data Format Address Verification Service AVS Authorization AVS Settlement Appendix E: Online Check Approval Check Approval Request Check Approval ID Type Codes Section I: INTRODUCTION Overview This specification outlines the manner in which a POS device programmed and maintained by a party other than First Data may perform realtime authorization and draft capture services with the First Data system. The scenario to be supported using this specification is one where the terminal system may, at any time, initiate a dial session and execute one or more credit card authorizations through the First Data host. In the same or a separate dial session, at the terminal systems option, the First Data host may be requested to settle transactions captured at the terminal. In its request, the remote system provides transaction details, and count and amount totals to insure system integrity. If in balance with (the same as computed by) the First Data host system, the batch is closed. If not, the user would be asked to call their vendor support desk to initiate resolution procedures, and allow the corrected/reconciled batch to proceed to settlement. This specification is written to include all of the major national credit cards. Other cards supported in the First Data system, such as private label or debit cards, and check approval services may be supported with additional documentation provided where needed. First Data provides a certification service to all new POS software developers. The primary objective of the certification process is to provide the vendor with a high level of comfort by providing a means to test the implementation of the interface with First Data. The secondary objective of the certification process is to allow the vendor to become familiar with the manner in which First Datas host system processes transactions and, in turn, for First Data to become familiar with the vendors interface so that the highest level of help desk support can be offered to the POS system developer. First Data currently utilizes direct asynchronous dial-in on 950 and 800 toll-free service. It is strongly recommended that the vendor implement the capability, described within, to use telephone numbers provided by the First Data host. If this is impossible, the on-site personnel should be able to access and modify the primary and backup telephone numbers using clerk-proof and user friendly procedures. In either case, the system must be designed such that First Data customer support personnel or user management may contact specified user personnel, and request that they change the dialing procedures they are using. In addition, the system should provide a function to perform a telephone dialing test as specified later in this document. Note: Some of the information contained within this document may be subject to change without notice. When referencing this document at a later date, you are encouraged to verify that you have the most current version. Payment Service Programs This revision of the First Data interface incorporates the requirements necessary to comply with incentive Payment Service programs recently established by Visa and MasterCard, including Visas CPS requirements available August, 1994. In order to achieve the most favorable discount rates, the authorization and capture system must be able to reliably transport additional Payment Service data from card authorization responses to the eventual settlement. Visa CPS/Retail (PS2000) and MasterCard ICP In some cases (described below), the terminal system must take responsibility for transport of retail-type Payment Service data; in other cases the First Data host system will accomplish this requirement. In addition to this data requirement, transactions must have the following characteristics to qualify for retail Payment Service treatment: The authorization must be accomplished electronically either the same day, or the day before the transaction date. The card must be present at the point of sale and the authorization request must include full magnetic stripe image. A single authorization must support the settled transaction. Settlement must be timely in accordance with deadlines established by merchant bank. There are two distinct categories of terminal systems using this specification which have differing requirements in order to insure the highest level of retail Payment Service qualification: Realtime Authorization and Settlement Via This Specification: If the terminal system acquires its authorizations and accomplishes the resultant settlement via this specification, the system may employ the Authorization Request Message Type 964, but must maintain integrity with respect to the authorization codes returned in 965 response messages. If the First Data host can match the settlement transaction detail uniquely with this auth code and the card number to the record of the authorization that it performed earlier, the transactions will be retail Payment Service qualified to the extent that Visa or MasterCard allows. In some environments, however, batch strategies used by the POS system may not follow those employed by First Data in matching Payment Service data, requiring the POS system to take responsibility for all Payment Service data management. In this case, Authorization Request Message Type 954 should be used so Payment Service data will be included in the subsequent response message. The required Payment Service data can then be included with each transaction (Credit Card Transaction Detail Request 966) during settlement. See Appendix D for details. This change should only effect those POS systems currently packing Payment Service fields previously defined as numeric, or assuming values for the PS2000 response code, which will be replaced with two new single-byte, alpha-numeric data elements. Realtime Authorization Only Via This Specification: If the terminal system only acquires its authorizations via this dialup standard and settles the resultant transactions via another route (such as First Datas Batch Service or another processor), the POS system desiring to qualify for Payment Service must use the Authorization Request Message Type 954 and store the Payment Service data which it receives in the corresponding response. This data plus the original amount authorized must be included with that transactions settlement record by whatever technique is employed, according to the specifications and capabilities of that technique. CPS/Hotel - CPS/Auto Rental - CPS/Direct Marketing For those POS systems processing auto rental, lodging or mail order transactions, that wish to qualify for these new programs (CPS/94), management of Payment Service data is required. In addition, POS systems must support the following capabilities to qualify for CPS/94: Duration: (Hotel and Auto Rental) The first authorization related to an eventual transaction, regardless of whether the card is actually swiped or not, must include a Duration value, indicating the number of days until the transaction will be settled. Payment Service Data: This data must be stored and retrievable for later incremental authorizations, reversals, and eventual settlement. Incremental Authorizations: (Hotel and Auto Rental) Used to increase the total amount authorized from the original (or latest prior incremental) authorization. Must contain Payment Service data from original authorization response, as well as incremental amount and duration required. The POS system must retain both the original, and revised total, amounts authorized. Partial Reversals: Used to decrease the total amount thus far authorized. As with a Incremental Authorization, this transaction must contain Payment Service data from original authorization response, downward revised amount, as well as original, and revised total, amounts authorized. Settled Amount Tolerance: With Hotels and Card Rental program, the final amount must be within 15% of the total (or net) authorized amount. With CPS/Direct Marketing, the final amount must match the net amount authorized exactly to the penny. Address Verification: (Direct Marketing Only) The initial authorization must include address verification data. NOTE: Even though this program is initially being implemented only with Visa, the vendor should perform this logic regardless of credit card type, since MasterCard and others will likely follow suit in the near future. Vendor Certification Procedures Prior to the acceptance of live transactions from a Credit Card system, each POS system vendor will be asked to complete certification test procedures with First Data. To begin submitting test transactions, the vendor will first contact First Datas POS Certification Department to obtain test phone number(s) and terminal ids. At that time, any additional information or assistance the vendor may need to begin the certification process will be provided. All initial test transactions will come into a test system designed to test various aspects of the POS system interface. During all phases of testing, submissions will be trapped at the First Data test system (not forwarded to an end processor). Testing and certification stages are as follows: Phase I: testing will consist of initial testing at the vendors control, during which basic communication protocols and formats are debugged; up through and including consistent send and receive of standard authorization requests and responses. Phase II: testing will consist of a series of communication protocol tests, under control of an First Data host certification specialist, in which both normal and error conditions will be present. Phase III: If draft capture is to be certified as part of the interface, settlement messages and error scenarios will be tested in Phase III. Phase IV: (Alpha) In this stage, test transmissions and settlements (if applicable) will be performed on a First Data production host: authorization requests will be live, posting against the cardholders credit limit. Settlements will be captured at the First Data host, but not forwarded to a settlement entity (financial institution), so no charges will ever be posted to the cardholders account. For those vendors attempting to qualify for CPS/94, additional scenarios related to card authorizer errors will be introduced; the POS vendor will be tested for proper error-handling procedures. Phase V: (Beta) Once alpha testing has been completed, the vendor will be released for live activity at the first merchant installations. During Beta, issues regarding setup and installation procedures will be finalized between the vendor and First Data. Once these phases have been completed, and Beta activities have been monitored to the satisfaction of the vendor, First Data, and any settlement entities (banks, Independent Sales Organizations, etc.) the POS System interface will be considered certified, and may install unlimited sites. Note: Pertinent issues regarding customer support, bank processing, and merchant support will have to be addressed before live installations can begin Beta testing. It is highly recommended that these issues be considered by the developer as soon as certification approaches completion; First Data cannot support any live installations until all such issues have been resolved. Vendor Support As a provider of POS software, the vendor must be responsible for direct support of that software, for any merchant locations. First Data, who provides network services, cannot provide first line support to merchants; First Data has no technical or operational knowledge of the installed software. Primary Support: The POS software vendor is responsible for primary support to all of their Merchants. Any technical support requested and/or required by a Merchant will be provided directly by the POS software vendor; First Data Customer Support is not responsible for direct support to any Merchant. Merchants contacting First Data Customer Support directly will be referred to the POS software vendor for support. Secondary Support: First Data Customer Support will provide technical support only to The POS software vendor, as secondary support to the Merchant. The POS software vendor will be provided with First Data Customer Support phone numbers; the POS software vendor is responsible for providing First Data Customer Support with The POS software vendor Support Desk phone numbers and availability information. Interface Monitoring: First Data reserves the exclusive right, in the case of excessive or reoccurring errors produced by interface violations, and/or excessive calls to First Data Customer Support, to: Limit any additional production setups (limited number of live Merchants.) 2. Bill the POS software vendor directly, based on a flat fee and/or a per call basis, for calls to First Data Customer Support. 3. If, after a specified period, reported problems persist, First Data reserves the exclusive right to revoke certification status, and desupport any production Merchant records from the First Data database (preventing any further on-line activity from the Merchant locations.) Re-certification must be completed before production Merchant locations can be re-activated. Section II: INTERFACE LEVEL PROTOCOL Communication Level Protocol Utilizing this interface, all communications with the First Data host are asynchronous, 300 or 1200 baud, seven-bit characters with even parity, one start bit, and one stop bit. All communications between the POS system and the First Data host operate around standard transmission control characters: Element Definition ENQ ASCII Inquiry character (Hex 05). Transmitted by the host after the initial connection has been established. Indicates the host is ready to receive a message from the POS system. The ENQ may be sent again, if the host does not receive or recognize that a message has been sent by the POS system. ACK ASCII Acknowledgment character (Hex 06). Used by either party to indicate that a message has been received successfully (LRC was verified). NAK ASCII Negative Acknowledgment character (Hex 15). Used by either party to indicate that a message received is thought to be in error: the receiver is unable to verify the LRC; encountered a character parity error; timed out waiting for all or any part of message In any case, the NAK is used to request a repeat transmission of the message. STX ASCII Start of Text character (Hex 02). Indicates the start of the message. ETX ASCII End of Text character (Hex 03). Indicates the end of a message; always followed by the LRC. LRC Longitudinal Redundancy Check character (ISO 1155). Parity check character calculated and sent by the originator immediately following the ETX and re-calculated (verified) by the receiver of the message. Ensures the integrity of the transmitted message. (See Appendix B) Field Format Types In the format layouts used in this document, field format types are: Type Definition A Alphanumeric. 7-bit ASCII printable character set. Left justified and space filled. N Numeric. The 0-9 subset of A. (Hex 30 through Hex 39, inclusive.) Right justified and zero filled. $ Dollar Amount. The 0-9 subset of A. Right justified, zero filled with two assumed decimal places. B Binary. The field allows the full range of binary values without regard to ASCII value, print ability or command duplication. Message Level Protocol All messages between the terminal and the First Data host are surrounded by a communication level protocol as follows: Element Size Type Comment Start of Message 1 B ASCII STX character (Hex 02) ID Block 25 A As defined below Message Type 3 N Defines the format and function of the message Remainder of Text Up to 224 Message text outlined below ETX 1 B ASCII ETX character (Hex 03) LRC 1 B Visa protocol standard (See Appendix B) All messages between First Data host and the terminal are surrounded by a communication level protocol as follows: Element Size Type Comment Start of Message 1 B ASCII STX character (Hex 02) Message Type 3 N Generally a value of one greater than request Message 1-253 B Message text outlined below ETX 1 B ASCII ETX character (Hex 03) LRC 1 B Visa protocol standard (See Appendix B) Host Error Concept Each response from the host to the terminal contains a Host Error Code field (the two bytes immediately following Message Type). This field is of primary concern to the POS system; once the message is received by the POS System, the Host Error Code field should first be verified as to its value. If 00, there is no error condition to report and the response should be handled normally. Any host error value other than 00 must cause the terminal to disconnect. If the Host Error field is any value other than 00, the Message Type field and the remainder of the message text should be ignored for normal processing (field values are unpredictable) and the response treated as an aborted transaction. If the field content is 98, however, the response takes on a unique format as described below and the host generated text should be displayed. Other values should result in an error display, such as ERR 26-CALL VENDOR SUPPORT, which should always include the Host Error Code number for debugging purposes with First Data customer support. Element Size Type Comment Message Type 3 N Variable Host Error Code 2 N Any non-zero host error code, except 98. Filler Var A Unpredictable Element Size Type Comment Message Type 3 N Variable Host Error Code 2 N 98 Host Error Text Var A Max length = 255 Terminal Identification Block Field Every request to the First Data host has as its first data field an identifier which is referred to as the ID Block. It is a 25-character field consisting of the following four sub-fields which together form a constant for any given terminal. The concept of a terminal is the lowest level which First Data will recognize for reporting, billing and, when necessary to the application, translation to another identifier. For purposes of controller- or LAN-based systems, the Merchant ID/Terminal ID cluster is best treated as a single Terminal ID in the context of this ID Block. The identity of the originating station for reporting or other purposes may be placed in an information field such as the transaction Invoice Number or the batch Invoice Number. The ID Block is formed as follows: Element Size Type Comment Device Type 2 A VV (Must be all capitals) Filler 1 N 0 (Zero) Merchant ID 11 N Assigned by First Data to each location; must be alterable. Right justified, zero filled. E.g.: 00001234566 It is strongly recommended that the POS software edit-check this field for validity upon entry, ensuring the field to be all-numeric, and of correct length. If less than 11 digits are entered, the field should automatically be zero-filled to the correct length. (May also be verified for valid Luhn check-digit; see Appendix A for details.) Terminal ID 11 N Assigned by First Data to each location; must be alterable. Right justified, zero filled. E.g.: 00001234566 It is strongly recommended that the POS software edit-check this field for validity upon entry, ensuring the field to be all-numeric, and of correct length. If less than 11 digits are entered, the field should automatically be zero-filled to the correct length. (May also be verified for valid Luhn check-digit; see Appendix A for details.) Credit Card Authorizations When a credit card transaction is required, obtain the necessary data specific to the transaction and dial using the telephone numbers and data provided. When the ENQ is received from the First Data host, transmit the authorization request. Upon successfully receiving a response (with a Host Error Code of 00) and transmitting the ACK, continue with any additional queued request. If no further messages are queued, disconnect to terminate the call. The terminal system should always wait a minimum of 200 milliseconds after transmitting its final ACK before disconnecting. Please refer to the earlier discussion of Visa Payment Service to help in determining which of the two Message Types to utilize in the interface. Authorization Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 964: Requesting NO Payment Service data be included in Authorization response. May qualify for Payment Service - See discussion above) 954: Requesting Payment Service data in response Field Separator 1 B Hex 1C (Decimal 28) Card Number Up to 19 N No embedded spaces or symbols. It is required that the POS software edit-check this field for validity upon entry, ensuring the Card Number to be all-numeric, Luhn check, and an acknowledged card type. (See Appendix A) Field Separator 1 B Hex 1C (Decimal 28) Expiration Date 4 N MMYY; verified for reasonableness. (Mail order merchants who do not have this date may submit 0000 for authorization, but this may adversely affect Payment Service qualification and approval rates.) OR Stripe Data Var A When available, the data from only one stripe is included. (Visa requires that Track 1 data be used when both tracks are read.) Start and End sentinels are optional; do not send the card stripe LRC. Field Separator 1 B Hex 1C (Decimal 28) Transaction Amount 7 $ Filler 6 N Zeroes POS Entry Mode 1 N 1 - Manually keyed 2 - Read from magstripe Customer Present Flag 1 A 0 - Customer present 1 - Customer not present Terminal Type 1 N 4 - Electronic Cash Register/POS System Terminal Capability 1 N 0 - POS system has magstripe reader/equipment 3 - POS system has no magstripe reader/equipment Extended Data may follow. See Appendix D for details Credit Card Authorizations (Continued) Authorization Response Element Size Type Comment Message Type 3 N 965 955 Host Error Code 2 N 00 Response Code 2 A AA - Approved ND - Declined NR - Referred (Call Voice Center) Authorization Code 0-6 A Present only with AA response Payment Service and/or Address Verification Response Data may follow. (Message Type 955 only) See previous section, Payment Service Programs, and Appendix D for details Incremental Authorization Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 946 Field Separator 1 B Hex 1C (Decimal 28) Card Number Up to 19 N No embedded spaces or symbols; verified per Appendix A Field Separator 1 B Hex 1C (Decimal 28) Expiration Date 4 N MMYY; verified for reasonableness Field Separator 1 B Hex 1C (Decimal 28) Incremental Amount 7 $ Additional amount required above previously authorized amount Pay Svc Data 23 A From original authorization response. Space fill if original authorization did not return Payment Service data. Additional Duration 2 N Duration in addition to any duration indicated in original authorization. 00 if none. Incremental Authorization Response Element Size Type Comment Message Type 3 N 947 Host Error Code 2 N 00 Response Code 2 A AA - Approved ND - Declined NR - Referred (Call Voice Center) Authorization Code 0-6 A Present only with incremental transactions not qualifying for Payment Services treatment. Partial Reversal Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 948 Field Separator 1 B Hex 1C (Decimal 28) Card Number Up to 19 N No embedded spaces or symbols; verified per Appendix A Field Separator 1 B Hex 1C (Decimal 28) Expiration Date 4 N MMYY; verified for reasonableness Field Separator 1 B Hex 1C (Decimal 28) Total Amount 7 $ Revised total amount authorized, reflecting downward adjustment Pay Svc Data 23 A From original authorization response Original Auth Code 6 A From original authorization response Previous Total Amount 7 $ Previously calculated total amount (Total Amount plus downward adjustment) Partial Reversal Response Element Size Type Comment Message Type 3 N 949 Host Error Code 2 N 00 Credit Card Settlement Throughout the processing cycle, the terminal must accumulate all pertinent transaction data, and be able to calculate the count and amount values of both charges and credits (refunds) in order to perform the daily close or settlement. These transactions should be captured as required by the merchant and subscribed under the First Data service agreement. In addition to capturing those approved via online authorizations, the terminal should also capture: Under-the-floor limit items. Those transactions on card types where the card company has granted the merchant a floor limit amount under which authorizations are not needed. Credits. Transactions representing merchandise return/refunds. Voice-approvals. Transactions where the response was a referral and where voice approval was obtained, and manually entered as part of the transaction. The terminal must request and retain the 6-character alphanumeric authorization code for settlement. If the POS device is managing Payment Service data, the following additional data must also be maintained: Original authorized amount: the exact dollar amount first authorized, not including any subsequent or incremental authorization(s). Total authorized amount: the total dollar amount of all authorizations performed. (Not necessarily the total settled amount.) Once the terminal system has been balanced by whatever local functions are provided, the electronic settlement begins with a normal dial to the First Data host. When the ENQ has been received, the settlement process includes the following steps: 1. The terminal transmits a Summary ID Request; the host response will include the correct (current) summary ID to be sent with transaction details. All Credit Card Detail Request messages must contain this value. 2. Each transaction detail is transmitted to the host, using the Credit Card Transaction Detail Request/Response sequence. 3. Once all details have been successfully sent to the host, the Credit Card Totals Request is transmitted; the Credit Card Totals Response indicates whether or not the totals agree. If the totals agree (as indicated by a C in the Completion Code field), the batch will be closed at the First Data Host, and Step 4 should be performed. If the totals do NOT agree (as indicated by a X in the Completion Code), the batch will not be closed; further settlement operations will be suspended. The terminal should alert the user that the settlement failed, and that user should initiate reconciliation procedures, including a call to their vendor support desk. 4. Only if totals agree in the previous step, a secondary Summary ID Request is transmitted to complete the settlement process, in order to confirm the batch was settled successfully at the First Data host. (Even if the response message to the POS System shows the batch in balance, subtle communication errors may prevent the batch from being closed.) The Summary ID field in this Summary ID Response message should be confirmed as one (1) greater than the batch just closed. Summary ID Requests The terminal should submit this request when initiating settlement, in order to obtain the current Summary ID from the First Data database. At the time the First Data host receives a Summary ID Request, the terminal record in the First Data database is checked for updates. If changes have been made since the last Summary ID Request, two additional fields will potentially be included in the Summary ID Response: primary and secondary telephone numbers. (See the Examples section following the message description.) If telephone numbers are received in the response, the terminal may choose to update the POS system for subsequent dial procedures. Summary ID Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 960 Field Separator 1 B Hex 1C (Dec 28) Serial Number 11 N Would indicate unique (to merchant ) copy of software. (Optional; zero-fill if unused) Software Rev Number 8 A Usually in the form 99.99.99. Indicates the version of software installed at the merchant site. (Optional; zero-fill if unused) Summary ID Response Element Size Type Comment Message Type 3 N 961 Host Error Code 2 N 00 Summary ID 5 N Summary ID to be used in Transaction Detail Requests Dial String #1 Var N Primary Phone Number * Field Separator 1 B Hex 1C (Dec 28) Dial String #2 Var N Secondary Phone Number * Field Separator 1 B Hex 1C (Dec 28) Field Separator 1 B Hex 1C (Dec 28) * These fields will only be present if the telephone numbers in the host database have been changed. Summary ID Request Examples The following examples show possible messages for different response scenarios. All hex characters are represented by . If a Summary ID Request is submitted to request the current Summary ID under normal conditions, the response message might look like this: <02>9610000001<1C><1C><1C><03> If the First Data host database contains updated telephone numbers, the response message might look like this: <02>961000000116153616829<1C>16153616833<1C><1C><03> Credit Card Settlement (Continued) Credit Card Transaction Detail Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 A 966 Summary ID 5 N From Summary ID Response Invoice Number 10 N User-reference field Record Code 2 N 05 - Sale 06 - Credit Card Number Up to 19 N No embedded spaces or symbols. If not captured from original authorization, it is required that the POS software edit-check this field for validity upon entry, ensuring the Card Number to be all-numeric, Luhn check, and a valid, acknowledged card type. (See Appendix A) Field Separator 1 B Hex 1C (Decimal 28) Transaction Date 4 N MMDD Amount 7 $ Total final transaction amount, including tip, if any. Transaction ID 5 N 00001 - 09999 Sequential number, unique within batch. Authorization Code 6 A May be all spaces for credits (Record Code 06) Tip Amount 7 $ Subset of Amount identified as gratuity Field Separator 1 B Hex 1C (Decimal 28) Extended Data Label 6 N 000000 Card Entry Mode 1 N 1 - Manually keyed 2 - Read from card stripe Customer Present Flag 1 N 0 - Customer present 1 - Customer not present Terminal Type 1 N 4 - Electronic Cash Register or Integrated POS system Terminal Capability 1 N 0 - POS system has magstripe reader/equipment 3 - POS system has no magstripe reader/equipment Enhanced Services Data may follow See Appendix D for details Credit Card Transaction Detail Response Element Size Type Comment Message Type 3 N 967 Host Error Code 2 N 00 Credit Card Settlement (Continued) Credit Card Totals Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 A 968 Summary ID 5 N From Summary ID Response Batch Invoice Number 10 N User-reference field; date/time often used. Count of Sales 3 N Total Sales 8 $ Count of Credits 3 N Total Credits 8 $ Credit Card Totals Response Element Size Type Comment Message Type 3 N 969 Host Error Code 2 N 00 Completion Code 1 A C - Complete X - Settlement Error; batch out-of-balance. This error condition will prevent any further settlement activity from the terminal until resolved. Telephone Tests As an aid to First Data Customer Support and other implementation personnel, the terminal system should provide a user friendly function for testing either the stored telephone numbers or an operator-entered number. The test consists of dialing the defined number, connecting with First Data and transmitting the test message shown below. If a properly formatted response is received, the terminal disconnects and reports a successful test. Telephone Test (Date/Time) Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 566 Telephone Test (Date/Time) Response Element Size Type Comment Message Type 3 N 567 Host Error Code 2 N See discussion above Filler 3 N Date/Time 13 N WYYMMDDHHMMSS (W: 0 = Sunday, 6 = Saturday.) Field Separator 1 B ASCII FS (Dec 28/Hex 1C) Section III: COMMUNICATION SESSION SCENARIOS Normal Communication Scenario, Single Transaction In support of the protocol described on the previous page, an illustration of a transmission following normal protocol (no errors occur within the transmission) is provided below. A transmission without errors may be depicted as follows: POS System First Data Host Dial/Wait for ENQ ENQ STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK Disconnect Disconnect Comment: In order to support the multiple device types communicating with First Data hosts, the startup ENQ is usually preceded by an ACK. This character can be ignored by the POS System; it is not meaningful to the POS system. Further error logic must keep this in consideration. Normal Communication Scenario, Multiple Transactions A transmission session containing multiple authorization requests without errors may be depicted as follows: POS System First Data Host Dial/Wait for ENQ ENQ STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK ... additional queued transactions ... STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK 500 Millisecond delay Disconnect Disconnect Error Scenarios The illustrations provided on the following pages reflect errors that may occur within a transmission. Errors Due to Non-verified LRC A transmission in which the host does not calculate the same LRC as received from the POS system may be depicted as follows: POS System First Data Host Dial/Wait for ENQ ENQ STX/MESSAGE/ETX/LRC NAK* STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC ACK Disconnect Disconnect * If the POS system should receive a NAK from the host, it should re-send the message. The host will allow five retries from this point. If the host NAKs five attempts in total, it will disconnect. Errors Due to Non-verified LRC (continued) A transmission in which the POS system does not calculate the same LRC as received from the host may be depicted as follows: POS System First Data Host Dial/Wait for ENQ ENQ STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC NAK* STX/MESSAGE/ETX/LRC ACK Disconnect Disconnect * In the event that the POS system NAKs five attempts from the host, the host will disconnect. Timeout Errors Note: The following illustrations and comments where timeout values are mentioned are provided as guidelines that the vendor should use in the development of the communications interface (i.e. determining timeout values for their POS system). The timeout values provided for the POS system side of the transaction are suggested values. The timeout values provided for the host side of the transaction are actual. A transmission during which the POS system is not receiving an ENQ may be depicted as follows: POS System First Data Host Dial/Wait 30 Seconds NO RESPONSE RECEIVED Disconnect Comment: Under normal conditions, the ENQ should be received within a few seconds after the initial connection has been established. To provide for error conditions that are occasionally present during communications, additional wait time should be allowed. If after thirty seconds, no ENQ is received, it is very unlikely that communications will follow normal protocol and the POS system should disconnect and re-dial the First Data host. Timeout Errors (continued) A transmission in which the First Data host is not receiving a message from the POS system after sending the ENQ may be depicted as follows: POS System First Data Host Dial/Wait ENQ/Wait 10 Seconds NO RESPONSE RECEIVED ENQ/Wait 10 Seconds NO RESPONSE RECEIVED Disconnect Comment: If the First Data host transmits an ENQ and does not receive a message from the POS system within ten seconds, another ENQ will be sent. The host will send three ENQs in total at ten second intervals in attempts to obtain the message from the POS system. If no message is obtained after these attempts, the host will disconnect. Timeout Errors (continued) A transmission in which the POS system sends the message and does not receive a positive or negative acknowledgment, but receives a valid response message within sixty seconds may be depicted as follows: POS System First Data Host Dial/Wait ENQ STX/MESSAGE/ETX/LRC/Wait Up To 60 Seconds STX/MESSAGE/ETX/LRC ACK Disconnect Disconnect Comment: Under normal circumstances a positive or negative acknowledgment should be received within five seconds after the transmission of the message. If a positive or negative acknowledgment, valid response message, or control character are not received within sixty seconds, the POS system should disconnect and redial the host. A sixty second wait period is recommended to allow ample time for the end processor to respond (the First Data host typically allows an end processor up to 55 seconds to respond). Timeout Errors (continued) A transmission in which the POS system sends the message and does not receive a positive or negative acknowledgment, but receives another valid control character within sixty seconds may be depicted as follows: POS System First Data Host Dial/Wait ENQ STX/MESSAGE/ETX/LRC/Wait Up to 60 Seconds ENQ* STX/MESSAGE/ETX/LRC (Repeat) ACK STX/MESSAGE/ETX/LRC ACK Disconnect Disconnect * If the POS system should receive an ENQ from the host, it should re-send the message. Error logic for this specific scenario can be quite tricky; the ACK preceding the ENQ could easily be seen as the acknowledgment for the request message. Therefore, the POS system should recognize an ENQ immediately following as an indication that the First Data host did not receive the request message, and resend. Results may vary Timeout Errors (continued) A transmission in which the host is not receiving any acknowledgment from the POS system after returning the response message can be depicted as follows: POS System First Data Host Dial/Wait ENQ STX/MESSAGE/ETX/LRC ACK STX/MESSAGE/ETX/LRC Wait 500 milliseconds Disconnect Disconnect Comment: The First Data host will wait ten seconds for the POS system to acknowledge the return message. If an acknowledgment is not received within ten seconds, the host will disconnect, and not consider the transaction as valid. Timeout Errors (continued) A transmission in which the POS system receives an ACK but no response message is received, may be depicted as follows: POS System First Data Host Dial/Wait ENQ STX/MESSAGE/ETX/LRC/Wait 60 seconds ACK NO RESPONSE MESSAGE RECEIVED Timeout/Disconnect Disconnect Comment: Under normal circumstances, the response message should be received within one - seven seconds of the ACK. However, if the end processor is slow to respond this may not occur. If the POS system does not receive the response message within 60 seconds after receiving the ACK, the POS system should disconnect and redial the host. * Note: When the First Data system becomes aware that a processor is consistently failing to respond, it will enter a mode in which it will return rejection messages to the POS system instantly. This will continue until such time as the processor resumes activity. Additional Error Scenarios Independent of the error scenarios presented previously, additional errors may be encountered during a transmission. Listed below are additional error scenarios and a course of action to be taken in response to each. Character Parity Errors If a character parity error should occur, the character causing the error should be ignored unless it occurs during the receipt of the response. Should the parity error occur during the receipt of the response, the POS system should wait until the receipt of the LRC and issue a NAK. Errors Due to Unexpected Characters If during one of the wait stages of the transmission, the POS system should receive unexpected characters, they should be ignored unless they are transmitted as a part of the response (beginning with the STX and concluding with the ETX). At that point they should be considered a part of a message. The First Data system will react in the same manner after returning a response. After the issuance of the ENQ, however, if the host receives more than four (4) characters without receiving the STX and/or the ETX, it will issue disconnect. Section IV: PROCESSING STANDARDS Appendix A Luhn MOD-10 (Account Number Verification) This self-checking scheme (referred to as the Luhn Mod-10 Method) is an international standard for validating card account numbers (ISO 2894/ ANSI 4.13). Such account numbers, which cannot exceed 19 digits including the check digit, are assigned, embossed and encoded to include a single check digit in the rightmost position. In addition, First Data uses the same scheme to check-digit its assigned Terminal IDs. The check digit is calculated as follows: 1. Beginning on the right with the digit which immediately precedes the check digit and moving toward the left, double every other digit. After doubling each selected digit, if the result is ten or greater, add the two digits together to arrive at a single-digit result. 2. Each individual resulting digit (plus those skipped above) are then added together. 3. This sum is then subtracted from the lowest multiple of ten which is equal to or greater than the sum and the single-digit result is the check digit. Example: 15-Digit Account Number 7951-0287-9015-54? 4 x 2 = 8 5 x 1 = 5 5 x 2 = 10 : 1 + 0 = 1 1 x 1 = 1 0 x 2 = 0 9 x 1 = 9 7 x 2 = 14 : 1 + 4 = 5 8 x 1 = 8 2 x 2 = 4 0 x 1 = 0 1 x 2 = 2 5 x 1 = 5 9 x 2 = 18 : 1 + 8 = 9 7 x 1 = 7 Sum = 64 Subtracted From = 70 Resulting Check Digit : 6 Note: Many programs written simply to verify such numbers begin with the check digit itself (weighted as 1) and simply assure that the result is a multiple of ten. Appendix A (Continued) Card Type Identification The standards organizations which determine and publish the account numbering schemes assign ranges of numbers to various card issuers to facilitate the identification of the type of card represented by any given Cardholder Account Number. In addition, the issuers themselves follow certain conventions which allow for further edit checks on the validity of a number. Listed below are the rules (current as this document is being published) for validating the most popular national cards: MasterCard - First digit must be a 5 and second digit must be in the range 1 through 5 inclusive. Only valid length is 16 digits. Visa - First digit must be a 4 and length must be either 13 or 16 digits. American Exp - First digit must be a 3 and second digit a 4 or 7. Only valid length is 15 digits. Diners Club / Carte Blanche - First digit must be a 3 and second digit a 0, 6, or 8. Only valid length is 14. Discover - First four digits must be 6011. Only valid length is 16 digits. enRoute - First four digits must be 2014 or 2149. Only valid length is 15 digits. JCB - First four digits must be 3088, 3096, 3112, 3158, 3337 or 3528. Only valid length is 16 digits. Appendix B Calculating the LRC The LRC is computed with respect to all characters of the message beginning with the first character following the STX byte, but including the ETX character. As outlined previously, the one byte result is transmitted immediately following the ETX. The LRC is an 8 bit byte which, for each bit position of each byte involved including the LRC itself, causes there to be an even number of bits on. The exception is the LRCs character parity bit, which is a reflection of character parity and not of longitudinal parity. The LRC is normally computed by using exclusive or math. It may be computed with logic such as: 1 - A = 0 2 - B = Next Byte 3 - A = A xor B 4 - If another byte, go to step 2 5 - A = the LRC to be used Exclusive Or logic operates on individual bits as follows: Bit 1 Bit 2 Result 0 0 0 0 1 1 1 0 1 1 1 0 Appendix C Sample Host Error Codes The following host error samples are provided as a guide during POS system design, certification, alpha/beta testing, and production (live) problem research. It is not advised that the system attempt to translate error codes into phrases. Although it is highly recommended that any host error received by the POS software be treated as a unrecoverable error, causing an immediate disconnect, some POS vendors may chose to include an additional level of intelligence to internal handling of host errors. Fatal: Must result in an immediate disconnect. POS system should report the numeric host error code to the operator, and initiate procedures to contact vendor support. Temporary: Some interim obstacle within First Data host processes has temporarily blocked this service. Most instances are of very short duration; a retransmission of the request message will often return no host error. Transaction Type: The specific service associated with the Message Type is unavailable or invalid for the Terminal ID in question. Any processes requesting this type of service should be blocked locally by the POS system Transaction: The specific transaction contains some form of data error (out-of-bounds, invalid character type(s), non-serviceability, etc.), and has therefore failed edit checking procedures. The request was ignored by the First Data host; no action was taken. Batch type processes being performed by the POS system can usually continue with the next record, ensuring the error is handled appropriately for the transaction in question. Error Code Severity System Error Resolution 19 Fatal Merchant number in First Data database does not relate to a defined bank or financial institution. Terminal record in First Data database must be updated with correct bank or financial institution ID. Merchants bank must contact First Data Account Management representative, with correct merchant bank information. 20 Fatal Terminal ID submitted by POS system is invalid, and/or was not found on First Data database. Correct Terminal ID should be confirmed with First Data Customer Support, and submitted as defined above (see Section II, Terminal Identification Block). 26 Fatal Terminal ID flagged as Inactive in First Data database. Merchants bank must contact First Data Account Management representative; Terminal ID can be flagged as active, or new Merchant and Terminal IDs will be assigned. Error Code Severity System Error Resolution 27 Fatal Merchant ID submitted by POS system does not match submitted Terminal ID Correct Merchant and Terminal IDs should be confirmed with First Data Customer Support, and submitted as defined above (see Section II, Terminal Identification Block). 30 Transaction Error resulting from attempt to write record to First Data summary database. Returned only during auth/capture event. Normally a temporary fault; transaction should be retransmitted. 31 Temporary Database record lock encountered Terminal record in First Data database is locked; normally caused by manual access to record for update purposes. Transaction should be retransmitted. 33 Temporary Database error in settlement (summary) process Summary record in database is locked; normally caused by manual access to record for update purposes. Transaction should be retransmitted. 50 Fatal Invalid Merchant ID (MID) submitted by POS system. The terminal record is subsequently flagged as violated, preventing any further activity (see Code 51). Correct Merchant ID must be confirmed with First Data Customer Support, and submitted as defined above (see Section II, Terminal Identification Block). Customer Support will clear violation flag, reactivating terminal record for further activity. 51 Fatal Terminal marked as having its security Violated. Service is blocked until Customer Support reactivates record. Correct Merchant ID must be confirmed with First Data Customer Support, and submitted as defined above (see Section II, Terminal Identification Block). Customer Support will clear violation flag, reactivating terminal record for further activity. 54 Fatal Different Device Type in First Data database than in the ID Block received. Terminal record in First Data database must be updated with correct POS system-type information; POS system must also confirm accuracy of Device Type field submitted within Terminal ID Block. 55 Transaction Type Database error in check approval process Terminal record in First Data database must be updated with correct check approval information. Merchants bank must contact First Data Account Management representative, with correct check approval information. 56 Transaction Type Invalid check approval merchant number in First Data database Terminal record in First Data database must be updated with correct check approval information. Merchants bank must contact First Data Account Management representative, with correct check approval information. Error Code Severity System Error Resolution 57 Transaction Invalid account number found by authorization process POS system has submitted for approval an invalid card type, or one not set up in the First Data database for the specific merchant. POS system should be configured to not accept the card type(s) in question; merchant may wish to contact their bank to initiate procedures required to accept this card type. 58 Transaction Type Unresolved out-of-balance batch at First Data host. Vendor must contact First Data Customer Support to clear out-of-balance batch. POS vendor should ensure transaction/batch data has been retained, and can be retransmitted. (Refer to Section II, Credit Card Settlement.) 59 Transaction Summary Id submitted with a Transaction Detail or Totals message refers to a previously closed batch. Vendor should confirm Summary ID being used for current batch; as well as confirm with First Data Customer Support the last settled batch, to ensure a batch has not been double posted. 60 Transaction Invalid data (non-numeric) in Card Number. Usually related to a manually keyed card number. Merchant and/or vendor must confirm that a valid card number has been entered or swiped, containing no leading, imbedded or trailing spaces. (See Section II, Authorization Request, and Appendix A.) 61 Transaction Invalid data in Transaction Detail message One or more fields in the message has failed an edit-check; vendor must confirm that message is assembled correctly based on base specification, and contains valid data. (See Section II, Transaction Detail Request) 62 Transaction Invalid data in Transaction Detail or Totals message Same as above; usually implies an out-of-bounds error for one or more data elements. Vendor must confirm that message is constructed correctly, according to specification, and contains valid data. (See Section II, Transaction Detail Request) 65 Fatal Invalid telephone number used. Vendor must confirm correct phone numbers with First Data Customer Support, to be used with specific Terminal ID in question. 66 Fatal Invalid telephone number used. Same as 65; usually occurs in conjunction with the assignment of new phone numbers. 98 Fatal Textual error message Implies text error message included with response message; text should be displayed to operator, or accessible for vendor research. (See Section II, Host Error Concept) Appendix D: Extended Data Overview First Data provides support for many of the industry- or card-specific services available in the Point of Sale industry; these services are supported through the use of Extended Data packets submitted with standard authorization and transaction detail messages, and included with authorization responses. Transactions are authorized using the same techniques described in the base specification; any additional required data is submitted as Extended Data. The Extended Data packet formats are described below; for interpretation of the fields within the base portion of a message, refer to the base specification (Communications Interface). In simple terms, Extended Data is position-delimited by field separators. The following principles apply: Each packet of Extended Data is preceded with an ASCII Field Separator (Hex 1C/Dec 28). Each Field Separator indicates, by its position, the type of data (if any) submitted, and are required only where Extended Data follows (inbound or outbound messages). Data types may include: Industry Specific Auxiliary Data (Lodging; Auto Rental; Fleet; AVS Request Information) Payment Service Data (Visa PS2000 and CPS/94, MasterCard ICP) AVS Response Codes An ETX character always terminates a message, indicating no further data to follow. Data positions are as follows: Authorization Requests: [request msg] [[aux data]] [[pserve data]] Authorization Responses: [request msg] [[pserve data]] [[avs codes]] Transaction Detail Requests: [request msg] [[aux data]] [[pserve data]] [[avs codes]] Any Extended Data included with an Authorization Response must be included with the corresponding Transaction Detail message, to ensure proper qualification for programs such as Payment Service, CPS/94, or Address Verification. Examples Authorization Request: Authorization Request, with Auxiliary Data (such as Fleet, or Address Verification): Authorization Request, with CPS/94 Data: Authorization Response: Authorization Response, with Payment Service Data: Authorization Response, with Address Verification Data: Authorization Response, with Payment Service and Address Verification Data: Transaction Detail Request: Transaction Detail Request, with Auxiliary data (such as Fleet or Lodging): Transaction Detail Request, with Address Verification Data: Transaction Detail Request, with Payment Service and Address Verification Data: Payment Service Data For those POS systems that take responsibility for Payment Service data management, Authorization Request Message Type 954 should be used so Payment Service data will be included in the subsequent response message. The required Payment Service data can then be included with each transaction (Credit Card Transaction Detail Request 966) during settlement. Authorization Response Element Size Type Comment Message Type 3 N 955 Host Error Code 2 N 00 Response Code 2 A AA - Approved ND - Declined NR - Referred (Call Voice Center) Authorization Code 0-6 A Present only with AA response Field Separator 1 B Hex 1C (Decimal 28) Present only if Payment Service and/or AVS Data follows. (See discussion Appendix D, Overview.) Pay Svc Data 23 A Present only with qualifying transactions. Critical to later settlements. (See discussion above.) Settlement Transactions are settled using the same techniques described in the base specification. However, Payment Service data found in any response messages is expanded to include the additional Payment Service information. The extended message formats are described below. For interpretation of the fields within the base portion of the message (through last field separator) refer to the base specification. Element Size Type Comment Field Separator 1 B ASCII F/S (Hex 1C/Decimal 28) Pay Svc Data 23 A From original authorization response Original Auth. Amount 7 $ Amount originally submitted for authorization Total Amount Authd 7 $ Required only for new CPS/94 transactions (not for retail type). Total amount authorized; sum of original and all incremental authorization amounts. CPS/94 Data For those POS systems that take responsibility for Payment Service data management, and wish to qualify for CPS/94, the Duration (number of days until the transaction will be settled) must be included with each original authorization (Authorization Request 954); those transactions associated with lodging or auto rental transactions, this value must be at least 01. If the merchant/hotel property intends to settle the transaction within the same business day (such as a retail sale, or Advanced Deposit charge), this value should be submitted as 00, and will be treated as a standard retail transaction. Original and total authorization amounts must be included with the final settlement transaction, if qualification for CPS/94 is desired (see applicable Auxiliary Data types below). Transactions are authorized using the same techniques described in the base specification. The extended message formats are described below. For interpretation of the fields within the base portion of the message (through last field separator) refer to the base specification. Element Size Type Comment Field Separator 1 B ASCII F/S (Hex 1C/Decimal 28) Duration 2 N 01 - 99: Lodging or Auto Rental transaction 00: Retail-style transaction Auxiliary Data Overview Specific processors, such as American Express, Visa (CPS/94 only), and Fleet, impose specialized data requirements for specific industry categories such as lodging or auto rental, in order to be certified for electronic settlement of transactions performed at an establishment in that industry. First Data provides a format for point-of-sale and property management system vendors to append this supplemental data to the otherwise standard electronic settlement record. Transactions are settled using the same techniques described in the base specification. However, each Credit Card Transaction Detail Request message for a is expanded to include the additional information. The expanded message formats are described below. For interpretation of the fields within the base portion of the message (through last field separator) refer to the base specification. Lodging Data Format The intention of the processor (American Express, Visa ) is to create a facsimile record of charge for the cardholders statement which the cardholder will associate without question with the actual charge activity performed. Therefore, they require: Primary Charge Type - this code indicates whether the primary charge is Lodging, Restaurant or Gift Shop. If other than Lodging, the remaining data is not required. Check-In Date - the date (MMDDYY) that the guest checked in to the hotel. Developer should insure that appropriate edits prevent unreasonable or illogical dates. Check-Out Date - the date (MMDDYY) that the guest checked out. Special Amex Program Code - this code distinguishes among the following special programs: Assured Reservation No Show - a reservation guaranteed against the Amex card; guest did not arrive Advance Deposit - a deposit on a future stay. Dates should indicate the estimated future check-in/check-out dates Delayed Charge - a charge incurred or added to the guest folio after the guests departure. Normal/Express Service - indicates that guest cardholder used express check-out service Assured Reservations - lodging charges where reservation was guaranteed against Amex card None Specified - used where none of the above apply Lodging Data Format (Continued) For use with Transaction Detail Request (settlements): Element Size Type Comment Field Separator 1 B Decimal 28, Hex 1C Extended Data Length 3 N Length of remaining portion of message excluding this field (027) Format Code 4 N 0004 (Lodging Data) Format Code Revision 2 N 02 Compression Indicator 1 A N (Not compressed) Primary Charge Type 1 N 1 = Lodging 2 = Restaurant 3 = Gift Shop Check-In Date 6 N MMDDYY (zeroes if not Primary Charge Type 1) Check-Out Date 6 N MMDDYY (zeroes if not Primary Charge Type 1) Special Program Code 1 N 1= No Special Code 2= Assured Reservation/No Show 3 = Advance Deposit 4 = Delayed Charge 5 = Express Check Out Service 6 = Assured Reservation/Normal 0 = Not Primary Charge Type 1 Extra Charge Code 6 A Up to 6 1-digit codes, each a partial or complete explanation of why charged amount differs from receipt cardholder received at checkout: 0 - No extra / Filler 2 - Restaurant 3 - Gift Shop 4 - MiniBar 5 - Telephone 7 - Laundry 6 - Other Reasons Auto Rental Data Format The intention of the processor (American Express, Visa ) is to create a facsimile record of charge for the cardholders statement which the cardholder will associate without question with the actual rental activity performed. Therefore, they require: Rental Agreement Number - the identifying number on the rental contract, a copy of which is retained by the renter as evidence of the charge. Rental/Return City/State - the city (18 characters) and the 2-letter postal code for the state of the locations where the car was checked out and then returned must be included. Both must be included even on a local rental where the return is the same location. Rental/Return Date/Time - the date (YYMMDD) and the time (HHMM) that the car was rented and then checked in are required. Developer should insure that appropriate edits prevent unreasonable or illogical time stamps. Renter Name - the 20-character name of the principal driver/renter should be shown, first name first, as it would normally be written. Audit Adjustment - the amount of charges added after the vehicle was checked in and included in the total amount being charged in this record. In other words, these charges did not appear on the evidence of charge that the cardholder took from the return counter. Auto Rental Data Format (Continued) For use with Transaction Detail Request (settlements): Element Size Type Comment Field Separator 1 B Decimal 28, Hex 1C Extended Data Length 3 N Length of remaining portion of message excluding this field (110) Format Code 4 N 0006 (Auto Rental) Format Code Revision 2 N 02 Compression Indicator 1 A N (Not compressed) Rental Agreement Num 9 A Contract invoice reference Audit Adjustment 7 $ Charges added after check in Rental City 18 A Where car was picked up Rental State 2 A Where car was picked up Rental Date 6 N YYMMDD when car was picked up Rental Time 4 N HHMM when car was picked up Return City 18 A Where car was checked in Return State 2 A Where car was checked in Return Date 6 N YYMMDD when car was checked in Return Time 4 N HHMM when car was checked in Renter Name 20 A As typically written (first name first) No Show Indicator 1 N 2 - No Show Charge 0 - Normal Charge Extra Charge Code 6 A Up to 6 1-digit codes, each a partial or complete explanation of why charged amount differs from receipt cardholder received at time of rental return: 0 - Filler/No Extras 1 - Refueling 2 - Extra Mileage 3 - Late Return 4 - One Way Fee Fleet Data Format Fleets intention is to create a facsimile record of charge for the cardholders statement which the cardholder will associate without question with the actual charge activity performed. Therefore, they require: Vehicle Number Driver ID Odometer Reading Product Code - for up to three product types Total Amount - For each of the three designated products Unit Price - e.g., per gallon cost of fuel Service Type - e.g., Full- or Self-Service Sales Tax Reference Number (Job Code) Note: Fleet transactions require Auxiliary Data be submitted with both authorization and settlement messages. Element Size Type Comment Field Separator 1 B Decimal 28, Hex 1C Extended Data Length 3 N Length of remaining portion of message excluding this field (065) Format Code 4 N 0001 (Fleet Data) First Data Version Number 2 N 02 Compression Format 1 N N Vehicle Number 5 N Driver ID 6 N Left-justified, fill with > (Hex 3E, Decimal 62) 000000 if not available E.g.: 123456 or 1234>> Odometer Reading 6 N Product Code[1] 2 N 01-11,21,26,30,40 Product Code[2] 2 N 21,26,30,40 Product Code[3] 2 N 21,26,30,40 Total Amount[1] 6 N Total Amount[2] 6 N Total Amount[3] 6 N Unit Price 5 N Right-justified, zero-filled. Three assumed decimal places. nnnnn (if fuel product) 00000 (if non fuel) Service Type 1 N 0 - No fuel service 1 - Self service 2 - Full service Sales Tax 6 N Reference Number 5 N Job Code Address Verification Service In order to achieve favorable discount rates for Mail Order transactions, cardholder address information may be submitted (as Auxiliary Data) with Authorization Requests. The intention of the credit card processors is to avoid fraudulent card use, by confirming account information normally available only to the cardholder (such as address information). The extended message format is described below. For layout and interpretation of the fields within the base portion of the message, refer to the base specification. Address - Formal street address, as would be printed as part of a mailing address. Any numerical reference must be converted to numeric format. For example: One First Street = 1 1ST STREET Third Ave South = 3RD AVE SOUTH Matching algorithms vary greatly between financial institutions; some choose to match only on submitted numerics. For example: One First Street = 11 Third Ave South = 3 Zip Code - Standard, 5-digit US Zip Code; or European Post Code. Transactions are authorized using the same techniques described in the base specification. Each Authorization Request message requesting Address Verification is expanded to include the additional cardholder address information as Auxiliary Data. Authorization Request Auxiliary Data Element Size Type Comment Field Separator 1 B Hex 1C (Decimal 28) Extended Data Length 3 N Remaining length of packet, excluding this field (036) Format Code 4 N 0012 Revision Number 2 N 01 Compression Flag 1 A N Zip Code 9 A Left-justified, space-filled. Street Address 20 A Left-justified, space-filled Authorization Response AVS Codes Element Size Type Comment Field Separator 1 B Hex 1C (Decimal 28) Address Match 1 A Y - Match N - No Match X - Service Unavailable/Not Applicable ZIP Code Match 1 A Y - Match N - No Match X - Service Unavailable/Not Applicable Authorizer Result Code 1 A Critical for later transaction settlement Address Verification transactions are settled using the same techniques described in the base specification. Each Transaction Detail message must include corresponding Address Verification data returned in the Authorization Response. The extended message format is described below. For layout and interpretation of the fields within the base portion of the message refer to the base specification. Transaction Detail Request AVS Codes Element Size Type Comment Field Separator 1 B Hex 1C (Decimal 28) Address Match 1 A From AV Response (Space if unavailable) ZIP Code Match 1 A From AV Response (Space if unavailable) Authorizer Result Code 1 A From AV Response (Required for certain services.) Appendix E: Online Check Approval When a check approval is required, obtain the necessary data specific to the transaction and dial (according to routines described in the base document). Note that the same dialing procedures are used for check approvals as for credit card authorizations or settlements. When the ENQ is received from the First Data host, transmit the Check Approval Request as specified below. Upon successfully receiving a response and transmitting the ACK, disconnect to terminate the call. Check Approval Request Element Size Type Comment ID Block 25 A See discussion above Message Type 3 N 950 ID Type 2 N 00-99 verified valid per Check ID Table ID Number 24 A Left justified, space filled; no imbedded spaces or symbols NOTE: Should this data reach a length greater than 19 digits, any submitted Check Sequence Number will be ignored. Date of Birth 6 N 000000 or MMDDYY Amount 7 $ Check Sequence Num 4 N nnnn, as found on check. (0000 is valid, and will be treated as if no sequence number was submitted.) Check Approval Response Element Size Type Comment Message Type 3 N 951 Host Error Code 2 N 00 means no error Response 24 A Host generated response text Check Approval ID Type Codes These codes are used to specify the form of ID used in a Check Approval transaction in the First Data system. The various check services use different coding schemes; First Data will make the appropriate translations. NOTE: Not all types are supported by all check approval companies; POS software are responsible for production testing and/or confirmation with Check Guarantee services as to supported types. Numerical List ID Type Description ID Type Description 00 Check MICR Number 55 Alaska DL 01 Northwest Territories DL 56 Maine DL 10 Military ID (SS#) 57 Kansas DL 11 British Columbia DL 59 Kentucky DL 12 Saskatchewan DL 60 Ohio DL 13 New Brunswick DL 61 Manitoba DL 14 Telephone Number 62 MasterCard 20 Arizona DL 63 Nebraska DL 21 Alberta DL 64 Minnesota DL 22 Visa Card 65 Oklahoma DL 23 California DL 66 Missouri DL 24 Carte Blanche Card 67 Oregon DL 25 Alabama DL 68 Montana DL 26 Colorado DL 69 New York DL 27 Arkansas DL 70 Puerto Rico DL 28 Connecticut DL 71 Quebec DL 29 American Express Card 72 South Carolina DL 31 Newfoundland DL 73 South Dakota DL 32 Diners Club Card 74 Rhode Island DL 33 Delaware DL 75 North Carolina DL 35 Florida DL 77 Mississippi DL 36 North Dakota DL 78 Pennsylvania DL 38 Nevada DL 79 Maryland DL 39 New Mexico DL 81 Prince Edward Island DL 40 Michigan DL 82 Virginia DL 41 Nova Scotia DL 83 Vermont DL 42 Georgia DL 86 Tennessee DL 43 Idaho DL 87 Massachusetts DL 44 Hawaii DL 88 Utah DL 45 Illinois DL 89 Texas DL 46 Indiana DL 91 Yukon Territories DL 47 New Hampshire DL 92 Washington State DL 49 Iowa DL 93 DC DL 50 Choice Card 94 Wisconsin DL 51 Ontario DL 95 Discover Card 52 Louisiana DL 98 West Virginia DL 53 New Jersey DL 99 Wyoming DL Alphabetical List By Categories Drivers Licenses - United States 25 Alabama 68 Montana 55 Alaska 63 Nebraska 20 Arizona 38 Nevada 27 Arkansas 47 New Hampshire 23 California 53 New Jersey 26 Colorado 39 New Mexico 28 Connecticut 69 New York 33 Delaware 75 North Carolina 93 District of Columbia 36 North Dakota 35 Florida 60 Ohio 42 Georgia 65 Oklahoma 44 Hawaii 67 Oregon 43 Idaho 78 Pennsylvania 45 Illinois 70 Puerto Rico 46 Indiana 74 Rhode Island 49 Iowa 72 South Carolina 57 Kansas 73 South Dakota 59 Kentucky 86 Tennessee 52 Louisiana 89 Texas 56 Maine 88 Utah 79 Maryland 83 Vermont 87 Massachusetts 82 Virginia 40 Michigan 92 Washington (State) 64 Minnesota 98 West Virginia 77 Mississippi 94 Wisconsin 66 Missouri 99 Wyoming Drivers Licenses - Canada 21 Alberta 41 Nova Scotia 11 British Columbia 51 Ontario 61 Manitoba 81 Prince Edward Island 13 New Brunswick 71 Quebec 31 Newfoundland 12 Saskatchewan 01 Northwest Territories 91 Yukon Territories Credit/Charge Cards 29 American Express 95 Discover 24 Carte Blanche 62 MasterCard 32 Diners Club 22 Visa Other Identification 00 Check MICR Number 14 Telephone Number 10 Military ID (SS#) ~hJgHnʪ =[x| O]_e=RTuw-6Ea 48,&03@   "" D @     $$Jh8: , 0 P T !."?"H#?#T##%>%P&]&v'<'Q'R'g''((++++,,,,----...."..0v0w0x02244,4-445Z5\5l5m5n66 67686C6D6U6k777Y7Z8899;;;;;; "" @@V;=)=<=>=B>m>p>?@X@[@@AAB)B<BBBBBBC[CmCCDID_DDDDDDDDFFFFFFFFGGH2HeHHI6IKKKKKKKKL]L_LfLgLkLlLpLqLxLLPP$P%P)P*P.P/P6PzP{QQRRT3TNVVW*W?WAWHWIWMWN@`WNWRWSW[WWWXXXNXPXX]d]]]]]]]]]]]]]]^_p_s_________aRaZb2bUbVb]b^bbbcbgbhbpcscccccccceGeOeef f%f&f-f.f2f3f7f8f@ftfhYhZi i iNiOiimPmxm}mnnohoio@]oooprru5uGuIuPuQuUuVuZu[ucvvvvvvvvvwxxzzzzzzzz{{{ { {{{|:|B03Z[cdhimnv $%)*2(7"#'(,-5r@^k~#$AB\f}">RSUVstvw!"$%-.KL 45H  ]$%BCEFbc $%LV*NX *43N#=JKMNSmz{}~n}@c}t%'23P6&4[ijz&pw+g8B)="iӄӌӎӘRoٵژڙڜڥ3]ۈ۶%S܍ܽ Hf݂  @ Z8k޽B`5?#v0;=u]tst pq;L$%56ABTU$% + 2       # <  ~ @@Z~RY$NOb > X!'!;!!!! @@   #<=K\]kxyz{|K  +5O_g!=Tw! ! ! ! !  @ ! @! ! ! !!! D/Pd{8V|2Ecv   ?@3ŻŶŮš! ! #(! #(! ! ! ! !!  !  @! ! ! ! ?34,-&'k;lmefg }}umuubXN ! hh ! hh ! hh! !  !  ! hh ! h! h ! hh ! hh ! hh ! hh! ! ! !  !"!  !-!.">"?#?#%>&]'R'''(((((**++,-./0v1z1{224Ӣ˙ˑˆ{{p{h`hX! ! !  !  !  ! ! h! hh ! hh ! hh ! hh! h! h! h! h ! hh hh!4444,4-5Z5[5\77889i9:6;;;;;;;;;;;;;;;;;=(=)===>>mŹ{ppe ! ` ! 0! !! !  !  !   !hh ! hh  !8hh! ! ! $>m>???@ @X@AB(B)B<B=BBBBBC[CDEDFDHDID`DaDbDDDE&EEEEEFFFFFFFGGBGgGGG¹®¦¹ž“~! ! !  p @ !  p @ !  ! 0! !  ! ` ! ` !  !  ! `/GGGGIIKKKKLLBL]L^L_LyLzLLLLLLLNNOOPPP7P8PeP{PRWRXT1T2T3TNTOVVW'W(W*ϯ{! !  p @ !  p @ !  p @ !  p @ ! !  !  p @ !  p @ ! ! ! !  p @ .W*W@WAW[W\WXXPXxXYYZZ[[[\\\>\[\\\].]d]~]]]]]]]ν߰o߰aa[U! !  !  p @ !  hp @ ! hp @ ! hp @  !-hp @ ! p @ ! ,p @, ! ,p @, !  p @ !  p @ ! ! !]]^ ^^/^Q^d^^^_ _V_q_s_____``````a;ab0b1b2bUbVbpbqbbbbbcqcrcsctcøzk!  p @ ! !  !  p @ ! !  !  p @ ! hp @ !  p @ !  p @ !  p @  p @ !  p @ !  p @ *ccccccd dYddde0egef f f f%f&f@fWfqfsftffhXhYi iNjOjPjk@kkkޣ}r}j`` ! !  !  !  ! ! ! !   p @ !  p @ ! !  p @ ! hp @ !  p @ !  p @ !  p @ $kllmmnnnohpprrrrs1s2u4u5uHuIucuduuuv1vvvvvvwwźwlallll\Wlllwlal! ! !  p @ !  p @ !  p @ ! ! !  !  ! h !  !  !  ! h ! ! ! "www1wuwwwxxAxBxxxxxxxxxyPyQyyzzzzrzszzzzzzzzz{{{;{R{z{{{|}}9}{ ! hp @  !8hp @ ! !  !  !  p @ ! !  p @ !  p @  p @ !  p @ 0}{}~~I~q~~~ +u13[\v)@h23Jd#$&'睗璴 !  p @ ! !  !  p @ !  p @ !  p @  p @ !  p @ ! hp @ !  p @ !  p @ 4'(89:56Ypqr:hijklmopq~"#:;CD! !H! !H! !H ! p @ !!  !  p @ !  p @ !  p @ !  p @ !  p @ 8D[\z|}!">?TU]^uv~ #$,-DEMNde|~./67PQR! !@!H! !H!H! !H! !H! !HNHI#$;<DE\]de~ &'=>JKL *+)*@AMN޾! !H! !H!H! !@! !H! !H! !H!HK()*/023NO"#>?LMTURSno|}mn׾!H! !H! !@! !H! !H!H! !H! !HKijwxy{|}st&'3QR/0ȽȲz! !   !    !!  ! ` ! ` ! `! ! ! ! !H! !H! !H/#$%Z[fq",B]^789$%&Z[jop! p! pp ! p`p ! p`p! !  !       ! @! ! : lmw+9GUcdfgrs}~7%' Ǻ}qee !  <u !  <u !  <u ! bb@ ! bb@ ! bb@! ! ! ` ! p ` ! pp ! pp! p! p' >;Ð/ƢǷ#˝)=wқfgiuӃӄӍӎԿրךƺޯvj !  ! hh! ! ! hh ! hh!  ! hh !  <u !  <u !  <u !  <u !  <u! )0CDؚ؛غRٴٵڙښڜڝڦڧڨک3^_ۈ۷۸۹ۺۻ%TU܍ܾܿ IJf݄݃8lm޽ʿⷮꩣ! ! ! hh ! hh !  ! ! h ! hh ! ;@yyz{_`6h#x޽ЮЮyyyyt! !  !  xH@ !  p @ ! ! ! ! ! ! !  p @ !  p @ !  p @ !  p @ !  p @ -xyHIb_00<=tu9WRøދ}o !  p @ !  p @ !  p @  p @ !  !  !  ! hh ! hh! !  p @ !  p @ ! ! +AZ[\]uvrs p}|"T}*TĿtf !  p @ !  p @ ! h! h! hh ! hh ! hh! ! ! ! ! p @  ! p @ !  p @ (+8:;MN#$5AT$BCDRv6CYJe|t! p @, ! p @, !  p @ !  p @ ! X! ! ! !  p @  ! p @ !  p @ - * +              " # =Ƕ|tldt[tM !  p @ ! ! !  ! ! 88p@ ! 0 p@ !88p @@ ! 88p @@ !! ! ! !   p @ !   @@  = f     , ] ^ _       ?Q}VWX}~64 +οܹ !  p @ ! ! ! !  p @ ! ! !  p @ !  p @ =&QRTUWXuv#$NOr(Ki&Hh ,Sp6Ry?Aabпбʤ !  !  !  ! ! ! !  p @ !  p @ !  p @ ;b:Y0Ke|  # ; > Y t    !%!'!<!]!}!!!!!!!!!  !  !  /QTOC 1TOC 2TOC 3TOC 4 Indented NoteDefault Paragraph Font1layoutMessagesQ        hh!@!@!@X!@( @x@  p @  !'3:CGKV)^rerqw2%n{}1zehٛ~9 V@=       !"#$% &'()*+,-./0;WNo}~!3 4>mGW*]ckw}{'D x =b!   8  H defg|V&p&r2 2j2u23(3)3*3+3,77778888888889:;;;;;;<m HH(EG(HH(d'@=/@H-:LaserWriter 8 TimesSymbol   EIE=direct dial cc specsTimothy C. SternTimothy C. Stern