syn2cat
/
phrack
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
phrack/phrack46/15.txt

1031 lines
48 KiB
Plaintext
Raw Permalink Blame History

This file contains invisible Unicode characters!

This file contains invisible Unicode characters that may be processed differently from what appears below. If your use case is intentional and legitimate, you can safely ignore this warning. Use the Escape button to reveal hidden characters.

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