June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`III-7
`
`Data elements marked with an asterisk are recommended to be part of the
`minimum data requirements for ICC transactions.
`
`For informational purposes, Annex D describes an example for conversion into
`message data elements.
`
`2.1.1 Authorisation Request
`
`An authorisation request should convey the data elements contained in Table III—1
`and Table III—2 subject to the specified conditions.
`
`Table III—1 contains the new data elements specifically created for an ICC
`transaction.
`
`Data Element
`
`Condition
`
`Application Interchange
`Profile *
`
`Application Transaction
`
`Cryptogram Information
`
`CVM Results
`
`IFD Serial Number
`
`Present if Terminal Identifier does not implicitly refer to IFD
`Serial Number
`
`Issuer Application Data *
`
`Present if provided by ICC in GENERATE AC command
`response
`
`Terminal Capabilities
`
`Terminal Type
`
`Terminal Verification
`
`Results *
`
`Unpredictable Number*
`
`Present if input to application cryptogram calculation
`
`Table Ill-1 - New Authorisation Request Data Elements
`
`Table III—2 contains existing data elements necessary for an ICC transaction.
`
`Petitioner First Data - Exhibit 1002 - Page 61
`
`

`
`III-8
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`Dataaement
`
`Acquirer Identifier
`
`Amount, Authorised *
`
`Present for Terminal Type = ‘1X’ or ‘2X’ if Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Amount, Other *
`
`Present if cashback used for current transaction
`
`Application Effective
`Date
`
`Application Expiration
`Date
`
`Present if in ICC
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN *
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`Sequence Number *
`
`Enciphered PIN Data
`
`Present if in ICC
`
`Present if CVM performed is ‘enciphered PIN for online
`verification’
`
`Merchant Category Code
`
`Present for Terminal Type = ‘2X’ if Merchant Identifier or
`Terminal Identifier does not implicitly refer to a single
`merchant category
`
`Merchant Identifier
`
`POS Entry Mode
`
`Present for Terminal Type = ‘2X’ if Terminal Identifier does not
`implicitly refer to a single merchant
`
`Terminal Country Code *
`
`Present if Terminal Identifier or IFD Serial Number does not
`
`implicitly refer to a single terminal country
`
`Terminal Identifier
`
`Track 2 Equivalent Data
`
`Present if in ICC
`
`Transaction Currency
`
`Present if Merchant Identifier or Terminal Identifier does not
`
`implicitly refer to a single transaction currency accepted at
`point of transaction
`
`Transaction Date *
`
`Transaction Time
`
`Transaction Type *
`
`Present if Terminal Type = ‘X2’, ‘X3’, ‘X5’, or ‘X6’
`
`Table Ill-2 - Existing Authorisation Request Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 62
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`Ill-9
`
`2.1.2 Financial Transaction Request
`
`A financial transaction request should convey the data elements contained in Table
`III—3 and Table III—4 subject to the specified conditions.
`
`Table III—3 contains the new data elements created specifically for an ICC
`transaction.
`
`Data Element
`
`Condition
`
`Application Interchange
`Profile *
`
`Application Transaction
`Counter *
`
`Application Usage
`Control
`
`‘ ARQC *
`
`Cryptogram Information
`Data
`
`CVM List
`
`CVM Results
`
`IFD Serial Number
`
`Issuer Action Code —
`
`Default
`
`Issuer Action Code —
`
`Denial
`
`Issuer Action Code —
`
`Online
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`Present if Terminal Identifier does not implicitly refer to IFD
`Serial Number
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`|
`
`Issuer Application Data *
`
`Present if provided by ICC in GENERATE AC command
`response
`
`Terminal Capabilities
`
`Terminal Type
`
`Terminal Verification
`
`Results *
`
`| Unpredictable Number *
`
`Present if input to application cryptogram calculation
`
`Table Ill-3 - New Financial Transaction Request Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 63
`
`

