Technologies and Products
Chaussée de Haecht 1442 B-1130 Bruxelles Belgium
Reference Functional Specifications
VIC Standard
Version: 1.07/11(Draft)
©
sa/nv 2010
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
2 / 75
Copyright Notice
The information contained in this document is subject to change without notice and should not be
construed as a commitment by Banksys.
Banksys assumes no responsibility for any errors or omissions that may appear in this document.
The contents of this document must not be reproduced in any form whatsoever, by or on behalf of
third parties, without the prior written consent of Banksys
Disclaimer
It is the Customer’s exclusive responsibility to take all appropriate security measures pertaining to
the operation of the Banksys product. Banksys disclaims any responsibility in that respect.
Procedures defined in these guidelines are designed for information only. The Customer assumes
full responsibility for their use and/or selection. Banksys does not warrant the result of the use of
these procedures, not that the procedures contained herein will meet the Customer’s requirements
or fitness for any purpose.
T&P / AR&D
1.
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
3 / 75
Document Summary
Ref
Title
Version
Created by
Last modified by
:
:
:
:
:
Status
Confidentiality
File Path
:
:
:
VIC Standard
VIC 1.07/11-07
T&P
Castadot Céline
Draft
G:\TP\Products\Applications\Product Functionalities\Integration\ECRVIC\VIC_standard\1-Functional Specifications\vic 1.07\vic 1.071107.doc
File Size
File version
Creation date
Last time edited
Date Printed
Number of pages
Number of words
:
:
:
:
:
:
:
1331 Kb
2
21-Sep-09 10:42
16-Mar-10 11:17
16-Mar-10 11:17
75 Pages
16419
Version management report
Version
Name(s)
Date
Comments
V 1.07
C Vanhée
05/08/02
New vic 1.07, modification for EMV and credit card
V1.07/2
C Vanhée
05/02/03
Few corrections
V1.07/3
C Vanhée
14/03/03
Few corrections, remove vmc_type list
V1.07/4
C Vanhée
01/09/03
add a value in ticket_data, add new value for
vic_application_id
and
vic_bitmap_application_id,
modification in vic_data field
V1.07/5
C Vanhée
10/10/03
add a cvc2 field in vmc_debit_request, modification in
vic_data
V1.07/6
O Planckaert
12/12/03
Correction of the
application PASS
V1.07/7
C Vanhée
13/04/04
Global review.
V1.07/8
O. Planckaert
23/06/05
Adding vic_bit_map_application_id for brand Aurora (acquirer
vic_bit_map_application_id
for
the
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
4 / 75
Version management report
Cetelem)
V1.07/9
O. Planckaert
15/03/06
Adding vic_bit_map_application_id for application Cora Xenta
V1.07/10
O. Planckaert
20/05/06
Adding vic_bit_map_application_id for application for the
EMV Pass card
V1.07/11
C. Castadot / O. Planckaert
05/10/06
SEPA Migration + Global review
V1.07/11-02
O. Planckaert
25/10/06
Add one bit in the vic_bit_map_application_id for the
EZSwitch TPA.
V1.07/11-03
O. Planckaert
28/11/07
Format of the pdv_clct_nr is different for petrol transaction
managed by EFT Server
V1.07/11-04
C. Castadot
28/04/08
Update of the Messages contents summary
V1.07/11-05
C. Castadot
22/12/08
Add vic_bitmap_application_id for Pay Fair
V1.07/11-06
C. Castadot
06/05/09
Add vic_bitmap_application_id for Sodexho and Accord
Service + 2 reserved id for future used
V1.07/11-07
C. Castadot
21/09/09
Add new feature for Contactless transaction
1.1.
Release Management
Document version
Version 1.07
Changes
-
Condition code of application_info
Vic_application_id
Vic_msg_type values
Info request current period for Vic_cmd_code not supported
VIC_card_ind values not supported
Creation due to EMV transactions treatment
New fields:
- Additional_amount
- Transaction_protocol
- Transaction_identifier
- Date_and_time
- Brand_id
- vic_bit_map_application_id
- hardware_type
- cvm
News values for existing fields:
- New vic_protocol_id
- In function_cc: Card_validity, Sale with Tip, Refund and Cash
advanced (for future use), balance with closing
- In vic_cmd_code: config and counters
- In iep_tx_inc: New incident has been created: floor limit
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
5 / 75
exceeded, Transaction refused by the terminal, transaction
refused by the card, transaction status forwarded to External
device without interpretation by the terminal
add new messages for international used:
ed_device_info, cz_device_info
remove messages and replace by the vmc_command and
pdv_command_reply:
 vmc_config and pdv_config_reply
 cz_counter_info_request and ed_counter_info_reply
Remove fields:
Sam_task_nr, sam_id, stan, dev_type, dev_subtype, sw_version.
Vic_data: no limitation to 24a for identifier 50 and 51.
New value 52
New value vmc_type: 0010 0110 0 company Itsec
Version 1.07/02
Version 1.07/03
Version 1.07/04
Version 1.07/05
Version 1.07/06
Version 1.07/07
Version 1.07/08
Version 1.07/09
Version 1.07/10
Version 1.07/11
Vmc_purse_request
If a vmc_debit_request is received in a time slot of 30 seconds
after a pdv_purse_result
Field of Level2_bitmap of application_info modified
New value for Vmc_type
Smart Line 001001110 Flower dispenser.
Wincor Nixdorf 001010000 Kiosk.
AP Trans 001010010 Ticket dispenser for the TEC
New behaviour for vic_data in transparent way
Remove vmc_type value and refer to another document
Modification in vic_data, new value for vic_application_id and
vic_bitmap_application_id
Add a cvc2 field in vmc_debit_request, modification of vic_data
reference for BC/MC.
Inversion of Pass CREDIT and Pass DEBIT in the
vic_bit_map_application_id
Add :
 a range for added applications incident codes in field
iep_tx_inc.
 a recovery_data field in pdv_debit_result

the reference1 from the host, in vic_data.
 TINA references and fields
 Ticket_data values
 new iep_tx_inc for fallback card reading time out
Change:
 format cvc2, pdv_clct_nr
 In Kiss, the answer timeout is computed following a new
formula.
 pdv_gen_tx_nr, pdv_clct_nr, data_and_time,
vic_cmd_code, iep_tx_inc
 vic_to minimal value
Remove:
 vic_application_id
Global review.
Adding vic_bit_map_application_id for brand Aurora (acquirer Cetelem)
Adding vic_bit_map_application_id for application Cora Xenta
Adding vic_bit_map_application_id for application for the EMV Pass
card
Add:
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version 1.07/11-02
Version 1.07/11-03
Version 1.07/11-04
Version 1.07/11-05
Version 1.07/11-06
Version 1.07/11-07
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
6 / 75
 vic_version
 brand_name in pdv_debit_result
 a vic_bitmap_application_id for Visa Vpay
 Tags in Function_cc
 Hardware type for Xenteo
Change:
 Keep only one form with tag for vic_data + a new tag for
authorization code
Remove
 Vic_private_id, vic_private_data and recovery_data.
 vic_cmd_code from vmc_debit_request.
 All code error 6***
 ed_applic_info_request / cz_applic_info_reply
 all functionalities related to Full CCM
Global review
Add one bit in the vic_bit_map_application_id for the EZSwitch TPA.
Format of the pdv_clct_nr is different for petrol transaction managed by
EFT Server
Update of the condition for the vic_bitmap_application_id in the
Messages contents summary
Add vic_bitmap_application_id for Pay Fair
Add vic_bitmap_application_id for Sodexo, Accord and reserved
Add the field Amount in the VMC_purse_request.
Create the new field POS entry mode.
Add the new field POS entry mode in the PDV_purse_result
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
7 / 75
Table of contents
1.
DOCUMENT SUMMARY ............................................................................................................................. 3
1.1.
RELEASE MANAGEMENT .......................................................................................................................... 4
2.
GLOSSARY................................................................................................................................................. 10
3.
INTRODUCTION......................................................................................................................................... 11
3.1.
3.2.
4.
DOCUMENT PURPOSE ............................................................................................................................ 11
RELATED DOCUMENTS ........................................................................................................................... 11
GLOBAL CONCEPTS................................................................................................................................ 12
4.1. WHAT IS VIC ? ....................................................................................................................................... 12
4.2. USEFULNESS OF VIC ............................................................................................................................. 12
4.3. PROTON CONCEPTS ............................................................................................................................... 12
4.3.1.
Difference between a Proton transaction and a Proton transfer ............................................... 12
4.3.2.
The Purse Transaction ................................................................................................................ 13
4.3.3.
The Transfer................................................................................................................................. 13
4.4. BC/MC CARD AND CREDIT CARD OPERATION ........................................................................................ 15
4.5. ADDED APPLICATIONS............................................................................................................................ 15
4.6. MULTIPLE APPLICATIONS ....................................................................................................................... 16
4.7. FINANCIAL COUNTERS ............................................................................................................................ 16
4.8. TINA SERVICES..................................................................................................................................... 16
4.8.1.
Global concept ............................................................................................................................. 16
4.8.2.
Activation/deactivation/consultation TINA – VMC_COMMAND / PDV_COMMAND_REPLY 17
4.8.3.
Transaction TINA – VMC_debit_request/ PDV_debit_result .................................................... 17
5.
VIC APPLICATION PROTOCOL .............................................................................................................. 18
5.1. PROTOCOL CHARACTERISTICS............................................................................................................... 18
5.2. A TYPICAL EXAMPLE OF A TRANSACTION FLOW ....................................................................................... 20
5.3. TIME-OUT CONTROLS ............................................................................................................................. 21
5.4. CONDITION CODES ................................................................................................................................ 22
5.5. MESSAGE DESCRIPTION ........................................................................................................................ 23
5.5.1.
vmc_purse_request ..................................................................................................................... 23
5.5.2.
pdv_purse_result ......................................................................................................................... 24
5.5.3.
vmc_debit_request ...................................................................................................................... 25
5.5.4.
pdv_debit_result........................................................................................................................... 26
5.5.5.
vmc_cancel .................................................................................................................................. 28
5.5.6.
pdv_error ...................................................................................................................................... 29
5.5.7.
vmc_command ............................................................................................................................ 30
5.5.8.
pdv_command_reply ................................................................................................................... 32
5.5.9.
vmc_data ...................................................................................................................................... 33
5.5.10. pdv_data....................................................................................................................................... 34
5.5.11. vmc_state_request ...................................................................................................................... 35
5.5.12. pdv_state_info .............................................................................................................................. 36
5.6. FIELD FORMAT........................................................................................................................................ 37
5.6.1.
a field ............................................................................................................................................ 37
5.6.2.
b field ............................................................................................................................................ 37
5.6.3.
I field ............................................................................................................................................. 37
5.6.4.
x field ............................................................................................................................................ 37
5.6.5.
llvar field........................................................................................................................................ 37
5.6.6.
llllvar field ...................................................................................................................................... 37
5.6.7.
Summary ...................................................................................................................................... 37
5.7. DICTIONARY ........................................................................................................................................... 38
5.7.1.
additional_amount ....................................................................................................................... 38
5.7.2.
application_info ............................................................................................................................ 38
5.7.3.
brand_id ....................................................................................................................................... 39
5.7.4.
brand_name ................................................................................................................................. 39
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
8 / 75
5.7.5.
card_id_disp ................................................................................................................................. 39
5.7.6.
counter_tab_pa ............................................................................................................................ 40
5.7.7.
curcy ............................................................................................................................................. 41
5.7.8.
cvc2 .............................................................................................................................................. 41
5.7.9.
cvm ............................................................................................................................................... 41
5.7.10. date_and_time ............................................................................................................................. 41
5.7.11. ecr_nr ........................................................................................................................................... 42
5.7.12. function_cc ................................................................................................................................... 42
5.7.13. hardware_type ............................................................................................................................. 42
5.7.14. iep_tx_inc ..................................................................................................................................... 43
5.7.15. iso2_track ..................................................................................................................................... 44
5.7.16. lg_cust .......................................................................................................................................... 44
5.7.17. more_info_ind .............................................................................................................................. 44
5.7.18. operator_nr ................................................................................................................................... 45
5.7.19. pdv_clct_info ................................................................................................................................ 45
5.7.20. pdv_clct_nr ................................................................................................................................... 46
5.7.21. pdv_gen_tx_nb ............................................................................................................................ 46
5.7.22. pdv_journ_pct_full ........................................................................................................................ 46
5.7.23. pdv_state ...................................................................................................................................... 47
5.7.24. pdv_state_mask........................................................................................................................... 47
5.7.25. pur_bal.......................................................................................................................................... 47
5.7.26. sam_gen_tot ................................................................................................................................ 47
5.7.27. term_id.......................................................................................................................................... 47
5.7.28. ticket_data .................................................................................................................................... 48
5.7.29. transaction_identifier .................................................................................................................... 48
5.7.30. Transaction_protocol ................................................................................................................... 49
5.7.31. tx_type .......................................................................................................................................... 49
5.7.32. vic_action_ind .............................................................................................................................. 49
5.7.33. vic_application_srv_name ........................................................................................................... 49
5.7.34. vic_bit_map .................................................................................................................................. 50
5.7.35. vic_ bit_map_application_id ........................................................................................................ 51
5.7.36. vic_block_nr ................................................................................................................................. 52
5.7.37. vic_card_ind ................................................................................................................................. 52
5.7.38. vic_cmd_code .............................................................................................................................. 52
5.7.39. vic_config_clct_amt ..................................................................................................................... 54
5.7.40. vic_cust_ind ................................................................................................................................. 54
5.7.41. vic_data ........................................................................................................................................ 55
5.7.42. vic_file_name ............................................................................................................................... 57
5.7.43. vic_more_block_ind ..................................................................................................................... 57
5.7.44. vic_msg_code .............................................................................................................................. 57
5.7.45. vic_msg_type ............................................................................................................................... 58
5.7.46. vic_pos_entry_mode ................................................................................................................... 58
5.7.47. vic_protoc_id ................................................................................................................................ 58
5.7.48. vic_to ............................................................................................................................................ 59
5.7.49. vic_tx_amt .................................................................................................................................... 60
5.7.50. vic_tx_id........................................................................................................................................ 60
5.7.51. vic_version ................................................................................................................................... 60
5.7.52. vmc_type (only relevant for CZAM/SPIN) .................................................................................. 60
5.8. MESSAGES CONTENTS SUMMARY........................................................................................................... 61
6.
LINE PROTOCOL : KISS........................................................................................................................... 62
6.1.
6.2.
6.3.
6.4.
6.5.
6.6.
6.7.
6.8.
FRAME LAYOUT ...................................................................................................................................... 62
CONTROL CHARACTERS ......................................................................................................................... 63
CRC COMPUTATION............................................................................................................................... 66
TIME OUT CONTROLS.............................................................................................................................. 68
RETRY COUNTER ................................................................................................................................... 68
BYTE STUFFING ...................................................................................................................................... 69
TRANSMISSION CONTROL SEQUENCES .................................................................................................. 69
ERROR RECOVERY ................................................................................................................................. 71
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
9 / 75
6.9. FLOW CHART.......................................................................................................................................... 72
6.10.
LINE CHARACTERISTICS...................................................................................................................... 75
Reference Functional Specifications
VIC Standard
T&P / AR&D
2.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
10 / 75
GLOSSARY
AA
Added application
Balance
The amount of electronic money present in a purse.
BC/MC
BanContact/Mister-Cash
CC
Credit Card
CCR
Chip Card Reader
CSM
Chip Security Module
Collection
Transfer of electronic value from a PDV to the host, including the transfer of other
electronic data between the terminal and host and vice versa during collection phase.
CRICC
Controlled Reader for Integrated Chip Cards
C-ZAM/SPIN
commercial name for High End Vending terminal
ECR
Electronic Cash Register
EFT
Electronic Fund Transfer
EMI
Electro Magnetic Interface
EMV
Eurocard Mastercard Visa
ESD
Electro Static Discharge
ICC
Integrated Chip Card, a card containing a chip.
IEP
Intersector Electronic Purse, an electronic purse which can be used in different sectors
thus containing the equivalent of electronic money.
LDV
Load Device, terminal allowing to load a purse.
Load
Transfer of electronic money from an account to a purse.
MCR
Magnetic Card Reader
MDB
Multi-Drop Bus
PCB
Printed Circuit Board
PDV
Purchase Device, Banksys terminal allowing to perform a purchase with a purse.
POS
Point Of Sales terminal
PLC
Private Label Card
PROTON
Commercial name of IEP
PTI
Payment Terminal Indoor (Petroleum sector)
PTO
Payment Terminal Outdoor (Petroleum sector)
Purse
ICC containing an IEP application
RX
Receive
SAM
Secured Application Module, used at PDV level
SIS
Social Identity System
TINA
Temporary Interrupt Application
TX
Transmit or Transaction (depending on the context)
VIC
Vending-IEP Communication standard
VMC
Vending Machine Controller
Reference Functional Specifications
VIC Standard
T&P / AR&D
3.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
11 / 75
INTRODUCTION
3.1.
Document Purpose
Most bank cards are provided with an integrated circuit chip. These cards will combine several payment
means like Bancontact/Mister Cash debit, Proton purse, or Visa credit.
The purpose of this document is to provide the VMC (Vending Machine Controller) suppliers and ECR
(Electronic Cash Register) suppliers with a detailed specification of the VIC (Vending-IEP-Communication)
standard as used in C-ZAM/SMASH, C-ZAM/SPIN or XENTA.
The VIC standard was originally intended for Proton transactions between a PDV (Proton Purchase Device)
and a VMC. The standard has gradually grown to support other services and devices and is now capable of
handling debit and credit payments and AA. The standard is now intended for PC, VMC and ECR.
WARNINGS:

