The Hacker's Encyclopedia 1998

home *** CD-ROM | disk | FTP | other *** search

/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / zines / phrack2 / phrack46.016 < prev next >

Wrap

Text File | 2003-06-11 | 43.4 KB | 944 lines

==Phrack Magazine== Volume Five, Issue Forty-Six, File 16 of 28 **************************************************************************** VisaNet Operations (Continued) 4.22 TRANSACTION AMOUNT This is a variable field from three to twelve digits in length. The transaction amount includes the amount in 4.28, Secondary Amount. Therefore, field 4.22 must be greater than or equal to field 4.28. The transaction amount is presented by the terminal with an implied decimal point. For example $.01 would be represented in the record as "001". When the terminal is used with an authorization system which supports the US dollar as the primary currency, the amount field must be limited to seven digits (9999999). [...] The terminal may be used with authorization system which support other currencies that require the full twelve-digit field. 4.23 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.24 DEVICE CODE/INDUSTRY CODE This field is used to identify the device type which generated the transaction and the industry type of the merchant. Table 4.24 provides a brief summary of the current codes. TABLE 4.24 Device Code/Industry Code C C O O D D E DEVICE TYPE E INDUSTRY TYPE ------------------------------------------------------------------------------- 0 Unknown or Unsure 0 Unknown or Unsure 1 RESERVED 1 RESERVED 2 RESERVED 2 RESERVED 3 RESERVED 3 RESERVED 4 RESERVED 4 RESERVED 5 RESERVED 5 RESERVED 6 RESERVED 6 RESERVED 7 RESERVED 7 RESERVED 8 RESERVED 8 RESERVED 9 RESERVED 9 RESERVED A RESERVED A RESERVED B RESERVED B Bank/Financial Institution C P.C. C RESERVED D Dial Terminal D RESERVED E Electronic Cash Register (ECR) E RESERVED F RESERVED F Food/Restaurant G RESERVED G Grocery Store/Supermarket H RESERVED H Hotel I In-Store Processor I RESERVED J RESERVED J RESERVED K RESERVED K RESERVED L RESERVED L RESERVED M Main Frame M Mail Order N RESERVED N RESERVED O RESERVED O RESERVED P POS-port P RESERVED Q RESERVED for POS-port Q RESERVED R RESERVED R Retail S RESERVED S RESERVED T RESERVED T RESERVED U RESERVED U RESERVED V RESERVED V RESERVED W RESERVED W RESERVED X RESERVED X RESERVED Y RESERVED Y RESERVED Z RESERVED Z RESERVED -------------------------------------------------------------------------------- 4.25 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.26 ISSUING INSTITUTION ID/RECEIVING INSTITUTION ID This six-digit field is provided by the merchant signing member and is present when the terminal is used to process transactions which can not be routed using the cardholder Primary Account Number. When a value is present in this field, it is used as an RIID for all valid transaction codes, field 4.12, except 81 through 88. This field is used as an IIID for transaction codes 81 through 88. Table 4.26 provides a summary of the RIID codes for check acceptance. TABLE 4.26 Check Acceptance RIID Values Vendor RIID --------------------------- JBS, Inc 810000 Telecheck 861400 TeleCredit, West 894300 [note; telecredit has been TeleCredit, East 894400 mutated/eaten by equifax] --------------------------- 4.27 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.28 SECONDARY AMOUNT (CASHBACK) NOTE: "Cashback" is NOT allowed on Visa cards when the Customer Data Field, see section 4.18, has been manually entered. This is a variable length field from three to twelve digits in length. The Secondary Amount is included in field 4.22, Transaction Amount. The secondary amount is presented by the terminal with an implied decimal point. For example $.01 would be represented in the record as "001". This field will contain 000 when no secondary amount has been requested. Therefore, when the terminal is used with an authorization system which supports the US dollar as the primary currency, the secondary amount field must be limited to seven digits (9999999). The terminal may be used with authorization systems which support other currencies that require the full twelve-digit field. 4.29 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.30 MERCHANT NAME This 25-character field contains the merchant name provided by the signing member. the name must correspond to the name printed on the customer receipt. The name is left justified with space fill. The first character position can not be a space. This field must contain the same used in the data capture batch. 4.32 MERCHANT STATE This two-character field contains the merchant location state abbreviation provided by the singing member. The abbreviation must correspond to the state name printed on the customer receipt and be one of the Visa accepted abbreviations. This field must contain the same data used in the data capture batch. 4.33 SHARING GROUP This one to fourteen-character field contains the group of debit card/network types that a terminal may have access to and is provided by the singing member. The values must correspond to one of the Visa assigned debit card /network types. This data is part of the VisaNet debit data. 4.34 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.35 MERCHANT ABA NUMBER This fixed length field is twelve digits in length. If this field is not used, its length must be zero. If this field is not used, the following field must also be empty. This number identifies the merchant to a debit switch provided by the signing member. The number is provided by the signing member. 4.36 MERCHANT SETTLEMENT AGENT NUMBER This fixed length field is four digits in length. If this field is not used, its length must be zero. If this field is not used, the previous field must also be empty. This number identifies the merchant settling agent. The number is provided by the signing member. 4.37 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.38 AGENT NUMBER This six-digit field contains an agent number assigned by the signing member. The number identifies an institution which signs merchants as an agent of a member. The member uses this number to identify the agent within the member systems. The acquirer BIN, Agent, Chain, Merchant, Store, and Terminal numbers are required to uniquely identify a terminal within the VisaNet systems. 4.39 CHAIN NUMBER This six-digit field contains a merchant chain identification number assigned by the singing member. The member uses this number to identify the merchant chain within the member systems. The acquirer BIN, Agent, Chain, Merchant, Store, and Terminal numbers are required to uniquely identify a terminal within the VisaNet systems. 4.40 BATCH NUMBER This three-digit field contains a batch sequence number generated by the terminal. The number will wrap from 999 to 001. This number is that data capture batch number. 4.41 REIMBURSEMENT ATTRIBUTE This is a single character fixed length field. This field contains the reimbursement attribute assigned by the singing member. This field must be a "space". 4.42 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 4.43 APPROVAL CODE This contains a six-character fixed length field. This field is only present in cancel transactions and contains the original approval code from the original transaction. The approval code was returned in the authorization response of the transaction to be canceled. 4.44 SETTLEMENT DATE This contains a four-digit fixed length field. This field is only present in cancel transactions and contains the settlement date from the original transaction and is in the format MMDD. The settlement date was returned in the authorization response of the transaction to be canceled. 4.45 LOCAL TRANSACTION DATE This contains a four-digit fixed length field. This field is only present in cancel transactions and contains the transaction date from the original transaction and is in the format MMDD. The transaction date was returned in the authorization response of the transaction to be canceled as MMDDYY. 4.46 LOCAL TRANSACTION TIME This contains a six-digit fixed length field. This field is only present in cancel transactions and contains the transaction time from the original transaction and is in the format HHMMSS. The transaction time was returned in the authorization response of the transaction to be canceled. 4.47 SYSTEM TRACE AUDIT NUMBER This contains a six-character fixed length field. This field is only present in cancel transactions and contains the trace audit number from the original transaction. The trace audit number was returned in the authorization response of the transaction to be canceled. 4.48 ORIGINAL AUTHORIZATION TRANSACTION CODE The field is a two-character fixed length field and must contain the original AUTHORIZATION TRANSACTION CODE (filed 4.12) of the transaction to be canceled. Currently, the only transaction that can be canceled in an Interlink Debit Purchase. 4.49 NETWORK IDENTIFICATION CODE This contains a single character fixed length field. This field is only present in cancel transactions and contains the network ID from the original transaction. The network ID was returned in the authorization response of the transaction to be canceled. 4.50 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 5.0 RESPONSE RECORD DATA ELEMENT DEFINITIONS The following subsections will define the authorization response record data elements. 5.01 PAYMENT SERVICE INDICATOR This field contains the one-character payment service indicator. It must be placed in the batch detail record for terminals that capture. Table 5.01 provides a summary of current Values. TABLE 5.01 Payment Service Indicator Values VALUE DESCRIPTION ------------------------------------------------------------------ A REPS qualified Y Requested a "Y" in field 4.14 and there was a problem REPS denied (VAS edit error or BASE I reject) N Requested an "N" in field 4.14 or requested a "Y" in field 4.14 and request was downgraded (by VAS) space If "Y" sent and transaction not qualified (VAS downgrade) ------------------------------------------------------------------- 5.02 STORE NUMBER This four-digit number is returned by VisaNet from the authorization request for formats "J" and "G", and can be used to route the response within a store controller and/or a store concentrator. 5.03 TERMINAL NUMBER This four-digit number is returned by VisaNet from the authorization request for formats "J" and "G", and can be used to route the response within a store controller and/or a store concentrator. 5.04 AUTHORIZATION SOURCE CODE This field contains a one-character code that indicates the source of the authorization. The received code must be placed in the data capture detail transaction record when data capture is enabled. Table 5.04 provides a summary of current codes. TABLE 5.04 Authorization Source Codes Code Description -------------------------------------------------------------------------------- 1 STIP: time-out response 2 LCS: amount below issuer limit 3 STIP: issuer in Suppress-Inquiry mode 4 STIP: issuer unavailable 5 Issuer approval 6 Off-line approval, POS device generated 7 Acquirer approval: BASE I unavailable 8 Acquirer approval of a referral 9 Use for non-authorized transactions; such as credit card credits [yum!] D Referral: authorization code manually keyed E Off-line approval: authorization code manually keyed -------------------------------------------------------------------------------- 5.05 TRANSACTION SEQUENCE NUMBER This field contains the four-digit code which was generated by the terminal as the sequence number for the transaction and passed to the authorization center in the authorization request record. The sequence number can be used by the terminal to match request and response messages. The transaction sequence number is returned by VisaNet without sequence verification. 5.06 RESPONSE CODE This field contains a two-character response code indicating the status of the authorization. Table 5.06 provides the response codes for formats "J" and "G". A response code of "00" represents an approval. A response code of "85" represents a successful card verification returned by TRANSACTION CODES 58, 68, and 88. All other response codes represent a non-approved request. The value returned is stored in the batch transaction detail record for terminals that capture. TABLE 5.06 Authorization Response Codes For Record Formats "J" & "G" Authorization Response AVS Result Response Message Code Response Definition Code -------------------------------------------------------------------------------- EXACT MATCH 00 Exact Match, 9 digit zip X EXACT MATCH 00 Exact Match, 5 digit zip GRIND Y ADDRESS MATCH 00 Address match only A ZIP MATCH 00 9-digit zip match only W ZIP MATCH 00 5-digit zip match only GRIND Z NO MATCH 00 No address or zip match N VER UNAVAILABLE 00 Address unavailable U RETRY 00 Issuer system unavailable R ERROR INELIGIBLE 00 Not a mail/phone order E SERV UNAVAILABLE 00 Service not supported S APPROVAL 00 Approved and completed see above CARD OK 85 No reason to decline see above CALL 01 Refer to issuer 0 CALL 02 Refer to issue - Special condition 0 NO REPLY 28 File is temporarily unavailable 0 NO REPLY 91 Issuer or switch is unavailable 0 HOLD-CALL 04 Pick up card 0 HOLD-CALL 07 Pick up card - Special condition 0 HOLD-CALL 41 Pick up card - Lost 0 HOLD-CALL 43 Pick up card - Stolen 0 ACCT LENGTH ERR EA Verification Error 0 ALREADY REVERSED 79 Already Reversed at Switch [ya got me] 0 AMOUNT ERROR 13 Invalid amount 0 CAN'T VERIFY PIN 83 Can not verify PIN 0 CARD NO ERROR 14 Invalid card number 0 CASHBACK NOT APP 82 Cashback amount not approved 0 CHECK DIGIT ERR EB Verification Error 0 CID FORMAT ERROR EC Verification Error 0 DATE ERROR 80 Invalid Date 0 DECLINE 05 Do not honor 0 DECLINE 51 Not Sufficient Funds 0 DECLINE 61 Exceeds Withdrawal Limit 0 DECLINE 65 Activity Limit Exceeded 0 ENCRYPTION ERROR 81 Cryptographic Error 0 ERROR xx 06 General Error 0 ERROR xxxx 06 General Error 0 EXPIRED CARD 54 Expired Card 0 INVALID ROUTING 98 Destination Not Found 0 INVALID TRANS 12 Invalid Transaction 0 NO CHECK ACCOUNT 52 No Check Account 0 NO SAVE ACCOUNT 54 No Save Account 0 NO SUCH ISSUER 15 No Such Issuer 0 RE ENTER 19 Re-enter Transaction 0 SEC VIOLATION 63 Security Violation 0 SERV NOT ALLOWED 57 Trans. not permitted-Card 0 SERV NOT ALLOWED 58 Trans. not permitted-Terminal 0 SERVICE CODE ERR 62 Restricted Card 0 SYSTEM ERROR 96 System Malfunction [whoop whoop!] 0 TERM ID ERROR 03 Invalid Merchant ID 0 WRONG PIN 55 Incorrect PIN 0 xxxxxxxxxxxxxxxxxx xx Undefined Response 0 -------------------------------------------------------------------------------- 5.07 APPROVAL CODE This field contains a six-character code when a transaction has been approved. If the transaction is not approved the contents of the field should be ignored. The approval code is input to the data capture detail transaction record. 5.08 LOCAL TRANSACTION DATE This field contains a six-digit local date calculated (MMDDYY) by the authorization center using the time zone differential code provided in the authorization request message. This date is used by the terminal as the date to be printed on the transaction receipts and audit reports, and as the date input to the data capture transaction detail record. This field is only valid for approved transactions. 5.09 AUTHORIZATION RESPONSE MESSAGE This field is a sixteen-character field containing a response display message. This message is used by the terminal to display the authorization results. Table 5.06 provides the message summary. The messages are provided with "sp" space fill. This field is mapped to the RESPONSE CODE, field 5.06, for all non-AVS transactions and for all DECLINED AVS transactions. For APPROVED AVS transactions (response code = "00" or "85"), it is mapped to the AVS RESULT CODE, field 5.10. 5.10 AVS RESULT CODE This one-character field contains the address verification result code. An address verification result code is provided for transactions and provides an additional indication that the card is being used by the person to which the card was issued. The service is only available for mail/phone order transactions. Table 5.06 provides a summary of the AVS Result Codes. An ANSI X3.4 "0" is provided for all non-AVS transactions and all declined transactions. 5.11 TRANSACTION IDENTIFIER This numeric field will contain a transaction identifier. The identifier will be fifteen-digits in length if the payment service indicator value is an "A" or it will be zero in length if the payment service indicator value is not an "A". This value is stored in the batch detail record for terminals that capture and is mandatory for REPS qualification. 5.12 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 5.13 VALIDATION CODE This alphanumeric field will contain a validation code. The code will contain a four-character value if the payment service indicator value is an "A" or it will be zero in length if the payment service indicator value is not an "A". This value is stored in the batch detail record for terminals that capture and is mandatory for REPS qualification. 5.14 FIELD SEPARATOR The authorization record format specifies the use of the "FS" character. 5.15 NETWORK IDENTIFICATION CODE This one-character fixed length field contains the identification code of the network on which the transaction was authorized. The network ID must be printed on the receipt. 5.16 SETTLEMENT DATE This four-digit fixed length field contains the transaction settlement date returned by the authorizing system (MMDD). The settlement date must be printed on the receipt. 5.17 SYSTEM TRACE AUDIT NUMBER This six-character fixed length field contains a trace audit number which is assigned by the authorizing system. The trace audit number must be printed on the receipt. 5.18 RETRIEVAL REFERENCE NUMBER This twelve-character fixed length field contains the transaction retrieval reference number returned by the authorizing system. The reference number should be printed on the receipt. 5.19 LOCAL TRANSACTION TIME This six-digit fixed length field contains the transaction time returned by the authorizing system (HHMMSS). The time must be printed on the receipt. 6.0 CONFIRMATION RECORD DATA ELEMENT DEFINITIONS The following subsections define the debit confirmation response record data elements. 6.01 NETWORK IDENTIFICATION CODE This one character fixed length field contains the identification code of the network on which the transaction was authorized. The network ID is printed on the receipt. 6.02 SETTLEMENT DATE This four-digit fixed length field contains the transaction settlement date returned by the authorizing system. 6.03 SYSTEM TRACE AUDIT NUMBER This six-character fixed length field contains the system trace audit number which is assigned by the authorizing system. 7.0 CHARACTER CODE DEFINITIONS The following subsections will define the authorization request record character set and character sets used for track 1 and track 2 data encoded on the magnetic stripes. The authorization request records are generated with characters defined by ANSI X3.4-1986. The data stored on the cardholder's card in magnetic or optical form must be converted to the ANSI X3.4 character set before transmission to VisaNet. Section 7.01 provides track 1 character set definition. Section 7.02 provides track 2 character set definition. Section 7.03 provides the ANSI X3.4-1986 and ISO 646 character set definitions. Section 7.04 provides a cross reference between the track 1, track 2, and ANSI X3.4 character sets. Section 7.05 describes the method for generating and checking the Mod 10 Luhn check digit for credit card account numbers. Section 7.06 describes the method for generating the LRC byte for the authorization request message and for testing the card swipe's LRC byte. Section 7.07 provides sample data for an authorization request and response for record format "J" testing. The POS device/authorization must perform the following operations on track read data before it can be used in an authorization request message. 1. The LRC must be calculated for the data read from the track and compared to the LRC read from the track. The track data is assumed to be read without errors when on character parity errors are detected and the calculated and read LRC's match. 2. The starting sentinel, ending sentinel, and LRC are discarded. 3. The character codes read from the magnetic stripe must be converted from the encoded character set to the set used for the authorization request message. The characters encoded on track 1 are six-bit plus parity codes and the characters encoded on track 2 are four-bit plus parity codes, with the character set used for the request message defined as seven-bit plus parity codes. All characters read from a track must be converted to the request message character set and transmitted as part of the request. The converted track data can not be modified by adding or deleting non-framing characters and must be a one-for-one representation of the characters read from the track. [sounds like they mean it, eh?] 7.1 TRACK 1 CHARACTER DEFINITION Table 7.01 provides the ISO 7811-2 track 1 character encoding definitions. This "standards" format is a SAMPLE guideline for expected credit card track encoding; ATM/debit cards may differ. Actual cards may differ [not], whether they are Visa cards or any other issuer's cards. Each character is defined by the six-bit codes listed in Table 7.01. Track 1 can be encoded with up to 79 characters as shown in Figure 7.01 +---------------------------------------------------------+ |SS|FC| PAN|FS| NAME|FS| DATE| DISCRETIONARY DATA |ES|LRC| +---------------------------------------------------------+ LEGEND: Field Description Length Format -------------------------------------------------------------------------------- SS Start Sentinel 1 % FC Format Code ("B" for credit cards) 1 A/N PAN Primary Account Number 19 max NUM FS Field Separator 1 ^ NAME Card Holder Name (See NOTE below) 26 max A/N FS Field Separator 1 ^ DATE Expiration Date (YYMM) 4 NUM Discretionary Data Option Issuer Data (See NOTE below) variable A/N ES End Sentinel 1 ? LRC Longitudinal Redundancy Check 1 --- Total CAN NOT exceed 79 bytes-----> 79 -------------------------------------------------------------------------------- FIGURE 7.01 Track 1 Encoding Definition NOTE: The CARD HOLDER NAME field can include a "/" as the surname separator and a "." as the title separator The DISCRETIONARY DATA can contain any of the printable characters from Table 7.01 TABLE 7.01 Track 1 Character Definition b6 0 0 1 1 BIT NUMBER b5 0 1 0 1 (a) These character positions ------------------------------------------- are for hardware use only b4 b3 b2 b1 ROW/COL 0 1 2 3 ------------------------------------------- (b) These characters are for 0 0 0 0 0 SP 0 (a) P country use only, not for 0 0 0 1 1 (a) 1 A Q international use 0 0 1 0 2 (a) 2 B R 0 0 1 1 3 (c) 3 C S (c) These characters are 0 1 0 0 4 $ 4 D T reserved for added 0 1 0 1 5 (%) 5 E U graphic use [nifty] 0 1 1 0 6 (a) 6 F V 0 1 1 1 7 (a) 7 G W 1 0 0 0 8 ( 8 H X (%) Start sentinel 1 0 0 1 9 ) 9 I Y (/) End sentinel 1 0 1 0 A (a) (a) J Z (^) Field Separator 1 0 1 1 B (a) (a) K (b) / Surname separator 1 1 0 0 C (a) (a) L (b) . Title separator 1 1 0 1 D - (a) M (b) SP Space 1 1 1 0 E - (a) N (^) +-----------------------+ 1 1 1 1 F / (?) O (a) |PAR|MSB|B5|B4|B3|B2|LSB| +-+---+-----------------+ | |--- Most Significant Bit |--- Parity Bit (ODD) Read LSB First 7.02 TRACK 2 CHARACTER DEFINITION Table 7.02 provides the ISO 7811-2 track 2 character encoding definitions. This "standards" format is a SAMPLE guideline for expected credit card track encoding; ATM/debit cards may differ. Actual cards may differ, whether they are Visa cards or any other issuer's cards. Each character is defined by the four-bit codes listed in Table 7.02. Track 2 can be encoded with up to 40 characters as shown in Figure 7.02. +--------------------------------------------------------+ |SS| PAN |FS| DATE| DISCRETIONARY DATA |ES|LRC| +--------------------------------------------------------+ LEGEND: Field Description Length Format -------------------------------------------------------------------------------- SS Start Sentinel 1 0B hex PAN Primary Account Number 19 max NUM FS Field Separator 1 = Discretionary Data Option Issuer Data (See NOTE below) variable A/N ES End Sentinel 1 0F hex LRC Longitudinal Redundancy Check 1 --- Total CAN NOT exceed 40 bytes-----> 40 -------------------------------------------------------------------------------- FIGURE 7.02 Track 2 Encoding Definition NOTE: The PAN and DATE are always numeric. The DISCRETIONARY DATA can be numeric with optional field separators as specified in Table 7.02. TABLE 7.02 Track 2 Character Set b4 b3 b2 b1 COL (a) These characters are for ------------------------------ hardware use only 0 0 0 0 0 0 0 0 0 1 1 1 (B) Starting Sentinel 0 0 1 0 2 2 0 0 1 1 3 3 (D) Field Separator 0 1 0 0 4 4 0 1 0 1 5 5 (F) Ending Sentinel 0 1 1 0 6 6 0 1 1 1 7 7 1 0 0 0 8 8 +---------------------------+ 1 0 0 1 9 9 | PAR | MSB | b3 | b2 | LSB | 1 0 1 0 A (a) +---------------------------+ 1 0 1 1 B (B) | | 1 1 0 0 C (a) | |--- Most Significant Bit 1 1 0 1 D (D) |--- Parity Bit (ODD) 1 1 1 0 E (a) 1 1 1 1 F (F) Read LSB first [ tables 7.03a, 7.03b, and 7.04 deleted... If you really need a fucking ascii table that bad go buy a book.] [ section 7.05 - Account Data Luhn Check deleted... as being unnecessary obtuse and roundabout in explaining how the check works. the routine written by crazed luddite and murdering thug is much clearer. ] 7.06 CALCULATING AN LRC When creating or testing the LRC for the read of the card swipe, the authorization request record, the debit confirmation record or the VisaNet response record; use the following steps to calculate the LRC: 1) The value of each bit in the LRC character, excluding the parity bit, is defined such that the total count of ONE bits encoded in the corresponding bit location of all characters of the data shall be even (this is also known as an EXCLUSIVE OR (XOR) operation) For card swipes, include the start sentinel, all the data read and the end sentinel. For VisaNet protocol messages, begin with the first character past the STX, up to and including the ETX. 2) The LRC characters parity bit is not a parity bit for the individual parity bits of the data message, but it only the parity bit for the LRC character itself. Calculated as an even parity bit. [ i list a routine for calculating an LRC o a string later on in the document ] 7.07 TEST DATA FOR RECORD FORMAT "J" The following two sections provide sample data for testing record format "J" with the VisaNet dial system. 7.07.01 TEST DATA FOR A FORMAT "J" AUTHORIZATION REQUEST Table 7.07a provides a set of test data for record format "J" authorization request. TABLE 7.07a Test Data For Record Format "J" Test Data Byte # Length Format Field Name -------------------------------------------------------------------------------- J 1 1 A/N Record Format 0, 2, or 4 2 1 A/N Application Type . 3 1 A/N Message Delimiter 401205 4-9 6 A/N Acquirer BIN 123456789012 10-21 12 NUM Merchant Number 0001 * 22-25 4 NUM Store Number 0001 * 26-29 4 NUM Terminal Number 5999 30-33 4 NUM Merchant Category Code 840 34-36 3 NUM Merchant Country Code 94546 37-41 5 A/N Merchant City Code 108 42-44 3 NUM Time Zone Differential 54 45-46 2 A/N Authorization Transaction Code 12345678 47-54 8 NUM Terminal Identification Number Y 55 1 A/N Payment Service Indicator 0001 * 56-59 4 NUM Transaction Sequence Number @ 60 1 A/N Cardholder Identification Code D, H, T, or X 61 1 A/N Account Data Source Track or Customer Data Field Manual Data "FS" N.A. 1 "FS" Field Separator 0000123 N.A. 0 to 43 A/N Transaction Amount "FS" N.A. 1 "FS" Field Separator ER N.A. 0 or 2 A/N Device Code/Industry code "FS" N.A. 1 "FS" Field Separator N.A. 0 or 6 NUM Issuing/Receiving Institution ID "FS" N.A. 1 "FS" Field Separator 000 N.A. 3 to 12 NUM Secondary Amount (Cashback) "FS" N.A. 1 "FS" Field Separator -------------------------------------------------------------------------------- NOTE:* Denotes fields that are returned in the response message 7.07.2 RESPONSE MESSAGE FOR TEST DATA Table 7.07b provides the response message for the test data provided in section 7.07.1. TABLE 7.07b Response Message For Test Data - Record Format "J" Test Data Byte # Length Format Field Name -------------------------------------------------------------------------------- A, Y, N, or * 1 1 A/N Payment Service Indicator "space" 0001 * 2-5 4 NUM Store Number 0001 * 6-9 4 NUM Terminal Number 5 * 1 1 A/N Authorization Source Code 0001 * 11-14 4 NUM Transaction Sequence Number 00 * 15-16 2 A/N Response Code 12AB45 * 17-22 6 A/N Approval Code 111992 * 23-28 6 NUM Transaction Date (MMDDYY) AP ______ 29-44 16 A/N Authorization Response Message 0, Sp, or "FS" 45 1 A/N AVS Result Code *Variable 0 or 15 NUM Transaction Identifier "FS" "FS" Field Separator *Variable 0 or 4 A/N Validation Code "FS" "FS" Field Separator -------------------------------------------------------------------------------- NOTE: * Move to data capture record for VisaNet Central Data Capture (CDC) -------------------------------------------------------------------------------- [ section two ] [ finding visanet ] finding visanet isn't hard, but it can be tedious. visanet rents time off of compuserve and X.25 networks. the compuserve nodes used are not the same as their information service, cis. to identify a visanet dialup after connecting, watch for three enq characters and a three second span to hangup. if you've scanned out a moderate portion of your area code, you probably have a few dialups. one idea is to write a short program to dial all the connects you have marked as garbage or worthless [ you did keep em, right? ] and wait for the proper sequence. X.25 connections should work similarly, but i don't know for sure. read the section on visanet usage for other dialup sources. [ section three ] [ visanet link level protocol ] messages to/from visanet have a standard format: stx - message - etx - lrc the message portion is the record formats covered in section one. lrc values are calculated starting with the first byte of message, going up to and including the etx character. heres an algorithm that calculates the lrc for a string. note: in order to work with the visanet protocols, append etx to the string before calling this function. unsigned char func_makelrc(char *buff) { int i; char ch, *p; ch = 0; p = buff; for(;;) { ch = (ch^(*p)); p++; if(!(*p)) break; } return ch; } for a single authorization exchange, the easiest kind of transaction, the sequence goes like this: host enq stx-response-etx-lrc eot term stx-request-etx-lrc ack <disconnect> matching this sequence with test record formats from section one, 7.07, heres an ascii representation of a transaction. control characters denoted in <>'s. [of course, you wouldn't really have a carriage return in middle of a message. duh. ] this transaction would be for card number 4444111122223333 with an expiration date of 04/96. the purchase amount is $1.23. visanet responds with an approval code of 12ab45. host: <enq> term: <stx>J0.401205123456789012000100015999840945461085412345678Y0001@H444411 1122223333<fs>0496<fs>0000123<fs>ER<fs><fs>000<fs><etx><lrc> host: <stx>Y00010001500010012AB45111992APPROVAL 12AB45123456789012345<fs> ABCD<fs><etx><lrc> term: <ack> host: <eot> authorizing multiple transactions during one connect session is only slightly more complicated. the etx character on all messages sent to visanet are changed to etb and the application type is changed from '0' to '2' [section one 4.02]. instead of responding after a transaction with eot, visanet instead polls the terminal again with enq. this continues until the terminal either changes back to the single transaction format or issues an eot to the host. heres a short list of all control characters used: stx: start-of-text, first message framing character signaling message start etx: end-of-text, the frame ending character the last message of a sequence eot: end-of-transmission, used to end an exchange and signal disconnect enq: enquiry, an invitation to transmit a message or retransmit last item ack: affirmative acknowledgment, follows correct reception of message nak: negative acknowledgment, used to indicate that the message was not understood or was received with errors syn: delay character, wait thirty seconds etb: end-of-block, the end framing character used to signal the end of a message within a multiple message sequence other quick notes: visanet sometimes sends ack before stx on responses lrc characters can hold any value, such as stx, nak, etc visanet can say goodbye at any time by sending eot people can get very anal about error flow diagrams [ section four ] [ half the story; central data capture ] a full transaction requires two steps, one of which is described in this document: getting the initial authorization. an authorization does basically nothing to a person's account. oh, you could shut somebody's account down for a day or two by requesting a twenty thousand dollar authorization, but no other ill effects would result. central data capture, the second and final step in a transaction, needs information from both the authorization request and response, which is used to generate additional data records. these records are then sent to visanet by the merchant in a group, usually at the end of each day. [ section five ] [ common applications ] access to visanet can be implemented in a number of ways: directly on a pos terminal, indirectly via a lan, in a hardware specific device, or any permutation possible to perform the necessary procedures. card swipers commonly seen at malls are low tech, leased at around fifty dollars per month, per terminal. they have limited capacity, but are useful in that all of the information necessary for transactions is self contained. dr delam and maldoror found this out, and were delighted to play the role of visanet in fooling the little device. close scrutiny of section one reveals atm formats, phone order procedures, and new services such as direct debit from checking/savings and checks by phone. start noticing the stickers for telecheck and visa atm cards, and you're starting to get the picture. [ section seven ] [ brave new world ] could it be? yes, expiration dates really don't matter.... this article written to thank previous Phrack writers... please thank me appropriately... 800#s exist... other services exist... mastercard runs one... never underestimate the power of asking nicely... numerous other formats are available... see section one, 3.0 for hints... never whistle while you're pissing...