Copy Link
Add to Bookmark
Report
Phrack Inc. Volume 05 Issue 46 File 16
==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...