In order to improve our service, the information of this document is subject to change.

In this document we sometimes use the generic abbreviation IEP (Inter-sector Electronic Purse),
the commercial name of the product being PROTON.

In this document we use „External Device’ to designate the VMC, the PC or the ECR and terminal
to designate the Banksys C-ZAM /SMASH, C-ZAM /SPIN or XENTA terminal.

The Banksys terminals support part or all of the VIC standard, depending on their specifications.
ADDITIONAL information can be found on the Internet:
 www.banksys.com
3.2.
Related documents
[VIC_vmc_type]
Vmc_type list describes all existing values of this field
[VIC_iep_tx_inc]
Iep_tx_inc list for added applications; describes the specific range reserved for AA.
[BKS DC.220 (v1.4(1)).pdf]
BKS DC.220 (v1.4(1)) BKS Acquiring Protocol
[addendum pass]
ADDENDUM VIC 1.07 COMPLEMENT for PASS application
[addendum TINA]
ADDENDUM VIC 1.07
[exxon]
BKS-Tokheim interface specification6-2; describes vic use in project exxon
[BKS D110-TN1]
Card Scheme management
TINA transaction recovery after terminal crash
BKS D.110-TN1, Release 2.0, 14 October 2003
[VIC_sis]
SIS on C-ZAM /SMASH Vic Integration.doc
Reference Functional Specifications
VIC Standard
T&P / AR&D
4.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
12 / 75
GLOBAL CONCEPTS
4.1.
What is VIC ?
VIC is an application protocol allowing the communication between a terminal and an External Device.
When a terminal is integrated with an External Device, the External Device talks to the terminal via
messages. These messages and their use are described in section 5.
VIC
External
Device
Application
TERMINAL
network
HOST
VIC
PC or
ECR or
KISS
RS232
described in this document
Automate
In order to assure reliable and delimited communication between External Device and terminal, messages
are exchanged using a telecommunication transportation protocol – KISS – described in section 6.
4.2.
Usefulness of VIC
VIC is used to perform different kinds of transactions;
 payment transactions like
- purse (eg. Proton)
- debit (eg. Bancontact/MisterCash, Maestro)
- credit (eg. Visa, Mastercard,...)
- …
 loyalty transactions
 PLC transactions
 health sector transactions like SIS (Social Identity System)
 …
4.3.
Proton concepts
4.3.1. Difference between a Proton transaction and a Proton transfer
Purse holders can transfer “electronic money” from their purse to a terminal (Purchase Device) in order to
pay for services or goods. This operation is called a transaction. This terminal accumulates the “electronic
money” and transfers it to the service provider‟s bank account during a process called a transfer.
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
13 / 75
4.3.2. The Purse Transaction
In order to perform a transaction, the terminal has an ICC (Integrated Chip Card) reader for reading and
writing to the purse and a display for the purse holders user interface (guidance).
The transaction process basically is:

Determining a transaction price and inserting the purse

Performing the transaction, displaying the result

Retrieving the purse
If the purse is inserted and a transaction request from the vending machine is pending, then the transaction
is performed:

The purse is checked for fraud

The purse validity date is checked

The purse balance is checked
All these checks are performed off line i.e. without communication with the Banksys host.

The purse holder is asked to press the <OK> key.

A PIN code is not used.

The purse is debited, the transaction is recorded in the journal of the purse.

The transaction is recorded in the memory of the terminal (the accumulated “electronic money” is
incremented, the transaction journal is updated) and in the CSM.

If the transaction is successful, this is displayed together with the transaction amount.

If the transaction failed, the reason is displayed to the cardholder.

If the purse was withdrawn during the critical phase of the transaction (between the purse debit and
the terminal credit), the terminal asks to reinsert the purse in order to continue the transaction.

The External Device (vending machine) is informed of the result of the transaction.
4.3.3. The Transfer
A transfer is basically a transfer of “electronic money” from the terminal‟s memory to the service provider‟s
bank account.
The On-line collection occurs by means of a compatible modem via the PSTN (Public Switched
Telephone Network) to Banksys. A Leased line, isdn or Ethernet can also be used.
During a collection, information is transferred from the terminal to the bank host computer. The information
transferred during a collection currently is:

The accumulated electronic money.

Statistical information.

The journal containing the details of each transaction.
(2)
The information is checked by the Banksys host. The “electronic money” is then transferred to the bank for
credit of the bank account associated to the terminal.
During a transfer, information is also transferred from the Banksys host computer to the terminal :
(2)

Acknowledgement of collection reception, allowing the terminal to erase the journal.

Parameters for the next collection.
This is done to allow a thorough monitoring of the system.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
14 / 75

Security information (the Banksys PROTON system is secured through a dynamically evolving
security which requires frequent security updates).

A red list containing fraudulent cards and the associated validity date of the red list. The red list is
expected to be empty due to the high security level of the purse operations. However an empty red
list also has limited validity duration and it should be confirmed that it is still empty.
The data that is exchanged during the collection operation is structured in files. The files should be
exchanged in a fixed sequence. One file is exchanged from the terminal to the host, three can be
exchanged from the host to the terminal. If a file is lost or corrupted, the whole process should be started
over again.
Here are the properties of the files:
*.TH
*.HT
Name
pdv_file
pdv_cmd
pdv_param
Size
500 bytes + 21
bytes
per
(3)
payment
250 bytes
300 bytes
Min – max
0 … 2500
Entries
Direction
terminal to host
host to terminal
host to terminal
180 bytes + 8 0 … 4096 host to terminal
bytes per card
Cards
(For more details see document „Collection Host Interface‟)
red_list
Transferred when
At least when
2500 entries and
every 4 weeks
Every time
Normally
once
every month
Every time if red
list renewal
The Banksys host and the terminal authenticate the files in such a way that any (deliberate or accidental)
change to the contents of the files would be detected and lead to refusal of the file.
Each collection is allotted a collection number. The attributes of a collection are the collection number, the
(4)
collected amount, the number of transactions and the date at which the period was started. A total of 10
sets of these attributes are kept in the memory of the terminal for consultation and matching with the bank
statements, which should contain the same information.
The terminal will not accept PROTON transactions anymore if one of the following conditions is met :

The transaction journal has reached its maximum capacity

The accumulated “electronic money” has reached the maximum allowed by Banksys .

The time-sensitive information of the terminal has expired
(5)
.
(6)
(7)
.
A collection is needed in order to make the terminal accept transactions again.
In order to prevent a blocked terminal, it will attempt an on-line collection automatically, during the night at a
time given by the Banksys host computer, if one of the following conditions is met :
(3)

The transaction journal has reached a percentage of the maximum capacity.

The accumulated “electronic money” has reached a percentage
Banksys.

The accumulated “electronic money” has reached the limit set by the service provider or the
vending machine.

The time-sensitive information of the terminal expires the next day.

A request of the merchant has been received.
(8)
(9)
of the maximum allowed by
A payment which has been started, but which is aborted (e.g. because the card is removed) is also registered
The current value and the last 9 collections.
(5)
Currently 2500 entries, subject to change.
(6)
Currently 100.000 BEF or 2.500 EUR, subject to change.
(7)
Currently after 5 weeks, subject to change.
(8)
Currently 80%, subject to change.
(9)
Currently 80%, subject to change.
(4)
Reference Functional Specifications
VIC Standard
T&P / AR&D
4.4.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
15 / 75
BC/MC card and Credit Card operation
In order to perform an EFT payment, the External Device (i.e. ECR) will send a vmc_debit_request
message to the terminal.
Then the terminal will verify the card status and the available amount by exchanging data with the
authorisation host and will do the necessary cardholder interaction. Normally, a pdv_debit_result message
will be sent to the external device; the field iep_tx_inc (incident code) being in fact the result of the
transaction.
When a pdv_debit_result message with 0000 as iep_tx_inc is generated, a transaction ticket could be
printed. In the case of a Credit Card transaction, if transmitted by the acquirer, the receipt is already
formatted in the field ticket_data. Except for an EMV transaction, depending on the acquirer, the value
date_and_time, transaction_identifier, brand_id, transaction authorized amount, additional_amount and also
the field ticket_data may be available on the ticket formatted by the external device. Two tickets should be
printed. For other types of transaction, at least the value of the fields term_id, vic_tx_amt, curcy and
card_id_disp should be printed on the receipt.
Remarks for credit card transactions:
 PIN based credit card transactions can be handled.
 For some credit card transactions, depending on the acquirer, the host response will not contain an
