NEOv1.00IDG Rev86 PDF
NEOv1.00IDG Rev86 PDF
NEO v1.00
80139403-001 Rev.86
Confidential
NEO Interface Developers Guide NEO v1.00
Copyright
Copyright © 2016, ID TECH. All rights reserved.
ID TECH
10721 Walker St.
Cypress, CA 90630
This document, as well as the software and hardware described in it, is furnished under license
and may be used or copied online in accordance with the terms of such license. The content of
this document is furnished for information use only, is subject to change without notice, and
should not be construed as a commitment by ID TECH. Reasonable effort has been made to
ensure the accuracy of information provided herein. However, ID TECH assumes no responsibility
or liability for any unintentional errors or inaccuracies that may appear in this document.
Warranty Disclaimer: The services and hardware are provided "as is" and "as-available" and the
use of the services and hardware is at its own risk. ID TECH does not make, and hereby
disclaims, any and all other express or implied warranties, including, but not limited to,
warranties of merchantability, fitness for a particular purpose, title, and any warranties arising
from a course of dealing, usage, or trade practice. ID TECH does not warrant that the services or
hardware will be uninterrupted, error-free, or completely secure.
ii
NEO Interface Developers Guide NEO v1.00
Table of Contents
1.0 INTRODUCTION ............................................................................................................................ 1
iii
NEO Interface Developers Guide NEO v1.00
iv
NEO Interface Developers Guide NEO v1.00
v
NEO Interface Developers Guide NEO v1.00
vi
NEO Interface Developers Guide NEO v1.00
vii
NEO Interface Developers Guide NEO v1.00
APPENDIX A.8: TRANSACTION RESULTS FOR MSD2.0.2 AC3.0 CRYPTOGRAM17 .................................... 306
APPENDIX A.9: PREPARING BITMAPS FOR USE WITH ILM ...................................................................... 307
APPENDIX A.11: ENHANCED ENCRYPTED MSR DATA OUTPUT FORMAT ................................................ 321
viii
NEO Interface Developers Guide NEO v1.00
List of Tables
Table 1: Hardware Cross Reference .................................................................................... 3
Table 2: Commands Sorted by Command Name ................................................................ 4
Table 3: Commands Sorted by Command Number ............................................................. 7
Table 4: Pass-Through Command Table .............................................................................. 9
Table 5: EMV Key Management – Protocol 2 .................................................................... 10
Table 6: EMV Key Management - Protocol 1..................................................................... 10
Table 7: Protocol 1 Status Codes ....................................................................................... 11
Table 8: Protocol 2 Status Codes ....................................................................................... 11
Table 9: Error Codes .......................................................................................................... 13
Table 10: RF State Codes ................................................................................................... 17
Table 11: Serial Port Settings ............................................................................................. 18
Table 12: Burst Mode Frames............................................................................................ 32
Table 13: Payload Frame with Cryptogram Data Format and Content When Status OK . 33
Table 14: Asynchronous UI Message Event ....................................................................... 38
Table 15: Asynchronous UI Message Event Status ............................................................ 39
Table 16: Asynchronous UI message Event Application Type ........................................... 39
Table 17: System AIDs ....................................................................................................... 46
Table 18: Global Configuration TLVs ................................................................................. 50
Table 19: Group Configuration TLVs .................................................................................. 54
Table 20: PayPass Default Group Configuration TLVs ....................................................... 61
Table 21: PayPass Group Configuration TLVs with Hard-Coded Default Values in Kernel 68
Table 22: Phone Message Table – Hard-Coded Default Value in Kernel .......................... 71
Table 23: American Express Default Group 2 Configuration TLVs .................................... 72
Table 24: AID Configuration TLVs ...................................................................................... 74
Table 25: System AID Default Configuration TLVs ............................................................. 77
Table 26: Get Full Track Data Error Codes ......................................................................... 87
Table 27: EMV Key Management Commands Error Codes – Protocol 1........................... 91
Table 28: Set CA Public Key Data Field .............................................................................. 94
Table 29: Error Codes for RTC Management Commands .................................................. 99
Table 30: Control User Interface Data ............................................................................. 106
Table 31: Activate Transaction Command Frame Data Format ...................................... 127
Table 32: Activate Command TLVs .................................................................................. 128
Table 33: Activate Transaction Response Frame Data Format ....................................... 130
Table 34: Activate Response TLVs ................................................................................... 130
Table 35: Activate Transaction Clearing Record TLVs ..................................................... 134
Table 36: Activate Transaction Cause of Failure When Not Request Online Authorization
................................................................................................................................. 136
Table 37: Activate Transaction Cause of Failure When Request Online Authorization .. 136
Table 38: Activate Transaction Response Frame Format, Failed Transaction ................ 136
Activate Transaction Response Frame Encrypted Data Format ...................................... 144
ix
NEO Interface Developers Guide NEO v1.00
Table 39: Get Transaction Result Format and Content ................................................... 149
Table 40: Update Balance Format and Contents............................................................. 152
Table 41: Update Balance Format and Contents When Status OK ................................. 152
Table 42: Update Balance Format and Contents When Status Not OK .......................... 153
Table 43: Cash Transaction TLVs ..................................................................................... 157
Table 44: DRL TLVs ........................................................................................................... 161
Table 45: EMV Key Manager Status Codes – Protocol 2 ................................................. 164
Table 46: Language Version Information ........................................................................ 177
Table 47: Exception List Record Format .......................................................................... 186
Table 48: Get PCD and PICC Parameters Data Field ........................................................ 187
Table 49: Poll for Token Data Field for Command Frame ............................................... 188
Table 50: Poll for Token Timeout .................................................................................... 189
Table 51: Poll for Token Data Field for Response Frame (Status Code is OK) ................. 189
Table 52: Enhanced Poll for Token Data Field for Command Frame .............................. 191
Table 53: Enhanced Poll for Token Timeout.................................................................... 191
Table 54: Enhanced Poll for Token Data Field for Response Frame ............................... 192
Table 55: LED Control Data Field ..................................................................................... 195
Table 56: Buzzer Control Data Field ................................................................................ 196
Table 57: PCD Single Command Exchange Data Field Protocol 2.................................... 197
Table 58: PCD Commands Protocol 2 .............................................................................. 198
Table 59: PCD Channel Redundancy Register Protocol 2 ................................................ 199
Table 60: PCD Single Command Exchange Data Field for Response ............................... 200
Table 61: Halt a Command Exchange Between Terminal/PC and Reader ...................... 201
Table 62: Enhanced Pass-Through Data Field ................................................................. 203
Table 63: Mifare Authentication Block Data Field........................................................... 211
Table 64: Mifare Read Block Data Field ........................................................................... 212
Table 65: Mifare Write Block Data Field .......................................................................... 214
Table 66: ePurse Value Block Format .............................................................................. 215
Table 67: Mifare ePurse Command Data Field ................................................................ 216
Table 68: Mifare ePurse Data Field for Debit/Credit Function Block .............................. 217
Table 69: Mifare ePurse Data Field for Backup Function Block ...................................... 218
Table 70: NFC Command Set List ..................................................................................... 221
Table 71: NFC Command Set Response Data List ............................................................ 222
Table 72: Summary of LCD Messages .............................................................................. 271
x
NEO Interface Developers Guide NEO v1.00
1.0 Introduction
This document is intended to provide application developers and integrators with the detailed
information necessary to integrate ViVOpay readers with point of sale terminals (POS). It
specifies the interfaces that terminals can use to communicate with a ViVOpay reader to carry
out contactless EMV transactions.
Historical Background
Before the introduction of the contactless EMV, the ViVOpay reader usually worked in
standalone mode, which did not require a terminal to initiate a transaction. In this mode, the
reader reads cards and sends transaction data independently. This mode is commonly referred
to as “Auto Poll Mode”.
ViVOpay readers can also function in an intelligent mode to provide EMV functionality and fast
processing of contactless EMV cards. This approach minimizes the time a cardholder needs to
hold a contactless EMV card in front of a reader. However, support for contactless EMV cards
requires that terminals set certain parameters and perform intelligent processing to complete a
transaction.
While contactless EMV transactions require control commands from a terminal, it is sometimes
desirable for the ViVOpay reader to function in standalone mode. This is especially useful for
test environments where a terminal may not be available or where all transactions are going to
be with contactless MagStripe cards. The EMV serial interface specified in this document
addresses the requirements of contactless EMV support, while maintaining backward
compatibility to standalone operation.
ViVOpay readers support MasterCard Contactless technology (PayPass 3.02). You will see
numerous references to “PayPass” throughout this guide. MasterCard has officially deprecated
the name “PayPass” (although not the technology). This version of the guide continues to use
“PayPass” to refer to MasterCard Contactless technology. Future versions of this guide will likely
drop the name “PayPass” altogether.
Protocol 1 Deprecated
Historically, ID TECH readers have used two serial protocols (Protocol 1 and Protocol 2).
Protocol 1 is no longer supported. For historical reasons, you may see references to Protocol 1 in
this guide. They will eventually be removed.
This document provides the details of how to communicate with ViVOpay readers, including the
physical connections, the ViVOpay command protocols, and the actual serial commands. The
document is organized into major sections that contain increasing levels of detail:
The Quick Reference section includes tables of commands, error and status codes. It is
intended to be a quick index into the Protocol Command Reference sections (Protocol 1
and Protocol 2), or a quick reference for decoding serial commands and responses.
1
NEO Interface Developers Guide NEO v1.00
The Serial Communication Interfaces section discusses the serial interfaces available.
The Tag and Data Set Configuration discusses the method for configuring AIDs and
groups (parameter/data sets).
The Card Application Selection section discusses the method for selecting a particular
card application and how selection of a particular AID may be controlled.
The Protocol Command Reference sections (Protocol 1 and Protocol 2) describe each of
the commands available, their frame formats, and the response formats
The Special Reader Features section discusses additional features that may optionally be
used in conjunction with ViVOpay readers. Some of these are specific to a particular
ViVOpay reader hardware platform.
Many useful examples of serial communication flows can be found in the various
Appendices at the back of this guide. Also, the Appendices contain examples of how to
parse data payloads received during transactions. In future editions of this guide, we
will continue to add examples.
Notational Conventions
Many of the tables used in this document describe data objects as TLV (tag, length, value)
elements. The details of how TLVs are encoded and explained in the BER-TLV rules. These
rules may be found in EMV 4.2 Book 3, Annex B (available from
https://www.emvco.com/specifications.aspx?id=223).
The format of the value fields are described in EMV 4.2, Book 3, “Data Element Format
Conventions”.
ViVOpay readers can be generally categorized by their capabilities to interact with the host
terminal. ViVOpay readers fall into one of the following categories according to the available
transaction interfaces:
Contactless Only
2
NEO Interface Developers Guide NEO v1.00
Generally, the commands and parameters related to the LCD display only work on the
ViVOpay readers with a display. However, there is an option to use an external display.
Refer to the Set/Get Source for RTC/LCD/Buzzer/LED command.
3
NEO Interface Developers Guide NEO v1.00
Command Tables
The tables in this section organize the commands by their names and by their command number.
4
NEO Interface Developers Guide NEO v1.00
5
NEO Interface Developers Guide NEO v1.00
All commands in the following table use Protocol 2 formats (see Protocol 2 Formats) except for
Get Full Track Data, Set RF Error Reporting, and Get ViVOpay Firmware Version.
6
NEO Interface Developers Guide NEO v1.00
7
NEO Interface Developers Guide NEO v1.00
8
NEO Interface Developers Guide NEO v1.00
All commands in the following table use Protocol 2 formats (see Protocol 2 Formats).
9
NEO Interface Developers Guide NEO v1.00
RID
All commands in the following table use Protocol 1 formats (see Protocol 1). These commands
are included for backward compatibility. New development should use Protocol 2 commands
listed above.
10
NEO Interface Developers Guide NEO v1.00
Status Codes
The tables in this section define status codes for Protocol 1 and Protocol 2. Note that Protocol 1
is deprecated.
11
NEO Interface Developers Guide NEO v1.00
1
Status codes in this range are “module-specific” so that their values can be re-used by different modules. The
meaning of these codes may depend on which command is being issued. An exception is 23h, which is used generally.
12
NEO Interface Developers Guide NEO v1.00
Error Codes
If the reader supports a contact interface, advise the user to complete the
Go to Contact transaction on the contact interface.
02h
Interface
Previously, this error code was used if the reader supported another
interface (beside the contact interface). Integrators should use error code
04h Go to Other Interface instead. The previous use has been deprecated.
Transaction If the transaction amount is zero and the terminal is “an offline only terminal”
03h then reader needs to terminate the transaction.
Amount is Zero
The transaction has failed.
Go To Other
04h
Interface If the reader supports another interface, advise the user to complete the
transaction on the other interface.
The transaction has failed.
If there is another nearby contact interface, advise the user to complete the
Go To Nearby
05h transaction on the nearby contact interface. This situation might be a case
Interface
where there are multiple pay stations, but only one of them has a contact
interface.
13
NEO Interface Developers Guide NEO v1.00
Error
Description Reason for Error and Suggested Error Handling
Code
The transaction has failed.
Go To MagStripe
06h If the reader has a MagStripe interface, advise the user to complete the
Interface
transaction using the MagStripe interface.
Card returned SW1SW2 not equal to 9000 hex. Value of the SW1SW2 bytes from
the Card is returned in the Data portion of the Response Frame. Details of what
the SW1SW2 codes mean for each RF State are Card dependent and are out of
the scope of this document.
How the terminal handles this error depends on when the error occurs in the
transaction flow. The RF State Code (see section on RF State Codes) indicates
the transaction state when the error occurred. Suggested error handling for
individual RF State Codes is given below:
14
NEO Interface Developers Guide NEO v1.00
Error
Description Reason for Error and Suggested Error Handling
Code
Card was removed from the field or there was a Communication Error
preventing the card response from reaching the reader. How the terminal
handles this error depends on when in the transaction the error occurred. The
RF State Code (see section on RF State Codes) indicates the transaction state
when the error occurred. Suggested error handling for each RF State Code is
given below:
15
NEO Interface Developers Guide NEO v1.00
Error
Description Reason for Error and Suggested Error Handling
Code
Terminal Risk The Terminal Risk Management step as defined in EMV Specifications failed.
56h Management This could be due to incorrectly set configuration. Retrying the transaction
(TRM) Failed does not correct the error until the EMV configuration is corrected.
Cardholder The Cardholder Verification step as defined in EMV Specifications failed. This
57h Verification could be due to incorrectly set configuration. Retrying the transaction does not
Failed correct the error until the EMV configuration is corrected.
Terminal Action The Terminal Action Analysis step as defined in EMV Specifications failed. This
58h Analysis (TAA) could be due to incorrectly set configuration. Retrying the transaction does not
Failed correct the error until the EMV configuration is corrected.
SD Memory Error This error is reported only when trying to retrieve Transaction Logs. This error
61h
is never reported during a transaction.
This is a generic / general error that is reported when a more specific reason
62h Generic Error
for the error is not known.
Torn An error occurred while attempting to clean the torn transaction log. This
73h Transaction Log might occur if the reader could not read the time and date from the real time
Error clock.
No Merchants This error usually occurred while MerchantID is empty.
80h have been
configured
TLV Parse This error usually occurred while fail to TLV parsing card response data.
81h
Failure
Merchant Data This error usually occurred while no merchant data returned from card.
82h
Error
System Memory This error usually occurred while fail to read or write system memory.
83h
Error
Application Skip This error usually occurred while configuration isn’t consistent on whether or
84h
Error not to skip payment application
Application This error usually occurred while application version number is incorrect.
85h
Version Error
If an error occurs during a transaction and the terminal determines that the reader must
perform exception processing, then the terminal must retry the transaction until the transaction
has been completed successfully or the terminal decides to abort it. The retries must be
continued even if successive transactions fail with conditions that do not require exception
processing. This must be done to allow the reader to complete exception processing (even if
there are failures during exception processing).
Under certain conditions, such as when a customer walks away or there is a problem with the
card, the terminal may want to abort the retries even if the reader has not been able to
complete exception processing. How and when the terminal stops retrying is out of the scope of
this document.
RF State Codes
For some Error Codes, the RF State Code indicates the exact Reader-Card command that failed.
This helps determine the exact place where the failure occurred.
16
NEO Interface Developers Guide NEO v1.00
17
NEO Interface Developers Guide NEO v1.00
Port Settings
To communicate with the ViVOpay reader, set the terminal’s serial communication parameters
to the values listed below.
Basic Communication
The ViVOpay reader and the POS terminal communicate by exchanging Command-Response
Frames. The terminal always initiates communication by sending a Command Frame and
ViVOpay responds by sending a Response Frame. What frames are exchanged depends on the
command and the protocol used. There are two command/response protocols. Protocol 1 uses
separate Data Frames and ACK/NACK responses. Protocol 2 is simplified by including data within
the Command/Response Frames.
18
NEO Interface Developers Guide NEO v1.00
Timeouts
The ViVOpay reader does not timeout while trying to receive a command. There is no maximum
inter-character delay. As a result, command frames with length errors may appear to “hang”.
A subsequent command that does not contain a length error can be received successfully.
Once the ViVOpay reader has received a command, the time required to respond to the terminal
varies from command to command, depending on what processing is required.
During a transaction, the Activate (02-01) command may specify a timeout value. The reader
will continue to poll until it starts to process a transaction, or the specified timeout period has
elapsed. The transaction may not complete within the timeout period.
ViVOpay readers can communicate with the terminal using a RS232 Serial link and/or a USB HID
link.
All ViVOpay commands sent over the USB HID interface are encapsulated in the following
protocol.
Note: The maximum length for any command or response is 1500 bytes since this is the size
of the command FIFO.
All HID reports sent to or received from the ViVOpay are 64 bytes long. The first byte of the
frame is a single byte Report ID number. The remaining 63 bytes carry the report payload. Any
reports with less than 63 bytes of command or response data are padded with NULL bytes (00h)
to make them 63 bytes long.
ViVOpay commands and responses are sent over the USB bus in 63-byte frames. Byte ordering in
the USB frame is the same as if the command were sent over the serial port. In other words, the
“ViVOtech2” command tag always starts in the second byte of the first report containing the
command, just after the Report ID.
There are four defined report IDs used in this protocol: 1, 2, 3, and 4. Undefined report IDs are
silently ignored.
3.1.1.1 Report ID 1
ID 1 frames are used when a complete command or response is 63 bytes or less. As soon as the
host or device receives a Report ID 1 frame, it should parse the report data to extract the
command or response.
19
NEO Interface Developers Guide NEO v1.00
3.1.1.2 Report ID 2
ID 2 frames are used when a complete command or response is more than 63 bytes long and
cannot fit in a single report. The Report ID 2 frame contains the first 63 bytes of the command.
So the “ViVOtech2” command tag is only present in Report IDs 1 or 2. The Report ID 2 frames
always contain 63 bytes of valid data with no padding bytes since the command is more than 63
bytes long.
3.1.1.3 Report ID 3
ID 3 frames are continuation frames. For any command or response that is more than 126 bytes
long, the middle frames of the response are sent with a report ID of 3. Any frame received with
a report ID 3 is ignored unless it is preceded by a report with an ID of 2 or 3. The Report ID 3
frames should always contain 63 bytes of valid data with no padding bytes.
3.1.1.4 Report ID 4
ID 4 frames mark the end of multi-report commands. Any padding needed to make the command
a multiple of 63 bytes should be placed in this report. Any frame received with a report ID 4 is
ignored unless it is preceded by a report with an ID of 2 or 3. As soon as the host or device
receives a valid Report ID 4 frame, it should parse the report data to extract the command or
response.
The exception to the rule of only adding pad bytes to reports with ID of 1 or 4 is debug test
frames. Surrounding a command with pad bytes to make the command span multiple reports is
valid for testing the multi-report handling of the host and device software. This must be avoided
in deployed code since it slows command processing times.
The serial port version of this command and response would be: (Data bytes in Hex format)
Command: 56 69 56 4F 74 65 63 68 32 00 18 01 00 00 B3 CD
Response: 56 69 56 4F 74 65 63 68 32 00 18 00 00 00 FA 83
20
NEO Interface Developers Guide NEO v1.00
Data Frames
Byte 0-8 Byte 9 Byte 10 Byte 11 … Byte n+10 Byte n+11 Byte n+12
CRC CRC
Frame MSB if from LSB if from
Frame Tag Data 0 Data 1 … Data n ViVOpay. ViVOpay.
Type LSB if from MSB if from
Terminal. Terminal.
ViVOtech\0 ‘D’ …
The pad bytes are marked with blue text in this example.
21
NEO Interface Developers Guide NEO v1.00
04 AC F8 00 FF FE 05 F8 50 AC A0 00 FF FF 05 00
00 00 00 00 72 56 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
The pad bytes are marked with blue text in this example.
Note: The response to this command changes each time the command is sent since it
includes the current time and date.
The serial port version of this command and response would be: (Data bytes in Hex format)
Command: 56 69 56 4F 74 65 63 68 32 00 03 02 00 00 5B 91
Response: 56 69 56 4F 74 65 63 68 32 00 03 00 00 C2 FF E4 01 00 9F 02
06 00 00 00 00 00 01 9F 03 06 00
00 00 00 00 00 DF 63 01 00 DF 64 01 01 DF 65 01
00 DF 66 01 00 FF F0 03 00 00 00 FF F2 08 30 30
30 30 30 30 30 30 FF F3 02 03 FF FF F7 01 02
FF F9 01 03 FF FA 02 03 E8 9A 03 00 01 04 9F 21
03 05 13 54 9C 01 00 5F 2A 02 08 40 9F 09 02 00
02 9F 1A 02 08 40 9F 1B 04 00 00 17 70 9F 33 03
00 08 E8 9F 35 01 22 9F 40 05 60 00 00 30 00
9F 66 04 A0 00 00 00 FF F1 06 00 00 00 01 00 00
FF F4 03 01 00 01 FF F5 06 00 00 00 00 80 00 FF
F8 01 00 FF FB 01 00 FF FC 01 00 FF FD 05 F8 50
AC F8 00 FF FE 05 F8 50 AC A0 00 FF FF 05 00
00 00 00 00 72 56
1. Any report with ID of 1 is processed as soon as it is received. All other unprocessed reports
are discarded.
2. Any report with an ID of 2 causes all other unprocessed reports to be discarded.
3. Any report with an ID of 3 is discarded unless the previous report had an ID of 2 or 3. If the
previous report ID 3 was discarded then this report also is discarded.
4. Any report with an ID of 4 is discarded unless the previous report had an ID of 2 or 3. If the
previous report had an ID of 3 and was discarded then this report also is discarded. If the
report ID 4 frame is retained, then all retained reports are processed.
Processing of reports means passing the concatenated Data Frames contained in the reports to
the command handler. The report ID bytes must be discarded when concatenating the report
Data Frames.
An alternate way to handle the rules for report IDs 3 and 4 is to set a flag when a report with an
ID of 2 is received and reset the flag when a report with an ID of 1 is received or an ID of 4 is
finished processing. Reports with IDs of 3 or 4 are only kept when the flag is set.
22
NEO Interface Developers Guide NEO v1.00
The error handling at the command level remains as it is currently implemented for serial port
commands.
Incomplete commands are silently ignored when the reception times out. This does not occur for
commands received over the USB HID interface unless a complete report is dropped, resulting in
missing data for the command. The normal USB handshaking is expected to prevent this.
A bad CRC value for the encapsulated command returns a bad CRC response to the command.
If the host does not receive any response to a command it should retry the command.
If the host receives a bad CRC response to a command it should retry the command. This is not
expected to occur when using USB since it includes a layer of error handling.
23
NEO Interface Developers Guide NEO v1.00
There are two main types of protocols: Protocol 1 and Protocol 2. Protocol 2 is the preferred
method of communicating between the terminal/POS and a ViVOpay reader. Protocol 1 is
retained for backward compatibility with older terminal/POS applications.
In addition to the two main protocols, there are modes of communication that are extensions of
the protocols. These modes provide flexibility in the control of the ViVOpay reader:
Pass-through mode allows the terminal/POS application to interact directly with the
contactless ISO 7816 cards.
Burst Mode is a legacy mode intended for use with MagStripe cards.
Protocol 1 (Deprecated)
Communication between ViVOpay and the terminal uses command-response pairs. The terminal
sends one or more Command Frames to the reader and waits for one or more response frames. A
simple command requires a single Command Frame with a single Response Frame. More complex
commands may involve a number of Command/Response Frames being exchanged. This sub-
section defines the different types of frames and their format.
Details of specific commands and the order in which different frames are exchanged are
documented in a later sub-section.
There are five types of frames – Command, Data, ACK, NACK and Special Frames. The format of
each type of frame is given below.
Command Frames
24
NEO Interface Developers Guide NEO v1.00
ACK Frames
NACK Frames
A NACK Frame has the same fields as an ACK Frame unless specified differently for a specific
command. The only difference between a NACK and ACK Frame is that the NACK Frame always
contains an Error Status. When ViVOpay returns a NACK Frame, the terminal must consider the
command terminated. The Data1 and Data2 fields are not used with a NACK, unless specified
differently by a command.
Special Frames
Protocol 2
There are two types of frames for Protocol 2: Command Frames and Response Frames. The
general format of these frames is given below.
25
NEO Interface Developers Guide NEO v1.00
Command Frames
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0
Response Frames
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag Data Data
Status
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Code
Version (MSB) (LSB)
ViVOtech2\0
Some versions of ViVOpay firmware provide a Pass-Through mode which can be used by a
terminal to communicate directly with an RF card. This feature allows a terminal to add support
for RF cards that are not directly supported by the ViVOpay firmware. Pass-through is actually a
special mode of the ViVOPay Protocol 2.
This section describes the Pass-Through protocol and frames for the ViVOpay Serial Interface
Protocol.
Pass-Through mode allows a terminal to communicate directly with an ISO 14443 Type A or Type
B Proximity Integrated Circuit Card (PICC) without the ViVOpay firmware knowing the specifics
of the application or data present on the PICC. The Pass-Through mode supports a set of basic
commands that allow polling and selection of a PICC and sending/receiving low level
information to/from the PICC. This allows a terminal to communicate with (and support) cards
with applications and data that are not supported by a System AID. Individual Pass-Through
commands are described in the sections that follow.
26
NEO Interface Developers Guide NEO v1.00
These commands have to be used whether you are using high level communication with the
PICC or low level communication. These commands include:
Pass-Through Mode Start/Stop
Poll for Token
The terminal must periodically instruct the ViVOpay reader to poll for cards. Whenever the
ViVOpay reader detects a card in the RF field, it tries to carry out ISO 14443 Layer 3 and Layer 4
negotiations and report the card type found. In the Pass-Through mode, ViVOpay does not
attempt to check whether the card application is one that it supports.
Once a card is detected, the terminal may use one of the Pass-Through commands to
communicate with the card at the application level and read the data.
Additional Pass-Through commands allow a terminal to use low-level features provided by the
ViVOpay reader, such as controlling the RF antenna (field).
Note: The Byte 14+n and Byte 15+n CRCs are the reverse of standard Protocol 1 Format and
Protocol 2 Format Command Frames. Within each Pass-Through Frame Type, the CRC is
stored as big-endian number i.e. higher byte (MSB) first.
27
NEO Interface Developers Guide NEO v1.00
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n
Byte 14+n-1 15+n
Header Tag Data Data
Status CRC
& Protocol Command Length Length Data CRC (MSB)
Code (LSB)
Version (MSB) (LSB)
See See See See
See Individual
ViVOtech2\0 Individual Individual Individual Individual
Commands
Commands Commands Commands Commands
Put the ViVOpay reader in Pass-Through Mode by sending a Start Pass-Through Mode command.
Periodically request ViVOpay to poll for cards by sending the Poll for Token command. If no
card is found within the time specified, the reader ViVOpay indicates this with a timeout error.
If a card is found, it returns the card type and serial number.
At this point ViVOpay already has gone through the anti-collision, selection and
activation (if required) sequence as per ISO 14443 A/B, and the card is ready for
communication. Depending on the Card Type, use the appropriate Pass-Through
commands to communicate with the card. Card Types and the applicable
commands are given below.
For ISO 14443-4 Compliant Type A or Type B Cards
Use the Exchange Contactless Data command to communicate with the Card at the
application level.
For ISO I4443 Type A or Type B Cards that are not ISO 14443-4 Compliant
(i.e. ISO 14443-3 Compliant Cards), Mifare Type A, and Mifare Ultralight Type A
Low Level Commands: Use the PCD Single Command Exchange command to communicate
with the Card. If required, use the Get PCD and PICC Parameters command for greater
control.
High Level Commands (For Mifare Cards Only): Or use the Mifare Authenticate Block, Mifare
Read Blocks, and Mifare Write Blocks commands to communicate with a Mifare Standard (1K)
or Mifare Ultralight Card.
For Card Type None
The Card has either been removed from the Field, or there was an error in trying to connect
to the card, or the card is not ISO 14443-3 or 14443-4 compliant. No need to communicate
with the card.
When done communicating with the card, the terminal is responsible for handling the
termination sequence. The terminal may use the Antenna Disable/Antenna Enable commands to
turn the RF field off and then on again.
The terminal can instruct the ViVOpay reader to terminate the Pass-Through Mode and start
normal polling for cards by sending a Stop Pass-Through Mode command.
28
NEO Interface Developers Guide NEO v1.00
Note: If the terminal communicates with the card in the Pass-Through mode and finds that it
does not support the card, then the terminal is responsible for handling the termination
sequence with the card. The terminal may keep sending Poll for Token commands to the
ViVOpay reader until the card has been removed from the field, replaced by another card
(different serial number), or a timeout has occurred before it terminates the Pass-Through
mode. The terminal may choose to terminate the Pass-Through mode as soon as it is reading
is complete.
Care should be taken to ensure that the ViVOpay reader is operating in the correct mode
(Auto-Poll or Poll on Demand) when returning from Pass-Through mode. If the card is not
removed from the field fast enough, and the reader is in Auto Poll mode, the terminal may
end up doing multiple reads of the same card.
The reader can be set to switch automatically out of polling (either Poll on Demand or Auto-
Poll) and enter Pass-Through Mode. This allows the POS application to send Pass-Through Mode
commands directly to the card APDU without explicitly setting the reader in Pass-Through Mode.
Auto-Switch can be enabled globally and for configurable User AIDs. This feature is not
supported for System AIDs.
If the Auto-Switch feature is enabled, the reader switches to Pass-Through Mode under the
following conditions:
There are two ways to use the auto-switch feature: Global Auto-Switch or User AID Auto-Switch.
The DF7C TLV sets the feature globally using the Set Configuration command (Global Auto-
Switch) and the Set Configurable AID sets the feature for user AIDs (User AID Auto-Switch). You
can use both at the same time if you wish, but they do different things so do not confuse the
two. In general, one is used for MiFare, DesFire or unrecognized cards. The second is ONLY used
for a specific User AID. The Auto-Switch setting in a User AID overrides the Global Auto-Switch
setting.
Once the Auto-Switch feature is activated, the POS application must handle error recovery and
exit Pass-Through Mode with the Pass-Through Mode Start/Stop command (2C-01) when done.
The reader returns to previous polling mode or idle state. For example, if you were exiting Pass-
Through mode and resuming Auto Poll mode, the POS must make sure the PICC has left the field
before terminating Pass-Through mode. Otherwise Auto Poll will start and the PICC will be read
by the reader again as a brand new transaction!
29
NEO Interface Developers Guide NEO v1.00
a completely unrecognized PICC (failed MiFare, DesFire, PPSE, Trial & Error)
Auto-Switch is invoked if Global Auto-Switch is enabled AND one of the above cards is tapped on
the reader during a transaction.
If successful, the reader returns a Response Frame containing some of the following items:
Error or Status condition
UID
PICC card type detected
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 50h or 51h
Code Table
Table 12: Poll for Token Data Field for Response Frame (Status Code is OK)
Data Field Length Description
(bytes)
Card 1 Type of Card Found (or No Card Found).
00h None (Card Not Detected or Could not Activate)
01h ISO 14443 Type A (Supports ISO 14443-4 Protocol)
02h ISO 14443 Type B (Supports ISO 14443-4 Protocol)
03h Mifare Type A (Standard)
04h Mifare Type A (Ultralight)
05h ISO 14443 Type A (Does not support ISO 14443-4 Protocol)
06h ISO 14443 Type B (Does not support ISO 14443-4 Protocol)
07h ISO 14443 Type A and Mifare (NFC phone)
Serial 0 or Serial Number (or the UID) of the PICC. Length depends on the Card
Number Variable Detected. If no card was detected, then a Serial Number is not returned.
Once Auto-Switch is invoked the reader remains in Pass-Through Mode with the RF antenna on.
The POS application must handle error recovery and exit Pass-Through Mode when done with the
Pass-Through Mode Start/Stop command (2C-01). The reader returns to previous polling mode or
idle state.
To enable Global Auto-Switch, send the Set Configuration command (04-00) with a 01h value for
the DF7C TLV.
30
NEO Interface Developers Guide NEO v1.00
Auto-Switch is invoked if User AID Auto Switch is enabled for an AID and a PICC is initiating a
transaction with this AID selected.
If successful, the reader returns a response frame containing some of the following items:
Error or Status condition
AID
PICC card type detected
Once Auto-Switch is invoked the reader remains in Pass-Through Mode with the RF antenna on.
The POS application must handle error recovery and exit Pass-Through Mode when done with the
Pass-Through Mode Start/Stop command (2C-01). The reader returns to previous polling mode or
idle state.
To enable Global Auto-Switch, send the Set Configurable AID command (04-02) with a 01h value
for the DF7C TLV.
Sending a Stop Pass-through command will turn off the RF Antenna. Otherwise,
the antenna is under the direct control of the POS/Terminal in Pass-through
mode.
Burst Mode
In Burst Mode, a Data Frame is sent from the ViVOpay reader to the terminal each time a card is
read successfully. The ViVOpay keeps polling for the supported RF Cards. Whenever the ViVOpay
reader detects a card in the RF Field, it tries to read the card data. If the read operation is
successful, the ViVOpay reader sends a “Card Payload” frame that contains the Status,
Application Type, Card Data and CRC to the terminal through its serial port. Detailed
information on the frame format is given in the sections ahead. The terminal does not have to
send any command or data to the ViVOpay reader.
Note: The reader must be in Auto Poll mode for Burst Mode to be used successfully. Setting
Burst Mode on for other configurations can lead to unexpected results.
Burst mode is intended to be used with magnetic stripe card data only.
Burst Mode is enabled using the Set Configuration command and the FFF7 tag. There are two
options for Burst Mode: Always On (FFF7 = 01) and Auto Exit (FFF7 = 02). When the reader is in
Burst Mode Always On, it ignores Activate Transaction and Get Full Track Data commands and
remains in Burst Mode. When Burst Mode Auto Exit is enabled, the reader ends Burst Mode (FFF7
31
NEO Interface Developers Guide NEO v1.00
= 00) and processes these command. Burst Mode then remains off until it is reactivated with a
new Set Configuration command with tag FFF7 set to 01 or 02.
When the Burst Mode is enabled, the standard ViVOpay Serial Interface is not disabled entirely.
Commands not related to transactions, such as Ping, can still be sent to the ViVOpay reader. In
the Command-Response Mode, the terminal sends a command to the ViVOpay reader and the
ViVOpay reader responds in a pre-defined manner. These commands allow a terminal to use
features provided by the ViVOpay reader, such as checking for the presence of the ViVOpay
reader by pinging it, retrieving the firmware version number, etc.
when encryption is enabled, burst mode is always OFF. When encryption is enabled, reader will
turn the burst mode to be OFF automatically. When encryption is enabled, if user wants to make
burst mode to be ON/AUTO EXIT through “Set Configuration (04-00)” command, reader will
response error.
The table below describes the Burst Mode frame types. The frame type appears
in Byte 0 of a Burst Mode packet.
On successful read ViVOpay sends a Card Payload frame to the terminal that always contains
Frame Type, Status and Application Type. The Status always shows Success (=00). The
Application Type can have any of the values defined in the “Data Definitions” section. This is
followed by the track data. Only those tracks the reader was able to read from the Card are
sent. Each Track begins and ends with its Start and End Sentinel. After the Track Data, the
reader sends two CRC bytes. The details of the CRC algorithm used are given in the “CRC
Calculation” section.
32
NEO Interface Developers Guide NEO v1.00
Example 1: Payload, Card Read Successfully, Application Type Visa, Both Track 1 and Track 2
Present
Example 2: Payload, Card Read Successfully, Application Type MasterCard, Only Track 2 Present
Example 3: Payload, Card Read Successfully, Application Type AmEx, Only Track 1 Present
Example 4: Payload, Card Read Successfully, Application Type Unknown, Both Track 1 and Track
2 Present
For MSD-only readers that require an online cryptogram (i.e. TTQ = ‘80 80 00 00’) MSD v1.4.2
and v2.0.2 transactions return the burst mode payload frame is described as follows (please
refer to Visa Contactless Payment V. 2.0.2 Including Additions and Clarifications 3.0 – August
2007):
Byte5 … Byte
Byte 0 Byte 1 Byte 2 Byte 3 Byte 4 Byte 5+n Byte6+n
5+n-1
Data Data
Frame Status Applicatio CRC
Length Length Data CRC (MSB)
Type Code n Type (LSB)
(MSB) (LSB)
See table See
03h below Applicatio See Data Tables
n Type
If Status Code is OK then the format and contents of the data field in the Response Frame are
given in the following table. All TLV lengths in the TLV include the Tag and Length bytes.
33
NEO Interface Developers Guide NEO v1.00
34
NEO Interface Developers Guide NEO v1.00
If the terminal fails to receive the card payload data, it can send a NACK frame and request the
ViVOpay reader to resend the card payload data. To ensure that the reader resends the card
payload data, the NACK frame must be received by the reader within 500ms after it sends the
original card payload. If the reader receives the NACK frame within this time period, it resends
the card payload data to the terminal. If the reader receives the NACK Frame after 500ms of
sending the original card payload, or if a new card has been detected, the reader ignores the
NACK frame and does not resend the payload data. Each payload data is only resent once.
35
NEO Interface Developers Guide NEO v1.00
Byte 0
Frame Type =0x55h
Example 1: ViVOpay receives NACK frame from terminal within 500ms after sending the original
payload data, ViVOpay resends the card payload data.
Resend Payload |
◄---------------------------------------------------------------------
|
▼
Original Payload:
Payload, Card Read Successfully, Application Type Master Card, Both Track 1 and Track 2
Present
[01][00][01]%B5325350000623567^840SMITH/JOHN^05085011492563892473?;532
5350000623567=05081019492993892483? <CRC1><CRC2>
Resent payload:
Payload, Card Read Successfully, Application Type Master Card, Both Track 1 and Track 2
Present
[01][00][01]%B5325350000623567^840SMITH/JOHN^05085011492563892473?;532
5350000623567=05081019492993892483? <CRC1><CRC2>
36
NEO Interface Developers Guide NEO v1.00
Example 2: Reader receives NACK frame from terminal after 500ms of sending
the original payload data, the reader does not resend the card payload data.
No Resend Payload |
▼
Payload, Card Read Successfully, Application Type American Express, Both Track 1 and Track 2
Present
[01][00][03]%B379013539021002^TEST/CARD001^0604718000877840?;379013539021002=0604718
00087784000102? <CRC1><CRC2>
Asynchronous message event is used by the reader to indicate specific events to the terminal.
These frames are only sent when LCD and LED are sent to external source.
In synchronizing with the transaction, the reader can send asynchronous user interface (UI)
message event to the terminal to specify the required user experience on the terminal.
37
NEO Interface Developers Guide NEO v1.00
Byte 3 is the UI Scheme # that allows the user to have different user interfaces (LCD display
message table, and buzzer/LED profiles).
Bytes 5 & 6 are the UI Event consisting of component (LCD, LED, or Buzzer) and acts as defined
below.
List of messages and the message flow for one user experience are given in Appendix 2. More
user experience shall be listed later.
38
NEO Interface Developers Guide NEO v1.00
The Status never has a value that matches the Track 1 and Track 2 Start/End Sentinels.
The Application Type never has a value that matches the Track 1 and Track 2 Start/End
Sentinels.
39
NEO Interface Developers Guide NEO v1.00
%B123456789^ABCDEF^12345678?
;12345678=12345?
01 00 0A 25 42 36 32 37 39 32 35 37 37 34 39 31
33 32 33 34 33 5E 54 45 53 54 20 43 41 52 44 2F
56 49 56 4F 54 45 43 48 5E 31 30 31 32 38 31 33
30 30 37 32 31 30 34 33 35 30 30 30 30 3F 3B 36
32 37 39 32 35 37 37 34 39 31 33 32 33 34 33 3D
31 30 31 32 38 31 33 30 30 37 32 31 30 34 33 35
30 30 30 30 3F B5 DC <-- Burst Mode Payload Frame
CRC Calculation
The 16-bit CRC value is based on CRC-16/CCITT and calculated based on the following
parameter set.
Width: 16-bits
Polynomial: x16 + x12 + x5 + 1
Truncated Polynomial: 1021 hex
Initial Value: FFFF hex
Input Data: Not Reflected
Output CRC: Not Reflected
XOR of Output CRC: Not Done
40
NEO Interface Developers Guide NEO v1.00
The CRC-16 is calculated for the entire frame inclusive of Frame Tags, unused bytes, etc.
For Protocol 1 and Protocol 2: The CRC of the Command Frames is little-endian, i.e. lower
byte first (LSB). The CRC of the Response Frames is big-endian i.e. higher byte first (MSB).
For Pass-through Frames, both Command and response frames have the CRC stored in big-
endian order (MSB first).
For Pass-through frames, the CRC is stored as big-endian number i.e. higher byte first.
Some test values that can be used to test an implementation of this algorithm are given below.
CRC: 29B1h
CRC: 9304h
Data (Hex): [56] [69] [56] [4F] [74] [65] [63] [68] [00] [43] [18] [00] [00] [00]
CRC: A1F5h
The following code snippet is an example of the CRC Calculation. The returned CRC would be
stored in big-endian or little-endian form, depending on whether the Protocol 1, Protocol 2 or
Pass-through Mode was being used. This code has been written in Microsoft Visual C++ 6.0.
41
NEO Interface Developers Guide NEO v1.00
// ---------------------------------------------------------------------------------------
// ID TECH
// ID TECH reserves the right to make changes without notice at any time. ID TECH makes no
// warranty, expressed, implied or statutory, including but not limited to any implied
// warranty of merchantability or fitness for any particular purpose, or that the use will
// not infringe any third party patent, copyright or trademark. ID TECH must not be liable
// for any loss or damage arising from its use.
// ---------------------------------------------------------------------------------------
42
NEO Interface Developers Guide NEO v1.00
The following illustration shows the basic approach to instantiating the tag
database for a transaction. Global variables (configured through the Set
Configuration command) are instantiated when the reader is reset or powered
up. When a card is in the field, an AID is selected and its tags are added to the
database. The selection of the AID will cause a “data set” (group) to be
selected and its tags are added to the database. As the transaction proceeds,
card tags will be added to the database, possibly overwriting or updating some
tags that were already in the database.
43
NEO Interface Developers Guide NEO v1.00
This section explains how you can create and modify Application Identifiers (AIDs) and associate
them with TLV Groups in the reader’s memory for specific transaction handling. Detailed
descriptions of the Configurable Application Identifier commands are also included.
Each AID uniquely identifies a payment application. The reader has default AIDs that are
preconfigured to support common payment applications such as VISA and MasterCard. These
AIDs are called the System AIDs and they can be modified or disabled but not deleted. The
reader also supports up to eight user-defined AIDs called User AIDs. Each AID must be associated
with a TLV Group that defines transaction processing for that payment application. The System
AIDs are initially associated with a default TLV Group, which can be modified but not deleted.
User AIDs can be associated to the default TLV Group or any of seven other user-defined TLV
Groups.
With the implementation of M/Chip 3.0, an additional default TLV Group (Group 1) has been
added. M/Chip 3.0 does not use the Reader Default Group (Group 0).
All AIDs must be unique. The reader’s default configuration is System AIDs and two default
groups. All of the System AIDs (except PayPass AIDs, as noted above) initially refer to the
default TLV Group 0. The diagram below shows the default reader AID configuration.
The Configurable Application Identifiers feature of the ViVOpay readers allows you to create and
customize AIDs and the TLV Groups associated with them. Each AID may have characteristics
that are unique and different from the reader’s default System AIDs and TLV Group
configuration.
To create a new configurable AID you need to send the AID and the TLV Group you wish to use to
the reader. If the AID already exists in the reader’s memory, it will modify the AID accordingly.
If you send a new AID, the reader creates and saves the new AID. Multiple AIDs can be
associated with the same TLV Group or they may refer to unique TLV Groups. You may also
redefine the functionality for an existing AID by linking it to a new configuration Group or you
44
NEO Interface Developers Guide NEO v1.00
may disable an AID if you do not want the reader to process transactions from that payment
application. You may delete an AID by communicating to the reader the AID number with no
parameters.
As you add or modify AIDs and TLV Groups, the reader remembers all changes on subsequent
boot up.
The diagram below shows an example of a reader’s AID configuration after it has been modified
with Configurable AID commands.
In this example, ten System AIDs have been disabled and four User AIDs and three new TLV
Groups have been configured. The new AID User AID – 1 has been linked to the Reader Default
Configuration (TLV Group 0) so that it functions as the other System AID 1 functions. The
Maestro AID has been linked to the user-defined TLV Group – 2. User AID – 2 functions as defined
in the new TLV Group – 3. Both User AID – 3 and User AID – 4 point to the new TLV Group – 4 and
function accordingly. Also notice that the other System AIDs have been disabled by removing
their link to a configuration group.
Use the Configurable AID Commands to create new AIDs or change configuration values for an
AID. Use the Configurable Group commands to create new groups or configuration values for a
group.
45
NEO Interface Developers Guide NEO v1.00
System AIDs
A System AID is an AID preloaded for a specific application using a known AID value. Examples
include MasterCard, American Express, and Visa. The table below shows all the System AIDs.
The terminal:
May disable a System AID
May ONLY modify some of the System AID properties
May NOT delete a System AID
User AIDs
A User AID is an optional AID that is added and/or configured by the user. These AIDs are used
for servicing transactions that are not defined by one of the System AIDs. This determination
needs to be made by the integrator.
The terminal:
May modify ANY User AID property
May delete a User AID
There is no equivalent to the System AID disable; the User AID either exists, and it is used for its
associated transactions, or the User AID is not present.
The reader is provided with a default TLV Group (Group 0) that defines all the properties (with
TLVs) required for a basic transaction. By default, all of the System AIDs except PayPass System
46
NEO Interface Developers Guide NEO v1.00
AIDs (MasterCard and Maestro) use TLV Group 0 to define their transaction processing. By
default, MasterCard PayPass System AIDs will use Group 1.
The user:
MUST ALWAYS include the Group Number TLV as the FIRST TLV in the Set Configurable
Group message.
MUST define AT LEAST ONE TLV in addition to the Group Number TLV (in a Set
Configurable Group command)
May modify ANY TLVs in TLV Group 0
May NEVER delete TLV Group 0
Unlike all other groups, the TLVs in the Default TLV Group (TLV Group 0) are constant. The
reader ALWAYS uses the latest copy of the TLV. If you issue a Set Configurable Group command
that only updates some TLVs in TLV Group 0, the reader continues to use older versions of the
TLVs that were not updated.
After each transaction, the reader reloads the default values from TLV Group 0, prior to the
next transaction. For this reason, TLV Group 0 maintains a copy of ALL TLVs that can be entered
into a TLV Group structure2.
Warning: Changing values in TLV Group 0 should be done with EXTREME CAUTION, since this
affects the default configuration that most (not PayPass) transactions use.
The PayPass default group is Group 1. PayPass M/Chip 3.0 does not use Group 0
tag definitions (not even for default values). The process of instantiating a
PayPass database is slightly different from other applications:
Group 0 tags are not loaded.
28 default tags defined in the EMV Contactless Book C-2 Kernel 2 Spec
v2.3 are initialized with their specified default values. See PayPass Group
Configuration TLVs with Hard-Coded Values in Kernel.
PayPass Group tags are loaded. (Group 1 is the default group for PayPass
applications).
Tags sent in the Activate Command are loaded into the database.
There are seven undefined TLV Groups in the reader at startup. These groups can be used for
any purpose.
The user:
MUST ALWAYS include the Group Number TLV as the FIRST TLV in the message.
2
PayPass specific tags are an exception to this rule. Those are maintained in Group 1.
47
NEO Interface Developers Guide NEO v1.00
MUST include AT LEAST ONE TLV other than the Group Number TLV (in a Set
Configurable Group command)
May modify ANY TLV in the TLV Group
May ALWAYS delete a TLV Group 1 through 7
SHOULD NEVER include the TDOL TLV if its length = zero (i.e., only include the TDOL if
it has a value)
User-defined TLV Groups differ from the default TLV Group 0 in two important ways. First, these
groups only need to contain TLVs that are different than the TLVs in the default TLV Group 0.
Thus they are normally a sub-set of the TLVs in the default group.
For American Express, Kiosk III reader is always capable of CVM processing, and CVM items in
terminal capabilities are supported (9F33 byte2 bit5-8 =1, 9F6E byte2 bit5-8 =1).
Secondly, the TLVs in TLV Groups 1 through 7 are not permanent. If you configure a TLV Group
and then issue a second Set Configurable Group command on the same TLV Group, the second
Set Configurable Group command overwrites EVERY change to the TLV Group made by the first
command.
Warning: Changing values in TLV Groups 1 through 7 overwrites all content in the TLV Group,
including deleting TLVs not in the update.
Except for MasterCard PayPass transactions, when one of these user-defined TLV Groups is
selected during a transaction, the reader uses the TLVs included in the group AND any other
TLVs required for the transaction are taken from the default Group 0. Once the reader has
finished transaction processing, it reloads TLV Group 0 values for all TLVs. It is now ready to
commence the next transaction.
There are some guidelines for setting and deleting TLV Groups listed below. Most of these
guidelines are intuitive (i.e., you may not delete a TLV Group if an AID exists that currently uses
it).
The Configurable AIDs feature requires memory to store TLV groups and User AIDs. ViVOpay
readers use 64K flash memory to support the Configurable AID feature. Refer to the reader’s
user documentation for more information on reader memory.
48
NEO Interface Developers Guide NEO v1.00
TLVs may be either standard TLVs or proprietary TLVs. Standard TLVs are defined by EMV and
the Payment Association Requirements and recognized by everyone. Proprietary TLVs are
created by individual payment associations and reader manufacturers for specific functions.
Proprietary TLVs must be handled in a manner that isolates them from other proprietary TLVs.
ViVOpay proprietary TLVs can be present with standard TLVs without encapsulation when the
command is processed exclusively by ViVOpay firmware or software. If the TLVs will be
processed by other devices, ViVOpay proprietary TLVs must be encapsulated to prevent conflicts
with proprietary TLVs from other organizations.
ViVOPay TLV Group Tag FFEE01 is used to encapsulate ViVOpay proprietary TLVs.
EXAMPLE
The following example is for an encapsulated Terminal Capabilities – CVM Required TLV.
49
NEO Interface Developers Guide NEO v1.00
The following table contains TLVs that are configurable using the Set
Configuration (04-00) command. These TLVs are global within in the reader.
50
NEO Interface Developers Guide NEO v1.00
Length
Tag Data Object Name and Description Format Default Value
(Bytes)
Communication Error Delay time
Delay between the time a communication error first
occurs and the time when the reader will issue an
indication of an error to the reader. If a tear n
DF75 3 00 30 00
occurs, but the card comes back into the field during (BCD)
this time, then no error indication is issued. Time is
expressed in milliseconds (default is 3000ms, or 3
seconds)
Auto-Switch to Pass-Through Mode.
Refer to Auto-Switch to Pass-Through Mode
DF7C b 1 00
00: Disable (default)
01: Enable
Track 1 and Track 2 Data Format
Sets the format of data returned from Activate
DF7D Transaction and Get Transaction Results commands. b 1 00
00: No start/end sentinels or LRC (default)
01: Add start/end sentinel and LRC
Improved Collision Detection (see special features
Improved Collision Detection.) RF signal locked to a
specified card only after a specified number of
DF7F polling attempts without an EMV collision. b 1 00
00h = Improved Collision Detection Disabled.
02h-FFh = Number of successful polling attempts
required.
Application Capability(1:Support,0:Not Support):
Byte 1: (Leftmost)
Meaning (0 = disable, 1 =
b8 b7 b6 b5 b4 b3 b2 b1
enable)
X Normal J/Speedy support
X ViVOpay Mifare for NFC
X Interac support
X
X Android Pay support
X X X RFU
Byte 2:
Meaning (0 = disable, 1 =
b8 b7 b6 b5 b4 b3 b2 b1
FFF3[1] enable) b 2 07 FF
- - - - - - - X MasterCard Credit support
- - - - - - X - American Express support
- - - - - X - - Visa support
- - - - X - - - Mobile J/Speedy support
- - - X - - - - ViVOwallet support
- - X - - - - - RBS support
- X - - - - - - MasterCard Cash support
X - - - - - - - Discover support
51
NEO Interface Developers Guide NEO v1.00
Length
Tag Data Object Name and Description Format Default Value
(Bytes)
Enable/Disable Burst Mode:
Value = 00: Disable Burst Mode
Value = 01: Enable Burst Mode
FFF7[1] b 1 02
Value = 02: Burst Mode Auto Exit. Burst mode is
turned off as soon as a transaction command is
received (Sections 6 and 14 of this document)
LCD Font Size:
FFF9[1]
[2] [3] Value = 02: Large b 1 03
Value = 03: Extra Large (default)
LCD delay time (ms) – default is 1000ms. 03 E8
FFFA[1]
[2] b 2 or
If the device has no LCD, then the value will be 0.
00 00
Language Option for LCD display:
Value = 00: English only display (default)
Value = 01: Chinese only display[2]
FFFB[1] Value = 02: English & Chinese display[2] b 1 00
Value = 03: French only display
Value = 04: Other Language (if ILM present)[2]
Value = 05: English & French display [4]
Poll Mode
Value = 00 : Auto-Poll
DF891B b 1 00
Value = 01 : Poll on Demand
Note: Only used for Vendi.
9F15 Merchant Category Code n4 2 00 00
Classifies the type of business being done by the
merchant, see ISO 8583:1993.
9F16 Merchant Identifier ans 15 00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
9F1C Terminal Identification an 8 00 00 00 00 00
00 00 00
9F40 Additional Terminal Capabilities b 5 60 00 00 10 01
Indicates the data input and output capabilities of
the terminal.
9F4E Merchant Name and Location ASCII <=30 00 00 00 00 00
Allows the reader to be configured with the 00 00 00 00 00
Merchants Name and Location (VCPS 2.1.1 and 00 00 00 00 00
M/Chip 3.0) 00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
9F7C Merchant Custom Data b <=20 00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
00 00 00 00 00
FFF2 Interface Device Serial Number an 8 30 30 30 30 30
This is equivalent to tag 9F1E. They refer to the same 30 30 30
parameter.
52
NEO Interface Developers Guide NEO v1.00
Length
Tag Data Object Name and Description Format Default Value
(Bytes)
FFF8 UI Scheme: b 1 00
Value = 00:ViVOpay User Interface (default)
Value = 02:Visa Wave User Interface
Value = 03:EMEA User Interface
Note: LCD Messages need to be configured
separately.
Warning: EMEA UI is intended for use in the EMV or
European environment, where the reader Vend is not
allowed to poll continuously (e.g., operate in Auto
Poll Mode). The reader Vend does NOT support Auto
Poll while in EMEA UI mode. The reader is not
certified to work properly in this situation.
The reader Vendi supports Auto Poll while in EMEA UI
mode.
9F53 Transaction Category Code an 1 00
Indicate type of transaction being performed,
defined by MasterCard and Interac.
Masked Output Data Parameter
FFEE1D b 5 04 04 2A 0C 31
The following table contains tags that may be configured within a Configurable
Group. For Group 0, default values exist. Except for groups associated with a
PayPass AID, if a group does not define some of these TLVs, then the values in
Group 0 will be used. The Set Configurable Group command should be used to
set the TLVs in this section.
The PayPass configuration tags are documented separately. To configure a group that will be
associated with a PayPass AID, refer to PayPass Group Configuration TLVs.
53
NEO Interface Developers Guide NEO v1.00
54
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 0
Default Transaction Certificate Data Object List (TDOL)
List of TLV data objects to be used by the terminal to
generate the TC Hash Value in case the TDOL is not
returned by the card.
Transaction Type
Indicates the type of financial transaction, represented
9C n2 1 00
by the first two digits of ISO 8583:1987 Processing
Code. (default = purchase goods or services)
Transaction Currency Code
Indicates the currency code of the transaction
5F2A according to ISO 4217. Note: make sure you use the n3 2 08 40
same Transaction Currency Code for all configurable
AIDs. (default = US Dollars)
Transaction Currency Exponent
Indicates the implied position of the decimal point
5F36 from the right of the transaction amount represented n1 1 02
according to ISO 4217. (decimal is two places from
right of the transaction amount)
9F01 Acquirer ID n 6 Not present
9F02 Amount Authorized (Numeric) n12 6 00 00 00 00 00 01
9F03 Amount Other (Numeric) n12 6 00 00 00 00 00 00
Application Version Number
PayPass M/Chip (Value = 00 02)
9F09 D-PAS (Value = 00 02) b 2 00 02
Interac (Value = 00 02)
Amex (Value = 00 01)
Terminal Country Code
9F1A Indicates the country code of the terminal, n3 2 08 40
represented according to ISO 3166. Default = US
Terminal Floor Limit
Indicates the floor limit in the terminal for the AID(s)
associated with this group.
Note: The value is the decimal limit amount given
9F1B in binary represented in Hex in the b 4 00 00 17 70
command/response. (100 limit = 10000 decimal =
2710h).
Default = $60.00
Terminal Identification
00 00 00 00 00 00
9F1C an 8
00 00
Note: Vendi default value is not present.
55
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 0
Terminal Capabilities
Indicates the card data input, CVM, and security
capabilities of the terminal
Default =
9F33 No CVM required b 3 00 08 E8
SDA supported
DDA supported
Card Capture
CDA supported
Terminal Type
Indicates the environment of the terminal, its
9F35 communications capability, and its operational control n2 1 22
Note: Vendi default value is 25.
56
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 0
Terminal Contactless Transaction Limit
FFF1[1] Indicates the terminal limit for this AID for Contactless n12 6 00 00 00 01 00 00
transactions.
Visa Reader Risk Flags
Byte 1
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable)
- - - - - - - X Status Check
X X X X X X X - RFU
Byte 2:
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable)
- - - - - - - X Transaction Limit Check
- - - - - - X - CVM Required Limit Test
- - - - - X - - Terminal Floor Limit Check
Cash Transaction Reader Risk
- - - - X - - -
(RR)
- - - X - - - - Cashback Reader Risk (RR)
DRL (Dynamic Reader Limits)
- - X - - - - -
RR
FFF4[1] X X - - - - - - RFU
b 3 00 06 01
Byte 3
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable)
1 = online cryptogram required
for zero amount (only used
- - - - - - - X
with zero amount check
enabled)
- - - - - - X - 1 = perform zero amount check
X X X X X X - - RFU
For example:
0x00 = Zero Amount check disabled.
0x01 = Zero Amount check is disabled and online
cryptogram required bit will not be checked.
(default)
0x02 = Zero Amount check enabled.
0x03 = Zero Amount check enabled and Option 1,
online Cryptogram Required
57
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 0
D-PAS Reader Risk Flags:
Byte 1
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable)
- - - - - - - X RFU
X 1=Status Check Support
X X X X X X - RFU
Byte 2:
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable) b 3
X X X X X X X X RFU
Byte 3
b b b b b b b b Meaning
8 7 6 5 4 3 2 1 (0 = disable, 1 = enable)
1 = online cryptogram required for
- - - - - - - X
zero amount
X X X X X X X - RFU
58
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 0
Specific Feature Switch
Used with Visa VCPS 2.1.1/2.1.2. It controls Visa CVN17
support and Track 1 & 2 data in the transaction
response.
Byte 1
b8 b7 b6 b5 b4 b3 b2 b1
- - - - - - - X RFU (Deprecated)
1 = Visa CVN17 supported
FFF0[1] - - - - - - X -
0 = Visa CVN17 disabled
b 3 02 00 00
[2]
Not used by M/Chip 3.0 because M/Chip 3.0 redefines this as a card tag that passes Application Capability
Information.
[3]
These objects only work on the Vendi.
[4]
These objects only work on the ViVOpay graphic reader.
59
NEO Interface Developers Guide NEO v1.00
If a PayPass AID will be assigned to a group, then the table in this section should
be used to configure the group. The Set Configurable Group command should
be used to set the TLVs in this section.
The following PayPass Group TLVs should not be configured for Group 0. The default PayPass
group is Group 1. That is, when the reader is configured from the factory, the PayPass
System AIDs will be associated with Group 1.
If there are tags in a PayPass group that should be set, they must all be set explicitly, since
the absent values are not filled in with Group 0 or Group 1 defaults.
PayPass Group tags are instantiated a little differently than other groups.
Group 0 is never used as a default. Refer to the section on PayPass Default
Group for an explanation of how the tag database is instantiated for PayPass.
60
NEO Interface Developers Guide NEO v1.00
Transaction Type
Indicates the type of financial transaction,
9C represented by the first two digits of ISO n2 1 00
8583:1987 Processing Code (default = purchase
goods or services)
Transaction Currency Code
Indicates the currency code of the transaction
5F2A according to ISO 4217. Note: make sure you use n3 2 08 40
the same Transaction Currency Code for all
configurable AIDs. Default = US Dollars(08 40)
Transaction Currency Exponent
Indicates the implied position of the decimal point
from the right of the transaction amount
5F36 n1 1 02
represented according to ISO 4217.
Default = decimal is two places to the right of the
last digit of the transaction amount.
9F01 Acquirer ID n 6 Not present
Amount Authorized (Numeric)
9F02 n12 6 00 00 00 00 00 01
Note: Vendi default value is not present.
9F03 Amount Other (Numeric) n12 6 00 00 00 00 00 00
Application Version Number (M/Chip)
9F09 PayPass M/Chip 3.0(Value = 00 02) b 2 00 02
Amex (Value = 00 01)
Merchant Category Code
9F15 Classifies the type of business being done by the n4 2 11 11
merchant, see ISO 8583:1993.
9F16 Merchant Identifier ans 15 Not present
61
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
Terminal Country Code
9F1A Indicates the country code of the terminal, n3 2 08 40
represented according to ISO 3166.
Terminal Floor Limit
Indicates the floor limit in the terminal in
conjunction with the AID (hex).
9F1B b 4 00 00 17 70
This tag is equivalent to MasterCard tag DF8123
Reader Contactless Floor Limit.
Terminal Identification
Terminal Type
Indicates the environment of the terminal, its
communications capability, and its operational
9F35 control n2 1 22
Note: Vendi default value is 25.
62
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
Transaction Category Code
This is a data object defined by MasterCard which
indicates the type of transaction being performed,
9F53 and which may be used in card risk management. an 1 01
Note: Vendi default value is 00.
63
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
Default UDOL
Used for calculating the CCC if no UDOL is present
DF811A b 3 9F 6A 04
in the card. The default is the tag and length of
the “Unpredictable Number”.
Maximum Lifetime of Torn Transaction Record
This is the maximum time a torn record can exist
in the log before it expires. It is expressed in
DF811C seconds. b 2 Not Present
While the transaction log is global to the reader,
the MasterCard application is the only application
that supports it.
Maximum Number of Torn Transaction Records
Due to storage limitations, the maximum number
of records that may be configured is 2. There
may be 0, 1, or 2 torn transaction records
configured. If 0 records are configured, the torn
DF811D b 1 Not Present
transaction recovery facility is effectively
disabled.
While the transaction log is global to the reader,
the MasterCard application is the only application
that supports it.
MagStripe CVM Required Capability
Indicates the CVM capability of the
Terminal/Reader in the case of a mag-stripe mode
DF811E b 1 10
transaction when the Amount, Authorized
(Numeric) is greater than the Reader CVM
Required Limit.
Reader Contactless Transaction Limit, No On-
Device CVM
DF8124 When there is no On-Device CVM available (e.g. n12 6 00 00 00 03 00 00
with a phone), then this is the transaction limit
that will be used. Default = $300.00
Reader Contactless Transaction Limit, On-Device
CVM
When On-Device CVM is available (e.g. with a
phone) then this is the transaction limit that will
DF8125 be used. n12 6 Not Present
Note: Vendi default values are 00 00 00 03 00
00. KioskIII default values are 00 00 00 05 00
00.
64
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
RF Hold Time Value
Indicates the time that the field is to be turned
off after the transaction is completed if requested
to do so by the cardholder device. The Hold Time
DF8130 b 1 Not Present
Value is in units of 100ms.
While this value is configurable, it is not used in
practice in the reader. It is a MasterCard
requirement.
Phone Message Table
Defines for the selected AID the message and
status identifiers as a function of the POS
Cardholder Interaction Information. The Phone
Message Table is a variable length list with 8-byte
entries. Each entry in the Phone Message Table
contains the following fields:
DF8131 B Var No Present
PCII Mask (3 bytes, binary)
PCII Value (3 bytes, binary)
Message Identifier (1 byte, binary)
Status (1 byte, binary)
The last entry in the phone message table must
always have the PCII Mask and PCII Value set to
‘000000’.
Proprietary Tag List
Proprietary tags that are not otherwise configured
FF69 b <=32 Not present
may be configured by encapsulating them in this
tag list.
Group Number
The group number that contains the
characteristics for this AID
FFE4[1] n2 1 --
This tag is mandatory when getting or setting group
parameters and it must be the 1st TLV in Data Field.
65
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
UI Scheme:
Value = 00:ViVOpay User Interface (default)
Value = 02:Visa Wave User Interface
Value = 03:EMEA User Interface
Note: LCD Messages need to be configured
separately.
Warning: EMEA UI is intended for use in the EMV
or European environment, where the reader is not
allowed to poll continuously (e.g., operate in Auto
FFF8[1] Poll Mode). The reader does NOT support Auto b 1 00
Poll while in EMEA UI mode. The reader is not
certified to work properly in this situation.
66
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 1
Terminal Action Code (Denial)
Reflect the acquirer-selected action to be taken
FFFF[1] upon analysis of the TVR. b 5 00 00 00 00 00
This is equivalent to MasterCard tag DF8121.
[2]
These objects only work on the ViVOpay graphic reader.
[3]
These objects only work on the Vendi
PayPass transactions do not use Group 0 at all. If a TLV data item has not been
defined in a PayPass group (Group 1 or higher), then the default value is not
picked up from Group 0 as for other card types.
There is a minimal sub-set of TLV data items that must be present for a PayPass
transaction to be performed. If any of the data items from this sub-set are not
present, a PayPass transaction cannot be performed.
A list of data items that have a hard-coded value and the default value are
given in the following table.
If any of these data items is “not present” in the PayPass group, then a Get Group command
will not return the values for these data items even though the PayPass kernel will use the
hard-coded default values for these data items.
67
NEO Interface Developers Guide NEO v1.00
Terminal Capabilities
Indicates the card data input, CVM, and security
capabilities of the terminal.
This tag (9F33) only configures bytes 1 and 3 of the
terminal capabilities. Byte 2 of the terminal
9F33 capabilities actually comes from DF28 or DF29 b 3 00 00 00
during the transaction. Refer to tags DF28 and DF29
for details.
Note: Byte 1 of 9F33 is the same as DF8117 Card
Data Input Capability defined in PayPass 3.0.2 and
Byte 3 of 9F33 is the same as DF811F Security
Capability.
Terminal Type
Indicates the environment of the terminal, its
9F35 n2 1 00
communications capability, and its operational
control
Additional Terminal Capabilities
9F40 Indicates the data input and output capabilities of b 5 00 00 00 00 00
the terminal
Application Version Number (MagStripe)
9F6D b 2 00 01
PayPass MagStripe (Value = 00 01)
Terminal Capabilities – No CVM Required
M/Chip v2.0 element indicating the Terminal
Capabilities to be used when Amount, Authorized
< CVM Required Limit. Formatted as Terminal
Capabilities (tag ‘9F 33’)
DF28 b 3 00 00 E8
Only byte 2 of this tag is actually used. The other
terminal capabilities are configured using tag 9F33.
68
NEO Interface Developers Guide NEO v1.00
Hard-Coded
Tag Description Format Length Default Value in
PayPass Kernel
Default UDOL
Used for calculating the CCC if no UDOL is present
DF811A b 3 9F 6A 04
in the card. The default is the tag and length of
the “Unpredictable Number”.
Maximum Lifetime of Torn Transaction Record
This is the maximum time a torn record can exist
in the log before it expires. It is expressed in
DF811C seconds. b 2 01 2C
While the transaction log is global to the reader,
the MasterCard application is the only application
that supports it.
Maximum Number of Torn Transaction Records
Due to storage limitations, the maximum number
of records that may be configured is 2. There
may be 0, 1, or 2 torn transaction records
configured. If 0 records are configured, the torn
DF811D b 1 00
transaction recovery facility is effectively
disabled.
While the transaction log is global to the reader,
the MasterCard application is the only application
that supports it.
MagStripe CVM Required Capability
Indicates the CVM capability of the
Terminal/Reader in the case of a mag-stripe mode
DF811E b 1 F0
transaction when the Amount, Authorized
(Numeric) is greater than the Reader CVM
Required Limit.
Reader Contactless Transaction Limit, No On-
Device CVM
DF8124 When there is no On-Device CVM available (e.g. n12 6 00 00 00 00 00 00
with a phone), then this is the transaction limit
that will be used.
Reader Contactless Transaction Limit, On-Device
CVM
DF8125 When On-Device CVM is available (e.g. with a n12 6 00 00 00 00 00 00
phone) then this is the transaction limit that will
be used.
MagStripe No CVM Required Capability
Indicates the CVM capability of the
Terminal/Reader in the case of a mag-stripe mode
DF812C b 1 F0
transaction when the Amount, Authorized
(Numeric) is less than or equal to the Reader CVM
Required Limit.
69
NEO Interface Developers Guide NEO v1.00
Hard-Coded
Tag Description Format Length Default Value in
PayPass Kernel
Message Hold Time
Indicates the default delay for the processing of
the next MSG signal. The Message Hold Time is an
DF812D integer in units of 100ms. n6 3 00 00 13
While this value is configurable, it is not used in
practice in the reader. It is a MasterCard
requirement.
RF Hold Time Value
Indicates the time that the field is to be turned
off after the transaction is completed if requested
to do so by the cardholder device. The Hold Time
DF8130 b 1 0D
Value is in units of 100ms.
While this value is configurable, it is not used in
practice in the reader. It is a MasterCard
requirement.
Phone Message Table
Defines for the selected AID the message and
status identifiers as a function of the POS
Cardholder Interaction Information. The Phone
Message Table is a variable length list with 8-byte
See next table
entries. Each entry in the Phone Message Table
‘Phone Message
contains the following fields:
DF8131 b Var. Table Hard-
PCII Mask (3 bytes, binary)
Coded Default
PCII Value (3 bytes, binary)
Value in Kernel’.
Message Identifier (1 byte, binary)
Status (1 byte, binary)
The last entry in the phone message table must
always have the PCII Mask and PCII Value set to
‘000000’.
CVM Required Limit
Indicates the CVM required limit in the terminal
FFF5[1] for the associated AIDs. n12 6 00 00 00 00 00 00
This is equivalent to MasterCard tag DF8126.
PayPass Profile
Information in this tag is equivalent to PayPass tag
DF811B, although it is formatted slightly
differently:
87654321 Bit Meaning Values
MagStripe 0 = normal transaction
-------X Only 1 = MagStripe only
FFFC[1] transactions allowed b 1 00
0 = normal transaction
M/Chip Only
------X- 1 = M/Chip only
Transactions allowed
On Device 0 = not supported
-----X--
CVM 1 = supported
XXXXX--- RFU
70
NEO Interface Developers Guide NEO v1.00
Hard-Coded
Tag Description Format Length Default Value in
PayPass Kernel
Terminal Action Code (Online)
Reflect the acquirer-selected action to be taken
FFFD[1] upon analysis of the TVR. b 5 CC 00 00 00 00
This is equivalent to MasterCard tag DF8122.
[1]
These objects use proprietary tags. The use of these tags should be restricted to the serial interface. Once the
Reader has returned an OK Response Frame, the Terminal application should dispose of the tags to avoid conflicts with
other proprietary TLVs.
If a American Express AID will be assigned to a group, then the table in this
section should be used to configure the group. The Set Configurable Group
command should be used to set the TLVs in this section.
The following American Express Group TLVs should not be configured for Group 0. The
default American Express group is Group 2. That is, when the reader is configured from the
factory, the American Express System AIDs will be associated with Group 2.
71
NEO Interface Developers Guide NEO v1.00
If there are tags in a American Express group that should be set, they must all be set
explicitly, since the absent values are not filled in with Group 0 or Group 1 defaults.
American Express Group tags are instantiated a little differently than other
groups. Group 0 is never used as a default. Refer to the section on American
Express Default Group for an explanation of how the tag database is instantiated
for American Express.
Transaction Type n2 1 00
Indicates the type of financial transaction,
9C represented by the first two digits of ISO
8583:1987 Processing Code. (default = purchase
goods or services)
n12 6 00 00 00 00 00
9F03 Amount Other (Numeric)
00
Application Version Number b 2 00 01
9F09 PayPass M/Chip (Value = 00 02)
Amex (Value = 00 01)
Terminal Country Code n3 2 08 40
9F1A Indicates the country code of the terminal,
represented according to ISO 3166. Default = US
Terminal Floor Limit b 4 00 00 17 70
ndicates the floor limit in the terminal for the
AID(s) associated with this group.
9F1B Note: The value is the decimal limit amount given in
binary represented in Hex in the
command/response. (60 limit = 6000 decimal =
1770h).
72
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 2
Transaction Time (HHMMSS) n6 3 FF FF FF
This value is used to set the Real Time Clock.
Terminal Capabilities b 3 00 08 E8
Indicates the card data input, CVM, and security
capabilities of the terminal
Default =
9F33 • No CVM required
• SDA supported
• DDA supported
• Card Capture
• CDA supported
Terminal Type n2 1 25
Indicates the environment of the terminal, its
communications capability, and its operational
control
73
NEO Interface Developers Guide NEO v1.00
Default Value in
Tag Description Format Length
Group 2
Terminal Action Code (Default) b 5 00 00 00 00 00
FFFE[1] Reflect the acquirer-selected action to be taken
upon analysis of the TVR.
Terminal Action Code (Denial) b 5 00 00 00 00 00
FFFF[1] Reflect the acquirer-selected action to be taken
upon analysis of the TVR.
[1]
These objects use proprietary tags. The use of these tags should be restricted to the serial interface. Once the
Reader has returned an OK Response Frame, the Terminal application should dispose of the tags to avoid conflicts with
other proprietary TLVs.
[2]
These objects only work on the ViVOpay graphic reader.
[3]
These objects only work on the Vendi
In this table, the “Usage” column indicates when the tag is used. In some
cases, the use may depend on whether a system AID or a user AID is being
configured. The possible usages are:
MAND – this is a mandatory tag when configuring an AID
OPT – this is an optional tag when configuring an AID
NEVER – this tag should never be used for configuring this type of AID
(e.g. “System”)
DEP – this tag is Mandatory depending on how another tag is configured.
For default values of the AID configuration TLVs for each System AID, refer to
the System AID Default Configuration TLVs table in the appendix.
74
NEO Interface Developers Guide NEO v1.00
75
NEO Interface Developers Guide NEO v1.00
Setting the FFE6 tag may disable an AID. However, the preferred method to disable an AID is
to issue a “Delete Configurable AID” command (04-04). For a system AID, the command will
set the disable bit in FFE6.
76
NEO Interface Developers Guide NEO v1.00
The following table lists the System AIDs and the default values for their TLVs
FF E6 = 80
Group FF E4 01 01
AID 9F 06 07 A0 00 00 00 04 30 60
Partial Selection FF E1 01 01
Application Flow FF E2 01 03
Max AID Length FF E5 01 10
MasterCard
Selection Features FF E3 01 74 PayPass
FF E9 0C 02 00 01 Application
Transaction Type
List 02 20 01
02 01 01
02 09 01
Kernel ID FF EA 01 02
77
NEO Interface Developers Guide NEO v1.00
FF E2 = FF
78
NEO Interface Developers Guide NEO v1.00
FF E2 = FF
Group FF E4 01 00
AID 9F 06 07 A0 00 00 03 24 10 10
FF E2 01 0D Discover
Application Flow
(ZIP)Application
Partial Selection FF E1 01 01
Max AID Length FF E5 01 10
Group FF E4 01 00
AID 9F 06 07 A0 00 00 01 52 30 10
Application Flow FF E2 01 0D Discover (D-PAS)
Application
Partial Selection FF E1 01 01
Max AID Length FF E5 01 10
Group FF E4 01 00
AID 9F 06 07 A0 00 00 04 17 01 01
Partial selection FF E1 01 01
STAR Application
Application Flow FF E2 01 0F
Max AID Length FF E5 01 08
Selection Features FF E3 01 08
Group FF E4 01 00
AID 9F 06 07 A0 00 00 02 77 10 10
Partial selection FF E1 01 01
Application Flow FF E2 01 15
Interac
Max AID Length FF E5 01 10 Application
Note: Vendi default value,
FF E2 = 15
79
NEO Interface Developers Guide NEO v1.00
Combined Selection
The following table defines each of the bits in the Selection Features tag (FFE3)
and describes how they control the logic flow:
-----x-- Cardholder Confirmation 0 = Cardholder Confirmation is allowed for this AID and if API bit
Not Supported 8 (Cardholder Confirmation) is true, the application will not be
added to the candidate list.
1 = Customer Cardholder Confirmation is not allowed for this
AID, API bit 8 (Cardholder Confirmation) will be ignored.
----x--- API Required 0 = the API is not required for this AID and the application may
be added to the candidate list if the API is missing.
1 = the API is required for this AID; the application will not be
added to the candidate list if the API is missing.
---x---- Invalid AID Allowed 0 = any invalid AID will cause this AID to terminate the
transaction.
1 = any invalid AID will be ignored as related to this AID.
--x----- Duplicate AID Allowed 0 = a duplicate AID, whether extended or not, is not allowed and
will not be added to the candidate list.
1 = a duplicate AID, whether extended or not, is allowed and
may be added to the candidate list.
-x------ Enable Kernel ID 1 = allow the evaluation of the Kernel ID.
0 = if a Kernel ID is provided by the card it is ignored.
x------- RFU Reserved for Future Use.
80
NEO Interface Developers Guide NEO v1.00
Refer to the System AID Defaults for the configuration of Selection features for
each of the AIDs. If no Selection Features tag (FFE3) is specified, then no
selection features are specified.
For some applications, an AID on the card may be longer than an AID configured
in the reader. If partial selection is allowed, the AID will be considered a match
if all of the AID configured in the reader matches the first portion of an AID in
the card.
Historically, Partial Selection has been a separate tag. However, it is an integral part of the
selection process, and may be used in conjunction with combined selection features.
“Trial & Error” is sometimes referred to as “List of AIDs”. It is a process by which the reader
will attempt to select an AID by going through its list, hoping for a successful selection.
81
NEO Interface Developers Guide NEO v1.00
The Terminal AID List Tag DFEF2C is associated with each Terminal AID which
set by the 04-02 (Load AID) command. This tag can control which Terminal AID
should be sent to the card, if the Select AID Command (with PPSE) get “Select
AID Failed”(response SW1/SW2 not 9000 or format error), or the AID list
returned by the card cannot matched by any Terminal AID. One by one, the
terminal will check each Tag DFEF2C associated with the Terminal AID, if the
Tag DFEF2C value is ‘01’, the terminal will send out that Terminal AID data to
the card, contactless transaction can be continued if any Terminal AID matched
by the card; if the Tag DFEF2C value is ‘00’, that terminal AID data will not be
sent.
82
NEO Interface Developers Guide NEO v1.00
The PayPass implementation required a new data model in which data objects
could be “not present” or “not defined”. As a result, the historical method of
using Group 0 to define default tags could not be used.
Group 0 is no longer used by the PayPass application. The default group for
PayPass applications is Group 1.
In addition to the PayPass default group, the PayPass Kernel also keeps hard-
coded values for a sub-set of the group parameters that are essential for a
transaction. If one of these data items is not available via Activate Transaction
or via Get Configurable Group, then the kernel uses its own hard-coded value
for the ‘Not Present’ data item.
The balance may be read from cards that support balance reading. The balance
may be read before or after the Generate AC process. In order to enable
balance reading, the tags for balance read must be defined in the tag database.
This may be accomplished through the Set Configurable Group command or by
including the balance TLVs (DF8104, DF8105) in the Activate command.
For example, if DF8104 is included in the Activate Command, and the card
supports balance reading, then the balance read prior to Generate AC will be
returned in the DF8104 TLV in the Activate response.
83
NEO Interface Developers Guide NEO v1.00
A method exists for saving data from a torn transaction and matching up that
transaction with a card that re-appears in the field to complete the transaction.
Due to space limitations in the reader, the maximum number of torn transaction
records that can be retained is two. New tags (configurable in a PayPass Group)
control the size and use of the torn transaction log:
These tags are configurable for PayPass groups. It they are configured for other groups, they
will not be used.
The MasterCard application can make use of the EMV Certificate Revocation List
features if they are enabled. The DF26 tag is used to enable or disable the
Certificate Revocation List function. The default value for this tag is “enabled”
(1).
The proprietary tag list feature is not specific to MasterCard. Please refer to
the Card Application Proprietary Tag List feature.
To guarantee the successful completion of PayPass transactions using CDA or SDA, size
restrictions noted in this section apply.
84
NEO Interface Developers Guide NEO v1.00
The combined length of the following data objects personalized to the card cannot exceed 2400
bytes. ICC Public Key Certificate
ICC Public Key Exponent
ICC Public Key Remainder
Static data used in data authentication (2048 bytes maximum)
The combined length of the following data objects personalized to the card cannot be greater
than 2400 bytes.
Signed Static Application Data
Static data used in data authentication (2048 bytes maximum)
85
NEO Interface Developers Guide NEO v1.00
This command allows the POS application to instruct ViVOpay to flush any Track Data that was
read from a card previously but has not been transferred to the POS yet. On receiving this
command ViVOpay clears any pending card data.
Use this command to return full track data from the ViVOpay reader. If a card has been swiped
at the magnetic stripe reader or presented to a reader in Auto Poll mode, ViVOpay sends back
an ACK Frame followed by a Data Frame containing track data. If no card has been swiped or
presented, ViVOpay just returns an ACK Frame and no Data Frame. If both Track 1 and Track 2
data is being returned, then the Data Frame contains the Track 1 Data, followed by a NULL
character (00h) marking the end of Track 1 Data, followed by Track 2 data.
If a card has been swiped, but an error occurred, then ViVOpay just sends an ACK Frame with
Status Failed.
86
NEO Interface Developers Guide NEO v1.00
Byte 12 is used for Tracks or Error Code, depending on the value of the Status in Byte 11 (see
Status Code Protocol 1). When Status is OK, Byte 12 is used to store Tracks. When Status is
Failed, Byte 12 is used to store the Error Codes from ViVOpay.
Note: These Error Codes are valid only when the RF Error Code Reporting is enabled through
Set RF Error Reporting command, see Set RF Error Reporting.
DataLen
Number of Data Bytes in the Data Frame to Follow. This does not include the Frame Tag, Frame
Type and Checksum bytes.
Data Frame from the Reader to PC (If the Reader sent an ACK and Track Data available)
Byte 0-8 Byte 9 Byte 10 Byte 11 … Byte n+10 Byte n+11 Byte n+12
CRC CRC
Frame Tag Frame Type Data 0 Data 1 … Data n
(MSB) (LSB)
ViVOtech\0 ‘D’ Data Data … Data
If the host fails to receive the track data, it can send a NACK Frame to request the reader to
resend the track data. To ensure that the reader resends the track data, the NACK Frame must
87
NEO Interface Developers Guide NEO v1.00
be received within 500ms after it sends the original track data. If the reader receives the NACK
Frame within that time period, it first resends the ACK Frame followed by the Data Frame to PC.
If the reader receives the NACK Frame after 500ms of sending out the original track data, or if a
new card has been detected, the reader sends an ACK/NACK Frame to the host and does not
resend the track data. Each payload data is only resent once.
Status
Tracks Example
Bit 0 = Track 1 Track = 00h => No Track Data
Bit 1 = Track 2 Track = 01h => Track 1 Data Only
Bit 3 = Track 3 Track = 02h => Track 2 Data Only
Track = 03h => Track 1 & Track 2 Data etc.
DataLen
Number of Data Bytes in the Data Frame to Follow. This does not include the Frame Tag, Frame
Type and Checksum bytes.
Data Frame from the Reader to PC (If ViVOpay sent an ACK and Track Data available)
Byte 0-8 Byte 9 Byte 10 Byte 11 … Byte n+10 Byte n+11 Byte n+12
CRC CRC
Frame Tag Frame Type Data 0 Data 1 … Data n
(MSB). (LSB).
ViVOtech\0 ‘D’ Data Data … Data
An example of the Data Frame sent in response to the Get Full Track data command is as
follows:.
56 69 56 4F 74 65 63 68 00 44 42 35 33 32 35 33
35 30 30 30 30 36 32 33 35 36 37 5E 53 4D 49 54
88
NEO Interface Developers Guide NEO v1.00
48 2F 4A 4F 48 4E 5E 30 35 30 38 35 30 31 31 30
30 36 32 36 30 30 34 34 35 30 30 30 30 30 37 38
36 32 30 39 33 33 00 35 33 32 35 33 35 30 30 30
30 36 32 33 35 36 37 3D 30 35 30 38 31 30 31 39
34 34 35 39 39 37 38 36 30 36 32 33 DF 03
Annotated
56 69 56 4F 74 65 63 68 00 – FRAME TAG
44 – FRAME TYPE ‘D’
TRACK 1 DATA
42 35 33 32 35 33 35 30 30 30 30 36 32 33 35 36
37 5E 53 4D 49 54 48 2F 4A 4F 48 4E 5E 30 35 30
38 35 30 31 31 30 30 36 32 36 30 30 34 34 35 30
30 30 30 30 37 38 36 32 30 39 33 33
00 – END OF TRACK 1 START OF TRACK 2
TRACK 2 DATA
35 33 32 35 33 35 30 30 30 30 36 32 33 35 36 37
3D 30 35 30 38 31 30 31 39 34 34 35 39 39 37 38
36 30 36 32 33
DF 03 – CRC
Use this command to return the ViVOpay reader’s Firmware Version Number. This is the Protocol
1 version of the command given in Get Version Protocol 2 (29-00). The ViVOpay reader returns
an ACK Frame containing the length of the Version Data. This is followed by a Data Frame
containing the firmware version information.
89
NEO Interface Developers Guide NEO v1.00
DataLen = Number of Data Bytes in the Data Frame to Follow. This does not include the Frame
Tag, Frame Type and Checksum bytes.
Note: The following commands use Protocol 1 frame formats. Whenever possible, you should
use the Key Manager commands in Protocol 2.
The Key Management Protocol 1 commands are retained for compatibility purposes and are not
to be used when doing secure communication.
Some ViVOpay firmware versions that support EMV security features provide an EMV Key
Management Interface that can be used by a terminal to Add/Delete CA Public Keys and related
data. These firmware versions also provide a Real Time Clock set up interface and an EMV
ViVOpay Terminal set up interface.
This document describes the ViVOpay Serial Interface, specifically the EMV Key Management
commands, the Real Time Clock set up commands and the EMV ViVOpay Terminal set up
commands. It describes the communication parameters, the ViVOpay Serial Interface Protocol
and the command-specific details.
Warning: DO NOT mix the two Key Management formats. Manage the keys using Protocol 1 or
Protocol 2 but not both.
ViVOpay provides a secure storage environment on its Crypto Chip for storing the Certification
Authority Public Keys. It allows for storage of up to a maximum of 30 keys which are uniquely
identified as a key index in each payment scheme (RID). The basic Key management functions
provided are setting of a new Public Key based on a Unique <RID, Key Index> Pair, and deletion
of a key. Once a key has been stored in the Crypto Chip, it does not allow retrieval of the key.
All authentication/decryption functions that require the key take place inside the Crypto Chip.
The ViVOpay reader periodically checks for Command Frames. Once it starts receiving a
Command Frame, it expects each successive byte to arrive within the inter-byte timeout. If the
ViVOpay reader is receiving multiple Data Frames it expects each successive byte to arrive
within the inter-frame timeout (see table below). If the data is not received within the timeout
period listed, the ViVOpay reader times out and a timeout failure response is sent.
90
NEO Interface Developers Guide NEO v1.00
Once the ViVOpay reader has received a command, the time in which it starts sending a
response back to the terminal varies from command to command, depending on what kind of
processing is required before a response can be sent back to the terminal.
00h No Error
01h Unknown Error
02h Invalid Data
03h Incomplete Data
04h Invalid Key Index
05h Invalid CA Hash Algorithm Indicator
06h Invalid CA Public Key Algorithm Indicator
07h Invalid CA Public Key Modulus Length
08h Invalid CA Public Key Exponent
09h Key already Exists (Try to Set Key after deleting existing Key)
0Ah No space for New RID
0Bh Key not Found
0Ch Crypto Chip not responding
0Dh Crypto Chip Communication Error
0Eh RID Key Slots Full
0Fh No Free Key Slots Available
Use this command to send data related to a CA Public Key to the ViVOpay reader for storing in a
secure environment (Crypto Chip Memory). The Public Key is uniquely identified by the <RID,
Key Index> pair. If the total length of the key related data being sent is more than 244 bytes,
then it can be broken down into two Data Frames.
91
NEO Interface Developers Guide NEO v1.00
ViVOpay PC / Peripheral
Device
ViVOpay
PC / Peripheral
Device
Set CA Public Key Cmd
ACK Frame
ACK Frame
Data Frame 1
Data Frame 1
ACK Frame
ACK Frame
Data Frame 2
Data Frame 2
Set Key in
Crypto
92
NEO Interface Developers Guide NEO v1.00
DataLen, DataLen2
If the key data is being sent in a single Data Frame, then DataLen contains the length of the
one and only Data Frame to follow and DataLen2 is 0.
If the key data is being sent in two Data Frames, then DataLen contains the length of the
first Data Frame and DataLen2 contain the length of the second Data Frame. The length of
either Data Frame must not exceed 244 (0xF4) bytes.
DataLen > 0, DataLen2 >= 0
If at any time ViVOpay sends back a NACK Frame with Status set to Failed, then the Error code
field indicates the reason for failure.
First Data Frame from terminal to Reader (If reader sent an ACK)
Byte
Byte 0-8 Byte 9 Byte 10-13 Byte 14 … Byte 10+(n-1) Byte 10+n
10+(n+1)
CRC CRC
Frame Tag Frame Type Data 0 Data 1 … Data (n-1)
(LSB) (MSB)
ViVOtech\0 ‘D’ Data Data … Data
93
NEO Interface Developers Guide NEO v1.00
The data field in the first Data Frame contains the complete or partial CA Public Key related
Data. The complete contents and format of the Key Data are given in the following Table. The
data portion of Data Frame 1 and Data Frame 2 (if present) when stripped of the Frame
overhead and concatenated, provides the data as given in the following table.
94
NEO Interface Developers Guide NEO v1.00
Second Data Frame from terminal to ViVOpay (If the reader sent an ACK, and Data remains to be
sent).
Byte
Byte 0-8 Byte 9 Byte 10-13 Byte 14 … Byte 10+(p-1) Byte 10+p
10+(p+1)
CRC CRC
Frame Tag Frame Type Data 0 Data 1 … Data (p-1)
(LSB) (MSB)
ViVOtech\0 ‘D’ Data Data … Data
If the second Data Frame is sent, then the data field in this frame contains the remaining CA
Public Key related Data.
On receiving valid data, the reader sends it to the Crypto Chip for secure storage. The Crypto
Chip checks the data and stores it in its memory. If the CA Public Key is stored successfully in
the Crypto Chip memory, the reader returns an ACK frame. If for any reason the CA Public Key is
not stored, the reader returns a NACK frame.
Final ACK Frame from Reader
Use this command to instruct the ViVOpay reader to delete a previously set CA Public Key from
within secure storage in the Crypto Chip. The Key is uniquely identified by the <RID, Key Index>
pair.
When this command is received, ViVOpay waits for a Data Frame containing the RID and Key
Index. It then instructs the Crypto Chip to delete the specified CA Public Key. Depending on the
result of this operation, the reader returns an ACK or NACK Frame.
95
NEO Interface Developers Guide NEO v1.00
NACK Frame
Byte 0-8 Byte 9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Frame CRC CRC
Frame Tag Command Status Data1 Data2
Type (MSB) (LSB)
ViVOtech\0 ‘N’ 24h FAILED Error Code Unused
The RID, together with the Key Index specifies a unique Key stored in ViVOpay Secure Memory.
96
NEO Interface Developers Guide NEO v1.00
Use this command to instruct the ViVOpay reader to delete all previously set CA Public Keys
from within secure storage in the Crypto Chip. The Keys is deleted regardless of the <RID, Key
Index> pair.
When this command is received, the reader instructs the Crypto Chip to delete all CA Public
Keys. Depending on the result of this operation, the reader returns an ACK or NACK Frame.
97
NEO Interface Developers Guide NEO v1.00
This command allows the POS application to Enable/Disable RF Error Code Reporting for the Get
Full Track Data command. When RF Error Code Reporting is enabled, if there is any RF error
code, it is reported to the POS application through the ACK Frame for Get Full Track Data
command (see Get Full Track Data).
Operation Code:
98
NEO Interface Developers Guide NEO v1.00
On ViVOpay readers that support EMV, the Real Time Clock must be configured with the correct
local date and time for the region in which it is used. The RTC commands allow a terminal to
check the date and time on a ViVOpay reader and change it if required.
Use this command to instruct the ViVOpay reader to set a specific time in the Real Time Clock.
99
NEO Interface Developers Guide NEO v1.00
Use this command to instruct the ViVOpay reader to return the current time from the Real Time
Clock.
100
NEO Interface Developers Guide NEO v1.00
Use this command to instruct the ViVOpay reader to set a specific Date in the Real Time Clock.
DataLen
If the key data is being sent in a single Data Frame, then DataLen contains the length of the
one and only Data Frame to follow and DataLen2 is 0.
If the key data is being sent in two Data Frames, then DataLen contains the length of the
first Data Frame and DataLen2 contain the length of the second Data Frame. The length of
either Data Frame must not exceed 244 (0xF4) bytes.
DataLen > 0, DataLen2 >= 0
ACK Frame from Reader
Byte 0-8 Byte 9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Frame CRC CRC
Frame Tag Command Status Data1 Data2
Type (MSB) (LSB)
ViVOtech\0 ‘A’ 25h Status=OK 00 00
Data Frame from Terminal to Reader (If the reader sent an ACK)
Byte 0-8 Byte 9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
CRC CRC
Frame Tag Frame Type Data 0 Data 1 Data 2 Data 3
(LSB) (MSB)
ViVOtech\0 ‘D’ YY1 YY2 MM DD
101
NEO Interface Developers Guide NEO v1.00
This command returns the reader’s the current Date from the Real Time Clock.
DataLen
102
NEO Interface Developers Guide NEO v1.00
Number of Data Bytes in the Data Frame to Follow. This does not include the Frame Tag,
Frame Type and Checksum bytes. This is either 0 (if Date is not being returned) or 4.
NACK Frame from Reader
Byte 0-8 Byte 9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Frame CRC CRC
Frame Tag Command Status Data1 Data2
Type (MSB) (LSB)
ViVOtech\0 ‘N’ 25h FAILED Error Code Unused
103
NEO Interface Developers Guide NEO v1.00
General Commands
Ping (18-01)
Use the Ping command to check if the ViVOpay reader is connected to the terminal. If the
ViVOpay reader is connected, it responds with a valid Response Frame, otherwise there is no
response.
Command Frame
Response Frame
The Set Poll Mode command allows the terminal to set the ViVOpay reader polling mode. The
ViVOpay reader functions in one of two polling modes: “Auto Poll” or “Poll on Demand”. The
value is saved in nonvolatile memory so you only need to send this command when you want to
change the mode.
The ViVOpay reader operates in Poll on Demand mode by default. Use the Poll on Demand mode
when you want the reader to poll for cards only when requested to by the terminal. In this mode
the ViVOpay reader remains in the idle state with the RF field off until it receives an Activate
Transaction command. Once the transaction is completed (or the reader times out while polling)
the reader returns to the idle state. This mode allows the terminal to send data to the reader
before the card data is read, as required for EMV transactions.
In Auto Poll mode, the RF field is always active and the reader continuously polls for the
presence of a contactless card. There is no requirement for the terminal to initiate a
transaction. When a supported contactless MagStripe card is detected, the Track data can be
104
NEO Interface Developers Guide NEO v1.00
sent out on the MagStripe interface (if the ViVOpay unit supports it) or retrieved using the Get
Transaction Result command. The Auto Poll mode is required in environments where the
ViVOpay reader is connected to a POS terminal via the terminal’s MagStripe interface.
Warning: EMEA UI is intended for use in the EMV or European environment, where the reader
is not allowed to poll continuously (e.g., operate in Auto Poll Mode). The reader does NOT
support Auto Poll while in EMEA UI mode and has the potential for aberrant or unstable
behavior. The reader is not certified to work properly in this situation.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 14+n Byte 15+n
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 01h 01h 00h 01h Poll Mode
Poll Mode
Response Frame
The Poll Mode has been set to the requested mode only if the Response Frame contains an OK
Status Code. No data is returned in the response.
Use the Control User Interface command to instruct the reader to display a message, change
LED behavior, and beep. Each action is controlled independently by values in the data field of
the command. This allows you to instruct the reader to beep when it displays a message. To
display messages, the reader must be in Poll on Demand mode. Readers without a display can
use this command to control the buzzer and LEDs.
There are three cases depending on the LCD Message index number:
Indexes 00h to 07h correspond to messages that are automatically displayed by the
reader. In most cases, you do not use the terminal to trigger these messages.
Indexes 08h to 0Bh are messages that are triggered by the terminal.
105
NEO Interface Developers Guide NEO v1.00
Index FFh indicates that the command is only setting the buzzer and/or LEDs. No
message is displayed.
After completion of a successful transaction, the "Thank You" message remains on the LCD until
the terminal sends a new Control User Interface command.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 01h 02h 00h 04h See Data Table
The format and contents of the data field in the Command Frame are given in the following
table.
106
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
non-pass-through mode has no effect.
00h: LED Off
LED Status 1
01h: LED On
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 01h 00h 00h
Code Table
If the Status Code does not return OK, the command failed.
Use this command to set up or get the source for RTC/LCD/Buzzer/LED on the ViVOpay reader.
The reader can be configured to use internal source or external source for RTC/Buzzer/LED
control. If necessary, the reader can be configured to use both internal and external source
except for the RTC.
Note: ViVOpay reader may not support all these options. Careful attention must be given to
these details.
When the data length is 02h, the command is used to set up the source configuration for
RTC/LCD/Buzzer/LED; when the data length is 0, the current source configuration shall be
returned in the Response Frame.
Bitmap for
ViVOtech2\0 01h 05h 00h 02h RTC/LCD/Buzzer/
LED
107
NEO Interface Developers Guide NEO v1.00
108
NEO Interface Developers Guide NEO v1.00
The Date/Time can be configured to use internal or external Date/Time, depending on the
reader configuration. When the reader is configured to use internal time, the RTC (Real Time
Clock) chip is needed on the ViVOpay reader and the date and time from the RTC chip is used.
When the reader is configured to use external time, the terminal needs to set up the RTC inside
the ARM processor of the ViVOpay reader (using the Set Configuration command).
If configured to use the internal buzzer, the ViVOpay reader’s buzzer is used to indicate the
transaction progress. If configured to use external buzzer, an external buzzer is used and the
ViVOpay reader’s buzzer is not used.
If configured to use internal LEDs, the ViVOpay reader’s LEDs are used to indicate the
transaction progress. If configured to use external LEDs, the LEDs on the terminal are used, and
the reader’s LEDs are not used. The source of the three transaction LEDs and the power LED can
be configured separately.
This command provides an external method for resetting parameters in non-volatile memory
(NVM) to their default values.
When this serial command is received an NVM Initialization function is called and the display is
changed to show the message.
Initializing ….
Please Wait
109
NEO Interface Developers Guide NEO v1.00
Once initialization is complete the display is returned to the ready state message.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 04h 09h 00h 00h 87h 30h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
ViVOtech2\0 04 00h 00h 00h AEh 16h
110
NEO Interface Developers Guide NEO v1.00
This command provides an external method for resetting parameters in non-volatile memory
(NVM) to their default values.
When this serial command is received, the reader will erase eeporm and keep encrypt keys.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 04h 0Ah 00h 00h F7h 46h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
ViVOtech2\0 04 00h 00h 00h AEh 16h
Admin Key
Encrypt type
Encrypt Status
111
NEO Interface Developers Guide NEO v1.00
Use this command to set or change the values of the specified Tag Length Value (TLV) data
objects in the reader. It can be used to set parameters for Auto Poll as well as Poll on Demand
Mode.
When the reader receives this command, it extracts the TLV encoded parameters from the data
portion of the command and saves them to the default TLV Group in non-volatile memory. If a
TLV data object is incorrectly formatted, the reader stops processing the object. A single
command may contain more than one TLV data object.
The Set Configuration command is the only mechanism for setting the values of global
configuration parameters.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 04h 00h
Objects
The TLV data objects that can be set using this command are defined in the Global
Configuration Tags table.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h 00h 00h
Code Table
Use this command to return the values of the TLV global data objects and default group data
objects (TLV Group 0) in the reader from the reader’s nonvolatile memory.
Note: If your reader supports Configurable Application Identifier (AIDs), the following
applies:
1. The Get Configuration command may be used to retrieve global configuration tags and
Group 0 configuration tags.
112
NEO Interface Developers Guide NEO v1.00
2. The Get Configuration command produces the same result as a Get Configurable Group
command for group 0 (default). Get Configuration cannot return TLVs from other TLV
Groups.
3. The Get Configuration command cannot return PayPass Group tags (because PayPass does
not use group 0).
When the reader receives this command, it returns the current values for all the parameters
that can be set using the Set Configuration command. Each parameter is returned as a TLV data
object. Floor Limits for different AIDs are preceded by the TLV of the specific AID associated
with that object.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 02h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 03h
Code Table Objects
Refer to the Global Configuration Tags and Group Configuration Tags for definitions of tags that
can be returned in this command.
Get the ViVOpay Firmware Version Number from the ViVOpay reader. The reader returns a
Response Frame containing the ViVOpay firmware version information.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 29h 00h 00h 00h
113
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status String
ViVOtech2\0 29h 00h Version string
Code Table length
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 29h 04h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status String
ViVOtech2\0 29h 00h Version string
Code Table length
This command instructs the reader to change its baud rate to the specified value. If the
Command Frame is valid and the ViVOpay reader supports the specified baud rate, it returns an
OK response and then switches to the specified baud rate. If the Command Frame is not valid,
or an invalid baud rate parameter is specified then the reader returns an error Response Frame.
The new baud rate is retained over power cycles.
114
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 14+n Byte 15+n
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
Baud Rate
ViVOtech2\0 30h 01h 00h 01h
Code
Important: All other values for Baud Rate Code are invalid and should not be accepted by
reader.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Data Length Data Length
Protocol Command Status Code CRC (MSB) CRC (LSB)
(MSB) (LSB)
Version
See Status Code
ViVOtech2\0 30h 00h 00h
Table
The reader switches baud rate only if the Response Frame contains an OK Status Code. No data
is returned in the response.
This command instructs the reader to change its baud rate to the specified value temporarily.
After power up, the baud rate will return to the previous value. If the Command Frame is
valid and the ViVOpay reader supports the specified baud rate, it returns an OK response and
then switches to the specified baud rate. If the Command Frame is not valid, or an invalid baud
rate parameter is specified then the reader returns an error Response Frame.
Note: If the new baud rate is set by sending 30-02 command, then after power up, the baud
rate will return to the previous value. If the new baud rate is set by sending 30-01 command,
then after power up, the baud rate will still be the new value.
Command Frame
115
NEO Interface Developers Guide NEO v1.00
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 14+n Byte 15+n
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
Baud Rate
ViVOtech2\0 30h 02h 00h 01h
Code
Important: All other values for Baud Rate Code are invalid and should not be accepted by
reader.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Data Length Data Length
Protocol Command Status Code CRC (MSB) CRC (LSB)
(MSB) (LSB)
Version
See Status Code
ViVOtech2\0 30h 00h 00h
Table
The reader switches baud rate only if the Response Frame contains an OK Status Code. No data
is returned in the response.
This command instructs the ViVOpay to store the 15-digit serial number in its non-volatile
memory. If a serial number has already been set in the reader then this command fails with a
Command Not Allowed error status. If the Command Frame is not valid, or the length is not 15
bytes then ViVOpay returns an error Response Frame.
Note: The reader serial number can only be set once. For Kiosk III, the coding of serial
number must follow ID Tech Product Serial Number Requirement. If the input serial number
does not satisfied by ID Tech Product Serial Number Requirement, reader will reject this
command and respond error. For detailed information, refer to "WI 7.5.1-8 ID TECH Product
Serial Number Requirements"
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 14+n Byte 15+n
116
NEO Interface Developers Guide NEO v1.00
Note: For the 15 digit Serial Number in Kiosk III, only the first 10 bytes are valid.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 12h 00h 00h
Code Table
Note: This command can only be used after the reader has received a Set Serial Number
command.
This command instructs the ViVOpay to return the 15-digit serial number stored in its non-
volatile memory. If a serial number has not been set in the reader then this command fails with
a Command Not Allowed error status. If the Command Frame is not valid then ViVOpay returns
an error Response Frame.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 12h 01h 00h 00h
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status 15-digit Serial
ViVOtech2\0 12h 00h 0Fh
Code Table Number
Note: For the 15 digit Serial Number in Kiosk III, only the first 10 bytes are valid.
117
NEO Interface Developers Guide NEO v1.00
The ViVOpay firmware has the ability to spontaneously transmit its version information over the
serial line during bootup. In this way the reader can notify the POS that it is ready to
communicate when the bootup process has finished.
This feature can be toggled on or off using of the Bootup Notification command.
Command Frame
Byte 14-
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 19 Byte 20
Byte 18
Header Tag & Sub Length Length Data CRC CRC
Command
Protocol Command MSB LSB 1 Bytes (LSB) (MSB)
ViVOtech2/0 14h 01h 00h 01h See below Varies Varies
Byte Description
00h Bootup Notification is disabled.
01h Bootup Notification is enabled.
If Bootup Notification is enabled, the firmware transmits its Firmware Version string one time at
the end of bootup.
For example, if a Vendi reader were enabled, it would begin to transmit its string, in this case,
“Vendi V1.00” each time it was restarted.
Response Frame
Byte 14-
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 14+n+1
Byte 14+n-1
Header Tag Length Length Data CRC CRC
Command Status
& Protocol MSB LSB 1 Bytes (LSB) (MSB)
ViVOtech2/0 14h Varies 00h 00h NA Varies Varies
118
NEO Interface Developers Guide NEO v1.00
This command creates or selects an AID for configuration or deletion. There are eight TLVs that
can be included in this command, some of which are mandatory.
TLV Group Number – This number refers to the group that has been created containing all of the
characteristics desired for this AID. Setting and configuring the TLV Group Number is explained
below. The TLV Group Number must be configured first. If an AID is communicated referring to a
non-existing group, that AID is rejected.
Registered Application Provider Identifier (RID) – The parameter is optional. If it is provided, this
number is used to reference the CA Public Key payment system. If it is not provided the first
five bytes of the AID are used.
Must always include the TLV Group Number TLV as the FIRST TLV in the message.
Must always include the AID TLV as the SECOND TLV in the message.
There are System AIDs in the reader. These can be disabled but cannot be deleted.
Must always include the TLV Group Number TLV as the FIRST TLV in the message.
Must always include the AID TLV as the SECOND TLV in the message.
There are eight User AIDs in the system. These can be added (set) or deleted at the user’s
discretion.
No User AID can have the same exact AID as a System AID.
All AIDs must reference a TLV Group (in the TLV Group Number TLV) that already exists
Any AID with a Partial Select TLV must also include the Max AID Length TLV
119
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 04h 02h
Objects
The TLV Data Objects that can be set using this command are defined in the AID Configuration
Tags.
To set Configurable AID tags, the Application Identifier (9F06) and Group Number (FFE4) are
mandatory tags.
Note: At present, the preferred means of disabling a System AID is NOT to include the FFE6
TLV. Instead, just issue a Delete AID command to for particular AID. This deletes a User AID
OR disables a System AID.
If a Set Configurable AID command is sent without an FFE6 TLV, the reader enables the AID if it
is not already enabled.
Finally, a Set AID command used for a User AID can include a FFE6 Disable AID Tag, but it is
ignored. This tag is only used to set System AID.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h 00h 00h
Code Table
This command creates or modifies a TLV Group. You configure a specific TLV Group by passing
the TLVs with the desired functionality and a unique TLV Group Number to the reader. The TLVs
that can be associated with a TLV Group are listed below. A TLV Group Number and at least one
other TLV is required. The reader uses TLVs in the default TLV Group 0 for any TLVs not defined
in the user-defined TLV Group.
For M/Chip 3.0, Group 0 is not used. If you are configuring a group for M/Chip PayPass, then
you should refer to the PayPass Group Tags. Otherwise, refer to the Group Configuration
Tags.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
120
NEO Interface Developers Guide NEO v1.00
If you are changing TLVs in Group 0 (the Default Group) the reader retains and uses the old
values of any TLVs not included in the Set Configurable Group command. If you are changing any
other Group, the reader discards existing TLVs not in the current Set Configurable Group
command.
The implication of the statement above is that if you are configuring a group for PayPass, you
must configure all of the necessary tags, as they will not default to Group 0 tags.
To set the TDOL TLV, simply pass on the desired values in the TLV. To disable the default TDOL,
send a TDOL TLV with Length set to zero and no Value field included. This instructs the reader
to delete any existing TDOL list for this group.
The TLV Data Objects that can be set using this command are given in the Configurable Group
Tags Table (for non- PayPass applications) or the PayPass Group Tags.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h 00h 00h
Code Table
This command returns the configurable (User) AID parameters. The user MUST send an AID TLV
in the command, as the first TLV in the command. The reader then returns all tags associated
with that User AID in the response.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 03h 04h
Objects
The command MUST include the TLV below. The command should NOT include any other TLV.
121
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 03h
Code Table Objects
The optional Data Objects encoded as TLV that is returned in the data section of the Response
Frame are the same as those listed in the AID Configuration Tags. The reader returns ALL TLV
associated with this AID in its response.
If an AID is requested and the reader fails to find it in its database, the reader returns the AID
TLV itself and NO additional arguments. This indicates that the command was correct with the
proper argument, but there was no match in the reader’s database. The reader does NOT
indicate an error situation.
If the user requests a System AID that is currently disabled, the reader returns the AID TLVs, but
appends the FFE6 TLV, showing that the AID is currently disabled.
Use this command to return all TLVs associated the specified Configurable Group. A configurable
Group Tag must be included as the ONLY TLV in this command. The response should contain all
of the Tags associated with this configurable Group.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 03h 06h
Objects
The following TLV MUST be encoded in the command, it is the ONLY tag included in the
command.
122
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 03h
Code Table Objects
The Data Objects encoded as TLV that is returned in the data section of the Response Frame are
given in the Group TLV Objects Table.
If the user requests a Group that is illegal, an error response is sent back.
If the user requests a valid Group number but the Group does NOT exist, then the reader returns
the regular response but only includes the Group Number TLV (no other TLV is included). This
signifies that the user has requested a valid number but no Group has been assigned to it.
Note: For a PayPass group, if a TLV data item is not present in the Group then it will not be
present in the data returned by this command. However, this does not mean that there is no
value for this particular TLV in order to perform a transaction. It is possible that the PayPass
Kernel may have a hard-coded value for this TLV which will be used in a transaction if the TLV is
not present in the Group or in Activate Transaction data. The data items for which the PayPass
kernel has hard-coded default values are given in in the section on PayPass Group Configuration
TLVs with Hard-Coded Values in Kernel.
This command deletes a configurable AID. It is MANDATORY to include the AID TLV of the AID to
be removed. No other TLVs should be included.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 04h 04h
Objects
The Data Object encoded as TLV that can be set using this command is below.
123
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 03h 00h 00h
Code Table
The user may NOT delete a System AID. If this command is used on a System AID, the reader
disables that System AID but does not delete it. That System AID can be restored at any point by
using the Set AID command on it. Until that point it does not function (but it continues to reside
in the reader’s database).
When deleting an AID, the reader returns an OK response if the operation was successful. If it
failed to find a matching AID, it returns an invalid parameter error response. If there was a
problem with the command, the error response indicates malformed data.
Use this command to delete a configurable Group. This means that this Group can no longer be
used to load the parameters for a transaction.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
TLV Data
ViVOtech2\0 04h 05h
Objects
It is MANDATORY to include the Group Number TLV of the Group the user wishes to delete. No
other TLVs should be included.
The group that contains the properties for AID
[1] Group
FFE4 MAND n2 1
Number
Note: This must be the ONLY TLV in Data Field.
[1]
These objects use proprietary tags. The use of these tags should be restricted to the serial interface. Once the reader
has received these values and saved them in memory, the Terminal should dispose of the tags.
124
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h 00h 00h
Code Table
Do NOT delete the Default Group 0. The reader does not allow this command, and does NOT
disable Group 0; instead it returns an error.
Finally, if the reader has ANY AID that references this Group, it does NOT delete the Group. It
returns an error. That is, ONLY Groups that are NOT referenced by existing AID can be deleted.
In this situation, the user must first delete or modify these AIDs, and then delete the Group.
Use this command to return all AIDs in the reader. This command may be used to verify
configured AIDs or to determine what System AIDs are in the reader.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 05h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 03h
Code Table Objects
The only Data Objects that should be returned from the GAA command are AID Tags. The reader
sends out ALL TLV associated with each AID.
The reader sends one or more frames with all the AID TLVs in it. Each AID grouping begins with
the Group Number TLV that this AID uses. The user can use this fact to parse between the AID
groups passed back to the POS.
125
NEO Interface Developers Guide NEO v1.00
This command returns all Groups in the reader. This command may be used to verify all
configured Groups in the reader.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 07h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 03h
Code Table Objects
The only Data Objects that should be returned from the GAG command are Group Tags. These
are the same as those itemized in the Group Configuration Tags table.
The reader sends one or more frames with all the Group TLVs in it. Each Group begins with the
Group Number TLV for the Group in question. The user can use this fact to parse between the
Groups passed back to the POS.
Use this command when the ViVOpay reader is in “Poll on Demand” mode to begin an EMV or
contactless MagStripe Card transaction. When the reader is in “Poll on Demand” mode, the RF is
turned on only after receiving an Activate Transaction command. When a valid Activate
Transaction command is sent to the ViVOpay reader, it starts polling for cards.
If the ViVOpay reader does not find a supported card (an AID that matches one of the configured
AIDs in the reader) for the specified time duration, it times out and ends the transaction. If the
ViVOpay reader finds a card within the specified time interval, it attempts to carry out the
transaction. The transaction flow between the reader and the card depends on the type of card
detected.
126
NEO Interface Developers Guide NEO v1.00
If the transaction is successful, the reader returns the data in the response data. If the
transaction is not successful, yet it proceeded into the transaction state machine, the reader
returns a Failed Transaction Record in the response data. The presence and format of the
Clearing Record, Track Data and Failed Transaction record depends on the type of card that was
detected.
Note: While an Activate command is in progress, only a Cancel or a Stop command may be
sent. Do not send other commands until Activate Transaction has completed, because the
reader will interpret these as a Cancel Transaction command.
Note: For Non-SRED version device, response format for Activate Transaction Command is
according to “Set Data Encryption Enable Flag (C7-36)” setting and Account DUKPT Key.
When Data Encryption is disabled, device responds with plaintext data format. When Data
Encryption is enabled: (1) When Account DUKPT Key exists and is valid, device responds with
encrypted data format. (2) When Account DUKPT Key exhausts or does not exist, device
responds status code 0x91/0x90 and no data.
For SRED version device, response format for Activate Transaction Command is according to
Account DUKPT Key. When Account DUKPT Key exists and is valid, device responds with
encrypted data format. When Account DUKPT Key exhausts or does not exist, device
responds status code 0x91/0x90 and no data.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
See Data
ViVOtech2\0 02h 01h
Format below
The format and contents of the data field in the Command Frame are given in the following
table. All length values include the Tag and Length bytes.
127
NEO Interface Developers Guide NEO v1.00
128
NEO Interface Developers Guide NEO v1.00
For EMV transactions, if the terminal has already set up one or more of these data items
using the Set Configuration or Set Configurable Group command, then the terminal need not
include those data items in the Command Frame. If the terminal includes one or more values
in the Command Frame, the reader uses the included values. If it does not, the reader just
uses the default or previously set values.
The ViVOpay reader starts polling for cards when it receives this command. If it finds a card, it
tries to complete a transaction with the card. If the card is a supported contactless EMV Card
the reader uses the TLV fields in the Command Frame for the transactions. If the card is a
contactless MagStripe Card, the reader does not use the TLV objects for the transaction.
If the transaction is completed successfully, and the card supported contactless EMV, then the
reader returns the Clearing Record in the response data, otherwise, if the card does not support
contactless EMV i.e. it is a contactless MagStripe Card, the reader returns Track information in
the response data.
If the transaction cannot be completed successfully, the response contains an appropriate status
code. The Response Frame contains more error information in the data field, for certain status
codes.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC CRC
& Protocol Command Status Code Length Length Data
(MSB) (LSB)
Version (MSB) (LSB)
See Response
See Status
ViVOtech2\0 02h Frame Data
Code Table
Format
Note: Specific TLV data may or may not be returned based on what was recovered from the
card. Also, there is no implied sequence for returning the TLVs; the TLVs may or may not be
returned in the order listed in the table based on what was recovered from the card.
Note: ViVOcomm and DesFire cards return raw track data only.
Note: Kiosk III/ Vendi don't support ViVOcomm and DesFire cards.
If the Status Code is OK or “Request Online Authorization” then the format and contents of the
data field in the Response Frame are given in the following table.
Some data objects may not be present depending on the card involved in the transaction and
the presence or absence of a Clearing Record object (DE 055). All TLV lengths include the Tag
and Length bytes.
129
NEO Interface Developers Guide NEO v1.00
TLV DE 055 Variable DE 055 data (if available) as a TLV data object encoded with Tag ‘E1’.
(Clearing Record) up to 128 The DE 055 data is the same data as is included in the Clearing
Record. Refer to the Activate Transaction Clearing Record table.
Tag: E1 Format: b1...126 variables.
TLV Data Variable See Activate Response TLVs below.
MasterCard transactions do not return a Clearing Record or the track data fields. Tags are
returned in a format specified by M/Chip 3.0. Track 1 and Track2 data are encapsulated in
tags according to the MasterCard specification.
130
NEO Interface Developers Guide NEO v1.00
Length
Tag Description Format
(in bytes)
57 Track 2 Equivalent Data.
Contains the data objects of the track 2, in accordance
ans <=19
with ISO/IEC 7813, excluding start sentinel, end
sentinel, and LRC.
5A Application Primary Account Number (PAN). <=19
cn
The cardholder account number. (10 bytes)
82 Application Interchange Profile.
Indicates the capabilities of the Card to support specific b 2
functions in the application.
84 DF Name.
Identifies the name of the DF as described in ISO/IEC b 5..16
7816-4.
95 Terminal Verification Results.
Status of various functions from the terminal b 5
perspective.
9A Transaction Date. n6
3
Local date that the transaction was performed. (YYMMDD)
9B Transaction Status Information. b 2
9C Transaction Type.
Indicates the type of financial transaction, represented n2 1
by the first two digits of ISO 8583:1993 Processing Code.
5F20 Cardholder Name. b <=26
5F24 Application Expiration Date. n6
3
The date after which the card application has expired. (YYMMDD)
5F25 Application Effective Date. n6
3
Date from which the card application may be used. (YYMMDD)
5F2A Transaction Currency Code.
Indicates the currency code of the transaction, in n3 2
accordance with ISO 4217.
5F2D Language Preference.
1-4 languages stored in order of preference, each
an 2..8
represented by 2 alphabetical characters according to
ISO 639.
5F34 PAN Sequence Number.
Identifies and differentiates cards with the same n2 (BCD) 1
Application PAN.
9F02 Amount, Authorized n12 6
9F03 Amount Other n12 6
9F06 Application Identifier (AID). b 5..16
9F07 Application Usage Control. b 2
9F09 Application Version Number (Reader)
Version number assigned by the payment system for the b 2
Kernel application.
9F0D Issuer Action Code (Default). b 5
9F0E Issuer Action Code (Denial). b 5
9F0F Issuer Action Code (Online). b 5
9F10 Issuer Application Data.
Contains proprietary application data for transmission to b <=32
the issuer in an online transaction.
131
NEO Interface Developers Guide NEO v1.00
Length
Tag Description Format
(in bytes)
9F11 Issuer Code Table Index.
Indicates the code table according to ISO/IEC 8859 for n2 1
displaying the Application Preferred Name.
9F12 Application Preferred Name.
ans <=16
The preferred mnemonic associated with the AID.
9F1A Terminal Country Code.
(Typically, this has been configured in the reader – refer n3 2
to Group Configuration Tags.)
9F1E Interface Device Serial Number.
Unique and permanent serial number assigned to the IFD
by the manufacturer. (Typically, this has been an 8
configured in the reader – refer to Group Configuration
Tags.)
9F21 Transaction Time. n6
3
Local time that the transaction was performed. (HHMMSS)
9F26 Application Cryptogram.
b 8
This is returned in the response to GenAC or RecoverAC.
9F27 Cryptogram Information Data
Indicates the type of cryptogram and the actions to be b 1
performed.
9F33 Terminal Capabilities.
Indicates the card data input, CVM, and security b 3
capabilities of the Terminal and Reader.
9F34 Cardholder Verification Method (CVM) Results.
b 3
Indicates result of last CVM performed.
9F35 Terminal Type.
(Typically, this has been configured in the reader – refer n2 1
to Group Configuration Tags.)
9F36 Application Transaction Counter.
b 2
Counter maintained by the application in the card.
9F37 Unpredictable Number.
A challenge number used by the card to ensure b 4
uniqueness of the generated cryptogram.
9F39 Point of Service (POS) Entry Mode. Indicates the method
by which the PAN was entered.
Values:
n2 1
90h = Magnetic Stripe Reader swipe
91h = Contactless MSD transaction
07h = Contactless EMV
9F42 Application Currency Code.
Indicates the currency in which the account is managed n3 2
in accordance with ISO 4217.
9F45 Data Authentication Code. b 2
9F4C ICC Dynamic Number. b 8
9F53 Transaction Category Code.
Indicates the type of transaction being performed, and an 1
which may be used in card risk management.
9F5A Membership Scheme - Account Number (Amex) an <=5
Or
Terminal Transaction Type (Interac) b 1
9F5B Membership Scheme Number of Points (Amex). an <=29
132
NEO Interface Developers Guide NEO v1.00
Length
Tag Description Format
(in bytes)
9F5D Available Offline Spending Amount (Balance). b 6
9F6B Track 2 Data.
Contains the data objects of the track 2 according to
b <=19
ISO/IEC 7813, excluding start sentinel, end sentinel and
LRC.
9F6C Card Transaction Qualifiers (Visa transactions only). If
card does not return this tag then a length of zero is b 16
returned.
9F6D Mag-Stripe Application Version Number (Reader).
Version number assigned by the payment system for the b 2
specific mag-stripe mode functionality of the Kernel.
9F6E Third Party Data.
Contains various information, possibly including b 5..32
information from a third party.
9F74 VLP Issuer Authorization b 6
E300 Authorization Code. b 8
Balance Read Before GenAC. (MasterCard)
DF8104 n12 6
Balance read from the card before the GenAC.
Balance Read After GenAC. (MasterCard)
DF8105 n12 6
Balance read from the card after the GenAC.
DF8115 Error Indication. (MasterCard)
Flags defining the error conditions from the transaction. b 6
Refer to the M/Chip PayPass specification.
DF8129 Outcome Parameter Set (MasterCard).
Contains the result of the transaction. Refer to the b 8
M/Chip PayPass specification.
FF8105 Data Record (MasterCard, container).
Contains the data from the transaction. Refer to the b varies
M/Chip PayPass specification.
FF8106 Discretionary Data (MasterCard, container).
Contains the discretionary data from the transaction. b varies
Refer to the M/Chip PayPass specification.
FFEE01 ViVOPay Group Tag. (container)
This three-byte Group Tag was created to contain b <=76
ViVOpay proprietary Tags. See tags below.
DF30 Track Data Source.
(ViVOpay This tag is embedded in the ViVOpay Group tag. It
proprietary) specifies whether the track data came from a swipe or
b 1
RFID transaction.
0Ch for swiped MagStripe
00h for a contactless card.
DF31 DD Card Track 1 (MagStripe Card)
(ViVOpay This tag is embedded in the ViVOpay Group tag. If Track
proprietary) 1 Data is present, then DD CARD TRACK1 contains a copy b <= 56
of the discretionary data field of Track 1 Data as
returned by the card.
DF32 DD Card Track 2 (MagStripe Card)
(ViVOpay This tag is embedded in the ViVOpay Group tag. If Track
proprietary) 2 Data is present, then DD CARD TRACK2 contains a copy b <=8
of the discretionary data field of Track 2 Data as
returned by the card.
133
NEO Interface Developers Guide NEO v1.00
Length
Tag Description Format
(in bytes)
DF33 Receipt Requirement (Interac)
(ViVOpay This tag is embedded in the ViVOpay Group tag for
proprietary) Interac transaction responses. b 1
00 = No receipt required
01 = Receipt required
DF5B Terminal Entry Capability (Visa).
(ViVOpay For Visa Transactions, defines reader support for VSDC
proprietary contact chip.
n2 1
Values:
05h = Reader supports VSDC contact chip
08h = Reader does not support VSDC contact chip
DFEE26 Encrypt Information
Length: 1 bytes
Values (same as Attribution):
bit0 – Card Type: 0 – Contact Card 1 – Contactless Card
bit2,1 – Encryption Mode: 00 – TDES Mode, 01 – AES Mode b 1
bit3 – Card Type: 0 – Contact/Contactless Card. 1 – MSR.
bit6~4 – Reserved
bit7 – Encryption Status: 0 – Encryption OFF. 1 –
Encryption ON.
If a Clearing Record is returned, its potential TLVs are described in the following table.
Different card applications may have a slightly different format, or different TLVs, for the
Clearing Record. MasterCard M/Chip 3.0 does not return a clearing record.
134
NEO Interface Developers Guide NEO v1.00
If the Status Code being returned in the Response Frame is “Failed” and the Error Code is not
“Request Online Authorization”, then the contents of the Data field contains further information
on the cause of the failure and does not contain the Track or Clearing Record information. In
this case the Data field in the Response Frame has the following format.
135
NEO Interface Developers Guide NEO v1.00
If the Status Code being returned in the Response Frame is “Failed” and the Error Code is
“Request Online Authorization”, then the contents of the Data field contains further information
on the cause of the failure and does not contain the Track or Clearing Record information. In
this case the Data field in the Response Frame has the following format.
If the Status Code is “User Interface Event” then the format and contents of the data field in
the Response Frame are given in the following table:
If the transaction failed, the Response Frame may have the following format. Invalid or
inappropriate cards may result in no Response Frame.
136
NEO Interface Developers Guide NEO v1.00
Transaction
Length
Data Item Description
(bytes)
Error Code 1 Error Code giving the reason for the failure. See sub-section on
Error Codes
SW1 1 Value of SW1 returned by the Card (SW1SW2 is 0000 if SW1 SW2
not available)
SW2 1 Value of SW2 returned by the Card (SW1SW2 is 0000 if SW1 SW2
not available)
RF State Code 1 RF State Code indicating exactly where the error occurred in the
Reader-Card transaction flow. See RF State Codes.
TLV data Varies Refer to the Activate Response TLVs.
Command Data
Data Item Length Description
(Bytes)
: : :
ViVOtech TLV Variable
Group Tag TLV 2 Byte Tag + This TLV defines one or more special transaction
FFEE01 Special 1 Byte Length flows for specific non-payment apps that are ISO
Flow + 14443-4 compliant.
Variable data Tag: DF50
(max 40 Format:
bytes) The TLV value contains one or more 4-byte
“Special Flow Record” entries. The format of a
Special Flow Record is given in the next table. A
Special Flow TLV cannot have more than 10
record entries.
TLV 2 Byte Tag + This TLV is for Android Pay only.
Read n-Byte Length This TLV contains the data that is to be sent to
Cmd + Variable the card as part of the Request Data command.
Data Data Format of the TLV value will be as defined by
Android Pay/Discover D-PAS and is out of the
scope of this document.
Tag: DF47
Format: Raw data
TLV 2 Byte Tag + This TLV is for Android Pay only.
Write n-Byte Length This TLV contains the data that is to be written to
Data + the card. Format of the TLV value will be as
Variable Data defined by Android Pay/Discover D-PAS and are
out of the scope of this document. Length of the
Value <= 255.
Tag: DF48
Format: Raw data
TLV 2 Byte Tag + This TLV is for Discover D-PAS only.
Issuer n-Byte Length This TLV contains the Issuer Script that is to be
Script + sent to the card. The Issuer Script is defined by
Variable Data the Discover D-PAS specification.
Tag: DF51
Format: Raw data
137
NEO Interface Developers Guide NEO v1.00
138
NEO Interface Developers Guide NEO v1.00
For Discover D-PAS 2nd Presentment of Issuer Update Process, the value in the Special Flow TLV will be:
Pre-PPSE Write D-PAS On-Line Script Processing DF50 04 0D 02 02 00
The 0xFFEE01 TLV format for Discover D-PAS when input Issuer Script for Issuer Update Processing:
FFEE01 <len> DF50 04 0D020200 DF51 <len> <Issuer Script>
<Issuer Script> is defined by D-PAS spec.
For Android Pay, each of the Transaction flows described below, the value in the Special Flow TLV will be
as follows:
(1) Pre-PPSE SA Data Read DF50 04 17 02 01 00
139
NEO Interface Developers Guide NEO v1.00
The Activate Transaction response data will contain a new tag that will contain the Android Pay
Transaction related data if an Android Pay Transaction was performed, regardless of whether the
transaction was successful or failed. See table below.
If an Android Pay operation was performed in the Pre-PPSE phase, Activate Transaction response contains
the following Transaction Data:
FFEE02 <len><DF49 TLV>
If an Android Pay operation was performed in the Post-PPSE phase, Activate Transaction response contains
the following Transaction Data:
FFEE03<len><DF49 TLV>
Reference files
[1] EMV Contactless Book C-2, Kernel 2 Specification, v2.3
[2] PayPass Test Cases for PayPass v3.0 Level 2 Reader Testing, Aug 2011
[3] EMV Contactless Specifications for Payment Systems, Book A, Architecture and General
Requirements, v2.3
[4] PayPass M/Chip Reader Card Application Interface Specification v3.0.2
[5] Engineering Specification, MChip 3.0 on GR, v1.6
140
NEO Interface Developers Guide NEO v1.00
According to reference [1], all objects listed below are to be added to the output buffer if they are present.
The Data Record (FF8105) may contain the following objects for an EMV transaction, with a maximum length
of 256 bytes (74 TL, 182 V).
The Data Record may contain the following objects for a Mag-Stripe transaction, with a possible maximum
length of 182 bytes (20 TL, 162 V).
141
NEO Interface Developers Guide NEO v1.00
Application PAN 5A 16
Application Preferred Name 9F12 16
Mag-stripe Application Version Number 9F6D 2
DF Name 84 16
Issuer Code Table Index 9F11 1
Track 1 Data 56 76
Track 2 Data 9F6B 19
Discretionary Data is always included in an OUT signal. Discretionary Data for an EMV transaction may
include the following objects, with a possible maximum length of 1009 bytes (61 TL, 948 V), ignoring the Data
Storage elements. Without the Torn Record maximum size would only be 80 bytes.
A Torn Record (FF8101) contains the following objects and may have a maximum length of 894 bytes (66 TL,
828 V);
Discretionary Data for a Mag-Stripe transaction may include the following objects, with a possible maximum
length of 117 bytes (15 TL, 102 V):
142
NEO Interface Developers Guide NEO v1.00
The most typical Intermediate OUT Signal (for cases such as Error – Other Card and Try Again) are only
required to include the Outcome Parameter Set and the Error Indication and the L2 tests usually focus on
verifying data within these objects.
143
NEO Interface Developers Guide NEO v1.00
A new proprietary TLV is defined to hold the intermediate signal data during a transaction. It will be populated
with one or more signal objects as the UI_MSG_Signal function in UserInterface.c receives MSG Signals and
the UI_OUT_Signal function in UserInterface.c receives OUT Signals.
This tag must be included in the ACT command to enable the signal data capture feature during the
transaction. If it is received in the ACT command this feature is enabled and the Signal Data Handler will add
signal data to the buffer. If it is not received, the Signal Data Handler will do nothing and the length of this
TLV will remain 0 and nothing will be returned.
A second new proprietary tag is defined (FFEE05) which is used to separate and identify each individual
signal entry added to the buffer, whether it is a MSG signal or an OUT signal. A new tag (DF8914) which
includes Activate Response TLVs (Table 29) may be included in FFEE05.
When the transaction is complete, if tag FFEE04 was received in the ACT command and the Signal Data tag
is not empty, it will be added to the ACT response. The signal data buffer (the “contents” of FFEE04) is
cleared when an ACT command is received.
TLV DE 055 Variable DE 055 data (if available) as a TLV data object encoded with Tag ‘E1’.
(Clearing Record) up to 128 The DE 055 data is the same data as is included in the Clearing
Record. Refer to the Activate Transaction Clearing Record table.
Tag: E1 Format: b1...126 variables.
144
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
TLV Data Variable See Activate Response TLVs
145
NEO Interface Developers Guide NEO v1.00
Data is follow Enhanced Encrypted MSR FIELD DATA. Refer to Appendix A.11:
Enhanced Encrypted MSR Data Output Format
146
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
TLV data Varies Refer to the Activate Response TLVs.
Sensitive TLV will be TDES/AES encrypted with Padding (0x00)
Please see “80000404-001 ID-Tech Encrypt Data Format In
Command Response Specification v.63F” for details
147
NEO Interface Developers Guide NEO v1.00
Use this command when the ViVOpay reader is functioning in “Auto Poll” mode. In this mode the
reader does not wait for an Activate Transaction command to start polling for a card. It is
always in Auto Poll Mode. When it detects a card, it carries out a transaction with the card. If
the card is a supported contactless MagStripe card, the reader does not need any parameters
from the terminal. If the card is a supported contactless EMV Card, then the reader uses the
default terminal parameters (Group 0 TLVs) in the reader. If some terminal parameters had
been set by using the Set Configuration command, then the reader uses the new values for these
parameters.
If the transaction is successful, the reader keeps the transaction data (Track or Clearing Record)
in its memory. When it receives the Get Transaction Result command, it returns this data to the
terminal immediately and reset its data buffer. If the reader has not detected any card since
power up or since the last Get Transaction Result command, and this command is received, the
reader responds back immediately indicating that it has no data for the terminal.
In Auto Poll Mode the reader can carry out only contactless MagStripe and contactless EMV
transactions. It cannot carry out any ticketing or ePurse transactions since these transactions
require interaction with the Terminal during the transaction itself.
Note: For Non-SRED version device, response format for Get Transaction Result Command is
according to “Set Data Encryption Enable Flag (C7-36)” setting and Account DUKPT Key.
When Data Encryption is disabled, device responds with plaintext data format. When Data
Encryption is enabled: (1) when Account DUKPT Key exists and is valid, device responds with
encrypted data format. (2) When Account DUKPT Key exhausts or does not exist, device
responds status code 0x91/0x90 and no data.
For SRED version device, response format for Get Transaction Result Command is according
to Account DUKPT Key. When Account DUKPT Key exists and is valid, device responds with
encrypted data format. When Account DUKPT Key is invalid or does not exist, device
responds status code 0x91/0x90 and no data.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 00h 00h 00h
On receiving this command, the ViVOpay reader returns one of the following …
148
NEO Interface Developers Guide NEO v1.00
If the transaction cannot be completed successfully, the response indicates an OK status and
indicates “No Data”.
Note: ViVOcomm and DesFire cards return raw track data only.
If there was an error in the Command Frame received then the response contains an appropriate
status code.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 03h See Data Tables
Code Table
If Status Code is OK then the format and contents of the data field in the Response Frame are
given in the following table. Some data objects may not be present depending on the card
involved in the transaction and the presence or absence of a Clearing Record object (DE 055).
All TLV lengths include the Tag and Length bytes.
Length
Data Item Description
(bytes)
Track 1 Length 1 If Track 1 is available, then this field gives the length of the Track 1
data that follows. If Track 1 is not available, then a Length of 00h is
returned.
Format: Binary
Track 1 Data Variable Track 1 Data (if available).
(MagStripe card) Format: ASCII (no null terminator)
Track 2 Length 1 If Track 2 is available, then this field gives the length of the Track 2
data that follows. If Track 2 is not available, then a Length of 00h is
returned.
Format: Binary
Track 2 Data Variable Track 2 Data (if available).
(MagStripe card) Format: ASCII (no null terminator)
DE055 (Clearing 1 If a Clearing Record (DE 055) field is available, then this field is 01h.
Record) Present If there is no Clearing Record (DE 055) field, then this field is 00h.
TLV DE 055 Variable DE 055 data (if available) as a TLV data object encoded with Tag
(Clearing Record) up to 128 ‘E1’. The DE 055 data is the same data as is included in the Activate
(see Clearing Transaction Clearing Record. Refer to the Activate Transaction
Record Format) Clearing Record table.
Tag: E1 Format: b1...126 variable.
TLV Data Variable Refer to Activate Response TLVs.
149
NEO Interface Developers Guide NEO v1.00
If the Status Code is OK the response is different depending on the card application:
A Status Code 23 (request online authorization) can be returned for some cards (qVSDC &
M/Chip) with a fully populated data field.
This command never returns a status code of “Failed”. If any status code other than OK or
status code ‘23’ (request online authorization) is returned, the data field is empty.
The above description is plaintext response. The encrypted data format is as follows: (Please see
“80000404-001 ID-Tech Encrypt Data Format In Command Response Specification v.63F” for details)
Get Transaction Result Encrypted data field format for contactless card
Length
Data Item Description
(bytes)
Attribution 1 bit0 – Card Type: 0 – Contact Card.1 – Contactless Card
bit2,1 – Encryption Mode: 00 – TDES Mode, 01 – AES Mode
bit3 – Card Type: 0 – Contact/Contactless Card. 1 – MSR.
bit6~4 – Reserved
bit7 – Encryption Status: 0 – Encryption OFF. 1 – Encryption ON.
TLV KSN 10 KSN of DUKPT Account Key
Tag: FFEE12 Format: Binary
TLV Track 1 Variable TDES/AES Encrypted Track 1 Data (if available) with Padding (0x00). If
(MagStripe Card) Track 1 is not available, this field is not present.
Tag: FFEE13 (Not Paypass), 56 (Paypass)
Format: ASCII (no null terminator)
TLV Track 2 Variable TDES/AES Encrypted Track 2 Data (if available) with Padding (0x00). If
(MagStripe Card) Track 2 is not available, this field is not present
Tag: FFEE14 (Not Paypass), 9F6B (Paypass)
Format: ASCII (no null terminator)
TLV DE 055 Variable DE 055 data (if available) as a TLV data object encoded with Tag ‘E1’.
(Clearing Record) up to 128 The DE 055 data is the same data as is included in the Clearing
Record. Refer to the Activate Transaction Clearing Record table.
Sensitive TLV will be TDES/AES encrypted with Padding (0x00)
Please see “80000404-001 ID-Tech Encrypt Data Format In Command
Response Specification v.63F” for details
Tag: E1 Format: b1...126 variables.
TLV Data Variable Refer to Activate Response TLVs.
Sensitive TLV will be TDES/AES encrypted with Padding (0x00)
Please see “80000404-001 ID-Tech Encrypt Data Format In Command
Response Specification v.63F” for details
150
NEO Interface Developers Guide NEO v1.00
Get Transaction Result Encrypted data field format for MSR card
Length
Data Item Description
(bytes)
Attribution 1 bit0 – Card Type: 0 – Contact Card.1 – Contactless Card
bit2,1 – Encryption Mode: 00 – TDES Mode, 01 – AES Mode
bit3 – Card Type: 0 – Contact/Contactless Card. 1 – MSR.
bit6~4 – Reserved
bit7 – Encryption Status: 0 – Encryption OFF. 1 – Encryption ON.
MSR TLV Variable MSR TLV
Data length compose of data length indicator (1 byte) and actual data length
byte.
Data is follow Enhanced Encrypted MSR FIELD DATA. Refer to Appendix A.11:
Enhanced Encrypted MSR Data Output Format
Use this command when the ViVOpay reader has been put in “Poll on Demand” mode and after
the reader sends an online request to the issuer. This command is the authorization response
sent by the issuer to the terminal including the Authorization Status (OK or NOT OK).
This command is also being used in some implementations (i.e. EMEA) to communicate the
results of Issuer Authentication to the reader in order to display the correct LCD messages.
With this command, the POS passes the authorization result (OK/NOT OK), and possibly the
Authorization Code (Auth_Code)/Date/Time to the terminal.
For a Visa transaction when the card supports Available Offline Spending Amount, the LCD
displays the available amount.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC
& Protocol Command Length Length Data CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 03h 03h See Data Table
151
NEO Interface Developers Guide NEO v1.00
The format and contents of the data field in the Command Frame are given in the following
table. All TLV lengths include the Tag and Length bytes.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 03h See Data Tables
Code Table
If the Status Code is OK then the format and contents of the data field in the Response Frame
are given in the following table. All TLV lengths include the Tag and Length bytes.
If the Status Code being returned in the Response Frame is “Failed”, then the contents of the
Data field contains further information on the cause of the failure and does not contain the
152
NEO Interface Developers Guide NEO v1.00
Authorization Code etc. In this case the Data field in the Response Frame has the following
format.
Use this command to stop reader/card communication after the Activate Transaction command
or Update Balance command has been sent to the reader.
After the terminal has issued the Cancel Transaction command, the terminal should not send
any commands until it receives a response from the reader. If the reader receives the Cancel
Transaction command before it sends the response to an Activate command, it only sends the
Cancel Transaction response. The reader then enters an “idle” state and waits for the next
command from the terminal.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 05h 01h 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 05h 00h 00h
Code Table
153
NEO Interface Developers Guide NEO v1.00
This section describes commands that are specific to MasterCard M/Chip 3.0
transaction behavior.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 05h 02h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag & Data Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 05h 00h 30h See below
Code Table
154
NEO Interface Developers Guide NEO v1.00
The Reset Torn Transaction Log effectively erases the content of the torn
transaction log and sets it back to an “empty” state.
Normally, this function will only be used in certification scenarios where the torn transaction
log must be put into a known state before performing a test.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 0Eh 00h 00h Varies Varies
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
CRC CRC
& Protocol Command Status Length Length
(LSB) (MSB)
Version (MSB) (LSB)
Refer to
standard
ViVOtech2\0 84h 00h 00h Varies Varies
status
values
This command, when sent, will restore the Torn Transaction Log back to its
original pristine state, as if a power up had just occurred.
This command is used to remove Torn Transaction Log entries that have
exceeded the allowed lifetime defined in tag DF811C (Maximum Lifetime of
Torn Transaction Log Record).
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 0Fh 00h 00h Varies Varies
Response Frame
Byte Byte Byte Byte Byte
Byte 0-9 Byte 10 Byte 11
12 13 14-N N+1 N+2
Header Tag Data Data
Data CRC CRC
& Protocol Command Status Length Length
(LSB) (MSB)
Version (MSB) (LSB)
155
NEO Interface Developers Guide NEO v1.00
Refer to
List of
standard
ViVOtech2\0 84h XX XX Torn Varies Varies
status
TLV’s
values
The response may contain expiring torn entries. These are returned inside a
Discretionary Data tag, as shown below:
NOTE: The terminal should execute the CLEAN command repeatedly, until no
more torn records are sent back to it. In other words, the final response will be:
Refer to the M/Chip PayPass specification for the contents of the Torn
Transaction Log Record.
Periodically, the POS should initiate a cleaning cycle and repeatedly issue the
“Clean” command (84-0F) at that point until the reader reports that the Torn
Log has been successfully purged.
How the POS accomplishes this is beyond the scope of the interface and this
document.
This command creates or modifies the TTQ and reader risk parameters associated with VCPS
2.1.1 cash transactions. Visa defines a “cash” transaction as a transaction that results in cash
156
NEO Interface Developers Guide NEO v1.00
only being returned, like a bank machine withdrawal. If the transaction is a cash transaction and
the Cash Transaction RR enable is set in the default FFF4 Visa Reader Risk Flags tag, then the
reader risk parameters provided are used instead of the default TTQ and reader risk
parameters. Once the transaction has been completed the TTQ and reader risk parameters are
returned to their default settings.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Byte 14+n-1
Header Tag & Data Data
Sub- CRC CRC
Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
TLV Data
Objects (see
ViVOtech2\0 04h 0Ch 00h 00h Cash
Transaction
TLVs)
Important: All the TLVs listed in the table below are mandatory. If any are omitted, the
command returns an error.
157
NEO Interface Developers Guide NEO v1.00
Length
Tag Data Object Name and Description Format
(Bytes)
Visa Reader Risk Flags
Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning (0 = disable, 1 = enable)
- - - - - - - X Status Check
X X X X X X X - RFU
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning (0 = disable, 1 = enable)
- - - - - - - X Transaction Limit Check
- - - - - - X - CVM Required Limit Test
- - - - - X - - Terminal Floor Limit Check
- - - - X - - - Cash Transaction Reader Risk (RR)
FFF4[1] - - - X - - - - Cashback Reader Risk (RR)
b 3
Byte 3
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
Zero Amount Test
0 = If amount is zero, transaction
- - - - - - - X disallowed
1 = If amount is zero, online cryptogram
required in the TTQ (9F66)
X Zero Amount Test. If 0, bit 1 is ignored.
X X X X X X - RFU
CVM Required Limit
FFF5[1] n12 6
Indicates the CVM required floor limit for a Visa Cash transaction.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h
Code Table
This command returns the TTQ and reader risk parameters that will be used for cash
transactions, if enabled.
158
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 0Ch 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
TLV Data
Objects (see
See Status
ViVOtech2\0 03h Cash
Code Table
Transaction
TLVs)
The only Data Objects that should be returned are the Cash Transaction TLVs sent in the Set
Cash Transactions Reader Risk Parameters command (9F66, FFF1, FFF5, and 9F1B).
This command creates or modifies the TTQ and reader risk parameters associated with a VCPS
2.1.1 cashback transaction. Visa defines a “cashback” transaction as a transaction that results in
the purchase of merchandise with cash being returned. If the transaction is a cashback
transaction and the Cashback Transaction Reader Risk enable is set in the default FFF4 Visa
Reader Risk Flags tag, then the reader risk parameters provided are used instead of the default
TTQ and reader risk parameters. Once the transaction has been completed the TTQ and reader
risk parameters are returned to their default settings.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Data Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
TLV Data
Objects
ViVOtech2\0 04h 0Dh 00h 00h (see Cash
Transaction
TLVs)
Important: All the TLVs listed in the Cash Transactions TLVs table are mandatory. If any are
omitted, the command returns an error.
159
NEO Interface Developers Guide NEO v1.00
1. If you define an Authorized Amount (9F02) that is greater than the Other Amount (9F03),
and the Other Amount is greater than zero, then the transaction will be treated as a
Cashback transaction. These parameters may be configured through configuration
commands or by including them in the Activate (02-01) command.
2. If you configure the Transaction Type (9C) using serial commands, or if you provide the
Transaction Type (9C) in the Activate Transaction command and set its value to 0x09, then
the transaction will be treated as a Cashback transaction.
3. If you provide an Other Amount (9F03) with a valid length of 6 bytes in the Activate
Transaction Command, the transaction will be treated as a Cashback transaction.
While the concept of cashback transactions may be applied to other card applications, the
command to set Reader Risk Parameters (04-0D) only applies to Visa. It allows the creation
or modification of the TTQ (Terminal Transaction Qualifiers).
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Header Tag &
Data Length Data Length CRC
Protocol Command Status Code CRC (MSB)
(MSB) (LSB) (LSB)
Version
See Status
ViVOtech2\0 04h 00 00
Code Table
This command returns the TTQ and reader risk parameters for all cashback transactions.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 03h 0Dh 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
TLV Data
Objects (see
See Status
ViVOtech2\0 03h Cash
Code Table
Transaction
TLVs)
160
NEO Interface Developers Guide NEO v1.00
The only Data Objects that should be returned are the Cash Transaction TLVs sent in the Set
Cash Transactions Reader Risk Parameters command (9F66, FFF1, FFF5, and 9F1B).
This command creates or modifies the Application Program ID and reader risk parameters for
four Dynamic Reader Limit sets. If a Visa card provides an Application Program ID that matches
one of the four programmed in the reader DRL sets and the DRL RR enable is set in the default
FFF4 Visa Reader Risk Flags tag, the Reader risk parameters for that DRL are used during the
transaction. Once the transaction has been completed the Reader risk parameters are returned
to their default settings.
Command Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n
Byte 14+n-1 15+n
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
DRL Index
ViVOtech2\0 04h 0Eh 00h 01h
and TLVs
Important: All the TLVs listed in the table below are mandatory. If any are omitted, the
command returns an error.
161
NEO Interface Developers Guide NEO v1.00
Length
Tag Data Object Name and Description Format
(Bytes)
Visa Reader Risk Flags
Byte 1
b8 b7 b6 b5 b4 b3 b2 b1 Meaning (0 = disable, 1 = enable)
- - - - - - - X Status Check
X X X X X X X - RFU
Byte 2:
b8 b7 b6 b5 b4 b3 b2 b1 Meaning (0 = disable, 1 = enable)
- - - - - - - X Transaction Limit Check
- - - - - - X - CVM Required Limit Test
- - - - - X - - Terminal Floor Limit Check
- - - - X - - - Cash Transaction Reader Risk (RR)
FFF4[1] - - - X - - - - Cashback Reader Risk (RR)
b 3
Byte 3
b8 b7 b6 b5 b4 b3 b2 b1 Meaning
Zero Amount Test
0 = If amount is zero, transaction
- - - - - - - X disallowed
1 = If amount is zero, online cryptogram
required in the TTQ (9F66)
X Zero Amount Test. If 0, bit 1 is ignored.
X X X X X X - RFU
CVM Required Limit
FFF5[1] n12 6
Indicates the CVM required floor limit for the DRL.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 04h
Code Table
This command returns the Index, Application Program ID, and reader risk parameters for the
DRL settings.
Command Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n
Byte 14+n-1 15+n
162
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
TLV Data
See Status
ViVOtech2\0 03h Objects (see
Code Table
DRL TLVs)
The response TLV Data Objects are formatted as shown in the table DRL Transaction TLVs
(Index, 9F5A, FFF1, FFF4, FFF5, and 9F1B).
Warning: DO NOT mix Protocol 1 and Protocol 2 Key Management commands. The preferred
method is to use the Protocol 2 commands.
The Key Management Protocol 2 commands are the preferred method. The Key Management
Protocol 2 commands MUST be used when doing secure communication.
The following status codes may be generated in response to the CA Public Key commands.
The following status codes are specific to the Key Manager module. Their values may have
different meanings when used with other commands.
163
NEO Interface Developers Guide NEO v1.00
This command retrieves all of the information related to a specific key. It includes the key
hash, the algorithms, and so forth. See the data definition below:
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 – 18 Byte 19 Byte 20 Byte 21
Header Tag &
Sub Length Length Key CRC CRC
Protocol Cmd RID
Cmd (MSB) (LSB) Index (LSB) (MSB)
Version
ViVOtech2\0 D0h 01h 00h 06h varies varies Varies Varies
Response Frame
Byte 19 –
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte n+1 Byte n+2
n
Header Tag & Length Length CRC CRC
Cmd Status Data
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
ViVOtech2\0 D0h Manager 00h varies varies Varies Varies
status codes
164
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 – 18 Byte 19 Byte 20 Byte 21
Header Tag &
Sub Length Length Key CRC CRC
Protocol Cmd RID
Cmd (MSB) (LSB) Index (LSB) (MSB)
Version
ViVOtech2\0 D0h 02h 00h 06h varies varies Varies Varies
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 19 – n Byte n+1 Byte n+2
Header Tag & Length Length Data CRC CRC
Cmd status
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
Manager
ViVOtech2\0 D0h 00h varies varies Varies Varies
status
codes
Checksum (20 bytes) – calculated over the key information as previously described
165
NEO Interface Developers Guide NEO v1.00
Command Frame
Bytes Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 – 18 Byte 19
19-n n+1 n+2
Header Tag &
Sub Length Length RID Key Index Key CRC CRC
Protocol Cmd
Cmd (MSB) (LSB) (5 bytes) (1 byte) Data (LSB) (MSB)
Version
See
ViVOtech2\0 D0h 03h varies varies varies varies Varies Varies
below
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Length Length CRC CRC
Cmd status
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
ViVOtech2\0 D0h Manager 00h 00h Calculated Calculated
status codes
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 – 18 Byte 19 Byte 20 Byte 21
166
NEO Interface Developers Guide NEO v1.00
Header Tag & Sub Length Length RID Key Index CRC CRC
Cmd
Protocol Version Cmd (MSB) (LSB) (5 bytes) (1 byte) (LSB) (MSB)
ViVOtech2\0 D0h 04h 00h 06h varies varies Varies Varies
The RID and Key Index for the key being deleted must be specified in the frame.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Length Length CRC CRC
Cmd status
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
Manager
ViVOtech2\0 D0h 00h 00h Calculated Calculated
status
codes
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Sub Length Length CRC CRC
Cmd
Protocol Version Cmd (MSB) (LSB) (LSB) (MSB)
ViVOtech2\0 D0h 05h 00h 00h Calculated Calculated
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Length Length CRC CRC
Cmd status
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
Manager
ViVOtech2\0 D0h 00h 00h Calculated Calculated
status
codes
The Get All CA Public RIDs command tells the reader to retrieve a list of all the RIDs.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
167
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 13-n Byte n+1 Byte n+2
Header Tag & Length Length CRC CRC
Cmd status RID(s)
Protocol Version (MSB) (LSB) (LSB) (MSB)
See Key
Manager Each RID is 5
ViVOtech2\0 D0h 00h varies Calculated Calculated
status bytes.
codes
Note: If the length returned is 0, then the communication was good, but no RIDs are stored.
The following command retrieves a list of key indices that are installed for this RID.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 – 18 Byte 19 Byte 20
Header Tag & Sub Length Length RID CRC CRC
Cmd
Protocol Version Cmd (MSB) (LSB) (5 bytes) (LSB) (MSB)
ViVOtech2\0 D0h 07h 00h 05h varies Varies Varies
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14-18 Byte 19 – n Byte n+1 Byte n+2
Header Tag & Length Length RID List of CRC CRC
Cmd status
Protocol Version (MSB) (LSB) (5 bytes) Indices (LSB) (MSB)
See Key
Manager
ViVOtech2\0 D0h 00h varies varies varies Varies Varies
status
codes
168
NEO Interface Developers Guide NEO v1.00
Module Versioning
The module versioning feature provides information about the firmware versions, and the
specification versions for specific modules, interfaces, and hardware in the reader. The information
is returned to the POS or the POS Simulator via the serial interface. Versioning of card
applications may also facilitate the tracking of changes for certification purposes.
The implementation of this feature has been simplified for the following reasons:
To align more closely with the behavior of the Advanced Reader firmware.
To make the version strings more accessible for human readers.
To facilitate maintenance of version strings.
The following subcommands are available for the Module Version command:
Sub-command Description
[1]
01h Get Product Type
[1]
Those sub-commands only work on Vendi.
Note: All other sub-commands for the Module version command have been deprecated.
However, a 0x00 in the sub-command field will return the same result as a 20h sub-command.
All other commands will return an “unknown sub-command” error.
The table below shows the information that is available and the subcommand that is used to
extract that information. The term “module” is used very loosely in the context of the firmware.
Sub-
Module Type Description Format
Command
20h The firmware version that is resident in the reader ASCII
text
For KioskIII, this verion number shows the
FW firmware version for Lab Verification, it
won’t change unless new Lab Verification is
done for the certain module.
3
Previously a subcommand “0x00” was supported. It is being deprecated. However, because some of the ViVOpay
internal utilities used that command to determine if the reader was alive, a subcommand of 0x00 will behave exactly
the same as a subcommand 0x20 and will not give an error.
169
NEO Interface Developers Guide NEO v1.00
Sub-
Module Type Description Format
Command
20h Contactless L2 Special Application ASCII
specification/version that not identified by the text
CL AppSpe
“application ID” (Example: Android Pay and Apple Pay
VAS)
20h ASCII
CL L1 L1 Interface specification/version
text
20h ASCII
UI User Interface specification/version
text
14h ASCII
SAM Secure Access Module version string
text
14h ASCII
HW Hardware platform identifier
text
14h ASCII
EEPROM The EEPROM version
text
N/A 02h Returns the processor type in TLV format TLV
The module types described above appear in the response packet for the respective sub-
command. Refer to the examples in the response packet section.
Command Frame
Response Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte12 Byte 13
Byte 13+n 14+n 15+n
Data Data CRC CRC
Header Tag Status
Command Length Length Data
& Protocol Code (MSB) (LSB)
(MSB) (LSB)
See Status
ViVOtech2\0 09h See below
Code Table
170
NEO Interface Developers Guide NEO v1.00
Product Type
Description
(hex values)
43 36 00 Vendi
55 33 00 Unipay III
55 31 00 Unipay 1.5
Command Frame
Response Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte12 Byte 13
Byte 13+n 14+n 15+n
Data Data CRC CRC
Header Tag Status
Command Length Length Data
& Protocol Code (MSB) (LSB)
(MSB) (LSB)
See Status
ViVOtech2\0 09h See below
Code Table
171
NEO Interface Developers Guide NEO v1.00
Processor Type
Description
(hex values)
4D 00 ARM Cortex-M4/ K21 Family
Processor Type
Description
(hex values)
45 00 ARM7/ LPC21xx
Command Frame
Response Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte12 Byte 13
Byte 13+n 14+n 15+n
Data Data CRC CRC
Header Tag Status
Command Length Length Data
& Protocol Code (MSB) (LSB)
(MSB) (LSB)
See Status
ViVOtech2\0 09h See below
Code Table
The Get Main Firmware Version sub-command returns a TLV string as follows:
Tag: 0xDF62
Length: Varies
Value: Varies field representing the main firmware version.
172
NEO Interface Developers Guide NEO v1.00
Response:
56 69 56 4F 74 65 63 68 32 00 09 00 00 14 DF 62 11 43 72 61 6E 65 56 65 6E
64 69 5F 31 2E 30 2E 30 00 E1 5D
Command Frame
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte12 Byte 13 Byte 15+n
Byte 13+n 14+n
Data Data CRC CRC
Header Tag Status
Command Length Length Data
& Protocol Code (MSB) (LSB)
(MSB) (LSB)
See Status
ViVOtech2\0 09h See below
Code Table
The format for hardware module version information returned is “human readable”, consisting of
fields that are separated by commas, and lines separated by carriage return and line feed
characters:
The following example shows the hardware version information subcommand and the information
being returned (in ASCII format).
Response:
56 69 56 4F 74 65 63 68 32 00 09 00 00 15 48 57 2C 56 50 56 65 6E 64 69 0D 0A 4B 32 31 46 20
52 65 76 39
ASCII Description
173
NEO Interface Developers Guide NEO v1.00
ASCII Description
HW,VPVendi<CR><LF>
Vendi
K21F Rev9
HW,VPUnipayIII<CR><LF>
Unipay III
K21F Rev9
HW,VPUnipay1.5<CR><LF>
Unipay 1.5
K21F Rev2
For KioskIII, this verion number shows the modules version for Lab Verification, it won’t
change unless new Lab Verification is done for the certain module. So it may not be
consistent with the result of “Get ViVOpay Firmware Version (29-00)” and “Get Main
Firmware Version (09-03)”
Command Frame
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte12 Byte 13 Byte 15+n
Byte 13+n 14+n
Data Data CRC CRC
Header Tag Status
Command Length Length Data
& Protocol Code (MSB) (LSB)
(MSB) (LSB)
See Status
ViVOtech2\0 09h See below
Code Table
If there is an error, the appropriate Status Code will be returned with an empty Data field (Data
Length = 0000h).
The format for module version information returned is “human readable”, consisting of fields that
are separated by commas, and lines separated by carriage return and line feed characters:
The following example shows the module version information subcommand and the information
being returned (in ASCII format).
174
NEO Interface Developers Guide NEO v1.00
Response:
56 69 56 4F 74 65 63 68 32 00 09 00 01 2A 46 57 2C 56 65 6E 64 69 20 56 31 2E 30 30 2C 2C
0D 0A 20 46 53 26 44 42 20 56 31 2E 30 30 2C 2C 0D 0A 20 43 4C 20 41 70 70 53 65 6C 2C 50
50 53 45 20 4D 6F 64 75 6C 65 2C 20 76 31 2E 30 30 2C 2C 0D 0A 20 43 4C 20 41 49 44 2C 4D
61 73 74 65 72 43 61 72 64 20 50 61 79 50 61 73 73 20 4D 2F 43 68 69 70 20 76 33 2E 30 2E 32
2C 20 56 65 6E 64 69 20 76 31 2E 30 2E 30 2C 2C 0D 0A 20 43 4C 20 41 49 44 2C 56 69 73 61
20 56 43 50 53 20 32 2E 31 2E 33 2C 20 76 30 2E 39 39 2C 2C 0D 0A 20 43 4C 20 41 49 44 2C
41 6D 65 78 20 45 78 70 72 65 73 73 50 61 79 20 33 2E 30 2C 20 76 31 2E 30 30 2C 2C 0D 0A
20 43 4C 20 41 49 44 2C 44 69 73 63 6F 76 65 72 20 44 50 41 53 20 31 2E 30 20 5A 69 70 20 33
2E 31 2E 32 2C 20 76 31 2E 30 30 2C 2C 0D 0A 20 43 4C 20 41 49 44 2C 49 6E 74 65 72 61 63
20 31 2E 35 2C 20 76 31 2E 30 30 2C 2C 0D 0A 20 43 4C 20 4C 31 2C 45 4D 56 20 34 2E 33 20
4C 31 2C 20 76 31 2E 30 30 00 8C 33
The goal of this feature is to offer support for foreign languages including those based on
graphical fonts (i.e. Chinese, Thai, Arabic…).
Four core language options built into it. Some of these are font-based; the others are ideogram-
based. The ideogram language options are stored in flash as bitmaps. The other languages use
fonts that have been stored in flash.
For example, an English message is composed of multiple small bitmaps that represent different
characters (i.e., a “Thank You” message is 8 bitmaps displayed together). The ideogram
messages are (usually) a single bitmap (i.e., the Chinese “Thank You” message is a single bitmap
displayed on the screen). See Appendix A.7 Preparing Bitmaps for Use by ILM for instruction on
working with bitmaps.
Each reader keeps four “core” languages in its firmware. This ensures that the reader can be
used in virtually any geographical area “as is”. A core language may NOT be modified or deleted
by customer/third party actions. They always exist and are always available for use.
French (fonts)
Chinese (ideograms)
175
NEO Interface Developers Guide NEO v1.00
See Set Configuration (04-00) for information on how to set a language preference.
Other Language
In addition to the Core Languages, a fifth language called “Other Language” is available. This is
a ‘slot’ in flash memory that can contain all the message bitmaps for a language.
Since this Other Language is stored in the ideogram bitmap format, it eliminates the need for
fonts, etc., for this language. The Other Language only needs a unique record for each distinct
message it must display.
At present there are twenty-two (22) predefined message types that can be displayed.
Note: Each time you configure the reader for ILM, you must download messages for all 22
indices in consecutive order. You cannot change individual messages.
The reader expects to load a simplified version of the monochrome bitmap. While data is the
same as in a standard bitmap, it must be converted to a format that the LCD hardware can use.
The standard 40-byte DIB bitmap header is discarded. It is replaced by a simplified ViVOpay
header, described in ILM Header Format.
Upside down.
Large parts of the bitmap are empty background. The LCD does not need to save this white
space, since it corresponds to off-pixel values (which are already turned off). This limited form
of image compression makes the image much smaller.
Each bitmap loaded onto a reader is expected to contain a proprietary header instead of the
standard DIB header.
This header format is shown in the following table, prefixed to the actual bitmap data:
176
NEO Interface Developers Guide NEO v1.00
Byte Description
Bitmap Length This data field contains the total number of bytes in the Bitmap Data Field.
Row Number This data field contains the row offset that this image should start at. Value is in
PIXELS.
Column Number This data field contains the column offset that this image should start at. Value is in
BYTES.
Height This data field contains the number of rows (in pixels) that this image contains.
Width This data field contains the number of columns (in bytes) that this image contains.
Type Reserved – must be set to 00h.
Bitmap Data This is the actual image data.
This block contains data used for version control of the ILM. It contains variables that identify
the particular language module that is currently stored in the system.
The language module specifies both the language name and the Country Code. This is done
because there are a number of languages (English, French, Spanish, etc.) that are shared by
multiple nations but the reader is intended to be operate in a particular country (such as
Canada).
Language Name is the name of the ILM language, using ASCII characters.
Abbreviation is the Country Code listed in ISO 3166. The format is either ASCII-2 character,
ASCII-3 character or a 3 digit decimal number. Regardless of method, it is stored in ASCII
alphanumeric characters.
The Format data field specifies the format of the Abbreviation field noted above. All follow the
specification from ISO DOC 3166.
177
NEO Interface Developers Guide NEO v1.00
Value Description/Example
01 Alpha2 (2 character) – “ES\0”
02 Alpha3 (3 character) – “ESP\0”
03 Decimal (3 digit) – “724\0”
Author is an ASCII string noting the customer that developed this language module.
Version is an ASCII string, also customer defined. It identifies this language module by version
number.
All fields are the length indicated. If (as is usually the case) the ASCII string does not occupy the
entire data field, the remaining bytes MUST be padded with zeroes.
The Language Version Information area is provided to the customer as a way to track which
language is currently loaded into the reader. It can be accessed and values are returned to the
POS. The intent is to facilitate automated updating through the POS. The POS can examine the
existing language module currently stored, and then make appropriate decisions as to its use
(i.e., updating the module).
How the Language Version Information is used by the customer cannot be defined or enforced. It
is only provided for identification and could be unused.
However, value of 00h in this area is interpreted as indicating that the ILM area of flash memory
is empty. Therefore, if the customer does edit the ILM area, they MUST update this Version
Information area as well, if only to write arbitrary non-zero values to it.
The Certificate Revocation List (CRL) contains entries that include the RID, Key
Index and Certificate Serial Numbers for cards that should be rejected. The
kernel checks the CRL for entries matching the index and serial number of the
Issuer Public Key Certificate provided by the card. If it is found the card is
rejected.
The M/Chip 3.0 application is the only application capable of using the Certificate
Revocation List feature.
178
NEO Interface Developers Guide NEO v1.00
This command returns information about the EMV revocation log. The
information returned can be used by the terminal/POS to determine how to
read the log.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 03h 00 00
Response Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13
Byte 13+n 14+n 15+n
Header Tag Data Data
CRC CRC
& Protocol Command Status Length Length Data
(LSB) (MSB)
Version (MSB) (LSB)
See Status TLV Data
ViVOtech2\0 84h
Code Table Objects
If the command is successful, the following data is returned. All fields are
encoded with MSB first.
Length
Offset Data Description
(bytes)
00h 4 Version number
04h 4 Number of records
08h 4 Size of records
This command adds a new entry to the revocation list. The new entry is added
at the end of the revocation list.
Command Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13
Byte13+n 14+n 15+n
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 04h 00 09
179
NEO Interface Developers Guide NEO v1.00
Length Example
Offset Data Description
(bytes)
00h 5 RID (packed hex format) A0 00 00 00 04
04h 1 Key Index (packed hex format) F8
08h 3 Certificate serial number (packed hex format) 00 10 00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
CRC CRC
& Protocol Command Status Length Length
(LSB) (MSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 84h 00 00
Code Table
Delete All Entries for Single Index in EMV Revocation List (84-05)
This command deletes all entries that match a key index and RID from the EMV
revocation list.
Command Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13
Byte13+n 14+n 15+n
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 05h 00 06
The data field contains RID and key index for the records to be deleted.
Length Example
Offset Data Description
(bytes)
00h 5 RID (packed hex format) A0 00 00 00 04
05h 1 Key Index (packed hex format) F8
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
CRC CRC
& Protocol Command Status Length Length
(LSB) (MSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 84h 00 00
Code Table
This command deletes all entries from the EMV revocation list.
180
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 06h 00 00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag Data Data
CRC CRC
& Protocol Command Status Length Length
(LSB) (MSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 84h 00 00
Code Table
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte13+n
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 07h 00 00
Length
Offset Data Description
(bytes)
00h 2 Size - maximum number of bytes to be retrieved (MSB first)
02h 2 Starting record4 (MSB first)
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte13+n
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 07h 00 00
4
For GR, this number must be less than 30. The first record is 0.
181
NEO Interface Developers Guide NEO v1.00
The data field will contain the maximum number of records that can fit in the
size provided in the command. No partial records are returned. The maximum
size of data bytes that can be returned is 282 bytes (12 + 9 * size of a list
record).
Length
Offset Data Description
(bytes)
00h 4 Number of records returned
04h 4 Number of records remaining in the file
08h 4 Record size
0Ch varies Revocation list records
Length Example
Offset Data Description
(bytes)
00h 5 RID (packed hex format) A0 00 00 00 03
05h 1 Key Index (packed hex format) FE
Certificate Serial Number (packed hex 00 10 00
08h 3
format)
This command deletes a specific entry from the EMV revocation list. Unlike the
commands described previously, this command deletes the specific entry that
matches the RID, the key index, and the certificate serial number.
Command Frame
Byte 14 … Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13
Byte13+n 14+n 15+n
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 84h 0Dh 00 09
The data field contains the information to select the EMV revocation list record:
Length Example
Offset Data Description
(bytes)
00h 5 RID (packed hex format) A0 00 00 00 04
05h 1 Key Index (packed hex format) F8
06h 3 Certificate Serial Number (packed hex format) 00 10 01
Response Frame
182
NEO Interface Developers Guide NEO v1.00
This command returns information about the EMV exception log. The version number, record size, and
number of records contained in the file are returned.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag
Sub- Data Length Data Length
&Protocol Command CRC (LSB) CRC (MSB)
Command (MSB) (LSB)
Version
ViVOtech2\0 84h 08 00h 00h
Response Frame
Byte 14- Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 15+n
13+n 14+n
Header Tag Data Data
CRC
&Protocol Command Status Code Length Length Data CRC (MSB)
(LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 84h 00h 00h
Code Table
Command Frame
Byte 14-
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 26 Byte 27
25
Header Tag Data Data
Sub-
&Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
See
ViVOtech2\0 84h 09 00h 0Ch
Below
183
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag
Data Length Data Length
&Protocol Command Status Code CRC (LSB) CRC (MSB)
(MSB) (LSB)
Version
See Status
ViVOtech2\0 84h 00h 00h
Codes Table
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag
Data Length Data Length
&Protocol Command Status Code CRC (LSB) CRC (MSB)
(MSB) (LSB)
Version
See Status
ViVOtech2\0 84h 00h 00h
Codes Table
184
NEO Interface Developers Guide NEO v1.00
This command deletes all entries from the EMV exception list.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag
Sub- Data Length Data Length
&Protocol Command CRC (LSB) CRC (MSB)
Command (MSB) (LSB)
Version
ViVOtech2\0 84h 0B 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag
Data Length Data Length
&Protocol Command Status Code CRC (LSB) CRC (MSB)
(MSB) (LSB)
Version
See Status
ViVOtech2\0 84h 00h 00h
Code Table
This command retrieves consecutive records from the EMV exception list.
Command Frame
Bytes 14- Bytes 16- Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 19
15 17 18
Header Tag Data Data Max
Sub- Starting CRC CRC
&Protocol Command Length Length number
Command Record (LSB) (MSB)
Version (MSB) (LSB) of bytes
ViVOtech2\0 84h 0C 00h 00h N 0-65535
Response Frame
Bytes 14-
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
13+n
Header Tag Data Data
&Protocol Command Status Code Length Length Data CRC (LSB) CRC (MSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 84h 00h 00h
Code Table
The data returned is the maximum number of transaction records that satisfy the command constrains. The
nmber of bytes returned always is an integer multiple of the transaction record size(i.e., no partial records
are returned) plus 12 decimal bytes. The maximum number of data bytes that can be returned in a single
operation is limited to 4080 bytes.
Offset Size in Bytes MSB First Description
0 4 Number of records returned
4 4 Number of records remaining in file
8 4 Record size
C n-C Exception list records
The format of an exception list record (as returned in the Response Data) is as follows:
185
NEO Interface Developers Guide NEO v1.00
The commands in this section provide the most basic capability to communicate
directly with a PICC. They provide control of the polling process, and exchange
of application protocol data units (APDU). These commands may be used to
“extend” the capabilities of the ViVOpay reader to accept cards using
application protocols that are not currently supported in the reader firmware.
The Pass-Through Mode Start/Stop command is used to enter and exit Pass-Through Mode. The
ViVOpay reader can only accept Pass-Through commands when it is in Pass-Through Mode.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 01h 00h 01h Mode
Mode
0 = Stop Pass-Through
1 = Start Pass-Through
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h 00h
Code Table
186
NEO Interface Developers Guide NEO v1.00
The Pass-Through Mode Start command must be used to enter Pass-Through Mode.
The Pass-Through Mode Stop command can only be used in Pass-Through Mode. If the reader
is not in Pass-Through mode when the Pass-Through Mode Stop command is issued, the
reader will respond with an error.
This command allows the terminal to retrieve PCD and PICC related parameters from the
ViVOpay reader.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 05h 00h 00h
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Status
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Code
Version (MSB) (LSB)
00h
See Status
ViVOtech2\0 2Ch 00h or See Table below
Code Table
0Fh
If a valid Command Frame is received from the terminal, the ViVOpay reader retrieves the
parameters from the PCD and PICC. If the parameters are retrieved successfully, the reader
returns a Response Frame with OK Status and Data containing the parameters given below. For
details on the parameters, refer to ISO 14443.
If the Command Frame contains any errors, or an error occurred while retrieving the
parameters, then the reader sends a Response Frame with an appropriate Status. No data is
returned in this case.
187
NEO Interface Developers Guide NEO v1.00
If you need to use these parameters, you should issue this command immediately after
issuing a “Poll for Token” command. This command simply reads the last parameters out of
the control block used to set parameters in the RF chip.
Once Pass-Through Mode is started, ViVOpay will not poll for any cards until the “Poll for Token”
command is received. This command tells ViVOpay to start polling for a Type A or Type B PICC
until a PICC is detected or a timeout occurs.
If a PICC is detected within the specified time limit, ViVOpay activates it and responds back to
the terminal with card related data such as the Serial Number.
If no PICC is detected within the specified time limit, ViVOpay stops polling and responds back
indicating that no card was found. No card related data is returned in this case.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14,15 Byte 16 Byte 17
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 02h 00h 02h See Below
188
NEO Interface Developers Guide NEO v1.00
Timeout2 Time in ms
0 0
1 10
2 20
: :
255 2550
Together Timeout1 and Timeout2 are used by the ViVOpay reader to calculate the Timeout i.e.
the time to wait for a PICC. For example:
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h Variable below
Code Table
The Data field contains data only if the Status Code is OK.
189
NEO Interface Developers Guide NEO v1.00
06h ISO 14443 Type B (Does not support ISO 14443-4 Protocol)
07h ISO 14443 Type A and Mifare (NFC phone)
Serial 0 or Serial Number (or the UID) of the PICC. Length depends on the Card
Number Variable Detected. If no card was detected, then a Serial Number is not returned.
Note: Most cards use a 4-byte UID, so the data field of the response is five (5) bytes long.
However, some cards with 7-byte UID’s have entered the market (for example, ViVOcard3)
and it is expected that cards with 10-byte UID’s will soon become available. All of these card
types are handled by this command.
Once Pass-Through Mode is started, ViVOpay waits until the Poll for Token command is
received. This command tells ViVOpay to start polling for a Type A or Type B PICC until a PICC is
detected or a timeout occurs.
If a PICC is detected within the specified time limit, ViVOpay activates it and responds back to
the terminal with card related data, such as the Card Type and Serial Number (UID).
If no PICC is detected within the specified time limit, ViVOpay stops polling and responds back
indicating that no card was found. No card related data is returned in this case.
Some cards have more than one type of application stored on them. These are known as Dual
Application cards. At present, all these cards have an ISO-APDU compliant application as well as
a Mifare application.
To date, the only such supported dual application card is Card Type ‘07’, supporting ISO 14443
Type A, Mifare.
For normal ViVOpay transactions (i.e., not Pass-Through Mode), these cards are automatically
handled as ISO 14443 applications.
In Pass-Through Mode, the POS controls the polling mechanism. The POS can use a standard Poll
for Token (2C-02), where Card Type ‘07’ establishes a Mifare session.
Alternatively, the POS can issue an Enhanced Poll for Token (02-0C), where Card Type ‘07’ can
establish an ISO 14443 session.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14,15 Byte 16 Byte 17
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
See Table
ViVOtech2\0 2Ch 0Ch 00h 04h
Below
190
NEO Interface Developers Guide NEO v1.00
Timeout2 Time in ms
0 0
1 10
2 20
: :
255 2550
Together Timeout1 & Timeout2 are used by the ViVOpay reader to calculate the Timeout, i.e.,
the time to wait for a PICC. For example:
191
NEO Interface Developers Guide NEO v1.00
Multiple Transaction Types in an Enhanced Poll for Token command are supported. That is, it is
possible to enable both Single PUPI Read and forced ISO 14443 polling simultaneously.
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag Data Data
Status
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Code
Version (MSB) (LSB)
00 - OK
ViVOtech2\0 2Ch 00h Variable See Table Below
?? – Fail
The data field contains data only if the Status Code is OK (i.e., = 00h). For more information on
the status, please check the Status Code Table.
Note: Most cards use a 4-byte UID, so the data field of the response is five (5) bytes long.
However, some cards with 7-byte UID’s have entered the market (for example, ViVOcard3)
and it is expected that cards with 10-byte UID’s soon becomes available. All of these card
types are handled by this command.
This command can be substituted for the standard Poll for Token in any transaction taking
place in Pass-Through Mode. Its differences in operation are noted as above; its other arguments
should be identical to those of the standard Poll for Token that it replaces.
Note: If you use an Enhanced Poll for Token command but have set all values in the
Transaction Type field to zero, then the command performs a standard Poll for Token
instead.
192
NEO Interface Developers Guide NEO v1.00
This pass-through command can be used to get the ATR received by the reader from the SAM
when a Level 1 session was established. This command applies to the SAM interfaces
(SAM1/SAM2).
Before this pass-through command can be used, a Level 1 session must have been established on
the contact interface to be used through the Enhanced Pass-through command (Poll for Token
single shot command).
Note: SAM interface is only supported in SRED devices. It is not supported in non-SRED
versions.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub- CRC
& Protocol Command Length Length Data CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 2Ch 12h 00h 01h Interface
Command Data
If a 21h or 22h is specified in the Data Field for any ViVOpay reader other than the VP5500,
the result will be the same as if a 00h was specified. That is, any GetATR command only
returns the last ATR received from the PICC.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data Data
& Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status ATR
ViVOtech2\0 2Ch 00h variable
Code Table
193
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\0 28h 01h 00h 01h Mode
Mode:
0 = Disable RF Antenna
1 = Enable RF Antenna
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 28h 00h 00h
Code Table
Turning off the antenna deactivates the RF field and returns the card to a Power Off state,
terminating any existing connection. A new “Poll for Token” command would need to be
issued to establish a new conversation with a card. Turning the antenna off and then turning
it back on is a useful way to reset the card to its Idle State where it will respond to polling
commands.
When exiting Pass-Through Mode, if the ViVOpay reader is returning to Auto Poll mode, it is
advised to issue an “Antenna Control Enable RF Antenna” command before exiting to ensure
the antenna is in the right state.
Pass-through UI Control
This command switches the specified ViVOpay LEDs off or on only when ViVOpay is in Pass-
Through Mode.
194
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14,15 Byte 16 Byte 17
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 0Ah 02h 00h 02h below
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 0Ah 00h 00h
Code Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
Buzzer
ViVOtech2\0 0Bh See Below 00h 01h
Parameter
195
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 0Bh 00h 00h
Code Table
This command allows the terminal to send, via ViVOpay, application-level APDUs to a PICC that
supports ISO 14443-4 Protocol. The PICC response is sent back by ViVOpay to the Terminal.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 03h Variable Variable APDU Out
APDU Out is the complete APDU that is to be sent to the PICC. The contents of the APDU depend
on the application residing on the PICC and are out of the scope of this document.
If a valid Command Frame is received from the terminal, ViVOpay sends the APDU data to the
PICC and receives its response. ViVOpay treats the PICC response as unknown data and does not
try to interpret it. If the operation was successful, ViVOpay returns a Response Frame with an
OK status and the response received from the PICC (APDU response).
196
NEO Interface Developers Guide NEO v1.00
If the Command Frame contains any errors, or an error occurred during communication with the
PICC, then ViVOpay sends a Response Frame with an appropriate Status. No Data is returned in
this case.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
APDU response
See Status
ViVOtech2\0 2Ch Variable Variable Or
Code Table
None
The Data field contains data only if the Status Code is OK. In this case, the data consists of
“APDU Response” i.e. the response data that was received from the PICC. The contents of the
response depend on the application residing on the PICC and are out of the scope of this
document.
For SRED device, the APDU data being received from the card/device by the reader will be
checked for sensitive data elements using rule in “Secure Pass-Through Function”. If found, the
Command will return a Parameter Not Supported error (0x06).
This command allows the terminal to send, via the ViVOpay reader, raw data to an ISO 14443
PICC that does not support ISO 14443-4 Protocol (such as Mifare Standard or Mifare Ultralight).
The PICC response is sent back by the reader to the terminal.
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
See Table
ViVOtech2\0 2Ch 04h Variable Variable
below
197
NEO Interface Developers Guide NEO v1.00
The Command Frame contains some PCD parameters and raw data. The PCD Command
Parameter is used by ViVOpay to determine what PCD function is to be carried out. The raw
data is sent to the PICC for the Transceive command, or is used for LoadKey/Authentication.
The contents of the data depend on the PICC and PCD and are out of the scope of this
document.
Note: The PCD LOADKEY and PCD AUTHENTICATE1 functions may also be performed by the
terminal directly by using the PCD Transceive Command.
198
NEO Interface Developers Guide NEO v1.00
~111 defines the number of bits of the last byte that shall be
transmitted.
A 000 indicates that all bits of the last byte shall be
transmitted.
After transmission, TxLastBits is cleared automatically.
5-7 RFU 00 Reserved for future use.
If a valid Command Frame is received from the terminal, ViVOpay sends the data to the PICC (or
carries out the appropriate action) and receives the PICC response. The ViVOpay reader treats
the response as unknown data and does not try to interpret it. If there is no error, the reader
returns a Response Frame with OK Status and the Data received from the PICC (if any). The
Response Frame also contains the result of the PCD Command (PCD Status). The PCD Status may
indicate success or an Error Code.
If the Command Frame contains any errors, or an error occurred during communication with the
PICC (such as PICC removed from the field), then the reader sends a Response Frame with an
appropriate Status. No Data is returned in this case.
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag & Data Data
Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
199
NEO Interface Developers Guide NEO v1.00
For SRED device, the Raw Data being received from the card/device by the reader will be
checked for sensitive data elements using rule in “Secure Pass-Through Function”. If found, the
Command will return a Parameter Not Supported error (0x06).
200
NEO Interface Developers Guide NEO v1.00
Assuming that ViVOpay has been put into Pass-Through Mode, a Type A PICC has been detected
using the Poll for Token command, and the terminal application has completed the transaction
with the card, an ISO 14443 HALTA command can be sent to the PICC using the PCD Single
Command Exchange command. Given below is a log of the command and data that the terminal
would send to ViVOpay and also the responses that may be received from ViVOpay.
The following serial data may be exchanged between a terminal/PC and a ViVOpay reader:
This command instructs the ViVOpay reader to send a HALT command to the card and can be
used for any Type A or Type B card. This command can only be used once the reader has been
put in Pass-Through mode and the “Poll for Token” command has indicated that a Card is
present.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag & Data Data
Sub-
Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 09h 00h 01h Card Type
Card Type:
0x01 = Type A
0x02 = Type B
201
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Length Data Length
Command Status Code CRC (MSB) CRC (LSB)
Protocol Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h 00h
Code Table
This command instructs the reader to carry out several tasks while in Pass-Through Mode. This
command is ONLY enabled in Pass-Through Mode. If the reader is not in Pass-Through Mode, the
reader ignores this command.
Note: SAM interface is only supported in SRED devices. It is not supported in non-SRED
version.
This command is based in large part on the standard Set Message Led/Buzz command. It differs
primarily in that:
Activation/Deactivation of interface
If this command is only used to set the Buzzer/LED then it works on the all readers.
There are three cases depending on the LCD Message index number:
Index 00h to 07h messages are directly display by the reader. Normally these messages are not
set through this command.
202
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
07 + N
ViVOtech2\0 2Ch 0Bh OR See Data Table
7+X+Y
The format and contents of the data field in the Command Frame are given in the following
table.
203
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
FF indicates not to set the LCD message which allows terminal to set
LED/Buzzer only.
Timeout2 Time in ms
0 0
1 10
2 20
: :
255 2550
This field is included when LCD Message Index AND 80h = True.
The field is X bytes long and consists of a simple character string. It
contains NO formatting information, ONLY text characters. If LCD
LCD String1 String1 Message and LCD String2 Message are included, then the
X
Message reserved field must be included, with LCD String1 Message appearing
immediately after it.
Note: The string must be null terminated (00) to indicate the end of
the string.
The field is Y bytes long and consists of a simple character string. It
LCD String2 contains NO formatting information, ONLY text characters.
Y
Message Note: The string must be null terminated (00) to indicate the end of
the string.
This field is present when the Single-Shot Commands Byte, Specified
Interface bit = 1:
It is 1 byte long.
Selected Allowed Interface Values are:
Z
Interface 00h = Contactless
20h = RFU
21h = SAM1 (SRED version only)
22h = SAM2 (SRED version only)
Note: If this field is not present, the firmware will default to standard
204
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
PICC behavior OR generate an error, depending upon which actions are
indicated.
Response Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag Data Data
& Protocol Command Status Code Length Length Data CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h Variable below
Code Table
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
CRC
& Protocol Command Status Code Length Length Data CRC (LSB)
(MSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h Variable below
Code Table
The message has been set to the requested message only if the Response Frame contains an OK
Status Code.
If the interface is Contactless Card, the response is as follows: If Poll for Token bit is disabled,
no data is returned in the response. It is the same for the beep indicator. If Poll for Token bit is
enabled, the response is the same as Poll for Token (2C-02) command..
The first data byte of the command lists several ‘single-shot’ commands. If the associated bit of
this field is set, the indicated discrete operation is carried out. If the bit is cleared, the
associated command is NOT carried out.
If the Poll for Token bit is enabled, the reader checks the value of the Use Specified Interface
bit.
If Use Specified Interface bit = 1, reader attempts a Poll for Token operation on the interface
specified in the Selected Interface byte
This bit turns on the RF antenna for the contactless interface by default.
If the “Use Specified Interface” bit in the Single-Shot Command byte is set, the specified
interface will be activated:
205
NEO Interface Developers Guide NEO v1.00
This turns off the RF antenna for the contactless interface by default.
If the Use Specified Interface bit in the Single-Shot Command byte is set, this bit turns off the
indicated interface:
This bit executes a Poll for Token on the Contactless interface by default.
If the Use Specified Interface bit in the Single-Shot Command byte is set, this bit performs a Poll
for Token on the indicated interface:
If the Use Independent Buzzer bit is set, the reader checks the Beep Indicator byte and calls the
standard Buzzer Command (0B 01).
If the bit is cleared, the reader checks the Buzzer byte and follows the Set Message Buzzer
command (01 02).
If the Use Independent LED bit is set, the reader reads the included LED Number and Status
bytes and then call the standard LED Command (0A 02).
If the bit is cleared, the reader reads the included LED bytes and then calls the Set Message LED
command (01 02).
This command has several elements that are mutually exclusive; the command fails if both are
enabled.
Antenna You cannot enable both the Switch On and Switch Off options.
Independent LED Reader uses the LED Bytes and calls the standard 0A 02 LED command
Enabled
Independent LED Reader uses the LED Bytes and follows the SetMsg 01 02 LED command
Disabled
206
NEO Interface Developers Guide NEO v1.00
Independent Buzzer Reader uses the Buzzer Byte and calls the standard 0B 01 Buzzer command
Enabled
Independent Buzzer Reader uses the Buzzer Byte and follows the SetMsg 01 02 Buzzer command
Disabled
LED, Buzzer and Message operations all occur simultaneously. The order in which processes are
executed depends upon the situation:
Switch Antenna On
o Switch Antenna On
o LED On
o Buzzer
207
NEO Interface Developers Guide NEO v1.00
The Enhanced Pass-Through command order for the same transaction flow becomes:
Byte 0 instructs the reader to single-shot the Turn Antenna On and Poll for Token commands
208
NEO Interface Developers Guide NEO v1.00
Byte 0 instructs the reader to single-shot the Turn Antenna Off command
Byte 1 instructs the reader to display message #4 (Thank You) on the display
Byte 2 says that give one short beep with the buzzer
Note: SAM interface is only supported in SRED devices. It is not supported in non-SRED
version.
This command allows exchange of application level APDU’s with the following:
o SAMs
An application level Command APDU meant for a card or SAM is sent to the reader in the
Command Frame, along with the interface. The reader sends the APDU to the card/SAM. The
response APDU received from the card/SAM is sent back by the reader in the Response Frame.
Before this pass-through command can be used, a Level 1 session must have been established
with a card on the interface to be used i.e., contactless (PICC) or contact (SAM1/SAM2) through
the Enhanced Pass-through command (Poll for Token single shot command).
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub- CRC
& Protocol Command Length Length Data CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
209
NEO Interface Developers Guide NEO v1.00
See
ViVOtech2\0 2Ch 13h Variable Command
Data Table
Command Data
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data Data
& Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status Response
ViVOtech2\0 2Ch 00h variable
Code Table APDU
For SRED device, if the interface is Contactless, the APDU data being received from the
card/device by the reader will be checked for sensitive data elements using rule in “Secure
Pass-Through Function”. If found, the Command will return a Parameter Not Supported error
(0x06).
This section contains serial commands that implement higher level functionality for the Mifare
Cards. These commands can only be used once the reader has been put in Pass-Through mode
and the “Poll for Token” command has indicated that a Mifare Card is present. These commands
do not work for non-Mifare cards.
This command allows the terminal to instruct the ViVOpay reader to authenticate the Mifare
Card sector containing the specified block of data. The Key to be used is also specified by the
terminal. This command is applicable only for Mifare Standard/Classic Cards.
210
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14–Byte 21 Byte 22 Byte 23
Header Tag & Data Data
Sub-
Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 06h 00h 08h See Table below
This command does not actually perform the authentication. It sets the key to be used for
the subsequent authentication. The actual authentication will be performed before the next
read or write operation. If a sector boundary is crossed, the reader will attempt to
authenticate using the key that was established with this command.
After receiving the Command Frame, the ViVOpay reader verifies the data and if the data is
valid, it interacts with the Mifare card to authenticate the sector containing the specified block.
If this operation is successful, the ViVOpay reader sends a Response Frame with an OK Status. If
the operation fails or the data was invalid, then the reader returns a Response Frame with an
appropriate Status.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h 00h
Code Table
If the card in the field is not a Mifare card, a 0Ch (Sub-command not allowed) will be returned
in the status code.
Use this command to read data from one or more blocks on the Mifare Card. The terminal can
instruct the reader to read up to 15 blocks using this command. If more than one block is
defined, then the reader automatically reads the starting block and the blocks that follow. For
multi-block reads, the sector trailer will be skipped. Sector trailer’s may be read (except that
the keys will not be visible) using a single block read.
211
NEO Interface Developers Guide NEO v1.00
If the card specified is a Mifare Standard card, then the terminal must have successfully sent at
least one Mifare Authenticate Block command to the reader for the first block to read. This
does not authenticate the block; it stores a key for use by the reader as it performs reads and
writes.
If the card specified is a Mifare Standard card and the read command specifies a single block
read, then the reader tries to read the data regardless of whether the block is a sector
trailer block.
If the card specified is a Mifare Standard card, and the read is a multi-block read, then the
reader skips reading the sector trailer blocks that contain the Keys (since the Keys cannot be
read). Skipped blocks are not included in the block count. While reading blocks in a Mifare
Standard Card, if the read requires access to the next sector, then the ViVOpay reader carries
out authentication for this block/sector automatically by using the Key Type and Key Value that
were set in the Mifare Authenticate Block command to authenticate the sector for the Starting
Block via the Mifare Authenticate Block command.
Block reads and writes that span multiple sectors assume that the keys to authenticate those
sectors are the same as the one that was set using the Mifare Authenticate Block command.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14,15 Byte 16 Byte 17
Header Tag & Data Data
Sub-
Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 07h 00h 02h See Table below
After receiving the Command Frame the ViVOpay reader verifies the parameters. If the
parameters are valid, then it reads the data from the card. If this operation is successful, the
ViVOpay reader sends a Response Frame containing a Status of OK and the data that was read. If
the operation fails or one or more parameters were invalid, then the reader sends a Response
Frame containing an appropriate Status, but no data.
212
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Status
& Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Code
Version (MSB) (LSB)
Data Read from
See Status Card
ViVOtech2\0 2Ch Variable Variable
Code Table OR
None
If the Status is OK, then the Data Length depends on the number of blocks read and the card
type.
DataLen = Blocks Read * (Bytes per Block for Card).
If there was an error or no data was read, then the Data Length is zero.
For SRED device, the data being received from the card/device by the reader will be checked
for sensitive data elements using rule in “Secure Pass-Through Function”. If found, the
Command will return a Parameter Not Supported error (0x06).
Mifare Ultralight cards differ from Mifare Cards. For Mifare Standard Cards the block size is 16
bytes. However, for Mifare Ultralight Cards the block (page) size is 4 bytes. When reading
Mifare Ultralight cards, Block Count is taken to mean the number of 16 byte blocks (each
consisting of four 4-byte pages). However, for Mifare Ultralight cards, the Start Block
represents a 4-byte page.
For example, if the card is a Mifare Ultralight card, and a read is requested starting at Block 3
and Block Count is 1 then 16 bytes of data are returned consisting of Page # 3, 4, 5 & 6. And if a
read is requested starting at Block 3 and Block Count is 2 then 16*2=32 bytes of data are
returned consisting of Page # 3, 4, 5, 6, 7, 8, 9, and 10.
Typically, Mifare Ultralight Cards are read by the ViVOpay reader, but are not written. This
is because they are typically used for disposable applications such as ticketing.
Use this command to instruct the ViVOpay reader to write data to one or more blocks on the
Mifare Card. The terminal can instruct ViVOpay to write up to 15 blocks of data using this
command. If more than one block is defined, then the reader automatically writes to the
starting block and the blocks that follow.
The block size depends on the type of Mifare card being accessed. For Mifare Standard Cards the
block size is 16 bytes. For Mifare Ultralight Cards the block size is 4 bytes.
213
NEO Interface Developers Guide NEO v1.00
If the card specified is a Mifare Standard card, then the terminal must have successfully sent at
least one Mifare Authenticate Block command to the reader for the first block to write. This
does not authenticate the block; it stores a key for use by the reader as it performs reads and
writes.
If the card specified is a Mifare Standard card and the write command is a single block write,
the reader tries to write the data regardless of whether the block is a sector trailer block or
not.
If the card specified is a Mifare Standard card, and the write is a multi-block write, then the
reader skips writing to the sector trailer blocks that contain the Keys. Skipped blocks are not
included in the block count. While writing blocks to a Mifare Standard Card, if the write requires
access to the next sector, then the ViVOpay reader carries out authentication for this
block/sector automatically by using the Key Type and Key Value that were used by the terminal
to authenticate the sector for the Starting Block via the Mifare Authenticate Block command.
Block reads and writes that span multiple sectors assume that the keys to authenticate those
sectors are the same as the one that was set using the Mifare Authenticate Block command.
Command Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag & Data Data
Sub- CRC
Protocol Command Length Length Data CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 2Ch 08h Variable Variable See Table below
After receiving the Command Frame the ViVOpay reader verifies the parameters. If the
parameters are valid, it writes the data to the card. If this operation is successful, the ViVOpay
reader sends a Response Frame with a Status of OK.
214
NEO Interface Developers Guide NEO v1.00
If the Command Frame is invalid or the write operation fails then the reader sends a Response
Frame with an appropriate Status.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Length Data Length
Command Status Code CRC (MSB) CRC (LSB)
Protocol Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h 00h
Code Table
Use this command to instruct the ViVOpay reader to carry out Debit, Credit and Backup
operations on value blocks in a Mifare card. These functions require that the related data blocks
be formatted as a value block and that operations and keys used match the defined Access
Conditions for that sector.
A Debit function subtracts a given amount from a Mifare value block and stores the result in the
same block. A Credit function adds a given amount to a Mifare value block and stores the result
in the same block. A Backup function reads a value block and stores a copy of it in another value
block in the same authenticated sector.
This command is flexible in that it allows any number of Debit, Credit or Backup function blocks
to be embedded within one Command Frame in any order, with or without keys specified, as
long as the total number of bytes is within the size capability of one Pass-Through command.
Operations are performed in the order they are specified.
For instance, a Purse Command could simply contain one Debit function to debit a value block
by a specified amount. If a key and key type is included they are used to authenticate the block
and the debit function is performed. If no key information is included the key and key type used
in the previous Mifare Authentication command is used.
In another case, the Purse Command could contain a Credit function to credit a value block by a
specific amount and a Backup function to backup the resulting balance to another value block
somewhere on the card. Each command could include a specific key for the block being
addressed, or omit the key information and let the reader use the last known key.
215
NEO Interface Developers Guide NEO v1.00
Note: The default key and key type are overwritten each time a key is encountered while
processing a Purse Command. The initial default values are those set when the Mifare
Authenticate Block command is received. That key type and key are used until another key is
encountered, at which point the new key becomes the default key for subsequent
transactions. If purse commands are used without key information then the terminal must
have successfully sent at least one Mifare Authenticate Block command to the reader for the
first block.
Warning: Multiple ePurse command blocks can be included in one command; each command
contains a count of the number of command blocks included in the command.
If the count of command blocks specified is not equal to the actual number of command
blocks included in the command, an error may or may not be returned to the user.
If the count of command blocks is greater than the actual number of command blocks
specified, all command blocks available are acted upon and an error is returned.
If the count of command blocks is less than the actual number of command blocks in the
command, only the number of commands specified in the count is acted upon but no error is
returned.
Command Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
14+n-1
Header Tag & Data Data
Sub-
Protocol Command Length Length Data CRC (MSB) CRC (LSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 2Ch 0Ah Variable Variable See Table below
216
NEO Interface Developers Guide NEO v1.00
217
NEO Interface Developers Guide NEO v1.00
Mifare ePurse backup commands are distinguished from Debit/Credit operations by the value
in the Command Length field.
After receiving the Command Frame the ViVOpay reader verifies the parameters. If the
parameters are valid, it performs the operations specified in the order in which they appear
within the Purse Command Data Frame.
Note: Although it is possible to include multiple value operations (Debit or Credit) in one
command, because there is only a single one-bit flag to specify the Debit or Credit mode all
value commands within one Purse Command must be either Debit or Credit functions.
(However, backup operations may be included because they are distinguished by the
command length field).
If all operations are successful, the ViVOpay reader sends a Response Frame with a Status of OK.
If the Command Frame is invalid or any of the operations fail then the reader sends a Response
Frame with an appropriate Status.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Length Data Length
Command Status Code CRC (MSB) CRC (LSB)
Protocol Version (MSB) (LSB)
See Status
ViVOtech2\0 2Ch 00h 00h
Code Table
Examples
Application: Perform a Debit operation. Subtract 2000 from value block number 20H using last
key specified. Blue shaded area shows the Debit function block within the Purse Command
Frame.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
218
NEO Interface Developers Guide NEO v1.00
Mode,
Header Tag
Sub- Data Length Data Length Card Type, Debit Cmd
& Protocol Command Value Block
Command (MSB) (LSB) Operation Length
Version
Count
Application: Perform a Credit operation. Add 100 to value block number 20H specifying Key A.
Blue shaded area shows the Credit function block within the Purse Command Frame.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Mode,
Header Tag
Sub- Data Length Data Length Card Type, Credit Cmd
& Protocol Command Value Block
Command (MSB) (LSB) Operation Length
Version
Count
64 00 00 00 01 Ka Kb Kc
Kd Ke Kf
Application: Perform a Debit operation with Backup. Subtract 300 from value block number 20H
specifying Key A and backup the result to value block number 21H using the same key. Blue
shaded area shows the Debit function block and yellow shaded area shows the Backup function
block within the Purse Command Frame.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Mode,
Header Tag
Sub- Data Length Data Length Card Type, Debit Cmd
& Protocol Command Value Block
Command (MSB) (LSB) Operation Length
Version
Count
2Ch 01 00 00 01 Ka Kb Kc
219
NEO Interface Developers Guide NEO v1.00
Application: Perform a Backup (value copy) operation only. Copy the value amount from block
1CH to block 1DH specifying Key B. Yellow shaded area shows the Backup function block within
the Purse Command Frame.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Mode,
Header Tag
Sub- Data Length Data Length Card Type, Backup Backup
& Protocol Command
Command (MSB) (LSB) Operation Block Cmd Length
Version
Count
Primary
Key Type Key
Block
1Ch 02h Ka Kb Kc Kd Ke Kf
Byte 25 Byte 26
This section contains serial commands that implement higher level functionality for the NFC
Cards. These commands do not work for non-NFC cards.
This command uses Data[0] in command data field to implement different functions. This
command should be used in Pass-Through mode and command with “Poll for a NFC Tag” data
should be used first. Command with other data can only be used once the “Poll for a NFC Tag”
command has indicated that a NFC tag is present.
NFC Commands
Byte 14
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 ...Byte Byte 14+n Byte 15+n
13+n
220
NEO Interface Developers Guide NEO v1.00
Individial commands in NFC command set are distingushed as to parameters in Data field.
Data[0]: FFh
Poll for a NFC Tag 2
Data[1]: Timeout (in second)
Data[0]: 12h
Tag1 Static Read a Byte 2
Data[1]: Address of the data
Data[0]: 13h
Data[0]: 14h
Data[0]: 15h
Tag1 Dynamic Read a
2
Segment
Data[1]: Address of the segment
Data[0]: 16h
Tag1 Dynamic Read 8 Bytes 2
Data[1]: Address of the data
Data[0]: 17h
Data[0]: 18h
Tag1 Dynamic Write 8 Bytes
10 Data[1]: Address of the data
NE
Data[2]~Data[9]: Data to be written
221
NEO Interface Developers Guide NEO v1.00
Data[0]: 22h
Data[0]: 23h
Tag2 Select Sect 2
Data[1]: Sect number
Data[0]: 41h
Data[0]: 42h
Data[0]: 0x81
Tag4 Command variable
Data[1]~Data[n]: data
NFC Response
Byte 14
Byte
Byte 0-9 Byte 10 Byte 11 Byte 13 ...Byte Byte 14+n Byte 15+n
12
13+n
Header Tag Data Data
& Protocol Command Status length length Data CRC(MSB) CRC(LSB)
Version (MSB) (LSB)
See Status See
ViVOtech2\0 2Ch 00 00
Code Table Below
222
NEO Interface Developers Guide NEO v1.00
For details on these data field, refer to the relevant NFC Specifications.
For SRED device, if the command isn’t “Poll for a NFC Tag”, the data being received from the
card/device by the reader will be checked for sensitive data elements using rule in “Secure
Pass-Through Function”. If found, the Command will return a Parameter Not Supported error
(0x06).
223
NEO Interface Developers Guide NEO v1.00
Any TLV or structure on the SRED list of protected financial data will cause the Pass-Thru
command response to return a Parameter Not Supported status (0x06) with no data returned.
In Secure Pass-Thru SAM access is always clear data. The SAM will never contain sensitive
financial data.
Cmd-Sub Name
2C-03 Exchange APDU
2C-04 PCD Single Command Exchange
2C-07 Read Mifare Block
2C-13 Exchange APDU
2C-40 NFC Commands
This section provides detailed instructions which are the primary methods used to determine if a
card contains sensitive financial data. Whether the data received by the reader from the card is
raw data, an APDU or Mifare data, all data will be parsed for recognizable sensitive financial
data as defined in “SRED List of Protected Financial Data”.
224
NEO Interface Developers Guide NEO v1.00
If the data does not follow the standard BER-TLV format then the data is evaluated to determine
if an image similar to Track data can be found.
Track 1 ASCII:
Start Sentinel (STX= “%”)
End Sentinel (ETX = “?”)
Format Code (FC = “B”)
Separator after the PAN (FS = “^”)
Max PAN 19 digits. Minimum Card Brand PAN size is 12.
Max record length 79 characters
1. If the Start Sentinel is found, followed by the Format Code, with the Separator within 12 to
19 characters after the Format Code, then sensitive data has been found.
2. If no Start Sentinel is found, but the Format Code followed by the Separator within 12 to 19
characters after the Format Code is found, then sensitive data has been found.
3. If no Start Sentinel and no Format code found, but the Separator is found within 12 to 19
characters from the start of data, then sensitive data has been found.
Examples:
Found with Test #1 – PAN length >11 < 20
%B6279257749132343^TEST CARD/VIVOPAY^10128130072?
Track 2 ASCII:
Start Sentinel (STX= “;”)
End Sentinel (ETX = “?”)
Separator after the PAN (FS = “=”)
Max PAN 19 digits. Minimum Card Brand PAN size is 12.
Max record length 40 characters
1. If the Start Sentinel is found, followed by the Separator within 12 to 19 characters after the
Start Sentinel, then sensitive data has been found.
2. If no Start Sentinel, but the Separator is found within 12 to 19 characters from the start of
data , then sensitive data has been found.
Examples:
Found with Test #1 – PAN length >11 < 20
;6279257749132340=10128130072104350000?
Track 3 ASCII:
Start Sentinel (STX= “;”)
End Sentinel (ETX = “?”)
Format Code (FC = “0x00 – 0x99”)
Separator after the PAN (FS “=”)
225
NEO Interface Developers Guide NEO v1.00
1. If the Start Sentinel is found, and the Format Code is found, followed by the Separator
within 12 to 19 characters from the Format Code, then sensitive data has been found.
2. If no Start Sentinel, but the Format Code is found and the Separator is found within 12 to 19
characters from the Format Code, then sensitive data has been found.
3. If no Start Sentinel, and no Format Code is found, but the Separator is found within 12 to 19
characters from the start, then sensitive data has been found.
Examples:
Found in Test #1 – PAN length >11 < 20
;011234567890123445=724724100000000030300XXXX040400099010=******==1=00?
226
NEO Interface Developers Guide NEO v1.00
Take time to familiarize yourself with certain key differences in device usage that come into
play when secure communications are required (as described below).
Burst mode
When encryption is enabled, burst mode is always OFF. When encryption is enabled, reader will
turn the burst mode to be OFF automatically. When encryption is enabled, if user wants to make
burst mode to be ON/AUTO EXIT through “Set Configuration (04-00)” command, reader will
respond with an error code.
Data Output
When secure communications are enabled, all magstripe data output (MSR) will be encoded
according to the rules described in ID TECH P/N #80000403-001, Enhanced Encrypted MSR Data
Output Format. All other encrypted output will conform to ID TECH P/N 80000404-001, ID Tech
Encrypt Data Format in Command/Response Specification for IC Communication. The former
(encrypted MSR) is a fixed-layout data encoding scheme with ID TECH proprietary semantics for
flag values, field meanings, etc. The latter (encrypted EMV/ICC) is a TLV-based format using
industry standard TLV (tag/length/value) encoding conventions, with a mix of industry-standard
EMV tags and ID TECH proprietary tags.
For further information (including actual data in the two output styles), see the appendix called
TDES Data Encryption Examples, and/or consult the appendix on Enhanced Encrypted MSR Data
Output Format.
Encryption Algorithms
The reader uses TDES encryption by default. During the authentication phase, the reader will
use TDES in ECB mode. Once the reader and terminal are authenticated, the data field in the
command/response frames is encrypted with Cipher Block Chaining (TDES-CBC).
Only the data fields of the ViVOpay command/response frames are encrypted. The 14-byte
preamble consisting of the command header, command, sub-command, and status fields, will
not be encrypted.
227
NEO Interface Developers Guide NEO v1.00
Data is encrypted using TDES-CBC. Once a session is established, the initial vector will never be
reset to its initial value until a new session is established. Thus, the chaining extends across
packets and ensures the order of packets. The result is that a session is encrypted in a
unique/per-instance non-repeatable way, to make replay attacks all but impossible.
Padding is usually required for the CBC algorithm, because TDES will require that data blocks be
a multiple of 8 bytes long, for example (whereas AES will require data blocks to be a multiple of
16 bytes). Since the length field in the ViVOpay frame indicates the length of the encrypted
data field, there must be a way to recognize the actual data (in order to recover the data as it
existed before padding).
1. Do DLE deletion.
2. Do decryption using CBC.
3. Remove pads.
If the data is a multiple of 8, then there will be eight pads of 0x08.
If the data was one less than a multiple of 8, then there is one pad of 0x01.
For all other cases, there are n pads of 0x0n, where n is between 1 and 8. The following
examples illustrate padding:
228
NEO Interface Developers Guide NEO v1.00
multiple of 8 bytes)
Last byte = 01h
This command exists to specify the encryption type of Account DUKPT Key, and MUST be used
before the initial loading of the Account DUKPT Key into the device. The encryption type
CANNOT be changed once the Account DUKPT Key is present. It must remain either TDES or AES.
Note: This command is only supported in NSRED device. In SRED device, only TDES algorithm
is used to encrypt transaction output sensitive data.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte16
Header Tag & Data Data
Sub- CRC CRC
Protocol Command length length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
Encryption
ViVOtech2\0 C7h 32h 00 01
Type
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data length
Protocol Command Status length CRC(MSB) CRC(LSB)
(LSB)
Version (MSB)
See Status Code
ViVOtech2\0 C7h 00 00
Table
Note: This command is only supported in NSRED device. In SRED device, only TDES algorithm
is used to encrypt transaction output sensitive data.
229
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte15
Data
Header Tag & Sub- Data length CRC CRC
Command length
Protocol Version Command (MSB) (MSB) (LSB)
(LSB)
ViVOtech2\0 C7h 33h 00 00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte14 Byte 15 Byte16
Header Tag & Data Data
CRC CRC
Protocol Command Status length length Data1
(MSB) (LSB)
Version (MSB) (LSB)
See Status Encryption
ViVOtech2\0 C7h 00 01
Code Table Type
TDES:
56 69 56 4F 74 65 63 68 32 00 C7 33 00 00 1A 9B
56 69 56 4F 74 65 63 68 32 00 C7 00 00 01 00 AC 7F
AES:
56 69 56 4F 74 65 63 68 32 00 C7 33 00 00 1A 9B
56 69 56 4F 74 65 63 68 32 00 C7 00 00 01 01 BC 5E
This command is meant to be used once (only), to turn encryption ON permanently. It elevates
the security status of the device. This is meant to be an irreversible event.
If user sends “Encryption Enable” command, reader will response OK and turn Encryption ON
only when an Account DUKPT Key is present and valid, otherwise reader will response error and
the setting doesn’t take effect.
Note: This command is supported only in non-SRED devices. In SRED devices, the reader is
always encryption-enabled and this command is unsupported.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte16
Header Tag & Sub- Data Data CRC CRC
Command Data
Protocol Command length length (MSB) (LSB)
230
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data length
Protocol Command Status length CRC(MSB) CRC(LSB)
(LSB)
Version (MSB)
See Status Code
ViVOtech2\0 C7h 00 00
Table
When Data Encryption is disabled, device will always output plaintext data
When Data Encryption is enabled, device will output data as follows:
(1) When Account DUKPT Key does not exist, the commands below will respond status code
0x90 and no data.
(2) When Account DUKPT Key exists and is valid, the commands below will respond
encrypted data.
(3) When Account DUKPT Key exists and exhausted, the commands below will respond
status code 0x91 and no data.
Commands:
(1) Activate Transaction Command (02-01)
(2) Get Transaction Result Command (03-00)
Note: This command is only supported in Non-SRED version devices, not supported in SRED
version devices.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte15
Data
Header Tag & Sub- Data length CRC CRC
Command length
Protocol Version Command (MSB) (MSB) (LSB)
(LSB)
ViVOtech2\0 C7h 37h 00 00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte14 Byte 15 Byte16
Header Tag & Data Data
CRC CRC
Protocol Command Status length length Data1
(MSB) (LSB)
Version (MSB) (LSB)
See Status Encryption
ViVOtech2\0 C7h 00 01
Code Table Enable Flag
231
NEO Interface Developers Guide NEO v1.00
This command allows setting parameters that determine encrypted output from MSR sessions.
Use it to force encryption data output to include various kinds of data per Enhanced Encrypted
MSR Data Output When Encryption is Turned On with C7-38 Command. Consult the table in that
Appendix (A.13) to see the types of output that can occur.
Command Frame
Byte 14 … Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n
Byte 14+n-1 15+n
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
MSR Secure
ViVOtech2\0 C7h 38h 00h 05h Parameters
TVL
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Status CRC CRC
& Protocol Command Length Length Data
Code (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\ See Status
C7h
0 Code Table
MSR Secure
ViVOtech2\
C7h 38h 00h 05h Parameters
0
TVL
232
NEO Interface Developers Guide NEO v1.00
MSR Secure
ViVOtech2\0 C7h 39h 00h 03h Parameters
TVL
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Status CRC CRC
& Protocol Command Length Length Data
Code (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\ See Status
C7h 00h 05h TLV
0 Code Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte14 Byte 15 Byte 16 Byte17
Header Tag Data Data
Sub- CRC CRC
& Protocol Command length length Data1 Data2
Command (MSB) (LSB)
Version (MSB) (LSB)
Timeout Timeout
ViVOtech2\0 C7h 2Dh 00 02
(MSB) (LSB)
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data length
Protocol Command Status length CRC(MSB) CRC(LSB)
(LSB)
Version (MSB)
See Status Code
ViVOtech2\0 C7h 00 00
Table
Timeout is in second, value scope is [120, 3600]. If timeout, remote key injection is canceled.
Command Frame
233
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte14 Byte 15 Byte 16 Byte17
Header Tag Data Data
CRC CRC
& Protocol Command Status length length Data1 Data2
(MSB) (LSB)
Version (MSB) (LSB)
See Status Timeout Timeout
ViVOtech2\0 C7h 00 00
Code Table (MSB) (LSB)
Timeout is in second, value scope is [120, 3600]. If timeout, remote key injection is canceled.
This command checks and returns the state of the DUKPT key associated with each slot.
Slot 2: Admin DUKPT Key (NSRED and SRED device support, use in Remote Key Injection)
Slot 3: MAC DUKPT Key (SRED device support, for future use)
Slot 5: Account DUKPT Key (NSRED and SRED device support, use to encrypt transaction output
sensitive data)
Command Frame
Byte 14 ~
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 81h 02h 00h 00h None
Response Frame
Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 ~ 13+n
14+n 15+n
Header Tag Data Data
CRC CRC
& Protocol Command Status Code Length Length
Data (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\ See Status 00h or Nothing
81h 00h
0 Code Table 0Ch or Key States
If successful, the returned Status Code is 00h and the response data will contain the key states
for 12 slots. Most of these slots are reserved for future use. Only the supported slot indexes will
contain key states. The format of the data returned on success is given below.
234
NEO Interface Developers Guide NEO v1.00
Length
Data Item Description
(bytes)
Key States 12 (0Ch) This data item contains the Key States for 12 DUKPT Key slots.
Each byte represents the Key State for a single slot.
Possible values for each Key State are:
00h: Unused (Slot is supported but no key injected)
01h: Valid (A valid key is available in this slot)
02h: End of Life (The key on this slot has reached end of life)
FFh: Not Available (This slot is not supported)
If the command is not successful, then the Status Code will not be 00h and no data is returned.
This command checks whether a valid DUKPT key is stored at the specified slot and if a valid key
is found then some basic information related to the type of key is returned. The actual Key data
is never returned.
This command can be used to check whether a key is already present before injecting a key in a
slot to prevent overwriting an existing DUKPT key.
Slot 2: Admin DUKPT Key (NSRED and SRED device support, use in Remote Key Injection)
Slot 3: MAC DUKPT Key (SRED device support, for future use)
Slot 5: Account DUKPT Key (NSRED and SRED device support, use to encrypt transaction output
sensitive data)
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 81h 04h 00h 01h Key Slot
Response Frame
Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14-13+n
14+n 15+n
Header Tag Data Data
CRC CRC
& Protocol Command Status Code Length Length
Data (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\ See Status Nothing
81h 00h variable
0 Code Table or Key States
235
NEO Interface Developers Guide NEO v1.00
If the Command Frame is valid, then the Status Code will be OK and the response data will
contain the key state and other key related data as shown in the following table. If the
Command Frame is not valid, then the Status Code will not be OK and no data will be returned.
Response Data (When Status is OK)
Byte Field Name Description Encoding
0 Key State Key State for the DUKPT key associated with the specified slot. Binary
Possible values for the Key State are:
00h: Unused (Slot is supported but no key injected)
01h: Valid (A valid key is available in this slot)
02h: End of Life (The key on this slot has reached end of
life)
FFh: Not Available (This slot is not supported)
Mandatory Field.
1-2 Key Usage ‘K0’ – Key Encryption or Wrapping 2AN
‘P0’ – PIN Encryption
‘D0’ – Data Encryption
‘M0’ – MAC Verification
Present only if key state indicates a valid key.
3 Algorithm ‘T’, hex 0x54. Triple DES 1AN
‘D’, hex 0x44. Single DES
Present only if key state indicates a valid key.
4 Mode of Use 'N' No special restrictions 1AN
'E' Encryption only
'D' Decryption only
Present only if key state indicates a valid key.
5-6 Key Version ‘00’, hex 0x3030. 2AN
Number If set to ‘00’ key version number is not used. Key version is not
supported in this version of the specifications
Present only if key state indicates a valid key.
Host can use this command to retrieve the KSN of the selected DUKPT key.
Slot 2: Admin DUKPT Key (NSRED and SRED device support, use in Remote Key Injection)
Slot 3: MAC DUKPT Key (SRED device support, for future use)
Slot 5: Account DUKPT Key (NSRED and SRED device support, use to encrypt transaction output
sensitive data)
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte 16
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Key Index
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 81h 0Ah 00h 01h Key slot
Response Frame
236
NEO Interface Developers Guide NEO v1.00
Byte 14
Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 … Byte
14+n 15+n
14+n-1
Header Tag
Data Length Data Length CRC CRC
& Protocol Command Status Code Data
(MSB) (LSB) (MSB) (LSB)
Version
ViVOtech2\0 81h Status Code 00h variable KSN
If the Command Frame is valid, the slot was supported and the DUKPT Key is valid, the Status
Code will be OK and the data portion will have the content described below. If the Command
Frame is not valid or the slot is unsupported or DUKPT Key is not valid, then the Status Code will
not be OK and no data will be returned.
237
NEO Interface Developers Guide NEO v1.00
This firmware supports the EMV Contactless Communication Protocol Specification. While the
EMV specification defines collision detection, there are often physical constraints which prevent
collision detection resolving within the timing limits outlined in the specification.
For instance, multiple cards in the field cannot always be detected reliably. If a particular card
responds more quickly to RF polling, or if a card has a stronger antenna, then the signal will lock
to that card. (This problem is not limited to ID TECH equipment.) Card geometry can also be a
major factor in collision detection.
The following bullets explain some of the difficulties associated with multiple card
presentation:
When a single type A and single type B card are presented side-by-side the reader will
detect collisions without much difficulty:
When two cards are stacked on top of one another, the faster card or the card that is closer
to the PCD will be activated. This is because the slower card or the card that is further from
the PCD suffers insufficient power, interference from the other card, or timing that falls
outside the boundaries defined in the EMV specification.
Presenting two cards of the same type side by side (e.g. A || A) will suffer from the same
problems described in the previous bullet, because the RF power draw from one card can
negatively impact the communication and/or power of the other card.
238
NEO Interface Developers Guide NEO v1.00
The six possible multiple card presentation scenarios are listed in the table below.
Note: Card Type B / B (scenarios 5 & 6) are inherently difficult to detect. When multiple
type B cards are presented they should detune one another. If there is minimal detuning then
no collision would be detected.
The firmware features two mutually-exclusive collision detection modes, Standard Collision
Detection and Improved Collision Detection, which are described in the subsections below.
Media removal events are handled as per the EMEA requirements for collision. When detecting a
collision a media removal UI event is triggered (all LEDs off, 2 tone alert, and appropriate
message for LCD equipped units), a small delay is then introduced before returning to polling.
Note:
It is important to understand that the procedure outlined above will repeat if the collision is
not resolved. Also, the media removal event only operates when the EMEA UI is enabled (tag
'FF F8' = '03'). Finally, this procedure occurs automatically without interaction from the
integrated system and will operate for the duration of the Timeout period, as set by Activate
Transaction.
239
NEO Interface Developers Guide NEO v1.00
The reader will then continue to retry the transaction; until either, the collision issue has been
resolved (and a transaction takes place), or until the transaction timeout expires. In the latter
case, the timeout will contain the timeout status (0x08) and timeout cause in the data field
(0x21, collision error).
Note: In this mode, if a collision is detected, the reader will interpret further
‘Communication Error’ or ‘Card Not Present’ events as being caused by collision.
1. While polling, the reader will attempt to find the PICC using the standard polling
method.
2. If a collision is detected, the reader will abort the transaction and notify the POS.
3. It will report this with an error in the data field of its response (0x21, collision error).
Tag DF7F enables/disables Improved Collision Detection. When this tag is set to zero (default
value), Improved Collision mode is disabled. When this tag is set to another value (1-255),
Improved Collision mode is enabled.
When Improved Collision mode is enabled, the DF7F tag value defines the number of successful
sequential polling attempts required for signal lock. For example, if tag DF7F = 3, then the
reader must detect a card successfully three times in a row before the firmware decides this is a
successful polling attempt. Given the same conditions, the reader must fail to detect a card
three times in a row before the firmware decides this is a 'card not present' polling attempt.
In this new mode, the collision scenarios have been improved in the following manner:
4. Increased sensitivity to improve collision detection generally. Previously, silent card and
garbled receive were not identified in the same manner as a standard collision.
5. If the transaction times out due to any of the collision methods described previously, the
serial response will reflect this in its error state, with Status Code 0x08 (Time Out) and Error
Code 0x21 (Collision Error).
240
NEO Interface Developers Guide NEO v1.00
Example
Assume a reader has enabled Improved Collision Detection with tag DF7F = 3. When two cards
are placed within view of the reader, the following polling results are obtained.
Polling Attempt 1 2 3
Polling Result OK OK L1C
These results show that the first and second polling attempts are successful; but, the third
polling attempt reports an EMV L1 collision (e.g. a slower or weaker signal). This collision
detection would result in immediate termination of the transaction and the reader returning a
collision status code. In contrast, if Standard Collision Detection mode was enabled instead,
then the reader would accept the first attempt and the transaction would proceed with the first
card detected.
241
NEO Interface Developers Guide NEO v1.00
The Boot Loader controls initial operation after reset and also provides the means to program
the Flash memory,
Kiosk III has two types of products: Non-SREd and SRED. This boot loader can be used in both
types of Kiosk III device.
Description
KIOSK III Boot Loader controls initial operation after reset and also provides the means to
program the flash memory which operate over both RS232 and USB interface.
KIOSK III uses a freescale K21 chip with 1M bytes embedded flash. The flash is divided into three
zones: boot-loader, configuration and application. As for boot-loader zone, it is divided into
three zones: BIM(boot image manager), boot-loader 1 and boot-loader 2. BIM cannot be
updated, application can be updated by boot-loader, boot-loader1 can be updated by boot-
loader2, and boot-loader2 can be updated by boot-loader1.
Boot loader code is executed every time the reader is powered on or reset.
If a valid user program is not found, the firmware downloader is invoked. If a valid user program
is found, then the execution control is transferred to it after 3 seconds waiting, during this
waiting time, user can invoke firmware downloader by sending boot load commands.
The firmware data to be updated to device is protected by firmware RSA key, which is RSA key
under RSA-2048. Firmware data is encrypted by firmware RSA private key, and must be
authenticated by firmware RSA public key when the data are all loaded into device. The
updated firmware data won't be valid before authentication succeed. The firmware RSA public
key is injected into device during manufacturing.
Boot Procedure
After any reset or power up the Kiosk III boot loader is the first code executed. Boot loader then
check whether the main application exists. If the application exists, boot loader waits 3 seconds
for user to send boot load commands. If user send boot load commands inside the waiting time,
the firmware downloader is invoked and a firmware image is to be downloaded. If user does not
send boot loader commands inside the waiting time, then boot loader passes control to the main
application. If the main application does not exist then boot loader invoke the firmware
downloader and waits for a firmware image to be downloaded.
After power up or reboot, boot-loader gets the control of the chip, and then does the following
tasks in order.
a) BIM reads and compares boot-loader1 and boot-loader2 flag, selects the newer and passes
the control to it.
b) The selected boot-loader check the reason of reboot. If the reboot reason is that the
application did the reboot in favor of entering boot-loader mode, then go to step f).
c) Check whether an application exists in application zone or not. If not, go to step f).
d) Wait boot loader commands from host for 3 seconds, if received boot load command,
invoke firmware downloader; if boot load command not received, go to e).
242
NEO Interface Developers Guide NEO v1.00
Communication Protocol
[firmware version]:
If the file is to update application, then [firmware version] is application main version. For
example: 'NEO v1.00.012'.
If the file is to update boot loader, then [firmware version] is boot loader version. for
example: 'KIOSKIII-BL-V3.00.010'.
If the file is to update both, then [firmware version] is showed as application main version
and boot loader version linked with '&'. For example: ' NEO v1.00.012 & KIOSKIII-BL-
V3.00.010'
[clear/encrypted]:
'ENC' means this download file is encrypted
'CLR' means this download file is not encrypted
If file name not marked with 'ENC' or 'CLR', that is encrypted file.
If firmware key is valuable in device, please use encrypted download file.
If firmware key is not valuable in device, please use clear download file.
Note: Encrypted download files are generally used in firmware updating. Clear download
files are only prepared for device recovery in special accidents.
[port]:
If the file is for RS232 port, then [port] is 'RS232'. If the file is for USBHID port, then [port]
is 'USBHID'.
' KIOSKIII-BL-V3.00.014_CLR_RS232.txt'
' KIOSKIII-BL-V3.00.014_CLR_USBHID.txt'
' KIOSKIII-BL-V3.00.014_ENC_RS232.txt'
'KIOSKIII-BL-V3.00.014_ENC_ USBHID.txt'
243
NEO Interface Developers Guide NEO v1.00
Firmware download file is coded in ASCII text. Firmware download commands and expected
responses are embed in text file one command per line. Host can retrieve each command in
order and convert the command from ASCII code to hex data then send them to Kiosk III device,
then compare the response from Kiosk III device with expected response next to the command in
text file.
Examples:
NEO v1.00.012_RS232.txt
#RS232 version
<START:
TIMEOUT:1000
SEND:5669564F746563683200C7410000ACF3
SLEEP:2000
SEND:5669564F746563683200C7110000F23D
WAIT:5669564F746563683200C7000000866E
SEND:5669564F746563683200C7120001014A91
WAIT:5669564F746563683200C7000000866E
SEND: 5669564F746563683200C71301008A8D92719D9D.......
WAIT:5669564F746563683200C7000000866E
......
......
......
WAIT:5669564F746563683200C7000000866E
SEND:5669564F746563683200C71500083230313530393234BE8B
WAIT:5669564F746563683200C7000000866E
SEND:5669564F746563683200C716000077AD
WAIT:5669564F746563683200C7000000866E
END>
NEO v1.00.012_USBHID.txt
#USBHID version
<START:
244
NEO Interface Developers Guide NEO v1.00
TIMEOUT:1000
SEND:015669564F746563683200C7410000ACF300000000000......
SLEEP:2000
SEND:015669564F746563683200C7110000F23D00000000000......
WAIT:015669564F746563683200C7000000866E00000000000......
......
......
......
SEND: 015669564F746563683200C71500083230313530393234BE8B000000000......
WAIT:015669564F746563683200C7000000866E000000000000......
SEND:015669564F746563683200C716000077AD000000000000......
WAIT:015669564F746563683200C7000000866E000000000000......
END>
When host wants to update firmware to Kiosk III device, please do as following steps:
step 1: Power on Kiosk III device.
step 2: Configure the communication ports and establish connection between host and Kiosk III
device.
step 3: Host selects the right firmware download file, parses data, then finishes the whole
commands.
step 4: End
Host must use this command to let reader reboot into boot loader mode if reader is running in
main application. No response for this command and just reset reader immediately.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Sub-Command Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
ViVOtech2\0 C7h 41h 00h 00h
Command Frame
245
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 14
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
...Byte 13+n
Header Tag & Data Length Data Length Data
Command Status Code CRC (MSB) CRC (LSB)
Protocol Version (MSB) (LSB)
See Status See Below
ViVOtech2\0 C7h 00h 00h
Code Table
Response data is the version of the boot loader.
For example: ' KIOSKIII-BL-V1.00.001'
This is the first command sent by host to open a firmware update process.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Sub-Command Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
ViVOtech2\0 C7h 11h 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 14 Byte 15
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 C7h 12h 00h 01h See Below
Data: 0x01 Erase application space
0x02 Erase boot loader space
0x03 Erase application and boot loader space
When this command is received, reader will store a dirty flag in flash.
246
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
Command Frame
Byte 14 -
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 270 Byte 271
Byte 269
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 C7h 13h 01h 00h See Below
In this command, data length must be 256 bytes. the 256 bytes data are encrypted firmware
check value. It is a SHA256 digest of the plaint firmware encrypted by firmware RSA public key.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
Send Plaint Firmware Check Value(C7-23)This command is used to send firmware check-value to
the device.
This command is supported later than KIOSKIII-BL-V3.00.007.
Command Frame
Byte 14 -
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 270 Byte 271
Byte 269
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 C7h 23h 00h 20h See Below
In this command, data length must be 32 bytes. the 32 bytes data are plaint firmware check
value. It is a SHA256 digest of the plaint firmware.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
247
NEO Interface Developers Guide NEO v1.00
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
This command is sent by host to program specified address in application zone or boot loader
zone. One command can send 2048 bytes data block which is 2048 bytes plaint firmware data
XOR with the 32 bytes firmware check value.
Command Frame
Byte 14 - Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 2066
Byte 2065 2067
Header Tag & Data Data Data
Sub- CRC
Protocol Command Length Length CRC (LSB)
Command (MSB)
Version (MSB) (LSB)
ViVOtech2\0 C7h 14h 01h 00h See Below
In this command, data length must be 2052 bytes:
The first 4 bytes are the address where the firmware data in this command should be put in
reader flash.
The other 2048 bytes are firmware plaint data XOR with the 32 bytes firmware check value and
will be XOR with 32 bytes firmware check value by reader, then reader update the plaint
firmware data into the right address got from the first 4 bytes.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
This is the last command sent by host to close a firmware update process.
Command Frame
Byte 14 -
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 22 Byte 23
Byte 21
Header Tag & Data Data Data
Sub- CRC CRC
Protocol Command Length Length
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 C7h 15h 00h 08h See Below
In this command, data length must be 8 bytes: 'YYYYMMDD', exp: '20150605'.
When this command is received, reader will do the following:
1. Clear the dirty flag.
248
NEO Interface Developers Guide NEO v1.00
2. If updated firmware is main application, reader then encrypts the firmware check value by
the 32 bytes inherent key using AES256 algorithm(Inherent key is a 32-byte random number
that protected by K21 tamper). The 32 bytes encrypted check value is stored in flash. If
updated firmware is boot loader, the check value is ignored, will not be store in flash.
3. If updated firmware is boot loader, reader stores boot loader sequence number and time
stamp in flash.
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Status Code Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
See Status
ViVOtech2\0 C7h 00h 00h
Code Table
Host can use this command to make boot loader reboot reader, and then enter main
application. No response for this command and just reset reader immediately.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Data Data
Header Tag &
Command Sub-Command Length Length CRC (LSB) CRC (MSB)
Protocol Version
(MSB) (LSB)
ViVOtech2\0 C7h 16h 00h 00h
249
NEO Interface Developers Guide NEO v1.00
Enter Boot
Loader Process
(C7-41)
Start Update
Process
(C7-11)
Erase Boot/Application
Space
(C7-12)
Firmware Key
Valiable?
Y N
Firmware Data N
Finished?
Y
End Update Process
(C7-15)
Start Application
(C7-16)
250
NEO Interface Developers Guide NEO v1.00
This command configures the buttons on the ViVOpay Vendi reader. Both the SWIPE and DONE
buttons can be independently disabled with this command. This command also sets the TAP
disable time for when the SWIPE button is pressed. When the SWIPE button is enabled, the
contactless reader is turned off for the programmed delay time so that a false read does not
occur when the user wishes to swipe a dual contactless/MagStripe card.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 to 16 Byte 17 Byte 18
Header Tag Data Data
Sub- CRC CRC
& Protocol Command Length Length Data
Command (LSB) (MSB)
Version (MSB) (LSB)
ViVOtech2\0 F0h F4h 00h 03h Done Swipe Delay
If Done (Byte 14) is set to 01h, the Done switch is enabled. If Done (Byte 14) is set to 00h, the
DONE switch is disabled. When the DONE button is pressed, the byte string: “02 02 5B 2F” is
sent to the serial port (5B 2F are the 2 CRC bytes). Pressing the DONE button also displays
“DONE” on the LCD display.
If Swipe (Byte 15) is set to 01h, the Swipe Card switch is enabled. If Swipe (Byte 15) is set to 00h
the Swipe Card switch is disabled. The Swipe Card button sends the 4 bytes “02 03 4B 0E” to
the serial port (4B 0E are the 2 CRC bytes). The Vendi can be configured to disable the
contactless reader for a specified number of seconds. The only visual indication is that the LCD
flashes when it writes “Please swipe card” on the LCD and then immediately rewrites the
default message.
The Delay is an unsigned delay value in seconds. This should probably not be set to values larger
than 30 seconds (Byte 16).
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
The reader switches configuration only if the Response Frame contains an OK Status Code. No
data is returned in the response.
251
NEO Interface Developers Guide NEO v1.00
This command reads the button configuration from the ViVOpay Vendi reader.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 F0h F5h 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 to 16 Byte 17 Byte 18
Header Tag Data Data
Status CRC CRC
& Protocol Command Length Length Data
Code (MSB) (LSB)
Version (MSB) (LSB)
ViVOtech2\ See Status Done Swipe Delay Swipe Delay
F0h 00h 03h
0 Code Table
This command stops the blue LEDs on the ViVOpay Vendi reader from flashing in left to right
sequence and turns the LEDs off, and contactless function is disable at the same time.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Sub- Data Length Data Length
Protocol Command CRC (LSB) CRC (MSB)
Command (MSB) (LSB)
Version
ViVOtech2\0 F0h F6h 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Data Length Data Length CRC
Protocol Command Status Code CRC (MSB)
(MSB) (LSB) (LSB)
Version
252
NEO Interface Developers Guide NEO v1.00
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
Use this command to control the blue LED behavior on the Vendi reader. If you send this
command with a Data Length 00h, the reader begins a continuous LED sequence and contactless
function is enable. To customize the LED behavior, you can define a sequence of up to eight LED
behaviors, but contactless function would keep disable if F0-F6 CMD has been issue. Custom LED
behavior can also be set for a continuous cycle. To exit a continuous LED sequence, send a
Disable Blue LED Sequence Command to the reader.
Command Frame
Byte 14-n Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte n+2
n+1
Header Tag Data Sequence
Sub- Data Length CRC CRC
& Protocol Command Length Data
Command (LSB) (LSB) (MSB)
Version (MSB)
00h=continuous 4 to 25
sequence bytes, if
ViVOtech2\0 F0h F7h 00h
04h to present
19h=custom
Sequence Data
Byte 0 Byte 1 Byte 2-3 Byte 4 Byte 5-6 Byte 7 – 24
Additional
Cycles LEDs Duration LED Duration
LED/Durations
0 = Cycle Given in Given in You can define up to 8
LED State LED State
once multiples of 10 multiples of 10 LED and duration
Bitmap Bitmap
1 = Repeat millisecond millisecond pairs.
Bit Description
8 Left blue LED, 0 = off, 1 = on
7 Center Blue LED, 0 = off, 1 = on
6 Right Blue LED0 = off, 1 = on
5 Yellow LED, 0 = off, 1 = on
4 Reserved for future use
3 Reserved for future use
2 Reserved for future use
1 Reserved for future use
253
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data Length
Protocol Command Status Code Length CRC (MSB) CRC (LSB)
(MSB)
Version (LSB)
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 F0h F9h 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data Length
Protocol Command Status Code Length CRC (MSB) CRC (LSB)
(MSB)
Version (LSB)
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
Note: Issuing this command disables LCD management by the reader. To resume LCD
management by the reader, send a Set Configuration (‘04 00’) with a UI Scheme (tag ‘FF F8’)
with value chosen at integration. However, firmware control of the LCD does not initiate
until after a transaction event. Therefore any UI messaging linked to the initiation of a
transaction (i.e. prompt for presentation or amount display) must be written to the LCD
before issuing an Activate Transaction. At the same time, to read LCD source and get
“Internal “ after issuing LCD Display Clear(F0-F9), this feature implemented on the Vendi
follows.
This command turns off the ViVOpay Vendi reader yellow LED. This LED is located below the
three blue LEDs.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
254
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status Code
ViVOtech2\0 F0h 00h 00h
Table
This command turns on the ViVOpay Vendi reader yellow LED. This LED is located below the
three blue LEDs.
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Sub-
Protocol Command Length Length CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 F0h FBh 00h 00h
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status Code
ViVOtech2\0 F0h 00h 00h
Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
255
NEO Interface Developers Guide NEO v1.00
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Data
Protocol Command Status Code Length Length CRC (MSB) CRC (LSB)
Version (MSB) (LSB)
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
Use this command to display text on the LCD display. On the Vendi reader the LCD is a 2-line
character display. Valid messages for the first line of text are between 1 and 16 printable
characters long. If the text message is greater than 16 bytes but not more than 32 bytes, byte
17 and onward are displayed as a second row of text. Messages with more than 32 bytes are
rejected with an unknown subcommand status code. All messages are left justified on the LCD
display.
Note: Issuing this command disables LCD management by the reader. To resume UI
management by the reader, send a Set Configuration (‘04 00’) with a UI Scheme (tag ‘FF F8’)
with value chosen at integration. However, firmware control of the LCD does not initiate
until after a transaction event. Therefore any LCD messaging linked to the initiation of a
transaction (i.e. prompt for presentation or amount display) must be written to the LCD
before issuing an Activate Transaction. At the same time, to read LCD source and get
“Internal “ after issuing LCD DisplayLine 1 Message (F0-FC), this feature implemented on the
Vend, and Vendi follows.
Command Frame
Byte 14 - Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13
(Byte 14+n-1_ (14+n) (14+n +1)
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 F0h FCh 00h Msg len LCD message
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data Length Data Length
Command Status Code CRC (MSB) CRC (LSB)
Protocol Version (MSB) (LSB)
256
NEO Interface Developers Guide NEO v1.00
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
This command displays the command’s message on line 2 of the LCD display. On the Vendi
reader the LCD is a 2-line character display. Valid messages are between 1 and 16 printable
characters long. Any message that is longer than 16 bytes is rejected with an unknown
subcommand status code. All messages are left justified on the LCD display.
Note: Issuing this command disables LCD management by the reader. To resume LCD
management by the reader, send a Set Configuration (‘04 00’) with a UI Scheme (tag ‘FF F8’)
with value chosen at integration. However, firmware control of the LCD does not initiate
until after a transaction event. Therefore any UI messaging linked to the initiation of a
transaction (i.e. prompt for presentation or amount display) must be written to the LCD
before issuing an Activate Transaction. At the same time, to read LCD source and get
“Internal “ after issuing LCD Display Line 2 Message (F0-FD), this feature implemented on the
Vend, and Vendi follows.
Command Frame
Byte Byte
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 +n
14+n+1 15+n=2
Header Tag Data Data
Sub-
& Protocol Command Length Length Data CRC (LSB) CRC (MSB)
Command
Version (MSB) (LSB)
ViVOtech2\0 F0h FDh 00h Msg len LCD message
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag & Data
Data Length
Protocol Command Status Code Length CRC (MSB) CRC (LSB)
(MSB)
Version (LSB)
See Status
ViVOtech2\0 F0h 00h 00h
Code Table
257
NEO Interface Developers Guide NEO v1.00
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC CRC
& Protocol Command length length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
See Data
00 02 9Ah Variable
Format below
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Data length Data length
Protocol Command Status CRC(MSB) CRC(LSB)
(MSB) (LSB)
Version
See Status Code
ViVOtech2\0 C7h 00 00
Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte16
Header Tag Data Data
Sub- CRC CRC
& Protocol Command length length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
Timeout
00 02 9Bh 00h 01h (1 byte, time in
seconds)
Response Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte 15+n
Byte 14+n-1
258
NEO Interface Developers Guide NEO v1.00
If Status code is OK, Data Field for Response Frame is a message received from the phone.
Otherwise, Data Length is zero and no data for Response Frame.
ApplePay Function
The device can store 6 Merchant Records at most. Each record includes an ID and an optional
URL.
259
NEO Interface Developers Guide NEO v1.00
11 PICC_POLL_TYPE_APPLE_PAY_ONLY,
PICC_POLL_TYPE_A and
PICC_POLL_TYPE_B
Transaction Responses
Both the ApplePay VAS response and the normal payment transaction response will be
provided in a single returned data record. Whether returned in response to a blocking ACT
or a non-blocking ACT it will be the same. As described above there are ApplePay VAS
scenarios where either the VAS transaction or the payment transaction may not be
performed. In those scenarios you will only see the results of the transaction that was
actually performed. Only when both VAS and payment transactions are performed will you
see both transaction responses in the same returned data record.
The Payment transaction response will not change. The VAS transaction response will be
embedded in the proprietary ApplePay VAS Container TLV (0xFFEE06). Each Merchant ID and
its associated data will be shown in sequence.
260
NEO Interface Developers Guide NEO v1.00
9F25 nn – Merchant ID b
9F2A nn – Mobile Token
9F27 nn – VAS Data
. . .
9F25 nn – Merchant ID n
9F2A nn – Mobile Token
9F27 nn – VAS Data
xx xx – CRC for entire response
261
NEO Interface Developers Guide NEO v1.00
9F21 nn - Time
9F25 nn – Merchant ID a
DF02 nn – ApplePay VAS Failure Report for Merchant ID a
9F25 nn – Merchant ID b
9F2A nn – Mobile Token
9F27 nn – VAS Data
. . .
9F25 nn – Merchant ID n
9F2A nn – Mobile Token
9F27 nn – VAS Data
xx xx – CRC for entire response
Command Frame
Byte 14 …
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14+n Byte15+n
Byte 14+n-1
Header Tag Data Data
Sub- CRC CRC
& Protocol Command length length Data
Command (MSB) (LSB)
Version (MSB) (LSB)
See Data
ViVOtech2\0 04 11h 63h
Format below
Response Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15
Header Tag &
Data length Data length
Protocol Command Status CRC(MSB) CRC(LSB)
(MSB) (LSB)
Version
See Status Code
ViVOtech2\0 04h 00 00
Table
Command Frame
Byte 0-9 Byte 10 Byte 11 Byte 12 Byte 13 Byte 14 Byte 15 Byte16
Header Tag Sub- Data Data CRC CRC
Command Data
& Protocol Command length length (MSB) (LSB)
262
NEO Interface Developers Guide NEO v1.00
263
NEO Interface Developers Guide NEO v1.00
For a contactless MagStripe transaction, the reader does not require any setup data from the
terminal.
Response: OK
Status DLen DLen CRC CRC
Header Cmd Data
Code (MSB) (LSB) (MSB) (LSB)
56 69 56 4F 74 65 63 68 32 00 01h 00 00h 00h 12h 53h
ViVOtech2\0 OK DLen = 0 decimal None
Reader starts polling for cards. The Terminal should keep checking for data from the reader. If a
card has been read, data is available, otherwise there is no data. The Get Transaction Result
command is for retrieving the data. This command is not required for the reader to poll for
cards or to carry out a transaction.
Reader continues to poll for cards. No Card has been presented so far.
264
NEO Interface Developers Guide NEO v1.00
Reader continues to poll for cards. No Card has been presented so far.
Reader continues to poll for cards. Card presented and accepted by the reader.
Data
38 34 38 30 38 5E 53 4D 49 54 48 2F 4A 4F 48 4E 5E 30 35 30 38 31 30 31 33 33 35 33 37 33 33 33 36 30 37
32 32 32
Track 1 Data
“84808^SMITH/JOHN^050810133537333607222”
265
NEO Interface Developers Guide NEO v1.00
Data
32 32 37 32 34 31 31 31 31 35 34 31 33 31 32 33 34 35 36 37 38 34 38 30 38 3D 30 35 30 38
25h
33 31 30 31
Track1 Data T2Len= Track 2 Data
2272411113 37 (dec) “5413123456784808=0508101”
CRC CRC
Data
(MSB) (LSB)
39 36 30 37 39 39 37 32 34 32 31 38 33 00h F1h FBh
Track 2 Data Clearing Record
9607997242183 Not Present
Contactless MagStripe card was presented and accepted by the reader before the Get
Transaction Result command. Track 1 and Track 2 data returned in response.
For a contactless MagStripe transaction, the reader does not require any setup data from the
terminal.
Response: OK
Status DLen DLen CRC CRC
Header Cmd Data
Code (MSB) (LSB) (MSB) (LSB)
56 69 56 4F 74 65 63 68 32
01h 00h 00h 00h 12h 53h
00
DLen = 0
ViVOtech2\0 OK None
decimal
Reader stops polling for cards. Terminal has to issue an Activate command to allow the reader
to poll for a card and carry out a transaction.
266
NEO Interface Developers Guide NEO v1.00
decimal (decimal)
Reader starts polling for cards. No card is presented. Reader stops polling after 10 seconds and
sends back a response indicating timeout.
Reader starts polling for cards. A contactless MagStripe card is presented within 10 seconds.
Reader completes transaction, even if more than ten seconds pass since Activate command was
received. After completing transaction the reader does not restart polling and just sends back
the response containing the Track1 and Track2 data.
Data
38 34 38 30 38 5E 53 4D 49 54 48 2F 4A 4F 48 4E 5E 30 35 30 38 31 30 31 33 33 35 33 37 33 33 33 36 30 37
32 32 32
Track 1 Data
84808^SMITH/JOHN^050810133537333607222
Data
32 32 37 32 34 31 31 31 31 35 34 31 33 31 32 33 34 35 36 37 38 34 38 30 38 3D 30 35 30 38
25h
33 31 30 31
Track1 Data T2Len= Track 2 Data
2272411113 37 (dec) “5413123456784808=0508101”
267
NEO Interface Developers Guide NEO v1.00
CRC CRC
Data
(MSB) (LSB)
39 36 30 37 39 39 37 32 34 32 31 38 33 00h F6h 7Fh
Track 2 Data Clearing Record
“607997242183 Not Present
The correct CA Public Keys required by the Cards that is read have already been set up using the
Key Management Commands (refer to Key Management). This operation needs to be done only
once for each key. Keys are retained over power cycles by the reader.
Response: OK
Status DLen DLen CRC CRC
Header Cmd Data
Code (MSB) (LSB) (MSB) (LSB)
56 69 56 4F 74 65 63 68 32
01h 00 00h 00h 12h 53h
00
DLen = 0
ViVOtech2\0 OK None
decimal
Reader stops polling for cards. Terminal has to issue an Activate command to allow the reader
to poll for a card and carry out a transaction.
Assuming the current terminal values is used for all other parameters (unless specified
otherwise in Activate command).
268
NEO Interface Developers Guide NEO v1.00
Response: OK
Status DLen DLen CRC CRC
Header Cmd Data
Code (MSB) (LSB) (MSB) (LSB)
56 69 56 4F 74 65 63 68 32
04h 00 00h 00h AEh 16h
00
DLen = 0
ViVOtech2\0 OK None
decimal
Note: These parameter values may not apply to all cards. The terminal has to make sure that
correct values have been defined for the parameters based on card requirements otherwise a
transaction fails.
Reader starts polling for cards. A contactless EMV (M/Chip) card is presented within 10 seconds.
Reader completes transaction, even if more than ten seconds pass since Activate command was
received. After completing transaction the reader does not restart polling and just sends back
the response containing the Clearing Record data.
Data
E1 56 9F 1A 02 01 58 9F 02 06 00 00 00 00 00 01 5F 2A 02 09 01 9A 03 05 08 02 9C 01 00 95 05 00 00 00 00
00 9F 37
Clearing Record (DE 055)
Data
04 84 77 98 32 82 02 58 80 9F 26 08 02 BB 21 5D D9 06 94 01 9F 27 01 40 9F 10 12 02 10 90 08 01 22 30 00
00 00 00
Clearing Record (DE 055)
Data
00 00 00 00 15 00 FF 9F 36 02 00 D0 5A 08 54 12 34 00 00 00 00 5F 34 01 00 5F 24 03 10 07
269
NEO Interface Developers Guide NEO v1.00
19 31
TLV PAN Seq TLV App
Clearing Record (DE 055) TLV App PAN
Num Expiration Date
Data
50 0A 4D 61 73 74 65 72 43 61 72 9F 34 03 00 1F 9F 45 02 DA 9F 4C 08 00 00 00 00 00 00 00
64 03 C0 00
Data Auth
TLV Application Label CVM Results ICC Dynamic Number
Code
Data
57 13 54 12 34 00 00 00 00 19 D1 00 72 01 14 43 14 31 00
56 00 9B 02 C8 00
00 0F
TLV Track 1 Transaction Status
TLV Track 2 Equivalent Data
Equivalent Data Information
270
NEO Interface Developers Guide NEO v1.00
The flow diagram below illustrates how an external UI may be controlled, using asynchronous UI
events.
271
NEO Interface Developers Guide NEO v1.00
272
NEO Interface Developers Guide NEO v1.00
The Alert tone is an indication to the card user that something unusual has occurred and some
action must be taken (for example, insert a card, swipe a card, check your mobile phone, use
one card at a time, etc.).
The following table describes the audible tones emitted by the reader for each of the interfaces
under various conditions:
273
NEO Interface Developers Guide NEO v1.00
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the DCA Command (Delete Configurable AID - Cmd 4, Sub Cmd 4)
56 69 56 4F 74 65 63 68 32 00 04 02 00 0E FF E4 01 00 9F 06 07 A0 00 00 00 04 10 10 D2 A8
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 07 00 00 2B 86
Uses the SCA Command (Set Configurable AID - Cmd 4, Sub Cmd 2)
56 69 56 4F 74 65 63 68 32 00 04 02 00 18 FF E4 01 00 9F 06 05 B0 12 34 56 78 FF E2 01 03 FF E1
01 01 FF E5 01 0A 09 AB
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the SCA Command (Set Configurable AID - Cmd 4, Sub Cmd 2)
274
NEO Interface Developers Guide NEO v1.00
From POS →
56 69 56 4F 74 65 63 68 32 00 04 04 00 08 9F 06 05 B0 12 34 56 78 DF 97
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the DCA Command (Delete Configurable AID - Cmd 4, Sub Cmd 4)
From POS →
56 69 56 4F 74 65 63 68 32 00 04 03 00 0D FF E4 01 01 FF F1 06 00 00 00 01 00 00 64 03
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the SCG Command (Set Configurable Group - Cmd 4, Sub Cmd 3)
275
NEO Interface Developers Guide NEO v1.00
From POS →
56 69 56 4F 74 65 63 68 32 00 04 02 00 18 FF E4 01 01 9F 06 05 B0 12 34 56 78 FF E2 01 03 FF E1
01 01 FF E5 01 0A FF 7E
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the SCA Command (Set Configurable AID - Cmd 4, Sub Cmd 2)
276
NEO Interface Developers Guide NEO v1.00
From POS →
56 69 56 4F 74 65 63 68 32 00 04 02 00 18 FF E4 01 00 9F 06 05 B0 12 34 56 78 FF E2 01 03 FF E1
01 01 FF E5 01 0A 09 AB
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the SCA Command (Set Configurable AID - Cmd 4, Sub Cmd 2)
Delete a Group
From POS →
56 69 56 4F 74 65 63 68 32 00 04 05 00 04 FF E4 01 01 0C 5D
From Reader ←
56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Uses the DCG Command (Delete Configurable Group - Cmd 4, Sub Cmd 5)
277
NEO Interface Developers Guide NEO v1.00
Item Description
ViVOPing.zip Visual C++ Project and C files containing the sample code given in
Appendix A.1 in this document.
ViVOPing.exe Executable File for the sample code given in this Document.
RFIDRead.exe Demo Utility that polls ViVOpay for Track Data.
Sample_RFIDRead.zip Source Code for the RFIDRead Utility (demonstrates use of Ping as
well as Get Track Data Commands).
278
NEO Interface Developers Guide NEO v1.00
Q2. Can you tell me which Terminal Types the reader supports?
The Kiosk III reader allows for storage of up to a maximum of 60 keys which are uniquely
identified as a key index in each payment scheme(RID).
Q4. How can I guarantee that all settings are erased in my reader when I
load a new release of firmware?
A. Use the Set Configuration Defaults Command (04-09) to re-initialize the setting to default
values.
A. The Terminal Contactless Transaction Limit (FFF1) and the CVM Required Limit (FFF5) Tags
are used by Visa and not by MasterCard. MasterCard uses the Floor Limit and the CVM List
structure described in the MasterCard specifications.
279
NEO Interface Developers Guide NEO v1.00
- CCPS 2.3.1
MasterCard
- M/Chip v3.02
- M/Stripe v3.3
Visa
Amex
- ExpressPay 3.0
Discover
Interac
- Flash 1.5
Q8. Whenever I try to load a key into the device it fails, with the error
EMV_KM_EC_NO_FREE_KEY_SLOTS. Why is that?
A. You must first delete a key from a slot before you can load a new one.
A. The way that we expect it to work is when a transaction error occurs; the reader sends error
codes back to the host. The host can use the error code to determine the appropriate message
to display on the reader using Control User Interface command. You may wish to replace the
message FAIL (05) with a more user friendly message or a blank message and manage it yourself.
280
NEO Interface Developers Guide NEO v1.00
Q10. Why am I receiving timeouts when I try to load CAP keys into my
reader using the key loading API?
A. A possible reason for the time out is because the ‘Data Length’ in the Command Frame is
greater than the actual data length of the data field being sent, therefore the ViVOpay reader
waits for more data and times out. Please ensure that the data length matches the actual size
of the data field being sent.
Q11. On certain Visa cards the PAN (tag 5A) and Application Expiration
Date (tag 5F24) are returned as zero length. Shouldn’t the reader provide
both PAN and expiry date because the Visa Contactless Payment
Specification, Protocol 2.0.2 says: "Note that the PAN and the Expiration
Date are obtained by the reader from the Track 2 Equivalent Data"?
A. The reader will only return those tags if they are present in the card, they will then be
provided in the transaction results.
Note: The reader will not provide the tags if the card does not send then in the Response
Frame.
A. Visa requires partial selection of the AIDs to be set in all PayWave applications. Please ensure
that partial selection is enabled as shown below.
---------CUT---------
AID SET
FFE4 01 02 ; Group
9F06 07 A0 00 00 00 03 10 10 ; Visa
FFE5 01 10 ; include both of these tags Max AID length and
FFE1 01 01 ; allow partial selection
END
---------CUT---------
Note: Partial selection is enabled by default for specific System AIDs (including Visa) but
when you reprogram the AID you have to specifically enable partial selection.
281
NEO Interface Developers Guide NEO v1.00
282
NEO Interface Developers Guide NEO v1.00
Examples are given for MSR data as well as ICC data. Note that data for the former will be in a
different format than data for the latter. The former uses the Enhanced Encrypted MSR Data
Output Format (see later appendix, or see ID TECH document P/N 80000403-001). By contrast,
ICC data comes back as TLV data, preceded by a ViVOtech2 header with command and response
bytes and two length bytes, and followed by a 16-bit CRC.
Step 2: Do a transaction
Burst off
[TX] - 56 69 56 4F 74 65 63 68 32 00 04 00 00 04 FF F7 01 00 B9 2E
[RX] - 56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Poll on demand
[TX] - 56 69 56 4F 74 65 63 68 32 00 01 01 00 01 01 D7 34
[RX] - 56 69 56 4F 74 65 63 68 32 00 01 00 00 00 12 53
The data will come back in the Enhanced Encrypted MSR Data Output Format, framed as follows:
Raw data:
Raw data:
02 Command
00 Status Code
283
NEO Interface Developers Guide NEO v1.00
88 Attribution
DF EE 23 MSR Tag
DF EE 26 01 88 Encrypt Information
284
NEO Interface Developers Guide NEO v1.00
The preamble is 14 bytes, as before (see example immediately above). The Attribution Byte will
have a value of 0x81 or 0x83 for contactless TDES or AES, respectively. (The lowest bit is a
Contactless flag. The second bit is a TDES/AES flag. The highest bit is a Encryption State flag.
See Chapter 9.) The TLV data section consists of tag, length, value triplets. The CRC is a 16-bit
cyclic redundancy check of the entire data packet, including the preamble.
Raw data:
56 69 56 4F 74 65 63 68 32 00 02 23 01 98 81 FF EE 12 0A 62 99 49 01 2C
00 04 60 00 02 82 02 00 00 95 05 00 00 00 00 00 9A 03 14 08 10 9C 01 00
5F 2A 02 08 40 9F 02 06 00 00 00 00 10 00 9F 03 06 00 00 00 00 00 00 9F
06 07 A0 00 00 00 04 10 10 9F 09 02 00 02 9F 1A 02 08 40 9F 1E 08 30 30
30 30 30 30 30 30 9F 21 03 12 02 37 9F 33 03 00 00 E8 9F 34 03 00 00 00
9F 35 01 25 9F 36 02 05 AB 9F 37 04 0F 0A 1A E5 9F 39 01 91 9F 53 01 00
DF 81 29 08 30 F0 F0 00 30 F0 FF 00 FF 81 06 44 DF 81 2A C1 20 10 18 E2
2A 40 63 49 89 C9 4B B1 01 3A D7 4A F6 1D 64 CF 42 5F 33 83 0A 9B BB 63
46 20 7A 72 76 DF 81 2B C1 10 16 DA F4 11 79 F9 0B A4 DC D0 64 31 65 31
CA B0 DF 81 15 06 00 00 00 00 00 FF FF 81 05 79 50 0A 4D 61 73 74 65 72
43 61 72 64 84 07 A0 00 00 00 04 10 10 9F 6D 02 00 01 56 C1 40 A5 14 AD
F8 E6 42 DA 3B 13 17 F5 D3 E6 65 B8 2B 4B E4 DE 13 C3 9F 98 2D D2 18 48
5E 2B 45 9E 3C B1 23 A5 A3 0B B8 08 2C DF B8 BF 07 8C D3 63 EA 19 00 4A
B7 5F A6 61 B6 D2 06 6B 0A AA BC F9 B7 9F 6B C1 18 79 95 EB 5E 9A F6 6A
B9 F6 2F 23 74 13 EE 51 75 1A A1 A9 84 75 68 95 D6 FF EE 01 3C DF 30 01
00 DF 31 C1 20 68 0B 25 F6 29 04 FA 8B D6 F8 BB 6C 64 A5 CD C6 10 A0 A7
60 B1 B4 80 AA 67 9B D5 27 CD 39 F5 BA DF 32 C1 10 38 32 34 F5 6A D7 99
CF 9C 4C 46 06 06 BC BC F9 DF EE 26 01 81 F8 99
Parsed data:
Head : 56 69 56 4F 74 65 63 68 32 00 02 23
Data : 01 98 81
Tag : FF EE 12
Length : 0A
Value : 62 99 49 01 2C 00 04 60 00 02
Tag : 82
Length : 02
Value : 00 00
Tag : 95
Length : 05
Value : 00 00 00 00 00
Tag : 9A
Length : 03
Value : 14 08 10
Tag : 9C
285
NEO Interface Developers Guide NEO v1.00
Length : 01
Value : 00
Tag : 5F 2A
Length : 02
Value : 08 40
Tag : 9F 02
Length : 06
Value : 00 00 00 00 10 00
Tag : 9F 03
Length : 06
Value : 00 00 00 00 00 00
Tag : 9F 06
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 09
Length : 02
Value : 00 02
Tag : 9F 1A
Length : 02
Value : 08 40
Tag : 9F 1E
Length : 08
Value : 30 30 30 30 30 30 30 30
Tag : 9F 21
Length : 03
Value : 12 02 37
Tag : 9F 33
Length : 03
Value : 00 00 E8
Tag : 9F 34
Length : 03
Value : 00 00 00
Tag : 9F 35
Length : 01
Value : 25
Tag : 9F 36
Length : 02
Value : 05 AB
Tag : 9F 37
Length : 04
Value : 0F 0A 1A E5
286
NEO Interface Developers Guide NEO v1.00
Tag : 9F 39
Length : 01
Value : 91
Tag : 9F 53
Length : 01
Value : 00
Tag : DF 81 29
Length : 08
Value : 30 F0 F0 00 30 F0 FF 00
Tag : DF 81 2A
Length : C1 20
Value(Encryption Data):
10 18 E2 2A 40 63 49 89 C9 4B B1 01 3A D7 4A F6 1D 64 CF 42 5F 33 83 0A 9B BB 63 46 20 7A 72
76
Value(Decryption Data):
DF 81 2A 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00
Tag : DF 81 2B
Length : C1 10
Value(Encryption Data):
16 DA F4 11 79 F9 0B A4 DC D0 64 31 65 31 CA B0
Value(Decryption Data):
DF 81 2B 07 00 01 00 00 01 00 2F 00 00 00 00 00
Tag : DF 81 15
Length : 06
Value : 00 00 00 00 00 FF
Tag : 50
Length : 0A
Value : 4D 61 73 74 65 72 43 61 72 64
Tag : 84
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 6D
Length : 02
Value : 00 01
Tag : 56
Length : C1 40
Value(Encryption Data):
287
NEO Interface Developers Guide NEO v1.00
A5 14 AD F8 E6 42 DA 3B 13 17 F5 D3 E6 65 B8 2B 4B E4 DE 13 C3 9F 98 2D D2 18 48 5E 2B 45 9E
3C
B1 23 A5 A3 0B B8 08 2C DF B8 BF 07 8C D3 63 EA 19 00 4A B7 5F A6 61 B6 D2 06 6B 0A AA BC F9
B7
Value(Decryption Data):
56 3E 42 35 32 35 36 38 33 32 30 33 30 30 30 30 30 30 30 5E 53 75 70 70 6C 69 65 64 2F 4E 6F 74
5E 31 32 31 32 35 30 32 38 38 33 31 30 31 34 35 31 31 35 32 31 31 31 31 31 31 31 31 31 31 31 32
Tag : 9F 6B
Length : C1 18
Value(Encryption Data):
79 95 EB 5E 9A F6 6A B9 F6 2F 23 74 13 EE 51 75 1A A1 A9 84 75 68 95 D6
Value(Decryption Data):
9F 6B 13 52 56 83 20 30 00 00 00 D1 21 25 02 32 21 01 45 11 52 2F 00 00
Tag : DF 30
Length : 01
Value : 00
Tag : DF 31
Length : C1 20
Value(Encryption Data):
68 0B 25 F6 29 04 FA 8B D6 F8 BB 6C 64 A5 CD C6 10 A0 A7 60 B1 B4 80 AA 67 9B D5 27 CD 39 F5
BA
Value(Decryption Data):
DF 31 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00 00
Tag : DF 32
Length : C1 10
Value(Encryption Data):
38 32 34 F5 6A D7 99 CF 9C 4C 46 06 06 BC BC F9
Value(Decryption Data):
DF 32 0D 30 30 30 31 30 30 30 30 30 31 30 30 32
Tail : F8 99
288
NEO Interface Developers Guide NEO v1.00
Auto poll
[TX] - 56 69 56 4F 74 65 63 68 32 00 01 01 00 01 00 F6 24
[RX] - 56 69 56 4F 74 65 63 68 32 00 01 00 00 00 12 53
03 Command
00 Status Code
88 Attribution
DF EE 23 MSR Tag
289
NEO Interface Developers Guide NEO v1.00
75 06 01 CE C6 1E 8A 64 0E 1C 2B EC
80 D4 51 48 AB 78 7E 8B 8D 05 DC 8A
C9 07 9E FC 98 53 27 0B ED B9 10 02
52 D6 AA D8 46 CB 85 69 24 FE 7C 93
52 0B 36 DA D9 25 00 00 00 00 00 00
00 00 00 00 62 99 49 01 2C 00 04 60
00 01 C1 0B 03
DF EE 26 01 88 Encrypt Information
Raw data:
56 69 56 4F 74 65 63 68 32 00 03 23 01 98 81 FF EE 12 0A 62 99 49 01 2C
00 04 60 00 04 82 02 00 00 95 05 00 00 00 00 00 9A 03 14 08 10 9C 01 00
5F 2A 02 08 40 9F 02 06 00 00 00 00 00 01 9F 03 06 00 00 00 00 00 00 9F
06 07 A0 00 00 00 04 10 10 9F 09 02 00 02 9F 1A 02 08 40 9F 1E 08 30 30
30 30 30 30 30 30 9F 21 03 12 02 53 9F 33 03 00 00 E8 9F 34 03 00 00 00
9F 35 01 25 9F 36 02 05 AC 9F 37 04 3E CE 50 B9 9F 39 01 91 9F 53 01 00
DF 81 29 08 30 F0 F0 00 30 F0 FF 00 FF 81 06 44 DF 81 2A C1 20 C6 9A 82
5D 19 7A 9E AE FC CF 50 39 66 88 21 C2 C9 EF 3B A9 B6 30 32 0E 7F 19 C0
4A A0 77 C0 EC DF 81 2B C1 10 92 95 3B 08 DF EA 80 31 E5 7F BB D2 91 55
3A 38 DF 81 15 06 00 00 00 00 00 FF FF 81 05 79 50 0A 4D 61 73 74 65 72
43 61 72 64 84 07 A0 00 00 00 04 10 10 9F 6D 02 00 01 56 C1 40 AA 67 C3
F5 0A 86 04 3B A9 B3 86 09 C8 88 D5 20 69 24 2D 63 AC 2B 8F 05 83 67 F3
66 44 EB 61 D2 70 F9 61 A4 7B 91 60 4C 7C A5 C9 AA 09 9E 2C 53 FA 7E 6E
C9 C7 8D EC AF C0 91 D9 37 ED 30 F6 26 9F 6B C1 18 0E 0C 92 E0 FC 96 1A
19 EC EB E1 E8 40 E4 8B D1 37 7F B0 9C DF 6D EB D6 FF EE 01 3C DF 30 01
00 DF 31 C1 20 FC 47 AC 22 D0 C7 AE 1B E9 A4 AD F2 7F 8E 60 B1 4E F0 92
73 5D EF CE 9B BA 3D CA BF B1 48 40 BB DF 32 C1 10 A3 1C EC AE 13 AF 03
7C 3A DE EC 45 7B BC DA 8A DF EE 26 01 81 28 F9
Parsed data:
Head : 56 69 56 4F 74 65 63 68 32 00 03 23
Data : 01 98 81
Tag : FF EE 12
Length : 0A
Value : 62 99 49 01 2C 00 04 60 00 04
Tag : 82
Length : 02
Value : 00 00
290
NEO Interface Developers Guide NEO v1.00
Tag : 95
Length : 05
Value : 00 00 00 00 00
Tag : 9A
Length : 03
Value : 14 08 10
Tag : 9C
Length : 01
Value : 00
Tag : 5F 2A
Length : 02
Value : 08 40
Tag : 9F 02
Length : 06
Value : 00 00 00 00 00 01
Tag : 9F 03
Length : 06
Value : 00 00 00 00 00 00
Tag : 9F 06
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 09
Length : 02
Value : 00 02
Tag : 9F 1A
Length : 02
Value : 08 40
Tag : 9F 1E
Length : 08
Value : 30 30 30 30 30 30 30 30
Tag : 9F 21
Length : 03
Value : 12 02 53
Tag : 9F 33
Length : 03
Value : 00 00 E8
Tag : 9F 34
Length : 03
Value : 00 00 00
Tag : 9F 35
Length : 01
Value : 25
291
NEO Interface Developers Guide NEO v1.00
Tag : 9F 36
Length : 02
Value : 05 AC
Tag : 9F 37
Length : 04
Value : 3E CE 50 B9
Tag : 9F 39
Length : 01
Value : 91
Tag : 9F 53
Length : 01
Value : 00
Tag : DF 81 29
Length : 08
Value : 30 F0 F0 00 30 F0 FF 00
Tag : DF 81 2A
Length : C1 20
Value(Encryption Data):
C6 9A 82 5D 19 7A 9E AE FC CF 50 39 66 88 21 C2 C9 EF 3B A9 B6 30 32 0E 7F 19 C0 4A A0 77 C0
EC
Value(Decryption Data):
DF 81 2A 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00
Tag : DF 81 2B
Length : C1 10
Value(Encryption Data):
92 95 3B 08 DF EA 80 31 E5 7F BB D2 91 55 3A 38
Value(Decryption Data):
DF 81 2B 07 00 01 00 00 01 00 2F 00 00 00 00 00
Tag : DF 81 15
Length : 06
Value : 00 00 00 00 00 FF
Tag : 50
Length : 0A
Value : 4D 61 73 74 65 72 43 61 72 64
Tag : 84
Length : 07
292
NEO Interface Developers Guide NEO v1.00
Value : A0 00 00 00 04 10 10
Tag : 9F 6D
Length : 02
Value : 00 01
Tag : 56
Length : C1 40
Value(Encryption Data):
AA 67 C3 F5 0A 86 04 3B A9 B3 86 09 C8 88 D5 20 69 24 2D 63 AC 2B 8F 05 83 67 F3 66 44 EB 61
D2
70 F9 61 A4 7B 91 60 4C 7C A5 C9 AA 09 9E 2C 53 FA 7E 6E C9 C7 8D EC AF C0 91 D9 37 ED 30 F6
26
Value(Decryption Data):
56 3E 42 35 32 35 36 38 33 32 30 33 30 30 30 30 30 30 30 5E 53 75 70 70 6C 69 65 64 2F 4E 6F 74
5E 31 32 31 32 35 30 32 30 35 39 31 30 31 34 35 32 31 35 33 31 31 31 31 31 31 31 31 31 31 31 32
Tag : 9F 6B
Length : C1 18
Value(Encryption Data):
0E 0C 92 E0 FC 96 1A 19 EC EB E1 E8 40 E4 8B D1 37 7F B0 9C DF 6D EB D6
Value(Decryption Data):
9F 6B 13 52 56 83 20 30 00 00 00 D1 21 25 02 51 71 01 45 21 53 2F 00 00
Tag : DF 30
Length : 01
Value : 00
Tag : DF 31
Length : C1 20
Value(Encryption Data):
FC 47 AC 22 D0 C7 AE 1B E9 A4 AD F2 7F 8E 60 B1 4E F0 92 73 5D EF CE 9B BA 3D CA BF B1 48 40
BB
Value(Decryption Data):
DF 31 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00 00
Tag : DF 32
Length : C1 10
Value(Encryption Data):
A3 1C EC AE 13 AF 03 7C 3A DE EC 45 7B BC DA 8A
Value(Decryption Data):
DF 32 0D 30 30 30 31 30 30 30 30 30 31 30 30 32
Tail : 28 F9
293
NEO Interface Developers Guide NEO v1.00
Examples are given for MSR data as well as ICC data. Note that data for the former will be in a
different format than data for the latter. The former uses the Enhanced Encrypted MSR Data
Output Format (see later appendix, or see ID TECH document P/N 80000403-001). By contrast,
ICC data comes back as TLV data, preceded by a ViVOtech2 header with command and response
bytes and two length bytes, and followed by a 16-bit CRC.
Step 2 Do a transaction
Burst off
[TX] - 56 69 56 4F 74 65 63 68 32 00 04 00 00 04 FF F7 01 00 B9 2E
[RX] - 56 69 56 4F 74 65 63 68 32 00 04 00 00 00 AE 16
Poll on demand
[TX] - 56 69 56 4F 74 65 63 68 32 00 01 01 00 01 01 D7 34
[RX] - 56 69 56 4F 74 65 63 68 32 00 01 00 00 00 12 53
02 Command
00 Status Code
8A Attribution
DF EE 23 MSR Tag
294
NEO Interface Developers Guide NEO v1.00
30 30 32 36 5E 43 41 52 44 2F 49 4D
41 47 45 20 30 33 20 20 20 20 20 20
20 20 20 20 20 20 20 5E 2A 2A 2A 2A
2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A
2A 2A 2A 2A 3F 2A 3B 36 35 31 30 2A
2A 2A 2A 2A 2A 2A 2A 30 30 32 36 3D
2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A 2A
2A 2A 2A 2A 2A 2A 2A 2A 3F 2A EB AB
97 04 89 00 E7 C6 5D BC FB BC F9 B3
B5 CA FC 1F 2C A0 AF 39 EC D2 C0 84
15 E4 E9 B9 9D 06 A3 BB B0 91 70 E1
76 B2 C2 17 90 88 84 22 A8 3C D7 12
EA B5 DC A4 A7 0B 5D A0 65 9B C1 73
09 31 92 1F 7B 23 2E F6 FA 1D A4 0A
65 19 BB E1 39 4D 80 EC E5 50 73 BB
BD 82 99 65 D2 EF E2 91 26 97 BA 56
C4 62 C8 18 70 F2 DE 1C AC 97 95 6C
0E 48 5E 8C 9F BB 62 EE 55 E7 47 B1
43 94 B2 D7 F4 31 51 48 AB 78 7E 8B
8D 05 DC 8A C9 07 9E FC 98 53 27 0B
ED B9 10 02 52 D6 AA D8 46 CB 85 69
24 FE 7C 93 52 0B 36 DA D9 25 00 00
00 00 00 00 00 00 00 00 62 99 49 01
2C 00 04 60 00 01 59 23 03
DF EE 26 01 8A Encrypt Information
The preamble is 14 bytes, as before (see example immediately above). The Attribution Byte will
have a value of 0x81 or 0x83 for contactless TDES or AES, respectively. (The lowest bit is a
Contactless flag. The second bit is a TDES/AES flag. The highest bit is a Encryption State flag.
See Chapter 9.) The TLV data section consists of tag, length, value triplets.The CRC is a 16-bit
cyclic redundancy check of the entire data packet, including the preamble.
Raw data:
56 69 56 4F 74 65 63 68 32 00 02 23 01 A1 83 FF EE 12 0A 62 99 49 01 2C
00 04 60 00 02 82 02 00 00 95 05 00 00 00 00 00 9A 03 14 08 10 9C 01 00
5F 2A 02 08 40 9F 02 06 00 00 00 00 10 00 9F 03 06 00 00 00 00 00 00 9F
295
NEO Interface Developers Guide NEO v1.00
06 07 A0 00 00 00 04 10 10 9F 09 02 00 02 9F 1A 02 08 40 9F 1E 08 30 30
30 30 30 30 30 30 9F 21 03 12 03 12 9F 33 03 00 00 E8 9F 34 03 00 00 00
9F 35 01 25 9F 36 02 05 AD 9F 37 04 12 1A 26 E5 9F 39 01 91 9F 53 01 00
DF 81 29 08 30 F0 F0 00 30 F0 FF 00 FF 81 06 44 DF 81 2A C1 20 41 9C 87
3B C8 E8 0E 5A 20 3D 75 E4 36 55 44 BA 2A EA BE 84 A5 9D F5 CE 68 60 FA
85 B6 A6 C8 81 DF 81 2B C1 10 D2 0A FE 17 44 FC 6D 4E 7D 57 33 94 31 6F
5F A9 DF 81 15 06 00 00 00 00 00 FF FF 81 05 81 81 50 0A 4D 61 73 74 65
72 43 61 72 64 84 07 A0 00 00 00 04 10 10 9F 6D 02 00 01 56 C1 40 32 16
A8 D7 1F 47 35 4B 66 69 F7 33 05 C7 4F 74 0B C3 1C 52 13 C5 D9 53 04 CD
BB DF 56 10 D1 AE DE 51 5D 08 D6 CB C6 EA 55 74 89 48 FB 78 25 55 B0 EF
50 66 4B 5A 71 BD 29 C0 0E 25 C2 E1 0B 86 9F 6B C1 20 4F 23 3E 0D CE 3E
D4 E2 84 A8 D8 91 29 DE 84 FE D3 C6 67 A4 8F F6 13 97 6B D4 0D 68 C3 DF
62 4A FF EE 01 3C DF 30 01 00 DF 31 C1 20 F5 C5 F0 6A 13 8A 8F 5E B6 51
5B 72 6C 2F 0B 78 8F E4 38 6C A2 1E 05 7F D8 C5 B4 DF 75 E9 CC 1A DF 32
C1 10 5F 6E DE AA 68 C6 DE FD 61 8C 5C 54 51 95 07 6D DF EE 26 01 83 B8
33
Parsed data:
Head : 56 69 56 4F 74 65 63 68 32 00 02 23
Data : 01 A1 83
Tag : FF EE 12
Length : 0A
Value : 62 99 49 01 2C 00 04 60 00 02
Tag : 82
Length : 02
Value : 00 00
Tag : 95
Length : 05
Value : 00 00 00 00 00
Tag : 9A
Length : 03
Value : 14 08 10
Tag : 9C
Length : 01
Value : 00
Tag : 5F 2A
Length : 02
Value : 08 40
Tag : 9F 02
Length : 06
Value : 00 00 00 00 10 00
Tag : 9F 03
Length : 06
Value : 00 00 00 00 00 00
Tag : 9F 06
Length : 07
296
NEO Interface Developers Guide NEO v1.00
Value : A0 00 00 00 04 10 10
Tag : 9F 09
Length : 02
Value : 00 02
Tag : 9F 1A
Length : 02
Value : 08 40
Tag : 9F 1E
Length : 08
Value : 30 30 30 30 30 30 30 30
Tag : 9F 21
Length : 03
Value : 12 03 12
Tag : 9F 33
Length : 03
Value : 00 00 E8
Tag : 9F 34
Length : 03
Value : 00 00 00
Tag : 9F 35
Length : 01
Value : 25
Tag : 9F 36
Length : 02
Value : 05 AD
Tag : 9F 37
Length : 04
Value : 12 1A 26 E5
Tag : 9F 39
Length : 01
Value : 91
Tag : 9F 53
Length : 01
Value : 00
Tag : DF 81 29
Length : 08
Value : 30 F0 F0 00 30 F0 FF 00
Tag : DF 81 2A
297
NEO Interface Developers Guide NEO v1.00
Length : C1 20
Value(Encryption Data):
41 9C 87 3B C8 E8 0E 5A 20 3D 75 E4 36 55 44 BA 2A EA BE 84 A5 9D F5 CE 68 60 FA 85 B6 A6 C8
81
Value(Decryption Data):
DF 81 2A 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00
Tag : DF 81 2B
Length : C1 10
Value(Encryption Data):
D2 0A FE 17 44 FC 6D 4E 7D 57 33 94 31 6F 5F A9
Value(Decryption Data):
DF 81 2B 07 00 01 00 00 01 00 2F 00 00 00 00 00
Tag : DF 81 15
Length : 06
Value : 00 00 00 00 00 FF
Tag : 50
Length : 0A
Value : 4D 61 73 74 65 72 43 61 72 64
Tag : 84
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 6D
Length : 02
Value : 00 01
Tag : 56
Length : C1 40
Value(Encryption Data):
32 16 A8 D7 1F 47 35 4B 66 69 F7 33 05 C7 4F 74 0B C3 1C 52 13 C5 D9 53 04 CD BB DF 56
10 D1 AE
DE 51 5D 08 D6 CB C6 EA 55 74 89 48 FB 78 25 55 B0 EF 50 66 4B 5A 71 BD 29 C0 0E 25 C2
E1 0B 86
Value(Decryption Data):
56 3E 42 35 32 35 36 38 33 32 30 33 30 30 30 30 30 30 30 5E 53 75 70 70 6C 69 65 64 2F
4E 6F 74
5E 31 32 31 32 35 30 32 35 37 38 31 30 31 34 35 33 31 30 33 31 31 31 31 31 31 31 31 31
31 31 32
Tag : 9F 6B
Length : C1 20
Value(Encryption Data):
4F 23 3E 0D CE 3E D4 E2 84 A8 D8 91 29 DE 84 FE D3 C6 67 A4 8F F6 13 97 6B D4 0D 68 C3 DF 62
4A
Value(Decryption Data):
9F 6B 13 52 56 83 20 30 00 00 00 D1 21 25 02 55 91 01 45 31 03 2F 00 00 00 00 00 00 00 00 00 00
298
NEO Interface Developers Guide NEO v1.00
Tag : DF 30
Length : 01
Value : 00
Tag : DF 31
Length : C1 20
Value(Encryption Data):
F5 C5 F0 6A 13 8A 8F 5E B6 51 5B 72 6C 2F 0B 78 8F E4 38 6C A2 1E 05 7F D8 C5 B4 DF 75 E9 CC
1A
Value(Decryption Data):
DF 31 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00 00
Tag : DF 32
Length : C1 10
Value(Encryption Data):
5F 6E DE AA 68 C6 DE FD 61 8C 5C 54 51 95 07 6D
Value(Decryption Data):
DF 32 0D 30 30 30 31 30 30 30 30 30 31 30 30 32
Tail : B8 33
299
NEO Interface Developers Guide NEO v1.00
Auto poll
[TX] - 56 69 56 4F 74 65 63 68 32 00 01 01 00 01 00 F6 24
[RX] - 56 69 56 4F 74 65 63 68 32 00 01 00 00 00 12 53
03 Command
00 Status Code
8A Attribution
DF EE 23 MSR Tag
300
NEO Interface Developers Guide NEO v1.00
65 19 BB E1 39 4D 80 EC E5 50 73 BB
BD 82 99 65 D2 EF E2 91 26 97 BA 56
C4 62 C8 18 70 F2 DE 1C AC 97 95 6C
0E 48 5E 8C 9F BB 62 EE 55 E7 47 B1
43 94 B2 D7 F4 31 51 48 AB 78 7E 8B
8D 05 DC 8A C9 07 9E FC 98 53 27 0B
ED B9 10 02 52 D6 AA D8 46 CB 85 69
24 FE 7C 93 52 0B 36 DA D9 25 00 00
00 00 00 00 00 00 00 00 62 99 49 01
2C 00 04 60 00 01 59 23 03
DF EE 26 01 8A Encrypt Information
301
NEO Interface Developers Guide NEO v1.00
Raw data:
56 69 56 4F 74 65 63 68 32 00 03 23 01 91 83 FF EE 12 0A 62 99 49 01 2C
00 04 60 00 03 82 02 00 00 95 05 00 00 00 00 00 9A 03 14 08 10 9C 01 00
5F 2A 02 08 40 9F 02 06 00 00 00 00 00 01 9F 03 06 00 00 00 00 00 00 9F
06 07 A0 00 00 00 04 10 10 9F 09 02 00 02 9F 1A 02 08 40 9F 1E 08 30 30
30 30 30 30 30 30 9F 21 03 12 09 12 9F 33 03 00 00 E8 9F 34 03 00 00 00
9F 35 01 25 9F 36 02 14 97 9F 37 04 71 33 B7 9A 9F 39 01 91 9F 53 01 00
DF 81 29 08 30 F0 F0 00 30 F0 FF 00 FF 81 06 44 DF 81 2A C1 20 7E 75 B6
C3 C9 56 2F F0 9F 96 0B 3D D7 6D 14 05 88 88 46 66 BB 7C 77 E9 EA 08 BB
E7 4B 64 67 3E DF 81 2B C1 10 25 7D 55 0C 4B 98 A3 58 37 BA C9 4D EC 49
4C 32 DF 81 15 06 00 00 00 00 00 FF FF 81 05 81 81 50 0A 4D 61 73 74 65
72 43 61 72 64 84 07 A0 00 00 00 04 10 10 9F 6D 02 00 01 56 C1 40 E0 A0
6E E3 6D B6 D0 DA E7 AE C5 5B 62 6E 1E 6E A7 A0 BD 32 4B B6 F9 56 4A 42
62 D5 B1 BB 27 14 B6 6E 69 EF 72 61 AD 9F 48 52 38 12 23 E9 8B C6 86 8F
7A B8 7B FA A1 04 18 7C 67 D0 13 21 F5 67 9F 6B C1 20 F0 30 4E EB A0 63
0A E1 6E EA D6 F6 2A 0A CC 46 04 D6 17 68 AA 4D 06 5D 62 87 B0 76 EB FE
D6 B4 FF EE 01 2C DF 30 01 00 DF 31 C1 10 96 82 E1 B2 47 DC 01 59 98 D0
FF A6 00 C3 37 C3 DF 32 C1 10 00 2C 77 11 34 E8 1D 52 52 84 54 42 27 71
00 27 DF EE 26 01 83 E6 31
Parsed data:
Head : 56 69 56 4F 74 65 63 68 32 00 03 23
Data : 01 A1 83
Tag : FF EE 12
Length : 0A
Value : 62 99 49 01 2C 00 04 60 00 03
Tag : 82
Length : 02
Value : 00 00
Tag : 95
Length : 05
Value : 00 00 00 00 00
Tag : 9A
Length : 03
Value : 14 08 10
Tag : 9C
Length : 01
Value : 00
Tag : 5F 2A
Length : 02
Value : 08 40
Tag : 9F 02
Length : 06
Value : 00 00 00 00 00 01
302
NEO Interface Developers Guide NEO v1.00
Tag : 9F 03
Length : 06
Value : 00 00 00 00 00 00
Tag : 9F 06
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 09
Length : 02
Value : 00 02
Tag : 9F 1A
Length : 02
Value : 08 40
Tag : 9F 1E
Length : 08
Value : 30 30 30 30 30 30 30 30
Tag : 9F 21
Length : 03
Value : 12 03 18
Tag : 9F 33
Length : 03
Value : 00 00 E8
Tag : 9F 34
Length : 03
Value : 00 00 00
Tag : 9F 35
Length : 01
Value : 25
Tag : 9F 36
Length : 02
Value : 05 AE
Tag : 9F 37
Length : 04
Value : F8 BF B4 C4
Tag : 9F 39
Length : 01
Value : 91
Tag : 9F 53
Length : 01
Value : 00
Tag : DF 81 29
303
NEO Interface Developers Guide NEO v1.00
Length : 08
Value : 30 F0 F0 00 30 F0 FF 00
Tag : DF 81 2A
Length : C1 20
Value(Encryption Data):
8A 25 46 F5 06 C6 62 6A 6E 9F CD E4 9D 3D 87 0F 4B 39 95 83 6C 0E 69 A6 A5 B2 36 CA 2B 6F
EB E0
Value(Decryption Data):
DF 81 2A 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00
00
Tag : DF 81 2B
Length : C1 10
Value(Encryption Data):
CB CF 47 87 FE 98 8E CA C7 75 18 61 3E E0 49 D2
Value(Decryption Data):
DF 81 2B 07 00 01 00 00 01 00 2F 00 00 00 00 00
Tag : DF 81 15
Length : 06
Value : 00 00 00 00 00 FF
Tag : 50
Length : 0A
Value : 4D 61 73 74 65 72 43 61 72 64
Tag : 84
Length : 07
Value : A0 00 00 00 04 10 10
Tag : 9F 6D
Length : 02
Value : 00 01
Tag : 56
Length : C1 40
Value(Encryption Data):
6A 85 B3 98 02 AC D6 6A B7 5D AB 39 17 AD F1 DE 35 78 57 46 D8 AA E3 0D 0A 3B 5B E7 67 AD
C1 BF
FE CD 7D 9A 53 F1 F1 F3 77 55 35 4E C1 60 0C 0D 3F B8 28 BA 67 8F 73 8C 70 2E 8B 23 54 1F
DC F5
Value(Decryption Data):
304
NEO Interface Developers Guide NEO v1.00
56 3E 42 35 32 35 36 38 33 32 30 33 30 30 30 30 30 30 30 5E 53 75 70 70 6C 69 65 64 2F 4E 6F
74
5E 31 32 31 32 35 30 32 32 32 32 31 30 31 34 35 34 31 37 33 31 31 31 31 31 31 31 31 31 31 31
32
Tag : 9F 6B
Length : C1 20
Value(Encryption Data):
1F 3D 43 55 15 93 7A A3 F9 4D 67 D5 56 78 DB 44 89 D7 EE A7 D5 2D 67 0D B6 E6 F7 16 83 21
E5 39
Value(Decryption Data):
9F 6B 13 52 56 83 20 30 00 00 00 D1 21 25 02 05 51 01 45 41 73 2F 00 00 00 00 00 00 00 00 00
00
Tag : DF 30
Length : 01
Value : 00
Tag : DF 31
Length : C1 20
Value(Encryption Data):
D0 11 1B C1 20 27 BA 4A B5 8D 84 BE B0 D1 FF 73 FC 4A 80 94 C8 F0 35 D2 91 F4 FD CF 02 B3
3B 96
Value(Decryption Data):
DF 31 18 30 30 30 31 30 30 30 30 30 31 30 30 31 31 31 31 31 31 31 31 31 31 31 32 00 00 00 00
00
Tag : DF 32
Length : C1 10
Value(Encryption Data):
09 57 32 31 63 68 79 8F EF 6C C9 D9 0F 27 AC 82
Value(Decryption Data):
DF 32 0D 30 30 30 31 30 30 30 30 30 31 30 30 32
Tail : 91 CC
305
NEO Interface Developers Guide NEO v1.00
306
NEO Interface Developers Guide NEO v1.00
The bit map images used for ILM support must be modified before they can be downloaded to
the reader. You need to make the following changes:
All processing of regular monochrome bitmaps must be done before attempting to download the
images to the reader. You cannot download color or grayscale images.
307
NEO Interface Developers Guide NEO v1.00
For each bitmap image, you must replace the standard bitmap header with a simplified ViVOpay
header. The ViVOpay bitmap header is 12 bytes of data in the format shown in the following
table, prefixed to the actual bitmap data:
The ViVOpay LCD expects each row of data in the opposite order than is in the bitmap. To invert
the image you can employ row swapping. Assuming the bitmap is a 128 x 64 pixel image, each 16
bytes of data constitutes one “row” of 128 pixels (128 pixels / 8 pixels/byte = 16 bytes).
Reversing the order of each 16 bytes of data in this case inverts the image.
308
NEO Interface Developers Guide NEO v1.00
Compared to a regular monochrome bitmap, the image used with ILM commands has inverted
color. White areas of the bitmap must be black and black areas white. To invert the color, each
bit of a bitmap image must be reversed by performing a NOT operation on each byte of image
data.
For example, suppose that 8 pixels were stored as 0x43 (0100 0011 in binary). This value must
be reversed with the logical NOT to become 0xBC (1011 1100 in binary). Thus, 0xBC on an LCD
matches 0x43 displayed on a PC monitor.
Image Cropping
Although message bitmaps can be sent at maximum screen size, cropping the images speeds the
download and uses less memory. Cropping MUST be done after all other processing of the bitmap
image. Other operations may be done in any order (as long as cropping is done last).
Cropping the image requires that you include the row number, column number, height and
width parameters in the ViVOpay header. The Column Number/Row Numbers define where the
upper-left corner of the bitmap is positioned. The Height and Width parameters determine the
area the bitmap takes up on the LCD screen.
Here is the same image with unnecessary white space cropped out. It is now 50x10 pixels:
Cropping must be expressed in byte boundaries instead of pixels. For example, suppose you
want to crop pixels 0 – 11 of a row of 128 pixels. Byte 0 (containing pixels 0-7) can be cropped
309
NEO Interface Developers Guide NEO v1.00
but Byte 1 (containing pixels 8-15) cannot be cropped, since it contains bits of non-cropped
data. Thus, in this case, the cropping would begin at the Byte 1 (i.e., Column 1 boundary).
310
NEO Interface Developers Guide NEO v1.00
The following diagram shows how the header parameters are derived.
0 1 2 . . . . . . . . . . . . . . . . . . . . . . .
. . . . . 14 15
1
2
.
0 .
1 .
2 .
. 62
. 63
.
. 0 1 2 . . . . . . . . . . . . . . . . . . . . . . .
62 . . . . . 14 15
63 1
2
0 .
1 .
2 .
The Row Number refers to the number of rows, each of which is a row of pixels. The Column
.
Number refers to a byte location. So Row varies from 0 to. 63, and the Column varies from 0 to
15. . 62
. 63
Example
.
62
63 is a simple example of a bitmap which measures 24x4 pixels (24 pixels per row, 4
The following
rows). All bitmap values shown are arbitrary (and in hexadecimal).
ACTUAL BMP:
[Bitmap Data = (11 00 00 00) (22 00 01 00) (33 00 01 00) (44 00 00 00)]
[Bitmap Data = (11 00 00 00) (22 00 01 00) (33 00 01 00) (44 00 00 00)]
Then invert the image by swapping the rows. In this example, each row is 32 bits, i.e., 4 bytes
long. Row 1 is swapped with the last row (4), Row 2 is swapped with the next-to-last row (3) and
so on.
311
NEO Interface Developers Guide NEO v1.00
[Bitmap Data = (44 00 00 00) (33 00 01 00) (22 00 01 00) (11 00 00 00)]
[Bitmap Data = (BB FF FF FF) (CC FF FE FF) (DD FF FE FF) (EE FF FF FF)]
Analyze the image. If the image needs to be cropped for white space reduction, do it now.
This modified image data is now ready to be displayed or stored on the ViVOpay LCD.
312
NEO Interface Developers Guide NEO v1.00
Please note, baud rate for the ViVOpay Vendi reader is 9600.
Polling Mode
The default configuration for the firmware is Auto Poll. While operating in Auto Poll, the reader
is constantly polling for contactless cards. When a card is presented to the field, reader
completes the data exchange. Transaction data is obtained by the POS via GET TRANSACTION
RESULT, READ FULL TRACK DATA, or a Burst Mode configuration. This poll mode is best suited
for contactless-magstripe data transactions (i.e. PayPass Mag Stripe & payWave MSD).
Auto Poll mode is not compatible with the EMEA User Interface configuration or M/Chip 3.0
applications. If you are using the EMEA UI or M/Chip 3.0, then you should configure the
polling mode to be “Poll on Demand”. Refer to the Set Poll Mode (01-01) command.
Burst Mode
While operating in Burst Mode, any time a valid contactless card is presented to the reader and
the transaction completes successfully, the Burst Mode Payload Packet is immediately
transmitted to the POS. The payload packet primarily consists of Track 1 and Track 2 data.
The default configuration for the firmware is Bust Mode, Auto-Off. When configured in this
fashion Burst Mode is fully active until receiving a transaction command (i.e. ACTIVATE
TRANSACTION, GET TRANSACTION RESULT, etc.) at which time Burst Mode is disabled until the
next power cycle.
Burst Mode is only valid for contactless applications returning magstripe Track 1 and Track 2
data, such as PayPass Magstripe & Visa payWave MSD.
To configure burst mode, refer to the Global Configuration Tags table, tag FFF7h.
The magstripe reader itself always operates in burst mode, regardless of the burst mode settings
defined in the EMV parameters, meaning that any swipe at the magstripe reader will result in a
payload packet immediately being sent across the serial interface.
Burst mode output from the magstripe reader can be disabled with the Burst mode parameter.
Refer to the Global Configuration Tags table, tag FFF7h.
RTC/LCD/Buzzer/LED Source
The ViVOpay readers are designed with flexibility in regards to the source of the Real Time
Clock (RTC), Liquid Crystal Display (LCD), Buzzer, and Light Emitting Diodes (LED). Each of these
components can be set to use a source internal or external to the ViVOpay unit. These
313
NEO Interface Developers Guide NEO v1.00
components can also be disabled by setting the source to "none". As a default the source of each
of these components is set as follows:
RTC: Internal for units with an RTC. External for units without an RTC
LCD: Internal
Buzzer: Internal
LED: Internal
314
NEO Interface Developers Guide NEO 1.0.0
315
NEO Interface Developers Guide NEO 1.0.0
316
NEO Interface Developers Guide NEO 1.0.0
L2: " Try Again " " Card Only " " "
L1: " Ré-essayez " " Internationale " " Ré-essayez "
FRA
L2: " " " Carte Seulement" " "
L1: "Please Try Again" " Card/Carte " " Try Again "
ENG&FRA
L2: " Ré-essayez " "International(e) " " Ré-essayez "
1_CARD SIGN_RECEIPT 1_CARD
L1: " Present One " " Please " " Present One "
ENG
L2: " Card Only " " Sign Receipt " " Card Only "
0x0A L1: " Présentez une " " Signez le recu " " Présentez une "
FRA
L2: " seule carte " " " " seule carte "
L1: " Present 1 Card " " Sign Receipt " "Present 1 Card "
ENG&FRA
L2: "Présentez 1 Cart" " Signez le recu " "Présentez 1 Cart"
WAIT SIGN_RECEIPT WAIT
L1: " Please Wait " " Please " " Please Wait "
ENG
L2: " " " Sign Receipt " " "
0x0B L1: " Attendez " "" Signez le recu " " Attendez "
FRA
L2: " " " " " "
L1: " Please Wait " " Sign Receipt " " Please Wait "
ENG&FRA
L2: " Attendez " " Signez le recu " " Attendez "
REMOVE_CARD ENTER_PIN REMOVE_CARD
L1: " Please " " Please " " Please "
ENG
L2: " Remove Card " " Enter PIN " " Remove Card "
0x0C L1: " Enlevez " "Entrez votre " " Enlevez "
FRA
L2: " carte SVP " " code " " carte SVP "
L1: " Remove Card " "PIN EntryRequire" " Remove Card "
ENG&FRA
L2: " Retirez la Carte" "Code exige" " Retirez la Carte"
APPROVED AVAIL_OFFLINE_AMOUNT APPROVED
L1: " Approved " " Offline Amount " " Approved "
ENG
L2: " " " " " "
0x0D L1: " Approuvé " " Montant " " Approuvé "
FRA
L2: " " " hors ligne " " "
L1: " Approved " " Offline Amount " " Approved "
ENG&FRA
L2: " Approuvé " " Mt hors ligne " " Approuvé "
NOT_AUTHORIZED ENTER_PIN DECLINED
L1: " Not " " Please " " Declined "
ENG
L2: " Authorized " " Enter PIN " " "
0x0E L1: " Non " "Entrez votre " " Refusé "
FRA
L2: " autorisé " " code " " "
L1: " Not Authorized " "PIN EntryRequire" " Declined "
ENG&FRA
L2: " Non autorisé " "Code exige" " Refusé "
317
NEO Interface Developers Guide NEO 1.0.0
5
String length over 16 characters, LCD displays first 16 characters only.
318
NEO Interface Developers Guide NEO 1.0.0
319
NEO Interface Developers Guide NEO 1.0.0
320
NEO Interface Developers Guide NEO 1.0.0
Note that data conforming to this standard will (as with EMV data) be framed within a ViVOtech2
standard header or "preamble" (consisting of 14 bytes: ViVOtech2\0, command byte, response byte,
two-byte length), at the beginning, plus a two-byte CRC at the end:
The 24 data fields can be parsed as shown below. Note that the first field is STX (0x02) and the last
field is ETX (0x03). It's essential to inspect the flag bits in fields 8 and 9 to determine which of several
optional fields are present, and also to determine whether encrypted fields are present (in which case,
padding must be taken into account; see detailed description hereunder).
The CRC is calculated using ALL upstream bytes of the data output (that is, using the preamble as well
as the 24 fields of data).
The presence/absence of Optional fields can be determined by inspecting flag bits in fields 8 and 9.
Field 1: STX
321
NEO Interface Developers Guide NEO 1.0.0
For ISO 7813 and ISO 4909 compliant Financial Transaction Cards:
Track 1 maximum length is 79 alphanumeric characters.
Track 2 maximum length is 40 numeric digits.
Track 3 maximum length is 107 numeric digits.
Field 8: Clear/mask data sent status byte and bit 0 is the least significant bit.
Bit 0: 1--- if Track1 clear/mask data present
Bit 1: 1--- if Track2 clear/mask data present
Bit 2: 1--- if Track3 clear/mask data present
Bit 3: 1— if fixed key; 0 DUKPT Key Management
Fixed key is only supported in some products
Bit 4: 0- TDES; 1 - AES
Bit 5: 0- No requirement to use IC (1st digit in Service Code is different from 2 or 6; 1- Use IC
where feasible (1st digit in Service Code is 2 or 6)
Bit 6: 1-- Pin Encryption Key; 0 – Data Encryption Key
Refer ANSI X9.24 2009 Page 56 for details.
Bit7: 1 – Serial # present; 0- not present
322
NEO Interface Developers Guide NEO 1.0.0
Fields 13, 14, & 15: These fields are the encrypted Track data, using either TDES-CBC or AES-CBC with
initial vector of 0. If the original data is not a multiple of 8 bytes for TDES or a multiple of 16 bytes
for AES, the reader pads the original data with trailing zeros. Hence, the length of the encrypted data
could be greater than the length of the original (unencrypted) data.
The key management scheme is DUKPT. For DUKPT, the key used for encrypting data is called the Data
Key. Data Key is generated by first taking the DUKPT Derived Key XOR’d with
0000000000FF00000000000000FF0000 to get the resulting intermediate variant key. The left side of the
intermediate variant key is then TDES encrypted with the entire 16-byte variant as the key. After the
same steps are preformed for the right side of the key, combine the two key parts to create the Data
Key.
Note that Tracks 1, 2 and 3 of card data are encrypted separately. In order to get the number of bytes
for each track’s encrypted data field, the field length is always a multiple of 8 bytes for TDES or
multiple of 16 bytes for AES. (This value will be zero if there was no data on a track.) Once the
encrypted data has been decrypted, all padding bytes need to be removed. The number of bytes of
decoded track 1, 2, or 3 data is indicated by the track 1, 2, or 3 unencrypted length field (Fields 5, 6
and 7, respectively).
Field 16: Session ID (Security level 4 only; not applicable to Kiosk II/III nor Vendi)
Field 17: Track1 hashed (if encrypted and hash track1 allowed)
Field 18: Track2 hashed (if encrypted and hash track2 allowed)
Field 19: Track3 hashed (if encrypted and hash track3 allowed)
SHA-1 is used for non-SRED products and 20 zeroes are used for SRED products. Refer to applicable
product manual for details.
SHA-1 is used to generate hashed data for track 1 to track 3 unencrypted data. It is 20 bytes long for
each track. This is provided with two purposes in mind: One is for the host to ensure data integrity by
comparing this field with a SHA-1 hash of the decrypted Track data, as a safeguard against unexpected
noise in data transmission. The other purpose is to enable the host to store a token of card data for
future use without keeping the sensitive card-holder data itself. This token may be used for comparison
with the stored hash data to determine if they are from the same card.
Field 20: Reader Serial Number (optional); always 10 bytes (pad with leading 0x30 if <10 digits)
323
NEO Interface Developers Guide NEO 1.0.0
324
NEO Interface Developers Guide NEO 1.0.0
For magstripe data, see ID TECH P/N 80000403-001, Enhanced Encrypted MSR Data Output Format.
The following TLV-based scheme applies to encrypted EMV (not MSR) transaction data.
For data passed in Tag/Length/Value (TLV) format, the Length value will be used to signal encryption
and/or masking of the Value being received. If the bottom 5 bits are ON (that is, if Byte & 0x1F == 0x1F),
then the next byte is also part of the tag. Likewise, if the most significant bit is ON (that is, if Byte & 0x80
== 0x80), then the next byte is also part of the tag.
Examples:
8F 02 03 04: Tag = 8F
9F 02 03 04: Tag = 9F02
BF A2 92 82: Tag = BFA292
Length
If the most significant bit (b7) of length is OFF, then that byte is, itself, the data length of the data
to follow.
If the most significant bit (b7) is ON, then the lower nibble specifies the number of following bytes
that contain the length of the data to follow.
Using Length Byte to Flag Mask and Encryption (IDTech Enhanced TLV)
The Length bit shall be used when data is masked or encrypted:
Bit 7 will be set to 1
Bit 6 will be set to 1 if there is encryption
Bit 5 will be set to 1 if there is a mask
Bits 0-4 signify the amount of bytes that follow specifying the data length
Using Length Byte to Flag Mask and Encryption (IDTech Enhanced TLV):
325
NEO Interface Developers Guide NEO 1.0.0
Bits 0-4 signify the amount of bytes that follow specifying the data length
The following table shows the tags that will be encrypted and/or masked:
Tag Data Object Note Plaintext Mask and format Encryption and
format
5A Application None Mask Encryption
PAN 5A A1 Len 5A C1 Len
<value> <value>
326
NEO Interface Developers Guide NEO 1.0.0
Plaintext
9F6B Track 2 Data 1. MasterCard-Paypass None None Encryption
(MagStripe) defines it 9F 6B Cx Len
2. DiscoverZip – Do not Define. <value>
3. Visa MSD –Define it for ‘Card
CVM Limit’. Now Do Not Encrypt
it in Visa MSD.
4. Amex – Do not Define.
5. PBOC–Define it for ‘Card CVM
Limit’. Now Do Not Encrypt it in
PBOC.
FFEE13 Track 1 Data 1. DiscoverZip Need Use it. None None Encryption
2. Visa MSD Need Use it. FF EE 13 Cx Len
3. Amex Need Use it. <value>
4. PBOC Need Use it.
FFEE14 Track 2 Data 1. DiscoverZip Need Use it. None None Encryption
2. Visa MSD Need Use it. FF EE 13 Cx Len
3. Amex Need Use it. <value>
4. PBOC Need Use it.
Tag Data Object Note Plaintext Mask and format Encryption and format
None None Encryption
DF812A DD Card Track 1
DF 81 2A Cx Len <value>
None None Encryption
DF812B DD Card Track 2
DF 81 2B Cx Len <value>
None None Encryption
DF31 DD Card Track 1
DF 31 Cx Len <value>
None None Encryption
DF32 DD Card Track 2
DF 32 Cx Len <value>
Note:
1. DiscoverZip has 56 Tag (Track 1 Data) and Formal Track1 & 2 Data (No Tags). So DiscoverZip will have 56, FF EE 13, FF
EE 14 (3 Tags) later.
2. Visa MSD, Amex, PBOC will have FF EE 13, FF EE 14 (2 Tags for Formal Track 1 & 2 Data) later.
327
NEO Interface Developers Guide NEO 1.0.0
Masked Area
The data format of each masked track is ASCII or Hex. The clear data includes start and end sentinels,
separators, first N, last M digits of the PAN, card holder name, expiry date and service code. The rest of
the characters should be masked using mask character.
3. Set DisplayExpirationDataID
1 byte parameter, value is 0x30 (Mask) / 0x31 (Not Mask), default value 0x31
6. Set ExpireDateOutputOpt
1 byte parameter, value is 0x30 (Output Masked for Tag 57 and Only Output EncryptedValue for Tag
5F24) / 0x31 (Output Plaintext), default value 0x31
Example:
ASCII Pan clear data: “012345678912”
Pre-PAN clear data characters: 5
Post-PAN clear data characters: 3
Mask Character = “*”
Masked Value = “01234****912”
328
NEO Interface Developers Guide NEO 1.0.0
5. In 57 Tag Value, the data before 0xDx is PAN data, it need be Masked as Tag 5A Value.
5. In 57 Tag Value, in the data 0xDy ym ms xz, yy mm is expiry date, and sxz is service code, they Need
Not be Masked.
6. In 57 Tag Value, the data after 0xDy ym ms xz are Other data, they need be Masked.
Example 1
2. Encrypt this TLV data (5A 08 47 61 73 90 01 01 00 10) to be 16 bytes Encrypted Data (XX XX XX XX
XX XX XX XX XX XX XX XX XX XX XX XX):
For TDES mode: The Length should be multiple of 8. If it was not multiple of 8, unit should zero
padded y bytes data follow automatically (the length +y should be multiple of 8).
For AES mode: The Length should be multiple of 16. If it was not multiple of 16, unit should zero
padded y bytes data follow automatically (the length +y should be multiple of 16).
Example 2
329
NEO Interface Developers Guide NEO 1.0.0
For AES mode: The Length should be multiple of 16. If it was not multiple of 16, unit should zero
padded y bytes data follow automatically (the length +y should be multiple of 16).
Example 3
2. Encrypt this TLV data (9F 20 05 01 94 60 02 7F) to be 8 (TDES mode) or 16 bytes (AES mode)
Encrypted Data:
For TDES mode: The Length should be multiple of 8. If it was not multiple of 8, unit should zero
padded y bytes data follow automatically (the length +y should be multiple of 8).
For AES mode: The Length should be multiple of 16. If it was not multiple of 16, unit should zero
padded y bytes data follow automatically (the length +y should be multiple of 16).
330
NEO Interface Developers Guide NEO 1.0.0
Example 4
If all TLVs are not same level (PayPass application list Record).
Raw Data:
<FF 81 06 (Tag00)> <82 01 70 (Len00)> <TLV10> <TLV11>
<FF 81 01 (Tag12)> <7F (Len12)> <TLV20> <TLV21> 57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17
58 98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01 94 60 02 7F <
TLV23 > … <TLV2n>
<FF 81 01 (Tag13)> <7F (Len13)> <TLV20> <TLV21> 57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17
58 98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01 94 60 02 7F <
TLV23 > … <TLV2n>
<TLV14> … <TLV1n>
<FF 81 05 (Tag01)> <60 (Len01)> <TLV10> <TLV11> 57 11 47 61 73 90 01 01 00 10 D1 51 22 01 17 58
98 93 89 5A 08 47 61 73 90 01 01 00 10 84 07 A0 00 00 00 03 10 10 9F 20 05 01 94 60 02 7F <TLV13>
<TLV14> …
New data:
<FF 81 06 (Tag00)> <82 01 D5 (Len00)> <TLV10> <TLV11>
<FF 81 01 (Tag12)> <81 B0 (Len12)> <TLV20> <TLV21> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51
22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX 84 07 A0 00 00 00 03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX < TLV23 >
… <TLV2n>
<FF 81 01 (Tag13)> <81 B0 (Len13)> <TLV20> <TLV21> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51
22 01 CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX
XX XX XX XX XX XX 84 07 A0 00 00 00 03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX <TLV24> …
<TLV2n>
<TLV14> … <TLV1n>
<FF 81 05 (Tag01)> <91 (Len01)> <TLV10> <TLV11> 57 A1 11 47 61 CC CC CC CC 00 10 D1 51 22 01
CC CC CC CC CC 57 C1 18 XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX 5A A1 08 47 61 CC CC CC CC 00 10 5A C1 10 XX XX XX XX XX XX XX XX XX XX XX XX
XX XX XX XX 84 07 A0 00 00 00 03 10 10 9F 20 C1 08 XX XX XX XX XX XX XX XX <TLV14> <TLV15>
…
Command Format
L2 commands do not carry sensitive data, hence the command can be plaintext.
331
NEO Interface Developers Guide NEO 1.0.0
Response Formats
1. 3 bytes KSN Tag – DF EE 12 (FFEE12 is reserved for existing contactless products – it will later
be replaced with DFEE12.)
2. 1 byte Len – 0A
3. 10 bytes KSN
Where:
1. Transaction Result: 2 bytes (Approve, Decline, Other)
2. Attribution: 1 Byte
BIT0 – Card Type: 0 – Contact Card
BIT2,1 – Encryption Mode: 00 – TDES Mode, 01 – AES Mode
BIT3 – Card Type: 0 – Contact/Contactless Card. 1 – MSR. (For ViVOpay IDG)
BIT6~4 – Reserved
BIT7 – Encryption Status: 0 – Encryption OFF. 1 – Encryption ON. (For ViVOpay IDG)
3. <TLV> is optional only if transaction was Approved or Declined
<TLV> will include KSN as first tag (DFEE12) if new or changed since last KSN value.
Encryption (bit 6) and Masking (bit5) flags will be utilized as appropriate in the Length component of
the TLV element
Where:
1. Status Code: 1 Byte. The usage is the same as in KioskII/KioskIII project and are used to specify if
transaction was approved or declined.
2. Error Code: 1 Byte. The usage is the same as in KioskII/KioskIII project and are used to specify if
transaction was approved or declined.
3. Attribution: 1 Byte
BIT0 – Card Type: 1 – Contactless Card
BIT2,1 – Encryption Mode: 00 – TDES Mode, 01 – AES Mode
BIT3 – Card Type: 0 – Contact/Contactless Card. 1 – MSR. (For ViVOpay IDG)
BIT6~4 – Reserved
BIT7 – Encryption Status: 0 – Encryption OFF. 1 – Encryption ON. (For ViVOpay IDG)
4. <TLV> is optional only if transaction was Approved or Declined
<TLV> will include KSN as first tag (Tag should be DFEE12, FFEE12 is reserved for existed
contactless products – Later it should be replaced with DFEE12.) if new or changed since last
KSN value.
Encryption (bit 6) and Masking (bit5) flags will be utilized as appropriate in the Length component of
the TLV element
332
NEO Interface Developers Guide NEO 1.0.0
333
NEO Interface Developers Guide NEO 1.0.0
Term Definition
AAC Application Authentication Cryptogram
AEF Application Elementary File (EMV)
AELx Evaluation Assurance Level (1 ..7)
AFL Application File Locator
AID Application Identifier
AIP Application Interchange Profile
API Application Programming Interface or
Application Priority Indicator (tag 87)
APDU Application Protocol Data Unit
ARQC Authorization Request Cryptogram
ASK Amplitude Shift Key
ATC Application Transaction Counter
ATR Answer To Reset
AUC Application Usage Control
BER Basic Encoding Rules (ASN.1)
CAT Cardholder Activated Terminals
CCC Compute Cryptographic Checksum
CDA Combined Dynamic Data Authentication/Application Cryptogram Generation (EMV)
CID Cryptogram Information Data
CVC Card Verification Code
CVM Cardholder Verification Method, EMV Book 3, C3
CVV Card Verification Value (That’s the 3 digit number on the back of cards)
DCVV Dynamic CVV
DDA Dynamic Data Authentication (EMV)
DF Dedicated File (7816-4)
DOL Data Object List
EF Elementary File (7816-4)
EMV Europay MasterCard Visa (EMVCo LLC)
IIN Issuer Identification Number
IPC Inter Process Communications
KSI Key set index
LRC Longitudinal Redundancy Check
MP Master File (7816-4)
MSD Magnetic Stripe Data
NFC Near Field Communications
PAN Primary Account Number
PCD Proximity coupling device
PICC Proximity card
PN511 FeliCa Chip from Philips
POS Point of Sale (terminal)
PPSE Proximity Payment Selection (or System) Environment
PSE Partial Selection something
PTS Protocol Type Selection
PUPI Pseudo Unique PICC Identifier
qVSDC Quick Visa Smart / Debit Credit
RID Registered Application Provider Identifier
RN Random Number
SAK Select Acknowledge
SAM Security Access Module, communicated via 7816-3 in T=0.
SDA Static Data Authentication (EMV)
SFGI Startup Frame Guard Interval (or time Integer)
SFI Short File Identifier (EMV)
334
NEO Interface Developers Guide NEO 1.0.0
Term Definition
SID SAM ID inside of reader
T=0 Protocol Type, T=0 is the asynchronous half duplex character transmission protocol.
T=1 Protocol Type, T=1 is the asynchronous half duplex block transmission protocol.
TAK Terminal Authentication Key
TC Transaction Certificate
TID Terminal ID
TLV Tag Length Value
TSI Transaction Status Information, EMV Book 3, C7
TTQ Terminal Transaction Qualifier
TVR Terminal Verification Results, EMV Book 3, C5
UN Unknown Number
XOR Exclusive OR
335
NEO Interface Developers Guide NEO 1.0.0
336
NEO Interface Developers Guide NEO 1.0.0
337
NEO Interface Developers Guide NEO 1.0.0
338
NEO Interface Developers Guide NEO 1.0.0
NEO v1.00 8/4/2015 # Added support for the following SRED items
Rev.58 1. Add Encrypted response format in below commands
> Pass Through-Exchange APDU Data (2C-13)
> Pass Through-NFC Command (2C-40)
2. Modify Pass Through commands encryption response format:
2C-03, 2C-04, 2C-05, 2C-07, 2C-13,2C-40
Raw data of Encrypted data field is <2 bytes plaintext Data Field
Length><whole plaintext Data Field><Padding (0x00)>
3. Add SRED note for response format in commands:
> C7-36, C7-37,
> 02-01, 03-00, 2C-03, 2C-04, 2C-05, 2C-07, 2C-13,2C-40
> Auto-Poll Burst Mode response
4. Add SAM interface in commands: 2C-0B, 2C-12, 2C-13.
SAM interface is only supported by SRED version device
# Other changes:
5. Replace SmartTap with Android Pay
6. Modify response format of Enhanced Pass-Through Command (2C-0B)
7. Add special TLV for Paypass application in Activate Command response
(02-01)
339
NEO Interface Developers Guide NEO 1.0.0
Rev. 64 11/9/2015
Added more Notes for MSR parsing table of Appendix A.11, to explain all
the fields in detail.
Rev. 65 11/12/2015
1. Add status code 70h(Antenna Error) and note for protocol 2.
340
NEO Interface Developers Guide NEO 1.0.0
2. Add Kiosk III Amex 9F33 and 9F6E configuration description in “User-
defined TLV Groups”
3. Add Status code 0x80 (Use another card) and 0x81 (Insert or swipe
card)
Rev. 67 12/4/2015
(KT) Add clarifications to Section 10: Enabling encryption is a one-time-only
event (it cannot be disabled), but non-encrypted data will necessarily
occur if a DUKPT key is not present.
Add enhanced descriptions in Appendix A.6, A.7, A.11 of sample data and
parsings.
Rev.68 12/8/2015
Add Appendix A.13 :Enhanced Encrypted MSR Data Output Format for
Force Encryption
11. Update Encrypted Contactless data example in Appendix A.6 and A.7
341
NEO Interface Developers Guide NEO 1.0.0
4. Add Table for Success Transaction--Encrypted data field format for MSR
card.
5. Correct Table "Get Transaction Result Encrypted data field format for
contactless card".
6. Add Table "Get Transaction Result Encrypted data field format for MSR
card.
7. Modify Appendix A.5: Firmware FAQ Q13 Encrypted EMV and Enhanced
Encrypted MSR layout.
10. Modify Appendix A.11: Enhanced Encrypted MSR Data Output Format
Rev.72 1/19/2016
1. Correct description of “NFC Tag Command (2C-40)”
342
NEO Interface Developers Guide NEO 1.0.0
4. Add note in Peer To Peer Function part: “Peer To Peer function can
only be used in Pass-Through mode”
Rev. 80 4/5/2016
(Yidong) 1. Add Secure Pass-Through Function
343
NEO Interface Developers Guide NEO 1.0.0
Rev. 82 5/10/2016
(Ching-Wei) 1.Add Tag DF891C. (Interac Retry Limit)
344