==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...