indication of the successfulness of the transaction. The host response is then sent in a “transparent way”
to the external device (accompanied by a specific incident code 5015. In this case, it is up to the external
device operator to decide if the transaction was successful or not.
4.5.
Added Applications
Some Added applications could be constituted with an application on PC running with an application loaded
on the terminal itself.
In this case, the messages vmc_data and pdv_data are used to allow the exchange of data between the
both parts of the Added application.
The messages exchanged are encapsulated by VIC protocol without any other treatment.
The field vic_bit_map_application_id is used to identify the source and the target AA.
Reference Functional Specifications
VIC Standard
T&P / AR&D
4.6.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
16 / 75
Multiple Applications
Some terminal types can accept different types of cards:

Cards of different payment schemes or applications

Cards of the same payment scheme but having a different currency
It is important to notice that the terminal decides which cards are accepted, depending on its configuration
(type, software version, CSM configuration, settings, activated services). The External Device does not
interfere in this matter.
The terminal keeps financial counters per period for each combination of application identifier + currency.
The External Device can query (depending on the service provider) these counters using a vmc_command
message described in section 5.5.7 for each combination.
The External Device can express its choice to the terminal through a vic_bit_map_application_id field in the
vmc_debit_request message. If more than one applications of the terminal are concerned by this
vic_bit_map_application_id, the terminal asks the cardholder to select one of them.
If the External Device makes no choice, then the terminal will present a choice to the user (merchant or
client).
4.7.
Financial counters
The counters basically consist of the number of transactions and the total amount of these transactions.
The currency of a transaction is defined as the currency as fixed by the merchant, except for Proton
transactions, where the transaction currency is the one found on the Proton card itself.
For BC/MC transactions, the accounting period is a reference number defined by the host.
For the PROTON transactions, the period is the interval between 2 consecutive PROTON collections.
For on-line transactions, the financial counter information is generated by the host, which stores and
increments the counter information.
4.8.
TINA services
The TINA services allow to perform a TINA transaction when the Banksys terminal cannot obtain an on-line
transaction authorisation for BC/MC from the Banksys Host and under some commercial and technical
conditions.
4.8.1. Global concept
If the Banksys Host is unreachable, no BC/MC on line transaction can be performed, TINA Service allows
the Terminal to perform fully offline transactions with BC/MC Chip Cards.
In this context, the standard BC/MC transaction is replaced by the TINA transaction (also called “EFT
backup transaction”) that is executed without any connection to the Banksys Host.
In order to reach an acceptable level of security, the TINA transaction is based on the Chip of the Card,
which means that the TINA transaction is exclusively reserved for BC/MC Cards containing a Chip and to
Terminals supporting Chips.
The TINA Service, if allowed by the Acquirer, allows the Merchant to switch the Terminal from the standard
Online Mode into the TINA Mode, which allows transactions to be performed offline but with regular
checking of the online connection status. This regular checking of the online connection status is achieved
by performing some transactions online and is used to automatically de-activate the TINA Backup Mode.
Even if TINA is active (as reported to ECR via last transaction result or consulted by ECR via specific
command), some on-line BC/MC (trials) may happen (due to system of automated de-activation). Deactivation on terminal level is not reported automatically to ECR : ECR can only detect if all following
transaction are done via on-line BC/MC or via explicit consultation of the mode
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
17 / 75
The TINA transactions are stored in the Terminal memory and an uploading mechanism is then used to
transmit these EFT backup transactions to the Banksys Host for clearing. The merchant has the possibility
to provide critical transaction data to Banksys via another channel in case of technical problems : those
fields are described in the document [BKS D110-TN1] . For this purpose, the ECR may store or print those
critical fields for recovery.
The interactions of the Merchant and of the Cardholder during an EFT backup transaction are identical to
the ones required during the standard BC/MC transaction.
4.8.2. Activation/deactivation/consultation
PDV_COMMAND_REPLY
TINA
–
VMC_COMMAND
/
The Backup Mode shall only be activated on Merchant request and the access to this activation function
shall locally be protected (e.g. by a password mechanism on ECR, etc.) to avoid clients or unauthorised
employees to switch the Terminal into the Backup Mode.
The activation, deactivation or consultation of TINA has to be performed with a VMC_command. The
VMC_command can also be used to consult the EFT mode at all time. There are TINA values for
vic_cmd_code and vic_bit_map_application_id.
4.8.3. Transaction TINA – VMC_debit_request/ PDV_debit_result
In case where the TINA transactions are allowed and the TINA service is activated, a TINA transaction is
possible under some technical conditions.
If the vic_bitmap_application_id is used in the
VMC_debit_request, it must not be TINA but BC/MC like for on-line transaction. Depending in which mode
the transaction happens (on line or off line), the terminal sets vic_bitmap_application_id to TINA or BC/MC
in the PDV_debit_result.
Reference Functional Specifications
VIC Standard
T&P / AR&D
5.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
18 / 75
VIC APPLICATION PROTOCOL
This chapter describes the VIC application protocol, i.e. the protocol of the highest level, between the
External Device and the terminal.
5.1.
Protocol Characteristics
The dialogue between the External Device and the terminal uses messages.
The External Device is considered as the master and the terminal as the slave: most of the exchanges of
messages are done at the initiative of the External Device.
This section describes those messages in detail.
An example of a message is a vmc_debit_request, which is the most important command of the External
Device to the terminal: it allows performing a transaction. Like any other message, this message carries a
message identifier (to be able to distinguish it from other messages). It also carries the requested amount
and other information explained further. The vmc_debit_request message is transmitted from the External
Device to the terminal. The communication protocol will indicate to the External Device that the terminal has
received the message. When the terminal receives the vmc_debit_request message, it will

Identify the message (recognise the message)

Check the message syntax (check the length, check the message contents format)

Check the context (e.g. a vmc_debit_request is refused if the terminal is collecting)
If these checks do not succeed, the message is considered to be bad and the terminal will transmit a
pdv_error message to the External Device.
If these checks do succeed, the terminal will attempt to perform the debit. The result of this attempt will be
communicated to the External Device through the pdv_debit_result message or pdv_error.
The 4 messages

vmc_debit_request,

vmc_cancel,

pdv_debit_result,

pdv_error
Are mandatory messages. They are always necessary to be able to use a terminal with an External Device
(Vending Machine or ECR). They form the minimum protocol.
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
19 / 75
Other messages exist, but are only required for certain features:

The vmc_purse_request and its answer, the pdv_purse_result are required if the External Device
wants information from the card before the transaction is performed and can be used to control the
user interface (e.g. selection of products) or to know the vic_bit_map_application_id (available
services) of the card.

The vmc_command and its answer, the pdv_command_reply, allow the External Device to control
the collection, to ask the current counter values concerning the specified application, to ask
financial information and to change the default settings of the terminal.

The vmc_state_request and its answer, the pdv_state_info allow the External Device to know the
state of the terminal, e.g. collecting, purse inserted.

…
The data elements carried by the messages (like the transaction amount or the vic_tx_id) are called fields.
The contents and use of these fields are explained in the chapter field format.
Each field has a unique serial number for all messages.
Some fields are not always present. See the condition codes section.
Remarks:

The term “product” used hereafter has to be interpreted in its general sense, i.e. it can designate a
product or a service (e.g. soft drink can, use of a car park, telephone call, ….).

The protocol contains elements, which allow for its evolution: an identifier of the protocol version
vic_protoc_id, an identifier for the number of release version vic_version and a bit map vic_bit_map
have been foreseen for this purpose.
Reference Functional Specifications
VIC Standard
T&P / AR&D
5.2.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
20 / 75
A typical example of a transaction flow
BC/MC transaction. (With a vic_bit_map_application_id present)
Exte rnal De v ice
M e rchant Unit
Base Unit
(if connected)
READ CARD
T YPES
READ CARD
MANUEL
card read
vmc_debit_request
PLEASE WAIT
EUR
12.40
CODE : . . . .
code
PLEASE WAIT
BANCONTACT/MCA
ACCEPTED
EUR
12.40
pdv_debit_result
optional
READ CARD
T YPES
MANUEL
READ CARD
T&P / AR&D
5.3.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
21 / 75
Time-out controls
Normal messages flow:
T1
T1
C-ZAM
T2
External Device
Values of the timings:
Time
T1
T2
Time between the CRC(msb) of a message and the
ACK or NAK of the receiver
Time between an ACK from the terminal and a
message from the terminal
Min
(Seconds)
0.01
Typically
(Seconds)
0.1
Max
(Seconds)
1
300
TYPICAL APPLICATION TIME-OUT FOR TERMINAL
FOR T2:
Conditions
Time
Maximum
To insert a card
When it is asked
45 s
To choose
service
45 s
a
To validate the
proton transaction
45 s
To type your code
By pin trial
45s for each key.
Conditions
After a client proton
validation, to accept or
refuse the transaction
No PRINTER End of
a credit transaction
Time max to have a
host connection
For BC/MC or credit
Time max to have a
host response
For BC/MC or credit
Time
Maximum
6 s (max)
The screen remains
5s
Pstn:
135s
Ethernet:
75s
45 s
TIME out if the proton
card is retrieved too
early and the terminal
asks to insert it again
30s
+time
insert
card+time validate
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
22 / 75
TIME TO GO IN IDLE STATE AT THE END OF A TRANSACTION
Conditions
Time
Conditions
Tx BC/MC chip or
proton
accepted
Retrieved card
3s
Tx BC/MC or proton
(refused or accepted)
If the card stays in the
chip reader
BEEP all the 2 s
until the card is
retrieved.
Tx BC/MC refused
and card retrieved
credit card
PRINTER
45 s
( reversal)
5s
2s
Tx proton
refused and
retrieved
If the SMOP is in a
menu
If the C-ZAM/SMASH
sends a STT
Each time, you send a
message to the CZAM/SMASH which is
not in idle
10 s
Credit with printer if
the TICKET key is not
pressed
card
Time
2s
45 s by Time-out and
by level menu.
30 s
Conditions
Credit with printer if
the TICKET key is
pressed and not the
Ok key
TIME out if the proton
card is retrieved to
early and the terminal
asks to insert it again
Time
45 s
30s
Tx BC/MC or proton
accepted
and the ticket option is
activated and card
retrieves.
2s
5.4.
without
Credit tx
with PRINTER after
press OK
Infinite
Condition Codes
In the message description in the next paragraphs, several condition codes are used. The table depicted
below gives an overview.
Conditions
m
o
mandatory
optional
Reference Functional Specifications
VIC Standard
T&P / AR&D
5.5.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
23 / 75
Message Description
This section list the transaction related messages, then the other messages in alphabetical order.
5.5.1. vmc_purse_request
Purpose
The vmc_purse_request message is used by the External Device to get card informations in the following
cases:
 Before asking for purse debit, the External Device wants to know:
 Whether a valid card has been read
 And/or the purse balance
 And/or the cardholder‟s language
 And/or the purse identifier
 Services supported by the card (vic_bit_map_application_id)
Examples:
 A discount is given to certain card holders on the basis of their card number
 The card number is recorded before access to a service for which the payment will be
done later. This allows for a service such as car parking without ticket (the
management is being done by a VMC).
 To know if there is a purse present in the reader, the External Device sends a vmc_purse_request.
Message layout
Field
Nr
1
3
16
20
171
179
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_tx_amt
vic_card_ind
vic_to
vic_bit_map_application_id
vic_version
m
m
m
o
m
m
o
m
Remarks :
vic_tx_amt should be present for contactless transaction. Not used in other case
Vic_to represents the time during which the terminal waits for the introduction of the card.
Vic_version indicates which subversion of the protocol is used.
Conditions for sending
This message is optional for the execution of a transaction.
If a vmc_debit_request is received in a time slot of 30 seconds after a pdv_purse_result message, the
terminal continues the transaction considering the vmc_purse_request is part of the transaction session;
otherwise the two messages are treated as separate transactions.
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
24 / 75
5.5.2. pdv_purse_result
Purpose
The pdv_purse_result message is used by the terminal to indicate the presence of a card and the purse
balance if applicable.
Message layout
Field
Nr
1
4
5
9
10
11
23
141
142
171
179
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
iep_tx_inc
lg_cust
pdv_state
pur_bal
card_id_disp
curcy
vic_pos_entry_mode
iso2_track
vic_bit_map_application_id
vic_version
m
m
m
m
m
m
m
m
m
o
o
m
m
Remarks :
card_id_disp is zero for EMV cards.
Lg_cust can be equal to zero for EMV cards.
If a card without a purse is read the purse balance (pur_bal) is equal to 00 00 00.
The curcy is the currency of the card if there is one. For magnetic card this is the currency of the terminal.
vic_pos_entry_mode is a conditional field. This field will be present if the field vic_tx_amt is present in the
request.
vic_bit_map_application_id is a bitmap. Several bits can be set to indicate the card is a multiservice card ie :
proton purchase(value : 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08) + BC/MC (value: 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 01) = 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09.
Vic_version indicates which subversion of the protocol is used.
Conditions for sending
It is sent by the terminal as reply to a vmc_purse_request message sent by the External Device.
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
25 / 75
5.5.3. vmc_debit_request
Purpose
The vmc_debit_request message is used by the External Device to ask the terminal for the debit of a card
or an account.
The External Device can have a certain control on the means of payment used for the transaction, but we
do not recommend it: this can be done by adding the optional field vic_bit_map_application_id with one or
more bits set according to the means of payment the external device wants to accept.
If a card with multiple means of payment is used for the transaction, the terminal will propose a list.
Message layout
Field
Nr
1
3
11
12
16
20
21
23
25
36
142
143
144
146
171
177
179
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_tx_amt
card_id_disp
tx_type
vic_card_ind
vic_to
vic_tx_id
curcy
vic_cust_ind
vic_data
iso2_track
operator_nr
function_cc
ecr_nr
vic_bit_map_application_id
cvc2
vic_version
m
m
m
m
m
m
m
m
m
m
m
o
o
m
o
o
o
o
m
Remarks :
If Function_cc is not present for an operation with a credit card the default function is „sale‟.
Vic_data is used for credit card hosts, special functions with Banksys host and reference on ticket BC/MC.
The vic_cust_ind indicates whether the client has to approve the transaction – by using the <OK> key –
before it happens (proton only and only if permitted by the acquirer).
Vic_to represents the time during which the terminal waits for introduction of the card.
Vic_version indicates which subversion of the protocol is used.
Conditions for sending
This message is required for the execution of a transaction.
In the exceptional case of no response received from the terminal after acknowledgement of the
vmc_debit_request, the vmc_debit_request shall not be repeated but the External Device has to send a
vmc_cancel message. Typical time-out values are 90 seconds for Leased Line and 180 seconds for dial up.
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
26 / 75
5.5.4. pdv_debit_result
Purpose
This message gives the result of the debit request or can also be the answer to a vmc_cancel message.
Message layout
Field
Nr
1
2
3
4
5
7
8
9
11
13
21
22
23
36
125
126
145
169
170
171
172
173
174
176
178
179
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
term_id
vic_tx_amt
iep_tx_inc
lg_cust
pdv_clct_nr
pdv_gen_tx_nb
pdv_state
card_id_disp
1
sam_gen_tot
vic_tx_id
vic_msg_type
curcy
vic_data
<tx>vic_tx_amt
<tx>curcy
ticket_data
Additional_amount
Transaction_protocol
vic_bit_map_application_id
Transaction_identifier
date_and_time
brand_id
cvm
Brand_name
vic_version
m
m
m
m
m
m
m
o
o
m
m
o
m
m
m
o
m
m
o
o
o
m
o
o
o
o
o
m
Remarks :
Vic_data is present when the Acquirer or the Banksys host sends a SDD and/or a reference and/or an
authorization code.
Ticket_data is present for TINA transaction and some credit card transactions depending on the acquirer.
Lg_cust is the language of the card.
Some applications (Credit Card) do not support yet pdv_clct_nr and pdv_gen_tx_nb.
The field pdv_gen_tx_nb is not yet relevant for credit card transaction.
For Proton this is the number of transactions proton since the beginning of the terminal life.
For BC/MC this is the number of transactions BC/MC in the current period back office.
For TINA, the terminal increments it for each transaction or incident. There may be holes in the
numbering.
1
This field contains information of the cash register used during the payment.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
27 / 75
The field pdv_clct_nr is not yet relevant for credit card transaction.
For Proton this is the collection number.
For BC/MC this is the ”period” depending of the back office
For TINA, This field will be treated separately from BC/MC on line transaction, the period number
contains the value of the current TINA period (remark that there might be holes in the numbering).
The additional_amount is in the currency of curcy field. To have the total of the transaction, look at the field
<tx>vic_tx_amt.
The card_id_disp is the card_id read on the card on the terminal side or sent by the host.
The fields pdv_state and sam_gen_tot are present but only relevant for proton.
Fields: transaction_protocol, transaction_identifier, date_and_time, brand_id are used only in EMV mode for
credit cards. Those fields are present only if they are transmitted by the acquirer or available.
The cvm field is built by emv application.
The date_and_time, Ticket_data fields are also used for TINA transaction.
The brand_name provides the brand label name to the ECR.
Vic_version indicates which subversion of the protocol is used.
Conditions for sending
The pdv_debit_result is sent to answer a vmc_debit_request or a vmc_cancel message.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
28 / 75
5.5.5. vmc_cancel
Purpose
This message cancels certain requests, collects information at the startup of the external device or on the
last transaction if there is any doubt on its outcome.
Message layout
Field
Nr
1
31
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vmc_type
m
m
m
m
Conditions for sending
The External Device may send a vmc_cancel in the following cases:

When the External Device wants to get information about the last debit request command.

All External Devices should send a vmc_cancel to the terminal after a power up

After a pdv_purse_result to avoid using the card data for the next transaction
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
29 / 75
5.5.6. pdv_error
Purpose
This message gives an error on an External Device message.
Message layout
Field
Nr
1
4
9
22
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
iep_tx_inc
pdv_state
vic_msg_type
m
m
m
m
m
m
Conditions for sending
This message is sent in reply to any External Device message when this message cannot be accepted by
the terminal, e.g. illegal message contents, illegal message length or terminal is not in correct state for this
message (e.g. vmc_debit_request while terminal not operational, iep_tx_inc 4009).
This message is sent when an error (e.g. card removed or <STOP> pushed) occurs during the card
recognition.
Depending on terminal setup (VIC or NewVIC), the terminal may also send a pdv_error if it has been
rebooted. In this case:
 The pdv_error will be repeated until it is acknowledged by the external device
 The field vic_msg_type will indicate that the pdv_error is sent due to a terminal reboot
This message can also be sent by the terminal as reply on a vmc_cancel.
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
30 / 75
5.5.7. vmc_command
Purpose
This message is used by the External Device to request the terminal to execute an action.
The required action can be a proton collection, an exchange of functional parameters between the External
Device and the terminal, a demand to the terminal to send the current counter values concerning the
specified couple application/service.
Message layout
Field
Nr
1
17
18
19
23
144
171
Remarks :
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_cmd_code
vic_config_clct_amt
pdv_state_mask
curcy
function_cc
vic_bit_map_application_id
m
m
m
m
o
o
m
o
m
Only one bit of the vic_bit_map_application_id may be set. The action will be performed
for one acquirer or one service (ie: credit counters).
To request information about the current period for a credit card type, the message
vmc_command with function_cc (summary or balance) and vic_bit_map_application_id set
for only one service shall be used.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
31 / 75
Conditions for sending
This message is optional.
The External Device sends a vmc_command message when it wants the terminal to execute an action.
Three different types of „actions‟ can be requested :
- action : configuration
 when the external device wants to modify a functional parameter of the terminal,
e.g. decide the way in which the collection has to be done and/or under which
conditions the External Device wants to receive the pdv_state_info messages.
If this possibility is not used, the terminal uses default values.
If this possibility is used, the external device should send this configuration
request message after every terminal reboot (check value of vic_msg_type in
pdv_error).
- action : counters
 when the external device wants to request the counters for the different means of
payment
- action : collect
 when the external device wants to initiate a Proton collect or retrieve previous
Proton counters
Depending on the action type requested, the following rules concerning presence of fields in the message
apply :
1
17
18
19
23
144
171
Vic_protocol_id
Vic_msg_code
Vic_bit_map
Vic_cmd_code
Vic_config_clct_amt
Pdv_state_mask
Curcy
Function_cc
Vic_bit_map_application_id
Config
Counters
(credit card)
M
M
M
M
M
M
M
M
M
M
M
M
M
M
M
Counters
(BCT/MC or
proton)
M
M
M
M
Collect
M
M
M
M
M
M
M
M
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
32 / 75
5.5.8. pdv_command_reply
Purpose
This message is the response of the terminal to the vmc_command message sent by the External Device.
Message layout
Field
Nr
1
4
6
7
9
23
45
145
157
171
175
Remarks :
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
iep_tx_inc
pdv_clct_info
pdv_clct_nr
pdv_state
curcy
pdv_journ_pct_full
ticket_data
counter_tab_pa
vic_bit_map_application_id
hardware_type
m
m
m
o
o
o
o
o
o
o
o
m
o
The value for iep_tx_inc concerns the counters repatriation, the new config completion.
For counter request: In one message, only one service could be invoked, this corresponds to
one counter for one period.
In case counter values are not available for the specified service, the pdv_command_reply
message doesn‟t contain the field counter_tab_pa (that is the reason why this field is
optional) and the iep_tx_inc is not present.
Conditions for sending
This message is always sent in reply to a vmc_command message.
Depending on the action type requested, the following rules concerning presence of fields in the message
apply :
Config
1
4
6
7
9
23
45
145
157
171
175
Vic_protocol_id
Vic_msg_code
Vic_bit_map
Iep_tx_inc
Pdv_clct_info
Pdv_clct_nr
Pdv_state
Curcy
Pdv_journ_pct_full
Ticket_data
Counter_tab_pa
Vic_bit_map_application_id
Hardware_type
M
M
M
O
M
M
Counters
(credit card)
M
M
M
O
Counters
(BC/MC or proton)
M
M
M
O
O
O
O
O
O
M
M
M
Collect
M
M
M
M
M
M
M
M
M
M
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
33 / 75
5.5.9. vmc_data
Purpose
This message is exchanged between terminal and the External Device either during a collection or when
data must be transferred to a host or to a specific application loaded in the terminal.
Should be used for routing to Added applications
Message layout
Field
Nr
1
36
37
38
39
44
171
Remarks :
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_data
vic_block_nr
vic_more_block_ind
vic_action_ind
vic_file_name
vic_bit_map_application_id
m
m
m
m
o
o
o
o
o
vic_block_nr, vic_more_block_ind, vic_action_ind and vic_file_name are mandatory in case
of off-line collection and are not present in the other cases.
Vic_bit_map_application_id is mandatory in case of full pass through mode for AA and is
not present in case of collection.
Conditions for sending
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
34 / 75
5.5.10. pdv_data
Purpose
This message is exchanged between terminal and the External Device either during a collection or when
data must be transferred from a host or from a specific application loaded in the terminal to an External
Device.
Message layout
Field
Nr
1
36
37
38
39
44
171
Remarks :
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_data
vic_block_nr
vic_more_block_ind
vic_action_ind
vic_file_name
vic_bit_map_application_id
m
m
m
m
o
o
o
o
o
vic_block_nr, vic_more_block_ind, vic_action_ind and vic_file_name are mandatory in case
of off-line collection and are not present in the other cases.
Vic_bit_map_application_id is mandatory in case of full pass through mode and is not
present in case of collection.
Conditions for sending
Reference Functional Specifications
VIC Standard
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
35 / 75
5.5.11. vmc_state_request
Purpose
This message is used when the External Device wants to request the terminal state.
Message layout
Field
Nr
1
171
Remark :
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
vic_bit_map_application_id
m
m
m
o
The field vic_bit_map_application_id has to be present for AA only.
Conditions for sending
This message is optional.
The External Device can send a vmc_state_request message when it wants to know the terminal state.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
36 / 75
5.5.12. pdv_state_info
Purpose
This message gives information about the terminal state.
Message layout
Field
Nr
1
4
9
22
Condition
Name
vic_protoc_id
vic_msg_code
vic_bit_map
iep_tx_inc
pdv_state
vic_msg_type
m
m
m
m
m
m
Conditions for sending
This message is always sent in the following cases :

reply to the vmc_state_request message

unsolicited message (refer to description of the field pdv_state_mask to know about the conditions
of sending this message)
Reference Functional Specifications
VIC Standard
T&P / AR&D
5.6.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
37 / 75
Field format
This section lists the data elements format conventions.
5.6.1. a field
ASCII fields need 7 bits per element, they are converted to one byte per character, right justified, and the left
most bit is always 0. (0x00->0x7F)
5.6.2. b field
Boolean fields need one bit per element, they are converted to one byte per 8 bits, left justified (bit one at
most significant bit position), padded with 0.
A b+ field indicates an extensible field, depending on the value of the first bit (usually used for bitmaps).
5.6.3. I field
Integer fields need 4 bits per element; they are converted to one byte per 2 digits, right justified, padded with
0.(Binary coded decimal BCD)
5.6.4. x field
Hexadecimal fields need 4 bits per element, they are converted to one byte per 2 digits, right justified,
padded with 0.
5.6.5. llvar field
In this format, the first byte of the field contains the field length in bytes (ll is of type 2i). The length indicated
in ll does not include the length of ll itself.
The total length of a field of format llvar is thus the length of the data in the field + 1 byte.
Example : 03 11 22 33
5.6.6. llllvar field
In this format, the first two bytes of the field contain the field length in bytes (llll is of type 4i). The length
indicated in llll does not include the length of llll itself.
The total length of a field of format llllvar is thus the length of the data in the field + 2 bytes.
Example : 0009 11 22 33 44 55 66 77 88 99
5.6.7. Summary
Format
a
b
I
x
llvar
Values
7 bits ASCII
false, true
0...9
0...9,A...F
0…9 (ll)
Justification
right
left
right
right
-
Padding
0
0
0
-
llllvar
0...9 (llll)
-
-
Remark
false = 0, true = 1
ll contains length of
data
llll contains length
of data
Reference Functional Specifications
VIC Standard
T&P / AR&D
5.7.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
38 / 75
Dictionary
This section lists the data elements in alphabetical order.
Convention used in the current section :
When the text appears in grey, it means that
the field is not yet used because the message including it is not yet supported
or the field is not used even if the message including it is supported.
5.7.1. additional_amount
Name :
Format :
additional amount (Tip)
6x
Definition :
This field is used, when a sale with tip (function_cc field) was requested and the customer
has decided to give a tip, for credit card transaction only and only if it is supported by the
acquirer. The additional_amount is in the currency of the field tx_curcy.
The additional amount defines the tip amount debited in the current transaction.
5.7.2. application_info
Name :
Format :
application information table
llllvar rt
Sub-structure definition
Field
data length
Fld_hdr
nb_record
file_updt_code
level2_bitmap
Format
4i
vic_bit_map_application_id
vic_application_srv_name
32x
16a
Level2_bitmap bit nr
1
2i
1i
16b+
2
3
Where :
fld_hdr:
nb_record:
file_update_code:
level2_bitmap:
 field header composed with
 number of record(s) included
in this table
 indicates the operation that
must be performed on the
content of the table

 bitmap
indicating
the
presence of the level2 fields
Where each record contains :
An application identification with one of the services available through this application.
The service name for each service (associated to an application) supported by the
terminal, these values are given. An application can provide several service(s) and a
service can be provided by several application(s). Obviously, the name of a couple
application/service must be unique and must be clear for the user.
Definition:
The Application Information gives information about the applications and services
supported by the terminal.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
39 / 75
5.7.3. brand_id
Name :
Format :
brand id
4x
Definition:
This field identifies a service. The different values are defined by EPCI. Here the values
known at this time (the number and content of the value can change in function of
the evolution of the market at the discretion of EPCI) :
1001
1002
1009
1010
2002
2003
2004
2005
2007
3001
Bancontact/MCA
Visa Electron
Maestro
Proton
Visa
Mastercard
American Express
Diners
JCB
Aurora
5.7.4. brand_name
Name :
Format :
Value :
brand name
llvar
any ASCII characters
Definition:
The field brand_name contains the brand label name of the card that was used for the
transaction
5.7.5. card_id_disp
Name :
Format :
Values :
Card Identification
24a
This field is left blank if the field iep_tx_inc is different from zero
Definition :
This field contains an identification of the card inserted in the terminal in a ready to print
format.
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
40 / 75
5.7.6. counter_tab_pa
Name :
Format :
financial counter table
llllvar rt
Sub-structure definition
Field
data length (in bytes)
Format
4i
level2_bitmap bit nr
fld_hdr
nb_record
file_updt_code
level2_bitmap
counter_id
counter_curcy
counter_name
tot_tx
tot_amount
terminal_period
2i
1i
16b+
4i
4i
16a
4i
8x
4i
2
3
4
5
6
7
brand_id
4x
9
1
where:
Definition :

fld_hdr:
 nb_record:
 file_update_co
de:
 level2_bitmap:


counter_id:
counter_curcy:


counter_name
tot_tx

tot_amount:

terminal_period

brand_id
field header composed with
number of record(s) included in this table
indicates the operation that must be
performed on the content of the table
bitmap indicating the presence of the level2
fields
identifies the current counter
indicates the currency used for the current
counter
indicates the name of the current counter
indicates the total number of valid
transactions in the current accounting period
for the current counter
indicates the total amount of transactions in
the current accounting period
for the current counter
indicates the number of the current
accounting period
identifies the brand associated to the current
counter
This table gives information about one or more counter(s) related to a couple
application/service.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
41 / 75
5.7.7. curcy2
Name :
Format :
Values :
Currency Code
4i
Euro (EURcent)
Definition :
The values refer to the ISO 4217 standard.
<tx>curcy is the currency of the transaction between the terminal and the card.
0978
5.7.8. cvc2
Name :
Format :
Values :
Card validation code 2
4i
0000-9999
Definition :
The cvc2 may be required for certain type of EMV credit card transactions depending on
the acquirer.
5.7.9. cvm
Name :
Format :
Values :
cardholder verification method
4x
xx AB
A
With cardholder signature required
Without cardholder signature required
default
1
2
0
B
With pin
Without pin
default
1
2
0
The default value for the most significant byte is 0x00. Other values are not yet used.
Definition:
This field informs the external device about the way the transaction was validated.
5.7.10. date_and_time
Name :
Format:
Values:
Date and time
14i
The format of this field shall be “YYYYMMDDhhmmss” where “YYYY” are the four digits
of the year, “MM” are the two digits of the month, “DD” are the two digits of the day, “hh”
are the two digits of the hour, “mm” are the two digits of the minutes, and “ss” are the two
digits of the seconds.
Definition:
The value refers to the time of authorisation by the acquirer.
For TINA, Reference to [BKS D110-TN1] : date and time
2
Or <tx>curcy
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
42 / 75
5.7.11. ecr_nr
Name :
Format :
ECR nr
2i
Definition :
number of the Electronic Cash Register.
Some multi-terminal configurations use this value to identify a terminal in a more
user friendly way.
5.7.12. function_cc
Name :
Format :
Values :
Function code
2a
Vmc_debit_request
“ “ : sale (20hex, 20hex)
“00” : sale cancellation (on the terminal
which has delivered the sale)
“02” : reservation
“03” : Sale after reservation
“04” : reservation cancellation
“05” : Sale after reservation cancellation
“07” : reprint of the last ticket
“08” : Summary
“09”: Card validity check
”10”: Sale with tips
“11”: Refund (Not necessarily on the
terminal which has delivered the sale)
“12”: Cash advance (for future use)
“13” : balance with closing
Definition :
Vmc_command
x
x
x
x
x
x
x
x
x
x
x
x
x
The function code identifies the type of transaction that will be sent to the credit host. The
values are under the responsibility of the acquirers and are not interpreted by the terminal
Associated to the selected function, a reference (like an authorization code) can be
requested depending on the acquirers: This reference is sent in the field vic_data.
The function_cc “07” and “08” are supported only on SMASH Terminals.
5.7.13. hardware_type
Name :
Format :
Hardware_type
2i
Values :
CZAM/SPIN with manual reader
CZAM/SPIN with motorized reader
CZAM/SMASH
XENTA
XENTEO with manual reader
XENTEO with motorized reader
Other
Definition :
Define the type of CZAM hardware
01
02
03
04
05
06
00
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
43 / 75
5.7.14. iep_tx_inc
Name :
Format :
Values :
Transaction Incident
4i
Result OK:
0000
Result Unknown :
Transaction status forwarded to external device without
interpretation by the terminal(credit card)
5015
Request not taken into account terminal busy:
Bad protocol state(terminal busy with the previous action)
4009
Result Not Ok
Technical Problem
Entered amount invalid
iep_host_id not valid
pur_id_ac_pub error
purse in red list
purse is locked for credit
purse is locked for debit
Purse expired
ICC state error
recovery error
purse key identifier error
purse balance is too large
pur_id_ext_ac_pub error
No purse in reader and time out expired
No validation by the customer and time out expired
Request aborted by the VMC
Insufficient purse balance
Bad value in a field
Invalid message length
Application not supported
Time-out on fallback card reading
Technical problem
Rejection by the host
Double operation (consecutive transactions with same amount and same card)
Technical problem at host level
Unrecoverable problem
Stop customer
Invalid currency
Rejection by the terminal
Communication problem (wrong phone nr,...)
Rejection of balance request (only C-ZAM/SMASH/PTI)
Floor limit exceeded (credit card)
Transaction refused by the terminal in EMV mode (credit card)
Transaction refused by the card (credit card)
The „Maximal Transaction Number per (Calendar) Month‟ is reached
The maximal number of uncollected journals in terminal reached
Service TINA (already) activated
Service TINA (already) deactivated
Acquirer does not support service activation
Maximum transaction records is reached
Maximum number of TINA activation reached
Amount higher than authorized amount
Problem linked to card
1501
1503
1504
1505
1506
1508
1509
1512
1513
1516
1517
1518
1520
4001
4002
4004
4005
4006
4008
4010
4011
5001
5002
5003
5004
5005
5006
5008
5009
5010
5011
5012
5013
5014
5016
5017
5018
5019
5020
5021
5022
5023
5024
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Incident codes for Added Application
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
44 / 75
7000 7999
see document [VIC_iep_tx_inc]
Definition :
The Transaction Incident indicates if the operation succeeded or not. If the operation didn‟t
succeed, it indicates the kind of problem encountered.
5.7.15. iso2_track
Name :
Format :
Iso2 track field
38x
Definition :
Left justified, padded with F hex
The first byte should be 0x5D (“]”)and the card number should be terminated by
D hex and followed by the date (mmyy). The rest has to be padded with “NULL”
This field is only used for a manual sale (mail order) request by an External
device.
5.7.16. lg_cust
Name :
Format :
Values :
Customer (Card Holder) Language
1i
Unknown
Dutch
French
German
English
Definition :
This field indicates the language of the card holder.
0
1
2
3
4
5.7.17. more_info_ind
Name :
Format :
Values :
more information indicator
2x
00H
transfer of information data terminated
80H
another information data block will follow
Definition :
Indicates if another information data block will follow after the current one.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
45 / 75
5.7.18. operator_nr
Name :
Format :
Values :
Definition :
Operator identifier
4i
0001..9999
This number identifies the operator.
Some multi-terminal configurations use this field to manage counters per
operator
5.7.19. pdv_clct_info
Name :
Format :
PDV Collection Information
llllvar 32 or 80 (depending on the value of vic_cmd_code)
Sub-structure definition
OR
Field
data length (in bytes)
Format
4i
tx_nb_0
ddmm_0
tot_0
...
tx_nb_1
ddmm_1
tot_1
...
tx_nb_3
ddmm_3
tot_3
...
tx_nb_9
ddmm_9
tot_9
4x
4i
8x
…
4x
4i
8x
…
4x
4i
8x
…
4x
4i
8x
Value
0032 when 4 periods
0080 when 10 periods
where:
Definition :

