Table of Contents - APTAStandards.com
Table of Contents - APTAStandards.com Table of Contents - APTAStandards.com
4.4 Vending Equipment Interface (VEI) 4.4.1 Description of the Specification The Vending Equipment Interface (VE I) specification was developed by Agent Systems of Texas to provide a common interface that allows managed data exchange between central c omputing systems and vending equipment. This interface was developed for use between any type of vending equipment and central computing environment and is operating system and manufacturer independent. The development of VEI came about as a natural response to the trend towards automation in vending equipment. Market segments that have interest in this interface include, mass transit, parking and merchandise vending. There is an increasing need for encapsulation of Electronic Financial Transaction (EFT) data in a secure manner. Along with the commands and event data that are normally exchanged between vending equipment and a managing server, VEI offers a vehicle for EFT data handling. The VEI specification permits the development and deployment of an integrated network of vending equipment and managing servers using an open standard free of proprietary restrictions. As VEI is adopted by industry, the possibility of procuring offthe-shelf vending equipment and pre-written server software applications that have a compatible messaging format increases dramatically. 4.4.2 Applicability to UTFS Effort As it stands today, VEI requires considerable amount of work by the WP4 to be modeled for the UTFS efforts. Additional data elements would need to be added to t his protocol specification in order to fully support the UTFS WP4 proposed requirements and it lacks an industry wide implementation base. However, there is an inhere nt mechanism built into the specification, which involves submission and acceptanc e of proposed changes by the issuer, Agent Systems. The VEI protocol can serve as a messaging protocol between servers of different organizations (i.e. local and regional entities); however, it is not the optimal solution. Unfortunately, the use of VEI can be costly, as each service that must be re-programmed by the application developer requires layering of services. The mechanisms in VEI used to preserve data integrity and sequencing are very useful, however, they are redundant to those in an underlying transport protocol such as TCP/IP. This amounts to additional overhead in each frame and provides no real advantage when running on top of a reliable network protocol. This overhead is likely to have little influence on transaction times, as most transaction decisions (e.g. accept or reject card) are made locally between the device and the card. The biggest cost inherent with the use of VEI is the level of effort in developing and testing the protocol. Because of the complexity of additional layers, an inordinate amount of time is required to fully test and deploy a VEI solution, when compared to XML or another simple strategy. This disadvantage Page 40
may well be eliminated if, and when, off the shelf VEI parsers or server applications become available. 4.4.3 Common Message Structure T he VEI protocol is similar to the OSI model, with a well-defined dialog sequence in the application layer. Each message that is a component of a dialog adheres to a standard format. A message always contains a message header, followed by the body of the message (see Exhibit 4.4-1). The body of the message differs for each of the six dialogs explained in the following sections. An initial message sent is referred to as the request message. A request message can have a response message returned. Also, an acknowledgement message can follow a response message. Exhibit 4.4-1 VEI Message Structure Data Link Header Transport Header Session Header Message Header: Protocol Headers Exhibit 4.4-2 further describes the message header. Message Header Message File Transfer Direction File Name File Attributes Exhibit 4.4-2 Message Header Field # Field Name Description 1 Message Identifier This field specifies uniquely the dialog class and the service 2 Message Type This field specifies the part of the dialog that this message constitutes. For example, request, response, or acknowledgment 3 Message Sequence Number For the first request message of a dialog, its value is always one. For the first response to a request, its value is echoed back. For acknowledgments, its value is always echoed back. For subsequent requests or responses, its value increments on each message 4 Dialog Sequence Number A number that the requester increments after each dialog (set of messages), but the responder and acknowledger only echo back 5 Message length Number of bytes in the message, including the header, records and field separators 6 Sender’s Device ID A unique number within a system that identifies the device Page 41
- Page 1 and 2: SMART CARD STANDARDS AND SPECIFICAT
- Page 3 and 4: 4.4.7 Security Requirements........
- Page 5 and 6: Document History Revision Reason Fo
- Page 7 and 8: Acronym List UTFS Universal Transit
- Page 9 and 10: technology to achieve interoperabil
- Page 11 and 12: This report encompasse s the review
- Page 13 and 14: Identify S m art Card Indust ry S t
- Page 15 and 16: The standards and specifications th
- Page 17 and 18: These standards and specifications
- Page 19 and 20: Although there is no “one-to-one
- Page 21 and 22: 4.1.4.2 Card Management Data The st
- Page 23 and 24: with ISO/IEC 7816-6, there is no re
- Page 25 and 26: these messages constitutes a file.
- Page 27 and 28: Phone interviews and/or email corre
- Page 29 and 30: The ITSO message body consists of i
- Page 31 and 32: Exhibit 4.2-2 Product Types Type Co
- Page 33 and 34: Capability Values or RFU Product Pr
- Page 35 and 36: opted to contract these services ou
- Page 37 and 38: e given careful consideration for a
- Page 39 and 40: - Transaction date and time - Trans
- Page 41 and 42: cardholder related data as in the c
- Page 43: CLIENT Exhibit 4.3-9 OFX Security S
- Page 47 and 48: Exhibit 4.4-4 Condition Dialogue St
- Page 49 and 50: 4.4.7 Security Requirements The Mes
- Page 51 and 52: Application Retailer Product Retail
- Page 53 and 54: Exhibit 4.6-1 CID Edge Interface Me
- Page 55 and 56: 4.6.8 Timing and Routing The CID Ed
- Page 57 and 58: 4.7.4.1 Transaction Data The “Far
- Page 59 and 60: 4.7.4.3 System and Device Data The
- Page 61 and 62: Following the authentication proces
- Page 63 and 64: Data” transaction messages propos
- Page 65 and 66: Field Name Description reading the
- Page 67 and 68: 4.8-7 Product Transactions Usage Me
- Page 69 and 70: 4.8.4.5 Peer-to-Peer Clearing and S
- Page 71 and 72: standard does not mandate the compl
- Page 73 and 74: Item Number Exhibit 4.9-2 Part 1 Fi
- Page 75 and 76: 4.9.4.2 PICC Scheme Control Message
- Page 77 and 78: • Registration • Negative List
- Page 79 and 80: 5.0 FINDINGS This section presents
- Page 81 and 82: Exhibit 5-2 illustrates the relevan
- Page 83 and 84: Required. This set of specification
- Page 85 and 86: Project/Specification/Standard Spon
- Page 87 and 88: APPENDIX B COMPLETED CRITERIA FORMS
- Page 89 and 90: ISO/IEC 8583 Criteria Transaction D
- Page 91 and 92: TRANSLINK ® Criteria Transaction D
- Page 93 and 94: RIS PART 4 Criteria Transaction Dat
may well be eliminated if, and when, <strong>of</strong>f the shelf VEI parsers or server<br />
applications<br />
be<strong>com</strong>e<br />
available.<br />
4.4.3 Common Message Structure<br />
T he VEI protocol is similar to the OSI model, with a well-defined dialog sequence<br />
in the<br />
application layer.<br />
Each message that is a <strong>com</strong>ponent <strong>of</strong> a dialog adheres to a standard format. A message<br />
always<br />
contains a message header, followed by the body <strong>of</strong> the message (see Exhibit<br />
4.4-1). The body <strong>of</strong> the message differs for each<br />
<strong>of</strong> the six dialogs explained in the<br />
following<br />
sections. An initial message sent is referred to<br />
as the request message. A<br />
request message can have a response message returned. Also, an acknowledgement<br />
message can follow a response message.<br />
Exhibit 4.4-1 VEI Message Structure<br />
Data Link Header Transport Header Session Header<br />
Message Header:<br />
Protocol Headers Exhibit 4.4-2 further describes the message header.<br />
Message Header Message<br />
File Transfer Direction File Name<br />
File Attributes<br />
Exhibit 4.4-2 Message Header<br />
Field # Field Name Description<br />
1 Message Identifier This field specifies uniquely the dialog class and the service<br />
2 Message Type This field specifies the part <strong>of</strong> the<br />
dialog that this message<br />
constitutes. For example, request,<br />
response, or<br />
acknowledgment<br />
3 Message Sequence Number For the first request<br />
message <strong>of</strong> a dialog, its value is always<br />
one. For<br />
the first response to a request, its value is echoed<br />
back. For acknowledgments,<br />
its value is always echoed<br />
back. For subsequent requests or responses, its value<br />
increments on each message<br />
4 Dialog Sequence Number A number that the requester increments after each dialog<br />
(set <strong>of</strong> messages), but the responder and acknowledger<br />
only echo back<br />
5 Message length Number <strong>of</strong> bytes in the message, including the header,<br />
records and field separators<br />
6 Sender’s Device ID A unique number within a system that identifies the device<br />
Page 41
Change language