`
`III-10
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`Table III—4 contains existing data elements necessary for an ICC transaction.
`
`Acquirer Identifier
`
`Present for Terminal Type = ‘Ix’ or ‘2x’ if Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Amount, Authorised *
`
`Present if final transaction amount is different from
`
`authorised amount
`
`Amount, Other *
`
`Present if cashback used for current transaction
`
`Application Effective
`Date
`
`Present if in ICC
`
`Application Expiration
`Date
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN *
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`Sequence Number *
`
`Present if in ICC
`
`Enciphered PIN Data
`
`Present if CVM performed is ‘Enciphered PIN for online
`verification’.
`
`Issuer Country Code
`
`Present if requested by acquirer
`
`Merchant Category Code
`
`Present for Terminal Type = ‘2x’ if Merchant Identifier or
`Terminal Identifier does not implicitly refer to a single
`merchant category
`
`Merchant Identifier
`
`POS Entry Mode
`
`Present for Terminal Type = ‘2x’ if Terminal Identifier does not
`implicitly refer to a single merchant
`
`Terminal Country Code *
`
`Present if Terminal Identifier or IFD Serial Number does not
`
`implicitly refer to a single terminal country
`
`Terminal Identifier
`
`Track 2 Equivalent Data
`
`Present if in ICC
`
`Transaction Amount *
`
`Petitioner First Data - Exhibit 1002 - Page 64
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`Ill-11
`
`Transaction Currency
`
`Present if Merchant Identifier or Terminal Identifier does not
`implicitly refer to a single transaction currency accepted at
`point of transaction
`
`
`
`Present ifTerminal Type = ‘X2’, ‘X3’, ‘X5’, or ‘X6’
`
`Table Ill-4 - Existing Financial Transaction Request Data Elements
`
`2.1.3 Authorisation or Financial Transaction Response
`
`Authorisation and financial transaction responses should convey the data elements
`contained in Table III—5 and Table III—6 subject to the specified conditions:
`
`Table III—5 contains the new data elements specifically created for an ICC
`transaction.
`
`
`
`Issuer Authentication
`Data
`
`Present if online issuer authentication performed
`
`Issuer Script(s)
`
`Present if commands to ICC are sent by issuer
`
`Table Ill-5 - New Authorisation or Financial Transaction Response Data Elements
`
`Table III—6 contains existing data elements necessary for an ICC transaction.
`
`Acquirer Identifier
`
`Present for Terminal Type = ‘1X’ or ‘ZX’ if in request message
`
`Code
`
`Authorisation Code
`
`Present if transaction is approved
`
`Authorisation Response
`
`Petitioner First Data - Exhibit 1002 - Page 65
`
`

`
`Ill-12
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`
`
`Table Ill-6 - Existing Authorisation or Financial Transaction Response Data
`Elements
`
`2.1.4 Financial Transaction Confirmation
`
`A financial transaction confirmation should convey the data elements contained in
`Table III—7 and Table III—8 subject to the specified conditions.
`
`Table III—7 contains the new data elements specifically created for an ICC
`transaction.
`
`
`
`Issuer Script Results
`
`Present if script commands to ICC are delivered by terminal
`
`WAAC —
`
`Table Ill-7 - New Financial Transaction Confirmation Data Elements
`
`Table III—8 contains existing data elements necessary for an ICC transaction.
`
`
`
`Table Ill-8 - Existing Financial Transaction Confirmation Data Elements
`
`2.1.5 Batch Data Capture
`
`Batch data capture should convey the data elements contained in Table III—9 and
`Table III—10 subject to the specified conditions. Message Type is used to distinguish
`between an offline advice and a financial record.
`
`Petitioner First Data - Exhibit 1002 - Page 66
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`|||-13
`
`Table III—9 contains the new data elements specifically created for an ICC
`transaction.
`
`Data Element
`
`Condition
`
`Application Interchange
`Profile *
`
`Application Transaction
`Counter *
`
`Application Usage
`Control
`
`Cryptogram Information
`Data
`
`CVM List
`
`CVM Results
`
`IFD Serial Number
`
`Issuer Action Code —
`
`Default
`
`Issuer Action Code —
`
`Denial
`
`Issuer Action Code —
`
`Online
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`Present if Terminal Identifier does not implicitly refer to IFD
`Serial Number
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`Present if requested by acquirer
`
`Issuer Application Data *
`
`Present if provided by ICC in GENERATE AC command
`response
`
`Issuer Script Results
`
`Present if script commands to ICC are delivered by terminal
`
`Terminal Capabilities
`
`Terminal Type
`
`Terminal Verification
`
`Present if input to application cryptogram calculation
`
`Table Ill-9 - New Batch Data Capture Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 67
`
`