tx_nb_0

ddmm_0

tot_0



tx_nb_x
ddmm_x
tot_x
indicates the total number of valid transactions in the current
accounting period (pdv_clct_nr)
indicates the date (day / month) of the beginning of the current
collection number
indicates the total amount of transactions in the current collection
number (expressed in the currency stated in pdv_command)
indicates the total number of transactions in the P-x period
indicates the date (day / month) of the beginning of the P-x period
indicates the total amount of valid transactions in the P-x period
(expressed in the currency stated in pdv_command)
The PDV Collection Information gives information about the last PDV collections.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
46 / 75
5.7.20. pdv_clct_nr
Name :
Format :
Values :
Definition :
PDV Collection Number
3i
Excepted 4i for
- TINA transactions
- Transactions managed via the EFT Server (IFSF)
not defined
000 or 0000
otherwise
001..999 or 0001..9999
Serial number of the accounting period, returns to 1 after 999 (or 1 to 9999).
Also appears on the merchant bank statement.
For Proton it is the collection number.
For BC/MC it depends upon the period back office.
For TINA, This field will be treated separately from BC/MC on line transaction and
this period number contains the value of the current TINA period (remark that there might
be holes in the numbering). Reference to [BKS D110-TN1] : batch number
Not yet used and not present for Credit cards.
For transactions managed by the EFT Server it‟s the period number
5.7.21. pdv_gen_tx_nb
Name :
Format :
Values :
General Transaction Number
8x
For Proton this is the number of transactions proton since the beginning of the terminal
life.
For BC/MC this is the number of transactions BC/MC in the current period back office.
For TINA, this represents the sequence of the transaction in the current transaction log
identified by pdv_clct_nr (= batch number).
For Credit cards : not yet used and not yet present.
Definition :
The Purchase Device General Transaction Number contains the total number of valid
transactions.
There is a separate pdv_gen_tx_nb for Proton, for BC/MC transactions and for and EMV
transactions.
In case of a proton transaction the pdv_gen_tx_nb refers to the total number of proton
transactions.
The pdv_gen_tx_nb field contains only the accepted transactions, except for TINA
transaction.
For TINA, the terminal increments it for each transaction or incident. there may be holes
in the numbering. Reference to [BKS D110-TN1] : sequence number
Caution : For Proton, there is NO reset of this number when the pdv_clct_nr changes.
5.7.22. pdv_journ_pct_full
Name :
Format :
Values :
terminal Journal Percentage Filled with transactions
2i
00 …99
Definition :
The field pdv_journ_pct_full contains the percentage of the journal capacity which is filled
with Proton transactions.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
47 / 75
5.7.23. pdv_state
Name :
Format :
Values :
Purchase Device State
32b
When the condition is true, the corresponding bit is set to 1
bit 2
Card or object inserted
bit 12
Collection started (Proton only)
bit 15 & bit 16
collection error (Proton only)
other bits
not relevant
Definition :
The Purchase Device State indicates the function state of the specified application in the
terminal.
5.7.24. pdv_state_mask
Name :
Format :
Values :
Purchase Device State Mask
32b
When the condition is true, the corresponding bit is set to 1
bit 2
Card or object inserted
bit 12
Collection started (Proton only)
Definition :
Every bit in the Purchase Device State Mask indicates if an unsolicited pdv_state_info
message shall be sent when the corresponding bit has changed since the last time the
pdv_state field has been sent to the External Device in any PDV message.
5.7.25. pur_bal
Name :
Format :
Values :
Purse Balance
6x
Except if service Proton is present on the cardholder, this value is set to zero.
Definition :
The Purse Balance defines the amount of electronic money in the Purse of the inserted
card. The purse balance is expressed in the currency of the field curcy.
This field is left zero if the field iep_tx_inc is different from zero
5.7.26. sam_gen_tot
Name :
Format :
Values :
SAM General Total
8x
Definition :
The SAM General Total defines the total amount of Electronic Money collected for all the
Purchase Transactions in the transaction currency since the very beginning of the SAM
life.
5.7.27. term_id
Name :
Format :
Terminal Identification
8i
Definition :
A Terminal Identification is assigned to every terminal.
It is used to identify the terminal administratively.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
48 / 75
5.7.28. ticket_data
Name :
Format :
Ticket data
llllvar a
Definition :
This field contains (in a "ready for print" format) information about the transaction.
The contents of this field have to be either displayed on the External Device
screen, either printed on the External Device printer, depending on the special
characters present.
The maximum width of printable data will not exceed 38 chars.
The maximum length of this field is 999 bytes.
The special characters the ticket_data may contain are:
(04 hex)
: Double height
LF (0A hex)
: line feed
VT n (0B hex) : Vertical tabulation: advance n lines
FF (0C) hex) : form feed
CR (0D hex) : carriage return
SO (0E hex) : expanded characters:
all data after SO are printed in double width
cancelled by LF, CR, FF, VT, DC3 and DC4.
DC1 (11h hex) : printer select
DC3 (13 hex) : printer deselect
DC4 (14hex) : cancel expanded mode
CAN (18h)
: buffer clear
10 hex
: Blank
<ESC> „L‟ : (1Bhex 4Chex) : set left margin to position 0=<n=<38
<ESC> „N‟ : (1Bhex 4Ehex) : set bottom margin to n lines
<ESC> „O‟ : (1Bhex 4Fhex) : cancel bottom margin set by ESC „N‟
<ESC> „P‟ : (1Bhex 50hex) : set page length to n lines
For TINA, In case the transaction is registered (as accepted at terminal level), the
terminal also formats the „ticket data‟ field.
Reference to [BKS D110-TN1] : R3D (R3 purse element) + KECS (key entry
checksum)
5.7.29. transaction_identifier
Name :
Format :
Values :
transaction_identifier
8i
00000000 =< t0= <99999999
Definition :
The transaction identifier field contains a unique reference number that is provided by the
Acquirer.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
49 / 75
5.7.30. Transaction_protocol
Name:
Format:
Values:
transaction_protocol
4x
xx AB
A
Chip
Magnetic
Magnetic in fall back mode
default
1
2
3
0
B
Off line
1
On line
2
Off line after communication failure
3
default
0
The default value for the most significant byte is 0x00. Other values are not yet used.
Definition:
The field informs external device about the way the transaction was authorised.
5.7.31. tx_type(14)
Name :
Format :
Definition :
Purse Transaction Type
2x
Normal transaction
04
Force on line transaction (credit transaction)
08
H
H
This field is used to define transaction type.
5.7.32. vic_action_ind
Name :
Format :
Values :
VIC action indicator
2x
no action (only used by PDV):
file transfer from PDV to external device (file *.TH):
file transfer from external device to PDV (file *.HT):
send file transfer instruction (only used by VMC):
Definition:
Instruction code that is used during file transfer: the VMC asks the PDV to send an
instruction. The PDV answers with the instruction code of the required action.
00H
01H
02H
FFH
5.7.33. vic_application_srv_name
Name :
Format :
Values :
application service name
16a
Any
Definition :
The value of this field can be displayed to identify in an unambiguous way a service
towards the client and to facilitate his choice between two or more services.
(14)
The sliced transactions may not be used without explicit approval of Banksys.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
50 / 75
5.7.34. vic_bit_map
Name :
Format :
VIC Bit Map
64b+ (multiples of 64 bits)
Definition :
The bit corresponding to the field number is set for every field present in a message. The
first bit of each 64 bits group is an exception: it is set if another 64 bits bitmap is following
this one (allowing extensions of the vic_bit_map field size).
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
51 / 75
5.7.35. vic_ bit_map_application_id
Name :
Format :
Values :
VIC bit map application identification
128 bits
hexa
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 01
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 02
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 04
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 08
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 10
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 20
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 40
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 80
00 00 00 00 00 00 00 00 00 00 00 00 00 00 01 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 02 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 04 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 08 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 10 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 20 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 40 00
00 00 00 00 00 00 00 00 00 00 00 00 00 00 80 00
00 00 00 00 00 00 00 00 00 00 00 00 00 01 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 02 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 04 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 20 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 40 00 00
00 00 00 00 00 00 00 00 00 00 00 00 00 80 00 00
00 00 00 00 00 00 00 00 00 00 00 00 01 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 02 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 04 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 08 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 10 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 20 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 40 00 00 00
00 00 00 00 00 00 00 00 00 00 00 00 80 00 00 00
00 00 00 00 00 00 00 00 00 00 00 01 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 02 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 04 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 08 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 10 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 20 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 40 00 00 00 00
00 00 00 00 00 00 00 00 00 00 00 80 00 00 00 00
00 00 00 00 00 00 00 00 00 00 01 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 02 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 04 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 08 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 10 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 20 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 40 00 00 00 00 00
00 00 00 00 00 00 00 00 00 00 80 00 00 00 00 00
00 00 00 00 00 00 00 00 02 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 04 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 08 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 10 00 00 00 00 00 00 00
00 00 00 00 00 00 00 00 20 00 00 00 00 00 00 00
80 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Definition :
Identification value
BANCONTACT/MCA
MAESTRO
PROTON (load)
PROTON (purchase)
VISA
EUROCARD/ MASTERCARD
AMERICAN EXPRESS (AMEX)
DINERS
JCB (JAPANESE CARD BUREAU)
National Company
International Company
FNAC
Smart Shopper
M-BANXAFE
Visa electron
Cirrus
Visa cash
Clip
Aurora
SIS BPA Application
Eloyse Application I and II
Pass CREDIT (PLC)
Pass CASH (PLC)
Pass
Pass promo 1
Pass promo 2
TINA
EIC (electronic identity card)
Exxon (PLC)
Cora Xenta
Pass promo 3
Pass promo 4
Pass promo 5
Pass promo 6
Pass promo 7
Pass promo 8
Pass promo 9
Pass promo 10
Pass promo 11
Pass promo 12
Pass promo 13
Pass promo 14
Pass promo 15
Pass promo 16
Visa VPAY
EZSwitch
Pay Fair
e-pass (Sodexo brand)"
Accor Services
Reserved
Reserved
Reserved
This field is a bit map. The position of the bit set, corresponds to an identification value.
This value identifies the application(s) present on a card with multiple applications. The
providers assign a unique identification to every application or brand.
For Example: In a pdv_purse_result, if the card inserted is a hybrid card with BC/MC and
proton purchase services and the terminal has these services activated, the
vic_bit_map_application_id will be 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 09.
T&P / AR&D
Reference Functional Specifications
VIC Standard
vic_bit_map_applic
ation_id present in
message coming
from the External
device
no
yes
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
52 / 75
Action on terminal
routed to the default application.
In case multiple card services are supported by the card,
the choice is proposed to the card holder on the
terminal.
Check the compatibility between the bit set by the ECR,
the services on the card and the application recognition.
If it succeeds the terminal proposes services or
payments choice.
5.7.36. vic_block_nr
Name :
Format :
Values :
VIC block number
2x
00H -> FFH
Definition :
For the transmitter: the number of the block sent (starts at 01H)
For the receiver: the block number received (starts at 00H)
5.7.37. vic_card_ind
Name :
Format :
Values :
VIC Card Indicator
1i
Card_withdrawal_not_requested
Card_withdrawal_requested
Card_not_needed
Display_brand_choice and card_withdrawal_requested [addendum vic pass]
Definition :
The VIC Card Indicator indicates whether the customer will be asked to retrieve his card
or not after the terminal has performed the action requested by the External Device.
Normally, the value is 1 for a vmc_debit_request and 0 for a vmc_purse_request.
Card_not_needed can be used e.g. when asking totals for Credit Card to avoid the
reading of a card on the terminal side.
The vic_card_ind is not taken into account in all messages.
5.7.38. vic_cmd_code
Name :
Format :
Values :
0
1
5
6
VIC Command Code
4x
If supported by the terminal (C-ZAM/SMASH/PTI), perform
immediately a balancing
Info request (4 periods) to get back collection information
0008
Info request (10 periods) to get back collection information
A000
Info request (4 periods) & collect immediately on line
4001
Info request (10 periods) & collect immediately on line
A001
H
4000
H
H
H
H
T&P / AR&D
Definition :
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
53 / 75
Info request (4 periods) & collect next night on line
4002
Info request (10 periods) & collect next night on line
A002
Config
C000H
Counters
B000H
Service activation request
E000H
Service deactivation request
E001H
Service consultation request
E002H
H
H
The VIC Command Code indicates the action the External Device requires the terminal
to do.
T&P / AR&D
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
54 / 75
5.7.39. vic_config_clct_amt
Name :
Format :
Values :
VIC Configuration Collection Amount
8x
Collection initiated by the terminal
00000000
H
Automatic collection by the terminal next
night when this amount is reached
> 00000000 and <= 000FFFFF
Not supported
> 00100000 and <= FFFFFFFE
Collection initiated by the External Device
H
H
3
H
H
FFFFFFFF
H
Example : 500 € is equivalent to 0000C350
H
Definition :
The VIC Configuration Collection Amount indicates whether the collection is initiated by
the External Device or by the terminal or automatically when a specified amount is
reached.
5.7.40. vic_cust_ind
Name :
Format :
Values :
VIC Customer OK Indicator
1i
Customer_OK_needed
Customer_OK_unneeded
Definition :
3
1
0
The Customer OK Indicator indicates whether or not the customer has to approve the
transaction–- by using the <OK> key–- before it happens.
Acquirer has to approve the setting of this parameter.
The default value is 1.
Only used in case of Proton transaction.
In this case the terminal will not start a collection on its own initiative. A collection can however be started via VIC or via the keyboard
(for operator).
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
55 / 75
5.7.41. vic_data
Name :
Format :
VIC data
llllvar
Max length: 999
Sub-structure definition in case of transfer to or from Banksys host (discretionary data)
Field
data length (in bytes)
set_of_data (SD)
Format
4i
llvar
Value
0001..0199
Subfield
data length (in bytes, this byte not include)
Type code
Format
2i
2i
Value
01..99
See
description
below
Data
See description below
The SD field is composed of:
Type code value :
01: presence of a cash back amount. (not yet used)
Data value (7x) represents the amount of the cash back transaction
currency = value of field curcy
02: presence of product code shop
Only used in case of Company cards.
Maximum 4 different shop data with the following format are allowed
Shop_code
Shop_amount
2i
6x currency = curcy
03: presence of petroleum data
Only used in case of Company cards.
Volume (expressed in centilitres)
6i
Unit_price (xxx.xxx EUR/litre or xxxx.xx BEF/litre)
Product_code
Product_name
6x currency = curcy
2i
16a
04: presence of a set of merchant reference
Merchant references are reference that the merchant can use to have a personal
mechanism to identify the transaction.
length max 98
Reference1 Reference2 Reference3 …
Var a
05: presence of discretionary data
length max 80
discretionary_data
Var a
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
56 / 75
06: presence of an authorization code
The authorization code is a reference that the host uses to identify an operation. If
the merchant wants make reference of a previous operation (e.g. a sale) during the
current operation (e.g. cancel of the sale), it uses the authorization code of the
previous operation
length max 6
Authorization Code
Var a
A combination of code in the same instance of vic_data is allowed. The same tag
can‟t be used twice.
E.g : 3304reference1;reference2;reference3 1105abcde12345 0706auth12
In case of collection (not yet used)
contains collect informations
Reference document : “PROTON Reference Functional Specifications Chapter 5.9–- VIC
extension for off-line collection via the operator network”.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
57 / 75
5.7.42. vic_file_name
Name :
Format :
Values :
VIC file name
12a
1..8a + “.” + 1..3a, right padded with 20x (space character)
Definition:
The field vic_file_name contains the name of the file that has to be or is being transferred.
5.7.43. vic_more_block_ind
Name :
Format :
Values :
VIC more block indicator
1i
more data blocks to follow:
transfer terminated, last block sent:
Definition:
Specifies if more data blocks will follow
1
0
5.7.44. vic_msg_code
Name :
Format :
Values :
VIC Message Code
2a
pdv_command_reply
pdv_data
pdv_debit_result
pdv_error
pdv_purse_result
pdv_state_info
vmc_cancel
vmc_command
vmc_data
vmc_debit_request
vmc_purse_request
vmc_state_request
Definition:
PM
PO
PD
PE
PP
PS
VC
VM
VO
VD
VP
VS
The VIC Message Code identifies the message exchanged between the External Device
and the terminal.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
58 / 75
5.7.45. vic_msg_type
Name :
Format :
Values :
VIC Message Type
8b
Default
Duplicate message
Unsolicited
Startup
Definition :
The VIC Message Type provides additional info about the reason why the message was
sent :

