945 lines
42 KiB
Plaintext
945 lines
42 KiB
Plaintext
==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...
|