`
`III-14
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`Table III—1O contains existing data elements necessary for an ICC transaction.
`
`Acquirer Identifier
`
`Present if for Terminal Type = ‘Ix’ or ‘2x’ Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Amount, Authorised *
`
`Present if final transaction amount is different from
`authorised amount
`
`Amount, Other *
`
`Present if cashback used for current transaction
`
`Application Effective
`Date
`
`Present if in ICC
`
`Application Expiration
`Date
`
`l Application PAN *
`
`Application PAN
`Sequence Number *
`
`Present if in ICC
`
`Authorisation Code
`
`Present if transaction is approved
`
`Authorisation Response
`Code
`
`Issuer Country Code
`
`Present if requested by acquirer
`
`Merchant Category Code
`
`Present for Terminal Type = ‘2x’ if Merchant Identifier or
`Terminal Identifier does not implicitly refer to a single
`merchant category
`
`Merchant Identifier
`
`Present for Terminal Type = ‘2x’ if Terminal Identifier does not
`implicitly refer to a single merchant
`
`Type —
`
`l Terminal Country Code *
`
`Present ifTerminal Identifier or IFD Serial Number does not
`
`implicitly refer to a single terminal country
`
`i—
`
`Petitioner First Data - Exhibit 1002 - Page 68
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`Ill-15
`
`Transaction Currency
`Code *
`
`Present if Merchant Identifier or Terminal Identifier does not
`implicitly refer to a single transaction currency accepted at
`point of transaction
`
`
`
`— T
`
`able Ill-10 - Existing Batch Data Capture Data Elements
`
`2.1.6 Reconciliation
`
`A reconciliation should convey the existing data elements necessary for ICC
`transactions and subject to the specified conditions.
`
`Data Hamant
`
`Acquirer Identifier
`
`Amount, Net
`Reconciliation
`
`Merchant Identifier
`
`Present for Terminal Type = ‘Ix’ or ‘2x’ if Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Present for Terminal Type = ‘2x’ if Terminal Identifier
`implicitly does not refer to a single merchant
`
`Reconciliation Currency
`Code
`
`Present if Merchant Identifier or Terminal Identifier does not
`implicitly refer to a single transaction currency accepted at
`point of transaction
`Terminal Iaaaafiar
`
`Transactions Number
`
`(per transaction type)
`
`Transactions Amount
`
`(per transaction type)
`
`Table Ill-11 - Existing Reconciliation Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 69
`
`

`
`Ill-16
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`2.1.7 Online Advice
`
`An online advice should convey the data elements contained in Tables III—12 and III-
`13 subject to the specified conditions.
`
`Table III—12 contains the new data elements specifically created for an ICC
`transaction.
`
`Data Element
`
`Condition
`
`Application Interchange
`Profile
`
`Application Transaction
`Counter
`
`Cryptogram Information
`Data
`
`CVM Results
`
`IFD Serial Number
`
`Present if Terminal Identifier does not implicitly refer to IFD
`Serial Number
`
`Issuer Application Data
`
`Present if provided by ICC in GENERATE AC command
`response
`
`Issuer Script Results
`
`Present if script commands to ICC are delivered by terminal
`
`Terminal Capabilities
`
`Terminal Type
`
`Terminal Verification
`
`Results
`
`TC or AAC
`
`Unpredictable Number
`
`Present if input to application cryptogram calculation
`
`Table Ill-12 - New Online Advice Data Elements
`
`Table III—13 contains existing data elements necessary for an ICC transaction.
`
`Petitioner First Data - Exhibit 1002 - Page 70
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`III-17
`
`Data Hement
`
`Acquirer Identifier
`
`Present for Terminal Type = ‘1X’ or ‘2X’ if Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Amount, Authorised
`
`Present if final transaction amount is different from
`
`Application Effective
`Date
`
`Application Expiration
`Date
`
`authorised amount
`
`Present if in ICC
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`Sequence Number
`
`Authorisation Response
`Code
`
`Merchant Category Code
`
`Merchant Identifier
`
`POS Entry Mode
`
`Present if in ICC
`
`Present for Terminal Type = ‘2X’ if Merchant Identifier or
`Terminal Identifier does not implicitly refer to a single
`merchant category
`
`Present for Terminal Type = ‘2X’ if Terminal Identifier does not
`implicitly refer to a single merchant
`
`Terminal Country Code
`
`Present if Terminal Identifier or IFD Serial Number does not
`
`implicitly refer to a single terminal country
`
`Terminal Identifier
`
`Track 2 Equivalent Data
`
`Present if in ICC
`
`Transaction Amount
`
`Transaction Currency
`Code
`
`Present if Merchant Identifier or Terminal Identifier does not
`
`implicitly refer to a single transaction currency accepted at
`point of transaction
`
`Date —
`
`Transaction Time
`
`Present if Terminal Type = ‘X2’, ‘X3’, ‘X5, or ‘X6’
`
`Type —
`
`Table Ill-13 - Existing Online Advice Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 71
`
`