Unsollicited is used to indicate that the terminal sent the message without
request from the External Device.

„Startup‟ is used to indicate the pdv_error is sent because the terminal is starting
up.
(18)

„Duplicate message‟ is used to indicate the pdv_debit_result is a repetition of a
previously transmitted identical message (possibly not received by the External
Device).
0000 0000
1xxx xxxx
x1xx xxxx
xx1x xxxx
x = not relevant
5.7.46. vic_pos_entry_mode
Name :
Format :
Values :
VIC Point-of-service entry mode
2i
Code
00
01
02
05
07
91
Definition :
Meaning
Unspecified (undefined or unknown)
Manual entry
Magstripe entry
Icc (Chip with contact)
Contactless Chip
Contactless Mag Stripe
The VIC Point-of-service entry mode inform about the way that the card information data
was entered or obtained.
5.7.47. vic_protoc_id
Name :
Format :
Values :
VIC Protocol Identification
4x
VIC protocol version 01.07
Definition :
The VIC Protocol Identification identifies the protocol version for compatible upgrade
management.
The External Device software shall take this into account and check on the value of
vic_protoc_id sent by the terminal.
(18)
Excluding repetitions by the communication layer.
0107
H
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
59 / 75
5.7.48. vic_to
Name :
Format :
Values :
VIC Time Out
4x
immediate response
wait delay (in seconds)
Definition :
0000H
> 0014 and < 002D
H
H
The VIC Time Out indicates the maximum time available to the terminal to execute the
reading of the card in seconds.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
60 / 75
5.7.49. vic_tx_amt4
Name :
Format :
Values :
VIC Transaction Amount
6x
left zero if the field iep_tx_inc is different from zero.
Definition :
The vic_tx_amt defines the amount debited in the current transaction, in the currency
used by the External Device.
The field <tx>vic_tx_amt contains the amount in the currency used for the transaction.
In case the currencies are different, the External Device can take into account the
conversion done by the terminal.
If a tip is granted by the customer, the field <tx>vic_tx_amt will contain the amount with
tip, the field vic_tx_amt will contain the original amount (not yet supported)
5.7.50. vic_tx_id
Name :
Format :
Values :
VIC Transaction Identification
8x
00000001 -> FFFFFFFF
Definition :
The VIC Transaction Identification is assigned to all debit messages depending to the
same transaction.
It allows the External Device to match a vmc_debit_request message and its response.
It should be changed by the External Device for each new transaction.
The terminal does not check the value of this field. It only echoes the value received in
the vmc_debit_request in the corresponding pdv_debit_result message.
H
H
5.7.51. vic_version
Name :
Format :
Values :
VIC version
2i
Any value
Description :
The field vic_version indicates which release version of the VIC version the ECR and the
terminal use.
E.g. the value for this version is 11.
5.7.52. vmc_type (only relevant for CZAM/SPIN)
Name :
Format :
Values :
Vending machine type
6x
Bytes 1 and 2: Vendor/Machine
Byte 3: Version number
Those values are available in the vmc_type list document. [VIC_vmc_type]
4
Or <tx>vic_tx_amt
-1 vic_msg_code
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
61 / 75
2a
pdv_data
vmc_data
pdv_state_info
vmc_state_request
pdv_command_reply
vmc_command
pdv_error
vmc_cancel
pdv_debit_result
vmc_debit_request
pdv_purse_result
Messages contents summary
vmc_purse_request
Field
5.8.
Format
T&P / AR&D
Nr
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
VP PP VD PD VC PE VM PM VS PS VO PO
(x56 (x50 (x56 (X50 (x56 (x50 (x56 (x50 (x56 (x50 (x56 (x50
x50) x50) x44) x44) x43) x45) x4D) x4D) x53) x53) x4F) x4F)
1 vic_bit_map
64b+
m
m
m
m
m
m
m
m
m
m
m
m
2 term_id
8i
m
3 vic_tx_amt
6x
o
m
m
4 iep_tx_inc
4i
m
m
m
o
m
5 lg_cust
1i
m
m
6 pdv_clct_info
82/34 bytes
o
7 pdv_clct_nr
4i
o
o
8 pdv_gen_tx_nb
8x
o
9 pdv_state
32b
m
m
m
o
m
10 pur_bal
6x
m
11 card_id_disp
24a
m
m
m
12 tx_type
2x
m
13 sam_gen_tot
8x
o
16 vic_card_ind
1i
m
m
17 vic_cmd_code
4x
m
18 vic_config_clct_amt
8x
o
19 pdv_state_mask
32b
o
20 vic_to
4x
m
m
21 vic_tx_id
8x
m
m
22 vic_msg_type
8b
m
m
m
23 curcy
4i
m
m
m
m
o
25 vic_cust_ind
1i
m
31 vmc_type
6x
m
36 vic_data
llllvar
o
o
m
m
37 vic_block_nr
2x
o
o
38 vic_more_block_ind
1i
o
o
39 vic_action_ind
o
o
44 vic_file_name
12a
o
o
45 pdv_journ_pct_full
2i
o
125 <tx>vic_tx_amt
6x
m
126 <tx>curcy
4i
m
131 CCM_field
llllvar
141 Vic_pos_entry_mode
2i
o
142 iso2_track
38x
o
o
143 operator_nr
4i
m
144 function_cc
2a
o
o
145 ticket_data
llllvar
o
o
146 ecr_nr
2i
o
155 application_info
llllvar
156 more_info_ind
2x
157 counter_tab_pa
llllvar
o
169 additional_amount
6x
o
170 transaction_protocol
4x
o
171 vic_bit_map_application_id 32x
o
m
o
m
m
m
o
o
o
172 Transaction_identifier
8i
o
173 Date_and_time
14i
o
174 brand_id
4x
o
175 hardware_type
2i
o
176 cvm
4x
o
177 cvc2
4i
o
178 brand_name
llvar
o
179 vic_version
2i
m
m
m
m
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
62 / 75
LINE PROTOCOL : KISS
The KISS protocol is a serial byte oriented protocol, totally full duplex, asynchronous, and with no notion of
master or slave.
It uses ASCII coding, and provides transparency over data field, by stuffing some characters (see Chapter
Byte Stuffing).
The connection is point-to-point.
The messages are wrapped up with a header and a tail to determine the beginning, the numbering, the end
and the validity. A message has a maximum length of 2Kbytes.
A message required to be sent by the application, can be repeated up to 3 times (thus a total of 4
transmissions) by the protocol when the message is not acknowledged.
If messages are lost or cannot be acknowledged, the protocol will re-synchronise itself on the numbering of
the first next correctly received message.
6.1.
Frame layout
There are two possible kinds of frames, which may be exchanged:

information frames

supervision frames
Information frames
Information frames consist of user data with a header, a trailer and a CRC (16-bit Cyclic Redundancy
Check). They have the following structure:
STX
Sequence
number
User data
ETX
CRC(lsb)
CRC(msb)
Supervision frames
1. Affirmative acknowledge frame
ACK
Sequence
number
The Sequence Number is the number of the last frame, which has been received correctly.
2. Negative acknowledge frame
NAK
3. Flow regulation frame (Wait for ACK)
WACK
All fields are described in detail in the next sections.
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.2.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
63 / 75
Control characters
STX (0x02)
Start of Text
Definition
The transmission control character STX precedes an information frame.
Description of use
1. An information frame must be preceded by STX.
2. STX resets the CRC computation to zero, when preceding an information frame.
3. If a User Data contains a character STX, it must be preceded by a DLE character
(Bytes stuffing).
4. If STX appears in the sequence number, no stuffing is done.
5. STX is not included in the CRC computation.
ETX (0x03)
End of Text
Definition
A transmission control character, which terminates an information frame.
Description of use
1. ETX indicates the end of an information frame.
2. ETX calls for a reply ACK, NAK or WACK from the other party.
3. ETX signals that the next following 16 bits are the CRC characters.
4. ETX is included in the CRC computation.
5. If a text contains a character ETX, it must be preceded by a DLE character (byte stuffing).
6. If ETX appears in the sequence number, no stuffing is done.
Reference Functional Specifications
VIC Standard
T&P / AR&D
DLE (0x10)
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
64 / 75
Data Link Escape
Definition
A transmission control character stuffs another control character in the data of an information
frame.
Description of use
1. DLE informs the receiving station that the next character is to be treated as data and must not be
considered as a control character.
2. DLE must precede STX, ETX and DLE when they are used in the data field of a message.
3. DLE is included in the CRC computation.
4. If DLE appears in the sequence number, no stuffing is done.
ACK (0x06)
Affirmative Acknowledgement
Definition
Transmission control character sent by a station as an affirmative response to the other station.
Description of use
1. ACK is transmitted by one station as an affirmative response to the other station.
2. ACK is used to indicate that the last transmitted information frame has been correctly received.
3. ACK is followed by a sequence number, which is identical to the number of the information
frame to which an affirmative acknowledgement is given.
NAK (0x15)
Negative Acknowledgement
Definition
A transmission control character sent by a station as a negative response to the other station.
Description of use
1. NAK indicates that the last transmitted information frame was not received correctly, and the
receiving station is ready to receive the same one.
2. NAK is not followed by a sequence number.
Reference Functional Specifications
VIC Standard
T&P / AR&D
WACK (0x13)
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
65 / 75
Wait for ACK (flow regulation)
Definition
A transmission control character sent by a station as a request to the other station to wait for ACK.
It is however possible that data is sent before this ACK.
Description of use
1. WACK is transmitted by one station as a request to wait for ACK
2. WACK is not followed by a sequence number.
3. WACK is used to indicate that the last frame has been correctly received but has not yet been
given to the application layer, because the buffers are not empty.
4. WACK will be repeated regularly (every time the receiving station tries to give the frame to the
application layer).
5. There is no limit on the number of WACKs, which might be transmitted.
6. The time between successive WACKs must be less than the time-out on the ACK reception on
the transmission station.
7. A WACK retriggers the ACK time-out at the transmission station.
8. When the frame is passed to the application layer, an ACK is sent.
Sequence Number (0x00..0xff)
Sequence Number
Definition
A sequence number sent by both stations as a way to mark the frames. Once the sequence
number has reached FF, it restarts to 00.
Description of use
1. The Sequence Number is a one byte value, and is sent just after the STX in an information
frame. The same value must be repeated in the affirmative acknowledgement.
2. The Sequence number is used to compute the CRC.
3. Each station manages its own transmission sequence numbering. It should be incremented
after an Affirmative Acknowledgement or after an answer time-out.
4. The Sequence number is used to avoid that the same frame is given twice (or more) to the
application.
5. Value 0xff is the only value for which the receiving station always accepts the frame regardless
of its previous sequence number.
6. No stuffing is done over the sequence number.
7. Upon reaching the value 0xFF, the sequence numbering should start at 0x00 again.
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.3.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
66 / 75
CRC computation
The CRC is computed over the sequence number and the ETX of a frame. It uses the polynomial
13
x15 + x + 1, and is sent after the ETX closing the frame.
A frame is made of:
STX - Sequence number - data field - ETX - CRC(lsb) - CRC(msb)
Upon reception of the STX, the lsb and msb of the CRC field are initialised with zeroes.
For each data byte between the Sequence Number (included) until and included the closing ETX, the
following algorithm is applied:
table_index = CRC(lsb) XOR data_byte
CRC(lsb) = CRC(msb) XOR lsb(table(table_index))
CRC(msb) = 0 XOR msb(table(table_index))
where :
lsb stands for Least Significant Byte
msb stands for Most Significant Byte
XOR stands for eXclusive OR
table is an array of 256 values (Refer to next page)
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
67 / 75
CRC computation table
0x0,
0x280,
0x500,
0xd80,
0xa00,
0x880,
0x1b00,
0xdf81,
0x1400,
0x1680,
0x1100,
0x3180,
0x3600,
0x3480,
0xff01,
0x3b80,
0x2800,
0x2a80,
0x2d00,
0x2580,
0x2200,
0x2080,
0x6300,
0xa781,
0x6c00,
0x6e80,
0x6900,
0xb981,
0xbe01,
0xbc81,
0x7700,
0xb381,
0x5000,
0x5280,
0x5500,
0x5d80,
0x5a00,
0x5880,
0x4b00,
0x8f81,
0x4400,
0x4680,
0x4100,
0xc0c1,
0xc241,
0xc5c1,
0xcd41,
0xcac1,
0xc841,
0xdbc1,
0x1f40,
0xd4c1,
0xd641,
0xd1c1,
0xf141,
0xf6c1,
0xf441,
0x3fc0,
0xfb41,
0xe8c1,
0xea41,
0xedc1,
0xe541,
0xe2c1,
0xe041,
0xa3c1,
0x6740,
0xacc1,
0xae41,
0xa9c1,
0x7940,
0x7ec0,
0x7c40,
0xb7c1,
0x7340,
0x90c1,
0x9241,
0x95c1,
0x9d41,
0x9ac1,
0x9841,
0x8bc1,
0x4f40,
0x84c1,
0x8641,
0x81c1,
0xc181,
0xc601,
0xc481,
0xf00,
0xcb81,
0xd801,
0xda81,
0xdd01,
0xd581,
0xd201,
0xd081,
0x3300,
0xf781,
0x3c00,
0x3e80,
0x3900,
0xe981,
0xee01,
0xec81,
0x2700,
0xe381,
0xa001,
0xa281,
0xa501,
0xad81,
0xaa01,
0xa881,
0xbb01,
0x7f80,
0xb401,
0xb681,
0xb101,
0x9181,
0x9601,
0x9481,
0x5f00,
0x9b81,
0x8801,
0x8a81,
0x8d01,
0x8581,
0x8201,
0x8081,
0x140,
0x6c0,
0x440,
0xcfc1,
0xb40,
0x18c0,
0x1a40,
0x1dc0,
0x1540,
0x12c0,
0x1040,
0xf3c1,
0x3740,
0xfcc1,
0xfe41,
0xf9c1,
0x2940,
0x2ec0,
0x2c40,
0xe7c1,
0x2340,
0x60c0,
0x6240,
0x65c0,
0x6d40,
0x6ac0,
0x6840,
0x7bc0,
0xbf41,
0x74c0,
0x7640,
0x71c0,
0x5140,
0x56c0,
0x5440,
0x9fc1,
0x5b40,
0x48c0,
0x4a40,
0x4dc0,
0x4540,
0x42c0,
0x4040
0xc301
0x780,
0xcc01,
0xce81,
0xc901,
0x1980,
0x1e00,
0x1c80,
0xd701,
0x1380,
0xf001,
0xf281,
0xf501,
0xfd81,
0xfa01,
0xf881,
0xeb01,
0x2f80,
0xe401,
0xe681,
0xe101,
0x6180,
0x6600,
0x6480,
0xaf01,
0x6b80,
0x7800,
0x7a80,
0x7d00,
0x7580,
0x7200,
0x7080,
0x9301,
0x5780,
0x9c01,
0x9e81,
0x9901,
0x4980,
0x4e00,
0x4c80,
0x8701,
0x4380,
0x3c0,
0xc741,
0xcc0,
0xe40,
0x9c0,
0xd941,
0xdec1,
0xdc41,
0x17c0,
0xd341,
0x30c0,
0x3240,
0x35c0,
0x3d40,
0x3ac0,
0x3840,
0x2bc0,
0xef41,
0x24c0,
0x2640,
0x21c0,
0xa141,
0xa6c1,
0xa441,
0x6fc0,
0xab41,
0xb8c1,
0xba41,
0xbdc1,
0xb541,
0xb2c1,
0xb041,
0x53c0,
0x9741,
0x5cc0,
0x5e40,
0x59c0,
0x8941,
0x8ec1,
0x8c41,
0x47c0,
0x8341,
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.4.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
68 / 75
Time out controls
Answer time-out
Implemented in every station.
The answer time-out is started at the transmitting station when a frame is sent out.
The answer time-out is re-triggered at the transmitting station when a WACK is received.
The answer time-out is stopped at the transmitting station when an answer (ACK, NAK) is received from the
other station. Please remark that the affirmative acknowledge must be followed by the same sequence
number as the frame just sent, to be considered as a valid affirmative acknowledgement.
The value of the answer time-out is computed as:
((frame length *10) /baudrate) * 2
The frame length includes the STX, sequence number, data field, ETX and CRC. This gives an extra
overhead of five bytes with regard to the data field length.
Example:
For a frame length of 255 bytes, the answer time-out is 531 msec.
Inter character time-out
Implemented in every station.
The inter character time-out prevents a station having received a STX and some more characters, to stay in
this state infinitely.
The value of the inter character time-out is: 2ms.
6.5.
Retry counter
Implemented in every station.
The retry counter is the maximum number of times a message may be re-transmitted in case of NAK
response, or no answer at all.
Value = 3
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.6.
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
69 / 75
Byte stuffing
The User data field allows transparent transmission. This means that every byte in this field may have a
valid value between 0 and 255. To avoid confusion between some values and control characters, a byte
stuffing mechanism is implemented at both stations.
The transmitting station scans every byte it received from its application, to find a STX, a ETX or a DLE
control character.
If it does, it stuffs this control character by adding a DLE just before this character.
On the receiving station, once the leading STX, and the Sequence Number are received, every DLE will be
discarded, reconstituting by the same way the original User data.
The DLEs added by this stuffing mechanism, are used in the CRC computation.
6.7.
Transmission Control Sequences
Normal message transmission
station 1
SS
TE<data>
XQ
ECC
TRR
XCC
station 2
AS
CE
KQ
CRC error and re-transmission accepted
station 1
SS
TE<data>
XQ
ECC
TRR
XCC
station 2
SS
TE<data>
XQ
ECC
TRR
XCC
N
A
K
AS
CE
KQ
CRC error and re-transmissions refused
station 1
SS
TE<data>
XQ
ECC
TRR
XCC
station 2
SS
TE<data>
XQ
ECC
TRR
XCC
N
A
K
SS
ECC
TE<data> TRR
XQ
XCC
N
A
K
SS
TE<data>
XQ
ECC
TRR
XCC
=> warns its application that the last message is
lost
N
A
K
N
A
K
Answer time-out and re-transmission accepted
station 1
SS
TE<data>
XQ
ECC
TRR
XCC
SS
TE<data>
XQ
ECC
TRR
XCC
=> time-out
station 2
AS
CE
KQ
Answer time-out and re-transmissions refused
station 1
station 2
SS
ECC
TE<data> TRR
XQ
XCC
SS
TE<data>
XQ
=> time out
ECC
TRR
XCC
SS
TE<data>
XQ
=> time out
ECC
TRR
XCC
SS
TE<data>
XQ
=> time out
ECC
TRR
XCC
=> time out
=> warns its application
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Inter character time-out and re-transmission accepted
station 1
station 2
SS
TE<data>
XQ
SS
TE<data>
XQ
ECC
TRR
XCC
N
A
K
AS
CE
KQ
=> inter character time out
Normal full duplex exchange
station 1
station 2
Ss
ECC
Te<data> TRR
Xq
XCC
AS
CE
KQ
SS
TE<data>
XQ
ECC
TRR
XCC
As
Ce
Kq
Information frame with out of order sequence number
station 1
SS
ECC
TE<data> TRR
XQ
XCC
station 2
SS
ECC
TE<data> TRR
XQ
XCC
X
AS
CE
KQ
AS
CE
KQ
X
=> warns its application for break in sequence numbering
ACK frame with out of order sequence number
station 1
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<data> TRR
XQ
XCC
=> invalid ACK. Fall in time out and re-send frame
station 2
AS
CE
KQ
X
AS
CE
KQ
WACK frame followed by an ACK
station 1
station 2
SS
ECC
TE<data> TRR
XQ
XCC
W
A
C
K
W
A
C
K
AS
CE
KQ
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
70 / 75
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.8.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
71 / 75
Error recovery
A negative (NAK) reply to an information frame causes re-transmission of the information frame. The
maximal number of re-transmissions is equal to the message retry counter (see RETRY COUNTER). This
implies that the information frame will be sent a number of times equal to the retry counter plus one !
When the retry counter overflows, the sending station generates an alarm to its application layer, and takes
the next information frame. The sequence number must be incremented for this new information frame.
station 1
SS
ECC
TE<data> TRR
XQ
XCC
station 2
SS
ECC
TE<data> TRR
XQ
XCC
N
A
K
SS
ECC
TE<data> TRR
XQ
XCC
N
A
K
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<new> TRR
XQ
XCC
+
1
=> warn application retry counter exceeded-
N
A
K
N
A
K
AS
CE
KQ
+
1
=> warns application
a frame has been lost
An answer time-out on an information frame on the side of the sending station, causes the re-transmission
of the information frame at maximum a number of times equal to the value of the retry counter + 1. In case
of unsuccessful re-sending, the sending station generates an alarm to its application layer, and take the next
information frame. The sequence number must be incremented for this new information frame.
station 1
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<data> TRR
XQ
XCC
SS
ECC
TE<new> TRR
XQ
XCC
+
1
=> warns application
station 2
AS
CE
KQ
+
1
=> warns application a frame has been lost
An information frame having the same Sequence Number as the previous received information frame, must
be acknowledged but discarded towards its application layer.
station 1
station 2
SS
TE<data>
XQ
ECC
TRR
XCC
SS
ECC
TE<data> TRR
XQ
XCC
AS
CE
KQ
SS
ECC
TE<new> TRR
XQ
XCC
+
1
AS
CE
KQ
=> give to application
1
=> discard !
AS
CE
KQ
+
=> give to application
An inter character time-out may be treated in two different ways. The easiest way is just not to answer and
wait for the answer time-out to elapse, causing the re-transmission of the information frame.
A more efficient way to handle the inter character time-out is to generate a negative (NAK) reply, causing a
faster re-transmission of the information frame.
The final choice is left open for the designer.
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.9.
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
72 / 75
Flow chart
Definitions
ICT:
AT:
inter character time-out
answer time-out
ACK:
NAK:
WACK:
DLE:
STX:
ETX:
*:
ASCII character 0x06
ASCII character 0x15
ASCII character 0x13
ASCII character 0x10
ASCII character 0x02
ASCII character 0x03
any character except ACK, NAK, WACK, DLE, STX, ETX
A_N:
M_T_S:
Answer_Needed : boolean specifying that the procedure waits for an answer
Message_To_Send : boolean specifying that the application wants to send a
message
Conventions
Every state transition is characterised by an event and an action.
In the further state transition diagram, they are marked as "event, action"
Those actions in parentheses are optional.
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
State transition
A_N & ACK,0
M_T_S,1
A_N & AT,3
A_N & NAK,4
IDLE
STX,2
A_N & WACK,14
ICT,5
WAIT_SEQ_NR
*,8
WAIT_AFTER_ACK
ICT,5
ICT,5 WAIT_AFTER_DLE
*,7
*,9
*,9
DLE,10
ICT,5
WAIT_CHARS
STX,2
ETX,11
ICT,5
WAIT_CRC_LSB
*,12
ICT,5
-,13
WAIT_CRC_MSB
Action list
0.
do nothing
1.
prepare message
send message
set A_N
start AT
reset retry_number
2.
start ICT
initialise receive buffer
3.
(increment time-out statistics)
action 3bis
3bis.
if retry_number <= 2
send again
increment retry_number
start AT
else
signal error to application
increment transmission sequence number
4.
(increment ACK statistics)
action 3 bis
5.
(increment time-out statistics)
7.
stop ICT
if char = transmission sequence number
stop AT
increment transmission sequence number
reset A_N
reset M_T_S
signal transmission OK to application
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
73 / 75
T&P / AR&D
Reference Functional Specifications
VIC Standard
Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
74 / 75
8.
start ICT
set receive sequence number to char
compute CRC
9.
stock char
compute CRC
start ICT
10.
start ICT
compute CRC
11.
start ICT
compute CRC
finalise CRC
12.
stock char in CRC(lsb)
start ICT
13.
stock char in CRC(msb)
stop ICT
if CRC <> computed CRC
send NAK
(increment NAK statistics)
if A_N then start AT
else
if receive sequence number = last receive sequence number
send ACK + receive sequence number
if A_N then start AT
else
give message to application
send ACK + receive sequence number
set last receive sequence number = receive sequence number
14.
restart AT
Reference Functional Specifications
VIC Standard
T&P / AR&D
6.10.







Version: 1.07/11/07
Status: Draft
Confid.:
Author: T&P
Line characteristics
Asynchronous
Full duplex
1 start bit, 8 data bits, 1 stop bit
Parity :
Speed :
Physical encoding method :
Byte serialisation :
None
9600 bps
Non Return to Zero (NRZ)
Least Significant Bit (LSB) first
Date edited: 21/09/2008
Date printed: 16-Mar-10
Page:
75 / 75