==Phrack Magazine== Volume Five, Issue Forty-Six, File 15 of 28 **************************************************************************** visanetoperations; part1 obtainedandcompiled by icejey /\ lowerfeldafederationforundercasing iiu delamolabz chuchofthenoncomformist && theilluminatibarbershopquartet greetz2; drdelam maldoror greenparadox kaleidox primalscream reddeath kerryk -------------------------- [ typed in true(c) 80 columns] ---------------------- ---------------------------- [ comments appear in []s ] ------------------------ [ section one ] [ from the word of god ] ------------------------------------------------------------- | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | \\\\\ ///// ///// //////////// /////\\\\ | | \\\\\ ///// ///// ///// ///// \\\\\ | | \\\\\ ///// ///// /////////// \\\\\\\\\\\\\\ | | \\\\\/// ///// ///// \\\\\\\\\\\\\\\\ | | \\\\\/ ///// //////////// ///// \\\\\ | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | | XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX | ------------------------------------------------------------- EXTERNAL INTERFACE SPECIFICATION -------------------------------- SECOND GENERATION AUTHORIZATION RECORD FORMATS For Record Formats -------------------------- J - PS/2000 REPS G - VisaNet Dial Debit 1.0 INTRODUCTION 2.0 APPLICABLE DOCUMENTS 2.01 RELATED VISA DOCUMENTS FOR AUTHORIZATION 2.02 RELATED VISA DOCUMENTS FOR DATA CAPTURE 3.0 AUTHORIZATION RECORD FORMATS 3.01 REQUEST RECORD FORMAT 3.02 RESPONSE RECORD FORMAT 4.0 REQUEST RECORD DATA ELEMENT DEFINITIONS 4.01 RECORD FORMAT 4.02 APPLICATION TYPE 4.03 MESSAGE DELIMITER 4.04 ACQUIRER BIN 4.05 MERCHANT NUMBER 4.06 STORE NUMBER 4.07 TERMINAL NUMBER 4.08 MERCHANT CATEGORY CODE 4.09 MERCHANT COUNTRY CODE 4.10 MERCHANT CITY CODE 4.11 TIME ZONE DIFFERENTIAL 4.12 AUTHORIZATION TRANSACTION CODE 4.13 TERMINAL IDENTIFICATION NUMBER 4.14 PAYMENT SERVICE INDICATOR 4.15 TRANSACTION SEQUENCE NUMBER 4.16 CARDHOLDER IDENTIFICATION DATA 4.17 ACCOUNT DATA SOURCE 4.18 CUSTOMER DATA FIELD 4.18.1 TRACK 1 READ DATA 4.18.2 TRACK 2 READ DATA 4.18.3 MANUALLY ENTERED ACCOUNT DATA (CREDIT CARD) 4.18.3.1 MANUALLY ENTERED ACCOUNT NUMBER 4.18.3.2 MANUALLY ENTERED EXPIRATION DATE 4.18.4 CHECK ACCEPTANCE IDENTIFICATION NUMBER 4.18.4.1 CHECK ACCEPTANCE ID 4.18.4.2 MANUALLY ENTERED CHECK ACCEPTANCE DATA 4.19 FIELD SEPARATOR 4.20 CARDHOLDER IDENTIFICATION DATA 4.20.1 STATIC KEY WITH TWENTY THREE BYTE CARDHOLDER ID 4.20.2 STATIC KEY WITH THIRTY TWO BYTE CARDHOLDER ID 4.20.3 DUK/PT KEY WITH THIRTY TWO BYTE CARDHOLDER ID 4.20.4 ADDRESS VERIFICATION SERVICE DESCRIPTION [hmmm...] 4.21 FIELD SEPARATOR 4.22 TRANSACTION AMOUNT 4.23 FIELD SEPARATOR 4.24 DEVICE CODE/INDUSTRY CODE 4.25 FIELD SEPARATOR 4.26 ISSUING INSTITUTION ID/RECEIVING INSTITUTION ID 4.27 FIELD SEPARATOR 4.28 SECONDARY AMOUNT (CASHBACK) 4.29 FIELD SEPARATOR 4.30 MERCHANT NAME 4.31 MERCHANT CITY 4.32 MERCHANT STATE 4.33 SHARING GROUP 4.34 FIELD SEPARATOR 4.35 MERCHANT ABA NUMBER 4.36 MERCHANT SETTLEMENT AGENT NUMBER 4.37 FIELD SEPARATOR 4.38 AGENT NUMBER 4.39 CHAIN NUMBER 4.40 BATCH NUMBER 4.41 REIMBURSEMENT ATTRIBUTE 4.42 FIELD SEPARATOR 4.43 APPROVAL CODE 4.44 SETTLEMENT DATE 4.45 LOCAL TRANSACTION DATE 4.46 LOCAL TRANSACTION TIME 4.47 SYSTEM TRACE AUDIT NUMBER 4.48 ORIGINAL AUTHORIZATION TRANSACTION CODE 4.49 NETWORK IDENTIFICATION CODE 4.50 FIELD SEPARATOR 5.0 RESPONSE RECORD DATA ELEMENT DEFINITIONS 5.01 PAYMENT SERVICE INDICATOR 5.02 STORE NUMBER 5.03 TERMINAL NUMBER 5.04 AUTHORIZATION SOURCE CODE 5.05 TRANSACTION SEQUENCE NUMBER 5.06 RESPONSE CODE 5.07 APPROVAL CODE 5.08 LOCAL TRANSACTION DATE 5.09 AUTHORIZATION RESPONSE CODE 5.10 AVS RESULT CODE 5.11 TRANSACTION IDENTIFIER 5.12 FIELD SEPARATOR 5.13 VALIDATION CODE 5.14 FIELD SEPARATOR 5.15 NETWORK IDENTIFICATION CODE 5.16 SETTLEMENT DATE 5.17 SYSTEM TRACE AUDIT NUMBER 5.18 RETRIEVAL REFERENCE NUMBER 5.19 LOCAL TRANSACTION TIME 6.0 CONFIRMATION RECORD DATA ELEMENT DEFINITIONS 6.01 NETWORK IDENTIFICATION CODE 6.02 SETTLEMENT DATE 6.03 SYSTEM TRACE AUDIT NUMBER 7.0 CHARACTER CODE DEFINITIONS 7.01 TRACK 1 CHARACTER DEFINITION 7.02 TRACK 2 CHARACTER DEFINITION 7.03 AUTHORIZATION MESSAGE CHARACTER SET 7.04 CHARACTER CONVERSION SUMMARY 7.05 ACCOUNT DATA LUHN CHECK 7.06 CALCULATING AN LRC 7.07 TEST DATA FOR RECORD FORMAT "J" 7.07.1 TEST DATA FOR A FORMAT "J" AUTHORIZATION REQUEST 7.07.2 RESPONSE MESSAGE FOR TEST DATA ------------------------------------------------------------------------------- 1.0 INTRODUCTION This document describes the request and response record formats for the VisaNet second generation Point-Of-Sale (POS) authorization terminals and VisaNet Authorization services. This document describes only record formats. Other documents describe communication protocols and POS equipment processing requirements. Figure 1.0 represents the authorization request which is transmitted to VisaNet using public communication services and the authorization response returned by VisaNet. Debit transactions include a third confirmation message. POS DEVICE VISANET ---------- ------- AUTHORIZATION REQUEST | TRANSMITTED TO A |----------> VISANET AUTHORIZATION AUTHORIZATION RESPONSE HOST SYSTEM | | RETURNED BY THE | VISANET HOST TO <--------| THE POS TERMINAL DEBIT RESPONSE CONFIRMATION--------------->TRANSMITTED TO HOST SYSTEM FIGURE 1.0 Authorization request and response. This document describes the record formats to be used for the development of new applications. Current formats or transition formats will be provided on request. The usage of some fields have changed with the new record formats. Applications which were developed to previous specifications will continue to be supported by VisaNet services. The new formats and field usage is provided with the intention of moving all new applications developed to the new formats. 2.0 APPLICABLE DOCUMENTS The following documents provide additional definitions and background. 2.01 RELATED VISA DOCUMENTS FOR AUTHORIZATION 1. EIS1051 - External Interface Specification Second Generation Authorization Link Level Protocol 2.02 RELATED VISA DOCUMENTS FOR DATA CAPTURE 1. EIS1081 - External Interface Specification Second Generation Data Capture Record Formats 2. EIS1052 - External Interface Specification Second Generation Data Capture Link Level Protocol 3.0 AUTHORIZATION RECORD FORMATS This section contains the record formats for the authorization request, response and confirmation records. The ANSI X3.4 character set is used to represent all record data elements. (See Section 7) In the record formats on the following pages, the column heading FORMAT is defined as: "NUM" represents numeric data, the numbers 0 through 9, NO SPACES. "A/N" represents alphanumeric data, the printing character set. "FS" represents a field separator character as defined in ANSI X3.4 as a "1C" hex 3.01 REQUEST RECORD FORMAT Table 3.01b provides the record format for the authorization request records. Section 4 provides the data element definitions. The authorization request record is a variable length record. The record length will depend on the source of the customer data and the type of authorization request. Refer to Table 3.01c to determine which GROUPS to use from Table 3.01a TABLE 3.01a IS PROVIDED FOR REFERENCE REASONS ONLY. ALL NEW APPLICATIONS SHOULD USE ONE OF THE FOLLOWING RECORD FORMATS: RECORD | APPLICATION | FORMAT | TYPE | REMARKS ------------------------------------------------------------------------------- J | CREDIT | All non-ATM card transactions (Visa cards, other credit | | cards, private label credit cards and check guarantee) G | DIAL DEBIT | Visa supported ATM debit cards The selection of format type J and G or any other value from Table 3.01a will depend on the VisaNet services that are desired. Contact your Visa POS member support representative for assistance in determining the required formats. TABLE 3.01a Record Format Summary Non-CVV CVV Terminal Compliant Compliant Generation Description ------------------------------------------------------------------------------- 0 RESERVED 1 N First Vutran 2 8 First Sweda 4 R First Verifone 6 P First Amex 7 3 First Racal A Q First DMC B R First GTE & Omron [velly intelestink] C 9 First Taltek S U First Datatrol - Standard Oil D T First Datatrol E RESERVED 5 F Second Non-REPS-Phase 1 CVV G Second Dial Debit H Second Non-REPS-Phase 2 CVV I Second RESERVED - Non-REPS Controller J Second REPS - Terminal & Controller K Second RESERVED L Second RESERVED - Leased VAP M Second RESERVED - Member Format N-O RESERVED V-Y RESERVED Z Second RESERVED - SDLC Direct [hmmm] ------------------------------------------------------------------------------- TABLE 3.01b Second Generation Authorization Request Record Format see Group Byte# Length Format Name section ------------------------------------------------------------------------------- 1 1 A/N Record Format 4.01 2 1 A/N Application Type 4.02 3 1 A/N Message Delimiter 4.03 4-9 6 NUM Acquirer Bin 4.04 10-21 12 NUM Merchant Number 4.05 22-25 4 NUM Store Number 4.06 26-29 4 NUM Terminal Number 4.07 30-33 4 NUM Merchant Category Code 4.08 34-36 3 NUM Merchant Country Code 4.09 37-41 5 A/N Merchant City Code (ZIP in the U.S.) 4.10 42-44 3 NUM Time Zone Differential 4.11 45-46 2 A/N Authorization Transaction Code 4.12 47-54 8 NUM Terminal Identification Number 4.13 55 1 A/N Payment Service Indicator 4.14 56-59 4 NUM Transaction Sequence Number 4.15 60 1 A/N Cardholder Identification Code 4.16 61 1 A/N Account Data Field 4.17 Variable 1-76 Customer Data Field 4.18.x (See: DEFINITIONS in Table 3.01d) Variable 1 "FS" Field Separator 4.19 Variable 0-32 A/N Cardholder Identification Data 4.20 Variable 1 "FS" Field Separator 4.21 Variable 3-12 NUM Transaction Amount 4.22 Variable 1 "FS" Field Separator 4.23 Variable 2 A/N Device Code/Industry Code 4.24 Variable 1 "FS" Field Separator 4.25 Variable 0-6 NUM Issuing/Receiving Institution ID 4.26 I Variable 1 "FS" Field Separator 4.27 Variable 3-12 NUM Secondary Amount (Cashback) 4.28 II Variable 1 "FS" Field Separator 4.29 Variable 25 A/N Merchant Name 4.30 Variable 13 A/N Merchant City 4.31 Variable 2 A/N Merchant State 4.33 Variable 1-14 A/N Sharing Group 4.33 Variable 1 "FS" Field Separator 4.34 Variable 0-12 NUM Merchant ABA 4.35 Variable 0-4 NUM Merchant Settlement Agent Number 4.36 Variable 1 "FS" Field Separator 4.37 Variable 6 NUM Agent Number 4.38 Variable 6 NUM Chain Number 4.39 Variable 3 NUM Batch Number 4.40 Variable 1 A/N Reimbursement Attribute 4.41 III Variable 1 "FS" Field Separator 4.42 Variable 6 A/N Approval Code 4.43 Variable 4 NUM Settlement Date (MMDD) 4.44 Variable 4 NUM Local Transaction Date (MMDD) 4.45 Variable 6 NUM Local Transaction Time (HHMMSS) 4.46 Variable 6 A/N System Trace Audit Number 4.47 Variable 2 A/N Original Auth. Transaction Code 4.48 Variable 1 A/N Network Identification Code 4.49 IV Variable 1 "FS" Field Separator 4.50 NOTE: The maximum length request can be as long as 290 bytes for an Interlink Debit Cancel request (including the STX/ETX/LRC). Since some terminals may be limited to a 256 byte message buffer, the following tips can save up to 36 bytes: - Limit fields 4.22 and 4.28 to 7 digits - Fields 4.26, 4.35 and 4.36 are not required for a debit request - Field 4.33 can be limited to 10 bytes TABLE 3.01C Legend for GROUP (from Table 3.01b) FOR THESE TRANSACTIONS, USE--------------------------------->GROUPS RECORD I II III IV FORMAT Check guarantee X J Non-ATM card transactions (Visa cards, other X X J credit cards, private label credit cards Visa supported ATM debit cards: Purchase, Return X X X G and Inquiry Request Visa supported ATM debit cards: Interlink Cancel X X X X G Request TABLE 3.01d Definitions for Customer Data Field (from Table 3.01b) Length Format Field Name See Section MAGNETICALLY read credit cards (SELECT ONE): up to 76 A/N Track 1 Read Data 4.18.1 up to 37 NUM Track 2 Read Data 4.18.2 MANUALLY entered credit cards: up to 28 NUM Manually Entered Account Number 4.18.3.1 1 "FS" Field Separator 4 NUM Manually Entered Expiration Date (MMYY) 4.18.3.2 MACHINE read and MANUALLY entered check acceptance requests: 1 to 28 A/N Check Acceptance ID 4.18.4.1 1 "FS" Field Separator 4.18.4.2 3 to 6 A/N Manually Entered Check Acceptance Data 4.18.4.2 MAGNETICALLY read ATM debit cards: up to 37 NUM Track 2 Read Data 4.18.2 3.02 RESPONSE RECORD FORMAT Table 3.02a provides the record format for the authorization response records. Section 5 provides the data element definitions. The authorization response record is variable length for record formats "J" & "G". Refer to Table 3.02b to determine which GROUPS to use from Table 3.02a. Table 3.02a Second Generation Authorization Response Record see Group Byte# Length Format Name section -------------------------------------------------------------------------------- 1 1 A/N Payment Service Indicator 5.01 2-5 4 NUM Store Number 5.02 6-9 4 NUM Terminal Number 5.03 10 1 A/N Authorization Source Code 5.04 11-14 4 NUM Transaction Sequence Number 5.05 15-16 2 A/N Response Code 5.06 17-22 6 A/N Approval Code 5.07 23-28 6 NUM Local Transaction Date (MMDDYY) 5.08 29-44 16 A/N Authorization Response Message 5.09 45 1 A/N AVS Result Code 5.10 Variable 0/15 NUM Transaction Identifier 5.11 Variable 1 "FS" Field Separator 5.12 Variable 0/4 A/N Validation Code 5.13 I Variable 1 "FS" Field Separator 5.14 Variable 1 A/N Network Identification Code 5.15 Variable 4 NUM Settlement Date (MMDD) 5.16 Variable 6 A/N System Trace Audit Number 5.17 Variable 12 A/N Retrieval Reference Number 5.18 II Variable 6 NUM Local Transaction Time (HHMMSS) 5.19 Table 3.02b Legend for GROUP (from Table 3.02a) FOR THESE TRANSACTIONS, USE--------------------------------->GROUPS RECORD I II FORMAT All non-ATM card transactions (Visa cards, other credit X J cards, private label credit cards and check guarantee) Visa supported ATM debit cards: Purchase, Return, Inquiry X X G Request and Interlink Cancel Request 3.03 CONFIRMATION RECORD FORMAT (ATM DEBIT ONLY) Table 3.03 provides the record format for the second generation debit response confirmation record. Section 6 provides the data element definitions. The debit response confirmation record is a fixed length record. TABLE 3.03 Second Generation Debit Response Confirmation Record see Group Byte# Length Format Name section -------------------------------------------------------------------------------- 1 1 A/N Network ID Code 6.01 2-5 4 NUM Settlement Date (MMDD) 6.02 I 6-11 6 A/N System Trace Audit Number 6.03 4.0 REQUEST RECORD DATA ELEMENT DEFINITIONS The following subsections will define the authorization request record data elements. 4.01 RECORD FORMAT There are several message formats defined within the VisaNet systems. The second generation authorization format is specified by placing one of the defined values in the record format field. Table 4.01 provides a brief summary of the current formats. TABLE 4.01 VisaNet Authorization Record Format Designators RECORD FORMAT RECORD DESCRIPTION -------------------------------------------------------------------------------- J All non-ATM card transactions (Visa cards, other credit cards, private label credit cards and check guarantee) G Visa supported ATM debit cards 4.02 APPLICATION TYPE The VisaNet authorization system supports multiple application types ranging from single thread first generation authorization to interleaved leased line authorization processing. Table 4.02 provides a summary of application type. TABLE 4.02 VisaNet Application Designators APPLICATION USE WITH TYPE APPLICATION DESCRIPTION REC. FMT. -------------------------------------------------------------------------------- 0 Single authorization per connection J and G 2 Multiple authorizations per connection J and G single-threaded 4 Multiple authorizations per connect, J interleaved 6 Reserved for future use --- 8 Reserved for future use --- 1,3,5,7 Reserved for VisaNet Central Data Capture (CDC) --- 9 Reserved for VisaNet Down Line Load --- A-Z Reserved for future use --- 4.03 MESSAGE DELIMITER The message delimiter separates the format and application type designators from the body of the message. The message delimiter is defined as a "." (period) 4.04 ACQUIRER BIN This field contains the Visa assigned six-digit Bank Identification Number (BIN) The acquirer BIN identifies the merchant signing member that signed the merchant using the terminal. NOTE: The merchant receives this number from their signing member. 4.05 MERCHANT NUMBER This field contains a NON-ZERO twelve digit number, assigned by the signing member and/or the merchant, to identify the merchant within the member systems. The combined Acquirer BIN and Merchant Number are required to identify the merchant within the VisaNet systems. 4.06 STORE NUMBER This field contains a NON-ZERO four-digit number assigned by the signing member and/or the merchant to identify the merchant store within the member systems. The combined Acquirer BIN, Merchant Number, and Store Number are required to identify the store within the VisaNet systems. 4.07 TERMINAL NUMBER This field contains a NON-ZERO four-digit number assigned by the signing member and/or the merchant to identify the merchant store within the member systems. This field can be used by systems which use controllers and/or concentrators to identify the devices attached to the controllers and/or concentrators. 4.08 MERCHANT CATEGORY CODE This field contains a four-digit number assigned by the signing member from a list of category codes defined in the VisaNet Merchant Data Standards Handbook to identify the merchant type. 4.09 MERCHANT COUNTRY CODE This field contains a three-digit number assigned by the signing member from a list of country codes defined in the VisaNet V.I.P. System Message Format Manuals to identify the merchant location country. 4.10 MERCHANT CITY CODE This field contains a five character code used to further identify the merchant location. Within the United States, the give high order zip code digits of the address of the store location are used. Outside of the United States, this field will be assigned by the signing member. 4.11 TIME ZONE DIFFERENTIAL This field contains a three-digit code used to calculate the local time within the VisaNet authorization system. It is calculated by the signing member, providing the local time zone differential from Greenwich Mean Time (GMT). The first two digits specify the magnitude of the differential. Table 4.11 provides a brief summary of the Time Zone Differential codes. TABLE 4.11 Time Zone Differential Code Format Byte # Length Format Contents -------------------------------------------------------------------------------- 1 1 NUMERIC DIRECTION 0 = Positive, Local Ahead of GMT, offset in hours 1 = Negative, Local Time behind GMT, offset in hours 2 = Positive, offset in 15 minute increments 3 = Negative, offset in 15 minute increments 4 = Positive, offset in 15 minute increments, participating in daylight savings time 5 = Negative, offset in 15 minute increments, participating in daylight savings time 6-9 = INVALID CODES 2-3 2 NUMERIC MAGNITUDE For Byte #1 = 0 or 1 0 <= MAGNITUDE <= 12 For Byte #1 = 2 through 5 0 <= MAGNITUDE <= 48 -------------------------------------------------------------------------------- A code of 108 indicates the local Pacific Standard time which is 8 hours behind GMT. 4.12 AUTHORIZATION TRANSACTION CODE This field contains a two-character code defined by VisaNet and generated by the terminal identifying the type of transaction for which the authorization is requested. Table 4.12 provides a summary of the transaction codes. TABLE 4.12 Authorization Transaction Codes TRAN CODE TRANSACTION DESCRIPTION ------------------------------------------------------------------------------- 54 Purchase 55 Cash Advance 56 Mail/Telephone Order 57 Quasi Cash 58 Card Authentication - Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested [ah-hah!] 64 Repeat: Purchase 65 Repeat: Cash Advance 66 Repeat: Mail/Telephone Order (MO/TO) 67 Repeat: Quasi Cash 68 Repeat: Card Authentication - Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested 70 Check guarantee, must include RIID (field 4.26) 81 Proprietary Card 84 Private Label Purchase 85 Private Label, Cash Advance 86 Private Label Mail/Telephone Order (MO/TO) 87 Private Label Quasi Cash 88 Private Label Card Authentication - Transaction Amt & Secondary Amt must equal $0.00, AVS may be requested 93 Debit Purchase 94 Debit Return 95 Interlink Debit Cancel (see NOTE below) -------------------------------------------------------------------------------- NOTE (for TRANSACTION CODE = 95) -------------------------------- - For Interlink Debit CANCEL request message, all of the fields in Groups I and II will come from the original transaction request or the original transaction response, with the exception of the following: - The AUTHORIZATION TRANSACTION CODE will need to be changed to the Debit CANCEL code. - The TRANSACTION SEQUENCE NUMBER should be incremented in the normal fashion. - The CUSTOMER DATA FIELD and the CARDHOLDER IDENTIFICATION DATE (PIN) will need to be re-entered. 4.13 TERMINAL IDENTIFICATION NUMBER This field contains an eight-digit code that must be greater than zero, defined by the terminal down line load support organization. Support may be provided by the Visa's Merchant Assistance Center (MAC), the signing member, or a third party organization. The terminal ID is used to uniquely identify the terminal in the terminal support system and identification for the VisaNet Central Data Capture (CDC). The terminal ID may not be unique within the VisaNet system. Each terminal support provider and member that provides its own terminal support can assign potentially identical terminal IDs within its system. The terminal ID can be used by the terminal down line load system to access the terminal application and parameter data from a system data base when down line loading a terminal. [huh?] NOTE: It is recommended that [the] Terminal ID Number should be unique within the same Acquirer's BIN. 4.14 PAYMENT SERVICE INDICATOR This is a one-character field used to indicate a request for REPS qualification. Table 4.14 provides a summary of the codes. TABLE 4.14 Payment Service Indicator Codes RECORD FORMAT VALUE DESCRIPTION ------------------------------ J Y Yes J N No G Y Yes G N No ------------------------------ [repetitive? you bet] 4.15 TRANSACTION SEQUENCE NUMBER This field contains a four-digit code which is generated by the terminal as the sequence number for the transaction. The sequence number is used by the terminal to match request and response messages. This field is returned by VisaNet without sequence verification. The sequence number is incremented with wrap from 9999 to 0001. 4.16 CARDHOLDER IDENTIFICATION CODE This one-character field contains a code that indicates the method used to identify the cardholder. Table 4.16 provides a summary of the codes. TABLE 4.16 Cardholder Identification Codes ID CODE IDENTIFICATION METHOD -------------------------------------------------------------------------------- A Personal Identification Number-23 byte static key (non-USA) fnord B PIN at Automated Dispensing Machine - 32 byte static key C Self Svc Limited Amount Terminal (No ID method available) D Self-Service Terminal (No ID method available) E Automated Gas Pump (No ID method available) K Personal Identification Number - 32 byte DUK/PT N Customer Address via Address Verification Service (AVS) S Personal Identification Number - 32 byte static key Z Cardholder Signature - Terminal has a PIN pad @ Cardholder Signature - No PIN pad available F-J,L,M,O-R Reserved for future use T-Y -------------------------------------------------------------------------------- 4.17 ACCOUNT DATA SOURCE This field contains a one-character code defined by Visa and generated by the terminal to indicate the source of the customer data entered in field 4.18. Table 4.17 provides a summary of codes TABLE 4.17 Account Data Source Codes ACCOUNT DATA SOURCE CODE ACCOUNT DATA SOURCE CODE DESCRIPTION -------------------------------------------------------------------------------- A RESERVED - Bar-code read B RESERVED - OCR read D Mag-stripe read, Track 2 H Mag-stripe read, Track 1 Q RESERVED - Manually keyed, bar-code capable terminal R RESERVED - Manually keyed, OCR capable terminal T Manually keyed, Track 2 capable X Manually keyed, Track 1 capable @ Manually keyed, terminal has no card reading capability C,E-G,I-P,S, RESERVED for future use U-W,Y-Z,0-9 -------------------------------------------------------------------------------- NOTE: - If a dual track reading terminal is being used, be sure to enter the correct value of "D" or "H" for the magnetic data that is transmitted - When data is manually keyed at a dual track reading terminal, enter either a "T" or an "X" 4.18 CUSTOMER DATA FIELD This is a variable length field containing customer account or check acceptance ID data in one of three formats. The cardholder account information can be read d from the card or it may be entered manually. Additionally the terminal can be used for check authorization processing with the check acceptance identification number entered by the operator for transmission in this field. NOTE: For all POS terminals operated under VISA U.S.A. Operating Regulations, the following requirement must be available as an operating option if the merchant location is found to be generating a disproportionately high percentage of Suspect Transactions [lets get downright hostile about it] as defined in chapter 9.10 of the VISA U.S.A. Operating Regulations. Specifically, chapter 9.10.B.2 requires that: - The terminal must read the track data using a magnetic stripe reading terminal - The terminal must prompt the wage slave to manually enter the last four digits of the account number - The terminal must compare the keyed data with the last four digits of the account number in the magnetic stripe - If the compare is successful, the card is acceptable to continue in the authorization process and the terminal must transmit the full, unaltered contents of the magnetic stripe in the authorization message. - If the compare fails, the card should not be honored at the Point of Sale 4.18.1 TRACK 1 READ DATA This is a variable length field with a maximum data length of 76 characters. The track 1 data read from the cardholder's card is checked for parity and LRC errors and then converted from the six-bit characters encoded on the card to seven-bit characters as defined in ANSI X3.4. The character set definitions are provided in section 7 for reference. As part of the conversion the terminal will strip off the starting sentinel, ending sentinel, and LRC characters. The separators are to be converted to a "^" (HEX 5E) character. The entire track must be provided in the request message. The character set and data content are different between track 1 and track 2. The data read by a track 2 device can not be correctly reformatted and presented as though it were read by a track 1 device. [aw shucks] The converted data can not be modified by adding or deleting non-framing characters and must be a one-for-one representation of the character read from the track. 4.18.2 TRACK 2 READ DATA This is a variable length field with a maximum data length of 37 characters. The track 2 data read from the cardholder's card is checked for parity and LRC errors and then converted from the six-bit characters encoded on the card to seven-bit characters as defined in ANSI X3.4. The character set definitions are provided in section 7 for reference. As part of the conversion the terminal will strip off the starting sentinel, ending sentinel, and LRC characters. The separators are to be converted to a "^" (HEX 5E) character. The entire track must be provided in the request message. The character set and data content are different between track 2 and track 1. The data read by a track 1 device can not be correctly reformatted and presented as though it were read by a track 2 device. The converted data can not be modified by adding or deleting non-framing characters and must be a one-for-one representation of the character read from the track. [repetitive? you bet] 4.18.3 MANUALLY ENTERED ACCOUNT DATA (CREDIT CARD) The customer credit card data may be key entered when the card can not be read, when a card is not present, or when a card reader is not available. 4.18.3.1 MANUALLY ENTERED ACCOUNT NUMBER This is a variable length field consisting of 5 to 28 alphanumeric characters. The embossed cardholder data, that is key entered, is validated by the terminal using rules for each supported card type. For example, both Visa and Master Card include a mod 10 check digit as the last digit of the Primary Account Number. The Primary Account Number (PAN) is encoded as seven-bit characters as defined in ANSI X3.4. The PAN is then provided in the manually entered record format provided in Table 3.01b. The PAN must be provided without embedded spaces. 4.18.3.2 MANUALLY ENTERED EXPIRATION DATE This four-digit field contains the card expiration date in the form MMYY (month- month-year-year) 4.18.4 CHECK ACCEPTANCE IDENTIFICATION NUMBER The customer data may be card read or manually key entered for check acceptance transactions. 4.18.4.1 CHECK ACCEPTANCE ID This field is a variable length field consisting of 1 to 28 alphanumeric characters. The check acceptance vendor will provide the data format and validation rules to be used by the terminal. Typically the ID consists of a two-digit state code and an ID which may be the customer's drivers license number. 4.18.4.2 MANUALLY ENTERED CHECK ACCEPTANCE DATA This six-character field contains the customer birth date or a control code in the form specified by the check acceptance processor. 4.19 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.20 CARDHOLDER IDENTIFICATION DATA This field will be 0, 23, 29 or 32 characters in length. The cardholder ID codes shown in Table 4.16 indicates the type of data in this field. Table 4.20 provides a brief summary of the current formats. TABLE 4.20 Cardholder Identification Data Definitions CARDHOLDER VALUE(S) FROM ID LENGTH DESCRIPTION TABLE 4.16 -------------------------------------------------------------------------------- 0 Signature ID used, No PIN pad is present @,C,D or E 0 Signature ID used on a terminal with a PIN pad Z 23 A PIN was entered on a STATIC key PIN pad A 32 A PIN was entered on a STATIC key PIN pad B 32 A PIN was entered on a DUK/PT key PIN pad K 32 A PIN was entered on a STATIC key PIN pad S 0 to 29 AVS was requested N -------------------------------------------------------------------------------- 4.20.1 STATIC KEY WITH TWENTY THREE BYTE CARDHOLDER ID NOTE: The 23 byte static key technology is NOT approved for use in terminals deployed in the Visa U.S.A. region. [thanks nsa!] When a PIN is entered on a PIN pad supporting 23 byte static key technology, the terminal will generate the following data: 1JFxxyyaaaaaaaaaaaaaaaa Where: 1J Header - PIN was entered f Function Key Indicator - A single byte indicating which, if any, function key was pressed on the PIN pad. This field is currently not edited. Any printable character is allowed. xx PIN Block Format - These two numeric bytes indicate the PIN encryption method used to create the encrypted PIN block. Visa currently supports four methods; 01, 02, 03, & 04. For more information, please refer to the VisaNet Standards Manual, Card Technology Standards, PIN and Security Standards, Section 2, Chapter 3, PIN Block Formats aaaaaaaaaaaaaaaa Expanded Encrypted PIN Block Data - The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using Table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field. 4.20.2 STATIC KEY WITH THIRTY TWO BYTE CARDHOLDER ID When a PIN is entered on a PIN pad supporting 32 byte static key technology, the terminal will generate the following data: aaaaaaaaaaaaaaaa2001ppzz00000000 Where: aaaaaaaaaaaaaaaa - Expanded Encrypted PIN Block Data - The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field. 20 - Security Format Code - This code defines that the Zone Encryption security technique was used. 01 - PIN Encryption Algorithm Identifier - This code defines that the ANSI DES encryption technique was used. pp - PIN Block Format Code - This code describes the PIN block format was used by the acquirer. Values are: 01 - Format is based on the PIN, the PIN length, selected rightmost digits of the account number and the pad characters "0" and "F"; combined through an exclusive "OR" operation. 02 - Format is based on the PIN, the PIN length and a user specified numeric pad character. 03 - Format is based on the PIN and the "F" pad character. 04 - Format is the same as "01" except that the leftmost account number digits are selected. zz - Zone Key Index - This index points to the zone key used by the acquirer to encrypt the PIN block. Values are: 01 - First key 02 - Second key 00000000 - Visa Reserved - Must be all zeros For additional information, refer to the VisaNet manual V.I.P. System, Message Formats, Section B: Field Descriptions. Specifically, fields 52 and 53; Personal Identification Number (PIN) Data and Security Related Control Information respectively. 4.20.3 DUK/PT KEY WITH THIRTY TWO BYTE CARDHOLDER ID When a PIN is entered on a PIN pad supporting DUK/PT technology, the terminal will generate the following 32 bytes: aaaaaaaaaaaaaaaakkkkkkssssssssss Where: aaaaaaaaaaaaaaaa - Expanded Encrypted PIN Block Data - The encrypted PIN block format consists of 64 bits of data. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 64 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand the 64 bit encrypted PIN block, remove four bits at a time and convert them to ANSI X3.4 characters using table 4.20. After this conversion, the 64 bit encrypted PIN block will consist of 16 characters that will be placed in the Expanded Encrypted PIN Block Data field. [repetitive? you bet] kkkkkk - Key Set Identifier (KSID) - Is represented by a unique, Visa Visa assigned, six digit bank identification number. ssssssssss - Expanded TRSM ID (PIN Pad Serial Number) & Expanded Transaction Counter - Is represented by the concatenation of these two hexadecimal fields. The PIN pad serial number is stored as five hex digits minus one bit for a total of 19 bits of data. The transaction counter is stored as five hex digits plus one bit for a total of 21 bits of data. These two fields concatenated together will contain 40 bits. Since the VisaNet Second Generation protocol allows only printable characters in data fields, these 40 bits must be expanded to ensure that no values less than hex "20" are transmitted. To expand this 40 bit field, remove four bits at a time and convert them to ASCII characters using table 4.20. After this conversion, this 40 bit field will consist of 10 characters that will be placed in the Expanded TRSM ID & Expanded Transaction Counter Field. TABLE 4.20 PIN Block conversion Table HEXADECIMAL | ANSI X3.4 DATA | CHARACTER --------------+---------------- 0000 | 0 0001 | 1 0010 | 2 0011 | 3 0100 | 4 0101 | 5 0110 | 6 0111 | 7 1000 | 8 1001 | 9 1010 | A 1011 | B 1100 | C 1101 | D 1110 | E 1111 | F ------------------------------- 4.20.4 ADDRESS VERIFICATION SERVICE DESCRIPTION [ah enlightenment] When Address Verification Service is requested, this field will contain the mailing address of the cardholder's monthly statement. The format of this field is: or Numbers are not spelled out. ("First Street" becomes "1ST Street", "Second" becomes "2ND", etc) "Spaces" are only required between a numeral and the ZIP code. For instance: 1391 ELM STREET 40404 is equivalent to: 1931ELMSTREET40404 P.O. Box 24356 55555 is not equivalent to P.O.BOX2435655555 If a field is not available or not applicable, it may be skipped. If nine digits are available, the last five digits should always be used to pour more sand into the wheels of progress. 4.21 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character.