`
`III-18
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`2.1.8 Reversal
`
`A reversal should convey the data elements contained in Table III—14 and Table III-
`15 subject to the specified conditions.
`
`Table III—14 contains the new data elements specifically created for an ICC
`transaction.
`
`Data Element
`
`Condition
`
`Application Interchange
`Profile
`
`Application Transaction
`Counter
`
`IFD Serial Number
`
`Present if Terminal Identifier does not implicitly refer to IFD
`Serial Number
`
`Issuer Application Data
`
`Present if provided by ICC in GENERATE AC command
`response
`
`Issuer Script Results
`
`Present if script commands to ICC are delivered by terminal
`
`Terminal Capabilities
`
`Terminal Type
`
`Terminal Verification
`Results
`
`Table Ill-14 - New Reversal Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 72
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`Ill-19
`
`| Table III—15 contains existing data elements necessary for an ICC transaction.
`Data ttataattt
`
`Acquirer Identifier
`
`Present for Terminal Type = ‘1x’ or ‘2x’ if Merchant Identifier
`or Terminal Identifier does not implicitly refer to a single
`acquirer
`
`Application Expiration
`Date
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`
`Present if not in Track 2 Equivalent Data
`
`Application PAN
`Sequence Number
`
`Present if in ICC
`
`Authorisation Response
`Code
`
`Merchant Category Code
`
`Present for Terminal Type = ‘2x’ if Merchant Identifier or
`Terminal Identifier does not implicitly refer to a single
`merchant category
`
`Merchant Identifier
`
`Present for Terminal Type = ‘2x’ if Terminal Identifier does not
`implicitly refer to a single merchant
`
`Original Data Elements
`
`Present if available at terminal
`
`POS Entry Mode
`
`Terminal Country Code
`
`Terminal Identifier
`
`Present if Terminal Identifier or IFD Serial Number does not
`implicitly refer to a single terminal country
`
`Track 2 Equivalent Data
`
`Present if in ICC
`
`Transaction Amount
`
`Transaction Currency
`
`Present if Merchant Identifier or Terminal Identifier does not
`implicitly refer to a single transaction currency accepted at
`point of transaction
`
`l
`l
`l
`
`ttaaaaattaa Data
`Present if Terminal Type = ‘x2’, ‘x3’, ‘x5, or ‘x6’
`ttaaaaattaa tvaa
`
`Table Ill-15 - Existing Reversal Data Elements
`
`Petitioner First Data - Exhibit 1002 - Page 73
`
`

`
`III-20
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`2.2 Exception Handling
`
`This section describes exception conditions that may occur during real—time
`authorisation, financial transaction, or online advice and the associated actions the
`
`terminal shall perform.
`
`In this section, the term ‘authorisation’ applies to authorisation messages as well as
`financial transaction messages.
`
`2.2.1 Unable to Go Online
`
`During transaction processing, the terminal may send an authorisation request to
`the acquirer due to at least one of the following conditions:
`
`I Online—only terminal type
`
`0 Attendant action (for example, merchant suspicious of cardholder)
`
`0 Terminal risk management parameters set by the acquirer
`
`0 Terminal action analysis in comparing Terminal Verification Results with Issuer
`Action Code — Online (see the Integrated Circuit Card Application Specification
`for Payment Systems)
`
`0 Card action analysis via its response to the first GENERATE AC command:
`Cryptogram Information Data indicates ARQC returned (see the Integrated
`Circuit Card Specification for Payment Systems and the Integrated Circuit Card
`Application Specification for Payment Systems)
`
`If the terminal is unable to process the transaction online, as described in the
`Integrated Circuit Card Application Specification for Payment Systems, the terminal
`shall compare the Terminal Verification Results with both Terminal Action Code —
`Default and Issuer Action Code — Default to determine whether to accept or decline
`the transaction offiine and shall issue the second GENERATE AC command to the
`
`ICC indicating its decision:
`
`0
`
`0
`
`If the terminal accepts the transaction, it shall set the Authorisation Response
`Code to ‘Unable to go online, offiine accepted’.
`
`If the terminal declines the transaction, it shall set the Authorisation Response
`Code to ‘Unable to go online, offiine declined’.
`
`The result of card risk management performed by the ICC is made known to the
`terminal through the return of the Cryptogram Information Data indicating either a
`TC for an approval or an AAC for a decline.
`
`Petitioner First Data - Exhibit 1002 - Page 74
`
`

`
`June 30, 1996
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`III-21
`
`2.2.2 Downgraded Authorisation
`
`When the authorisation response received by the terminal does not contain the
`Issuer Authentication Data, the terminal shall not execute the EXTERNAL
`
`AUTHENTICATE command and shall set the ‘Issuer authentication was performed’
`bit in the Transaction Status Information to ‘O’, as described in the Integrated
`Circuit Card Application Specification for Payment Systems. The terminal shall
`continue processing based on the Authorisation Response Code returned in the
`response message as described in section I—2.2.6 of this specification.
`
`Note: If the acquirer or the intermediate network is unable to support ICC
`messages, the terminal should send messages compliant with current payment
`system specifications. Payment systems will determine compliance requirements
`for message content.
`
`2.2.3 Authorisation Response Incidents
`
`The authorisation response may not be correctly received by the terminal. The
`following incidents may occur:
`
`0 Response not received or received too late (for example, network failure, time-
`out)
`
`0 Response with invalid format or syntax
`
`0 Request not received by the authorisation host (for example, network failure)
`
`After repeat(s) of the authorisation request, the terminal shall process the
`transaction as being unable to go online. As described in the Integrated Circuit
`Card Application Specification for Payment Systems, the terminal shall compare the
`Terminal Verification Results with both Terminal Action Code — Default and Issuer
`
`Action Code — Default to determine whether to accept or decline the transaction
`offline and shall issue the second GENERATE AC command to the ICC indicating
`its decision:
`
`0
`
`0
`
`If the terminal accepts the transaction, it shall set the Authorisation Response
`Code to ‘Unable to go online, offline accepted’.
`
`If the terminal declines the transaction, it shall set the Authorisation Response
`Code to ‘Unable to go online, offline declined’.
`
`The result of card risk management performed by the ICC is made known to the
`terminal through the return of the Cryptogram Information Data indicating either a
`TC for an approval or an AAC for a decline.
`
`When online data capture is performed by the acquirer, the terminal shall send a
`reversal message regardless of the final decision on the transaction (to ensure that
`if the authorisation host received a request and sent a response, the transaction is
`cancelled). After transmission of the reversal, if the transaction is finally approved
`
`Petitioner First Data - Exhibit 1002 - Page 75
`
`

`
`III-22
`
`Part III - Cardholder, Attendant, and Acguirer Interface
`
`June 30, 1996
`
`offline (TC returned by the ICC), the terminal shall create a financial record to be
`forwarded to the acquirer.
`
`2.2.4 Script Incidents
`
`The Issuer Script may not be correctly processed. The following incidents may
`occur:
`
`0 Script length error: The response message contains one (or more) Issuer
`Script(s) whose cumulative total length is larger than the script length
`supported by the network or terminal.
`
`0 Script with incorrect format or syntax: The terminal is unable to correctly parse
`the Issuer Script(s) into single Script Commands, as specified in the Integrated
`Circuit Card Application Specification for Payment Systems.
`
`If either of these incidents occur, the terminal shall terminate the processing of the
`Issuer Script in which the incident occurred, shall read if possible the Script
`Identifier (when present) and shall report it as not performed in the Issuer Script
`Results of the financial transaction confirmation or batch data capture message.
`The terminal shall continue processing any subsequent Issuer Script.
`
`2.2.5 Advice Incidents
`
`If the terminal is unable to create an advice when requested by the card in the
`Cryptogram Information Data returned in the response to the GENERATE AC
`command as described in section I—2.2.6, of this specification, the terminal shall
`terminate the transaction.
`
`Petitioner First Data - Exhibit 1002 - Page 76
`
`

`
`Annexes
`
`Petitioner First Data - Exhibit 1002 - Page 77
`
`

`
`June 30, 1996
`
`Annex A - Coding of Terminal Data Elements
`
`A-1
`
`Annex A - Coding of Terminal Data Elements
`
`This annex provides the coding for the Terminal Type, Terminal Capabilities,
`Additional Terminal Capabilities, CVM Results, Issuer Script Results, and
`Authorisation Response Code.
`
`Coding of data (bytes or bits) indicated as RFU shall be ‘0’.
`
`A1. Terminal Type
`
`Operational Control Provided By:
`
`Environment
`
`Financial
`Institution
`
`Cardholder”
`
`Attended
`
`Online only
`
`Offline with online
`
`capability
`
`Offline only
`
`Unattended
`
`Online only
`
`Offline with online
`
`capability
`
`Offline only
`
`Table A-1 - Terminal Type
`
`Terminal Types ‘14’, ‘15’, and ‘16’ with cash disbursement capability (Additional
`Terminal Capabilities, byte 1, ‘cash’ bit = ‘1’) are considered to be ATMs. All other
`Terminal Types are not considered to be ATMs.
`
`14 For the purpose of this specification, an attended cardholder—controlled terminal is
`considered to be a nonexistent category.
`
`Petitioner First Data - Exhibit 1002 - Page 78
`
`

`
`A-2
`
`Annex A -Coding of Terminal Data Elements
`
`June 30, 1996
`
`Examples of terminal types are:
`
`0 Attended and controlled by financial institution: Branch terminal
`
`0 Attended and controlled by merchant: Electronic cash register, portable POS
`terminal, stand—alone POS terminal, host concentrating POS terminal
`
`I Unattended and controlled by financial institution: ATM, banking automat
`
`0 Unattended and controlled by merchant: Automated fuel dispenser, pay
`telephone, ticket dispenser, Vending machine
`
`0 Unattended and controlled by cardholder: Home terminal, personal computer,
`screen telephone
`
`See Annex F for more detailed examples.
`
`Petitioner First Data - Exhibit 1002 - Page 79
`
`

`
`
`
`June 30 1996 Annex A - Codin of Terminal Data Elements
`
`A2. Terminal Capabilities
`
`In the tables, a ‘1’ means that if that bit has the value ‘1’, the corresponding
`‘meaning’ applies. An ‘x’ means that the bit does not apply
`
`Byte 1: Card Data Input Capability
`
`flflflflE
`
`EEE n T
`
`able A-2 - Terminal Capabilities
`
`Petitioner First Data - Exhibit 1002 - Page 80
`
`

`
`
`
`Annex A -Codin of Terminal Data ElementsA-4 June 30 1996
`
`
`
`Byte 2: CVM Capability
`
`flflEflE
`
`1
`
`x
`
`x
`
`1
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x
`
`Plaintext PIN for ICC
`
`Verification
`
`x
`
`Enciphered PIN for online
`Verification
`
`nnnnnnnnwmww
`
`MMMMM T
`
`able A-2 - Terminal Capabilities
`
`If the terminal supports a CVM of signature, the terminal shall be an attended
`terminal (Terminal Type = ‘X1’, ‘X2’, or ‘x3’) and shall support a printer (Additional
`Terminal Capabilities, byte 4, ‘Print, attendant’ bit = ‘1’).
`
`Petitioner First Data - Exhibit 1002 - Page 81
`
`

`
`J U ne 30 1996
`Annex A - Codin of Terminal Data Elements
`
`Byte 3: Security Capability
`
`mnmmmmufi
`
`X
`
`1
`
`x
`
`x
`
`x
`
`x
`
`x
`
`X Dynamic data
`authentication
`
`Table A-2 - Terminal Capabilities
`
`Petitioner First Data - Exhibit 1002 - Page 82
`
`

`
`
`
`Annex A -Codin of Terminal Data ElementsA-6 June 30 1996
`
`
`
`A3. Additional Terminal Capabilities
`
`In the tables, a ‘1’ means that if that bit has the Value ‘1’, the corresponding
`‘meaning’ applies. An ‘x’ means that the bit does not apply
`
`Byte 1: Transaction Type Capability
`
`flflflflE
`
`Table A-3 - Additional Terminal Capabilities
`
`15 For the purpose of this specification, an inquiry is a request for information about one of
`the cardholder's accounts.
`
`15 For the purpose of this specification, a transfer is a movement of funds by a cardholder
`from one of its accounts to another of the cardholder's accounts, both of which are held by the
`same financial institution.
`
`17 For the purpose of this specification, a payment is a movement of funds from a cardholder
`account to another party, for example, a utility bill payment.
`
`Petitioner First Data - Exhibit 1002 - Page 83
`
`

`
`J U ne 30 1996
`Annex A - Codin of Terminal Data Elements
`
`Byte 2: Transaction Type Capability, continued
`
`flEflflE
`
`MMMMMMMM T
`
`able A-3 - Additional Terminal Capabilities
`
`Petitioner First Data - Exhibit 1002 - Page 84
`
`

`
`
`
`Annex A -Codin of Terminal Data Elements June 30 1996
`
`Byte 3: Terminal Data Input Capability
`
`flEflflE
`
`x
`
`1
`
`x
`
`x
`
`x
`
`x
`
`x
`
`x Alphabetic and special
`characters keys
`
`Command
`
`E
`
`RFU
`RFU
`
`RFU
`
`Table A-3 - Additional Terminal Capabilities
`
`Petitioner First Data - Exhibit 1002 - Page 85
`
`

`
`
`
`Annex A - Codin of Terminal Data ElementsJune 30 1996 A-9
`
`
`
`Byte 4: Terminal Data Output Capability“?
`
`flEflflE
`
`MM
`
`Table A-3 - Additional Terminal Capabilities
`
`The code table number refers to the corresponding part of ISO 8859.
`
`18 If the terminal is attended (Terminal Type = ‘X1’, ‘X2’, or ‘x3’) and there is only one printer,
`the ‘Print, attendant’ bit shall be set to ‘1’ and the ‘Print, cardholder’ bit shall be set to ‘O’.
`
`If the terminal is attended and there is only one display, the ‘Display, attendant’ bit shall be
`set to ‘1’ and the ‘Display, cardholder’ bit shall be set to ‘O’.
`
`If the terminal is unattended (Terminal Type = ‘x4’, ‘x5’, or ‘x6’), the ‘Print, attendant’ and
`‘Display, attendant’ bits shall be set to ‘O’.
`
`Petitioner First Data - Exhibit 1002 - Page 86
`
`

`
`A-10 Annex A -Codin of Terminal Data Elements
`June 30 1996
`
`Byte 5: Terminal Data Output Capability, continued
`
`flEflflE
`
`Table A-3 - Additional Terminal Capabilities
`
`Petitioner First Data - Exhibit 1002 - Page 87
`
`

`
`June 30, 1996
`
`Annex A - Coding of Terminal Data Elements
`
`A-11
`
`A4. CVM Results
`
`Byte 1: CVM Performed
`
`Last CVM of the CVM List actually performed by the terminal: One—byte CVM
`Code of the CVM List as defined in the Integrated Circuit Card Application
`Specification for Payment Systems (‘3F’ if no CVM is performed)
`
`Byte 2: CVM Condition
`
`One—byte CVM Condition Code of the CVM List as defined in the Integrated
`Circuit Card Application Specification for Payment Systems
`
`Byte 3: CVM Result
`
`Result of the (last) CVM performed as known by the terminal:
`
`‘O’ = Unknown (for example, for signature)
`‘1’ = Failed (for example, for offline PIN)
`‘2’ = Successful (for example, for offline PIN)
`
`A5. Issuer Script Results
`
`Byte 1: Script Result
`
`First nibble: Result of the Issuer Script processing performed by the terminal:
`
`‘0’ = Script not performed
`‘1’ = Script processing failed
`‘2’ = Script processing successful
`
`Second nibble: Sequence number of the Script Command
`
`‘O’
`‘1’ to ‘E’
`‘F’
`
`= Not specified
`= Sequence number from 1 to 14
`= Sequence number of 15 or above
`
`Bytes 2-5: Script Identifier
`
`Script Identifier of the Issuer Script received by the terminal, if available, zero
`filled if not. Mandatory if more than one Issuer Script was received by the
`terminal.
`
`Bytes 1-5 are repeated for each Issuer Script processed by the terminal.
`
`Petitioner First Data - Exhibit 1002 - Page 88
`
`

`
`A-12
`
`Annex A -Coding of Terminal Data Elements
`
`June 30, 1996
`
`A6. Authorisation Response Code
`
`When transmitted to the card, the Authorisation Response Code obtained from the
`authorisation response message shall include at least the following:
`
`0 Online approved
`
`0 Online declined
`
`0 Referral (initiated by issuer)
`
`0 Capture card
`
`In addition, the terminal shall be able to generate and transmit to the card the
`following new response codes when transactions are not authorised online:
`
`0 Unable to go online, offline approved
`
`0 Unable to go online, offline declined
`
`0 Offline approved
`
`0 Offline declined
`
`0 Approval (after card—initiated referral)
`
`0 Decline (after card—initiated referral)
`
`The codes are to be set by individual payment systems.
`
`The terminal shall never modify the Authorisation Response Code returned in the
`response message19.
`
`19 The cards final decision is reflected in the Cryptogram Information Data and not in the
`Authorisation Response Code.
`
`Petitioner First Data - Exhibit 1002 - Page 89
`
`

`
`
`
`£98..mm...:o_E_._umon_
`
`(‘O
`
`]
`
`2-:
`9°
`
`
`
`
`
`
`
`.Ow,.n._®.~NCE\G.Hm..«._~mEE.8323.wOmm3_:n_mmmoHSQHSOUSNHSQCMNHNU23mmumungca~NCE\G.H®..«._~NCO3wUU<
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`Aomm.~mC3.C.Hm..—._E39?ucmcbmmmscamE_3_>>.8.:=com23833:8?bm=E:D.833:m3.§_:_8<
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`.NO,.u.—®.~NCwC..:®.H.Am3:oE3m:.wwmwfivsixmvCOEUNWCNHHOH:..wOHCSOENU®mT—O—.._u3<U®mT—O—.._u3<.uC3OE< .mwO,.:.._®. ~NCE\G.Hm..«._XUNQSWNUNw:3:mmm.&m._COMHUNWCNLH93£uw>>w3m8ommmHCSOENzgmwcoomm<.230.uC5OE< uuoma.HmC3.C.H®..—._xomnsmmomw:3:mmo.&o._soflummsmb9333>umzmbommm358:8xumusoumm<.830.3::oE<
`
`
`
`
`
`
`
`
`
`
`
`omm.mmn_-Noo_.Ecxm-END3m.__n_._m:o::m.n_
`
`
`
`
`
`
`
`2a.898.fiEE.8H3::0282EBe.sm%mm:o3mo:nEm93m2.:3:mE._2.:3_.83_83mo:nE<
`
`
`
`
`
`
`
`
`
`
`
`.<mmm.fiEE.8Hz2.8.::u22.8.8.3?23Ewmmmmgmxm2.38:8Umm323:<m28.8.8m.3::oE<
`
`
`
`
`
`
`
` Tm22¢98u2m_mm_-_m:_E_3-mxwcc<82om82.
`
`
`
`¢_nm._.Ema_oBm_mm_-_m:_E._m._.-mx2E<
`
`
`
`
`
`88..Tm838%.mE.8m\m..w~:mE\mm.n~KQK:8.G.ms.Q.8mQ.m.38.0328303.8.m:%.8:.\.93E38%:8828E893B858.8393:83wmfiucmcmb
`
`
`
`
`
`
`
`
`
`.8.3.=¢8.2mE.8m\m.m.~:mE\mm.n~55%:8.G.m6.Q.8moW.38.03:830_o.8.m.:~%.8E.23mam“$55.83238E823E83wmfiucmcmbSaw8:8:
`
`
`
`
`
`
`
`.:o3n:.8moU
`
`moflzfimamo
`
`
`
`
`
`
`
`Sam.mm:23.83E:o3omm:m3_m8:m:3.838mEmm8o.E:o3omm:m3mctsw858.8393\&O—wmm:2.._>2:393Sawmum:Tm298%
`
`
`
`
`
`
`
`
`
`
`
`
`
`:2.:E.8HAm2.8E3m:€mwfiusixovcobbmmcmb93mo3::oEmUwm_._93:<Uwm_._93:<.3::oE<
`
`
`
`
`
`
`
`ofmfimc
`
`
`
`
`
`
`
`
`
`3::oEmofmfimc
`
`G_8E:Zv
`
`
`
`
`
`
`
`3::oEmG_8E:Zv
`
`
`
`¢CmEmc58:50
`
`628
`
`
`
`
`
`
`
`homo.~mC3.C.Hm.H:o3mu:nEm238.3E32?Eastman23anw2._w_mmm.8285::o_m.8>_8_m.8>:o3mo:nE<
`
`
`
`
`
`
`
`
`
`828:Z