Implementing GPE interface

User Guide for integrators

version 13.00
Implementing GPE interface
User guide for integrators
User guide version: v13.00 / supported with Newton version 5.13 and above
For more information, please visit [Link]
Document level Confidential

© 2018 Global Payments Europe, s.r.o.

Under the conditions stipulated in this agreement, Global Payments Europe s.r.o. provides the holder with a
gratuitous, quantitatively and locally unrestricted, nonexclusive and perpetual (for the entire duration of the rights to the work)
possibility of using the work. The holder is not entitled to reproduce the work, include it in collected works and further reproduce
the work as part of collected works, they are not authorized to spread and disclose the work alone or as part of collected works
to the public. The holder is entitled to use the Work in the aforementioned manners, solely for their own needs. All rights for
the Work, which are not expressly granted, remain reserved.
Content

INTRODUCTION ................................................................................................................................................ 6
1.1 PAYMENT TRANSACTIONS ................................................................................................................................ 7
1.2 INTEGRATION USE CASES / BEST PRACTICES ......................................................................................................... 8
1.2.1 Attended vs unattended .................................................................................................................. 8
1.2.2 Enhanced matching feature ............................................................................................................ 8
1.2.3 Attended best practices ................................................................................................................... 9
1.2.4 Unattended best practices .............................................................................................................. 9
1.3 INTEGRATION PACKAGE PROVIDED BY GPE........................................................................................................ 10
1.4 BENEFITS FOR ECR AND POST INTEGRATION .................................................................................................... 10
1.5 INTEGRATION RISKS ...................................................................................................................................... 10
1.6 CERTIFICATION PROCESS ................................................................................................................................ 11
2 IMPLEMENTATION OF INTERFACE ......................................................................................................... 12
2.1 BEFORE YOU START – TERMINAL CONFIGURATION .............................................................................................. 12
2.2 AVAILABLE CONNECTION TYPES ....................................................................................................................... 12
2.2.1 RS232............................................................................................................................................. 12
2.2.2 Ethernet (TCP/IP) ........................................................................................................................... 13
2.3 INTERFACE INTERACTION ............................................................................................................................... 14
2.3.1 General rules ................................................................................................................................. 14
2.3.2 Interaction of RCARC type ............................................................................................................. 17
2.3.3 Interaction of RC type with Abort transaction............................................................................... 17
2.3.4 Explanation of terms used in the diagrams ................................................................................... 19
2.4 PROCESSING STATUSES.................................................................................................................................. 20
2.5 SPECIFICATIONS FOR APPLICATION PROTOCOL .................................................................................................... 21
2.5.2 Message header ............................................................................................................................ 22
2.5.3 Message data part ........................................................................................................................ 23
2.5.4 Rules for working with data fields ................................................................................................. 24
2.5.5 Data fields of Payment Services .................................................................................................... 25
2.5.6 Transaction response codes .......................................................................................................... 32
3 VALUE ADDED SERVICES ....................................................................................................................... 33
3.1 EET SERVICE (ONLY FOR CZECH REPUBLIC)........................................................................................................ 33
3.1.1 EET transactions ............................................................................................................................ 33
3.1.2 Extended data fids of EET service .................................................................................................. 34
3.1.3 Fids for other EET transactions ...................................................................................................... 34
3.1.4 Fid definition.................................................................................................................................. 35
3.1.5 EET Check ...................................................................................................................................... 35
3.1.6 EET Synchronization of transactions ............................................................................................. 36
3.1.7 EET Payment and EET Sale ............................................................................................................ 38
3.1.8 EET Cash Refund, EET Refund ........................................................................................................ 38
3.1.9 EET Reversal .................................................................................................................................. 38
3.1.10 Fids structure ............................................................................................................................ 38
3.1.11 The EET sFids of fid e ................................................................................................................ 40
3.1.12 The EET transaction treatment ................................................................................................. 40
3.1.13 Type of registered payment ...................................................................................................... 40
3.1.14 Signature and security codes .................................................................................................... 41
3.1.15 Unique EET Transaction number .............................................................................................. 42
3.1.16 EET Repeat Last Trn. ................................................................................................................. 42
3.1.17 EET advices and recommendations .......................................................................................... 43
3.2 TRANSPORT ADDITIONAL INFORMATION ........................................................................................................... 43
4 APPENDICES .......................................................................................................................................... 44
4.1 ALGORITHM FOR CALCULATING CRC16 IN C LANGUAGE ...................................................................................... 44
4.2 SERIAL CABLE STRUCTURE .............................................................................................................................. 45
4.3 COMMUNICATION TRACE .............................................................................................................................. 46
4.4 FAQ ......................................................................................................................................................... 52
5 REFERENCES .......................................................................................................................................... 53

Abbreviations, terms and references

Abbreviation Explanation
AT Attended devices (desktop, mobile) like iCT220, iWL228 etc.
CAT Unattended devices like iUC180B, iUP250 etc.
DHCP Dynamic Host Configuration Protocol
ECR Electronic Cash Register
EET Electronic Registration of Sales (fiscal law for Czech Republic)
POST or POS Point of Sale Terminal (EFT POS)
RCARC Interaction diagram (Request, Confirmation, Activity, Response, Confirm.)
SFS Server of Financial Service (fiscal law for Czech Republic)
SSL Secure Sockets Layer provides the encrypted connection above TCP/IP
TCP/IP Transmission Control Protocol/Internet Protocol
Terminal Management System used for terminal parameters and application
TMS
management
Chapter 0: INTRODUCTION

INTRODUCTION
This document describes the cash register (or any other system like self-service
kiosks, vending machines, etc.) interface to the GPE Newton payment terminal
application and includes information needed for the implementation of this interface
to the cash register (further mentioned as ECR) or any other system.
The cash register interface of the payment terminal is the same for commonly
used GPE terminals (attended and also unattended) but implemented only for terminal
types in which its usage makes sense (for example mobile GPRS terminal does not
have any interface for cash register). We do provide also integration for mobile
platforms like Android or iOS, but this function is not a part of this document. Please
contact GPE for more information.

secure collection of input data, mediating the transaction processing via central GPE
systems and providing trustworthy information (e.g. output) on the results of the
processing.
The operating process of this relation is not usually managed by only the
involved systems, but also influenced by two human factors (the operator and
customer).

Merchant system (ECR) Payment system

IBM

Remote connection

Local connection GPE central system

Merchant site

System for replenishment of mobile phone’s cards,

System for processing of gift cards

GPE payment terminals currently offer three groups of transaction services:

Non-cash payment transactions - Non-cash payments made by card issued by VISA,

MASTERCARD, AMEX, JCB, DINERS CLUB, China Union Pay and others. Card details
can be stored on plastics, in mobile phone or any other technology.
Top-Up GP Mobile engine enables credit top-up for prepaid mobile phones of all
Czech mobile operators: O2, T-Mobile and Vodafone.
Gift cards GP Gift allows for activation, credit top-up and payment via prepaid gift
cards issued by GPE.

Specific information is always divided into sub- Payment transactions

top-up
can always be distinguished in the text.

Page 6 of 53
1.1 Payment transactions

payment methods:

Available for
Type Description
AT CAT
to the
Sale  
services or cash.
Transfer of an amount from the account of the merchant to the
Refund This transaction is very risky for frauds, so  
please handle it carefully.

account for limited time (time range depends on the card issuer).
Preauthorization  
Preauthorization completion is necessary to finalize/catch the
transaction amount.
Transaction allowing to increase the amount of original
preauthorization. These transactions can be made as a chain of
Incremental
transaction completed by one preauthorization completion.  
preauthorization
Completion is initiated for last successful incremental
preauthorization.
Finalizes the Preauthorization It means, that
Preauthorization
Completion can be done for partial or full amount of  
completion
preauthorization. Higher completion amount than preauthorized is
not allowed.
This operation allows to cancel transaction Sale or
Transaction Preauthorization completion transaction (as long as it was
 
cancellation completed). Regarding to settlement between the vendor and
card holder, it has an inverted character to the Sale operation.
Reversal Cancellation (reversal or VOID) of last transaction successfully
 
(VOID) done by terminal.
The transaction is used for casinos and gambling room for selling
Quasi Cash  
tokens.
Its purpose is to compare the number and sum of amounts of all
transactions made between the payment terminal (or cash
Subtotals  
register) and authorization system. It is only used for the
immediate comparison of the accumulated transaction status.
The purpose of this transaction is to conclude the accounting
period (e.g. with a change of operator) and to check the balance
of the transaction state between the payment terminal (or cash
Batch close  
register) and authorization system. The result of the operation (in
contrast to the Sub-total transaction) is always the clearing of the
accumulated transaction state of all systems.
This operation is only reads card, from PAN+EXP makes hash,
Token  
encrypts by RSA and sends this data to ECR(Kiosk)
This operation reads card, sends offline data to AC, checks Deny
Variable Fare List stored in POS and from PAN+EXP makes hash, encrypts by  
RSA and sends this data to ECR(Kiosk)
This operation is for sending additional information from ECR
VF Advice  
(Kiosk) to previous Variable Fare transaction.
Offline Transaction used for sending offline transaction locally stored in
 
upload terminal to authorization host. This is used mainly by unattended

Page 7 of 53
Chapter 0: INTRODUCTION

terminals.
.
Host This administrative transaction is used for testing connection to
 
Handshake authorization host.
TMS This operation initiated ECR(Kiosk) to force the POS connect to
 
connect TMS for upload software, OS or parameters.
Last TMS This operation returns the last TMS connection date + time and
 
connect also the last versions of all POS applications.
POST data The purpose of this operation is to get print data from POS for last
 
printing transaction or configuration (SW, HW and setting)
The return status and data last transaction was performed. Used
Last TRN only if previous transaction was Sale, Cancellation, Refund,
 
Repeat Preauthorization, Completion Preauthorization, Token, Variable
Fare, Variable Fare Advice, EET Payment or EET Cash refund.

1.2 Integration use cases / best practices

As the GPE protocol provides wide range of integration options and there are plenty
of customer verticals, we tried to prepare use cases to simplify whole integration and
to eliminate the reading all chapters, which can be for your purpose useless.
1.2.1 Attended vs unattended
Attended terminals (AT)
It covers the integration with desktop and mobile terminals. Terminal act as a server,
ECR as a client.
Device examples: iCT220, iPP320, iWL228, Desk 3200, Lane 5000, etc.

Unattended terminals (CAT)

Implementing GPE protocol for unattended terminals works vice versa. It means, that
in following chapters, the terminal act as a client and ECR (kiosk) act as a server.
Device examples: iUC160B, iUC180B, iUP250

1.2.2 Enhanced matching feature

At the moment GPE provides two ways, how to manage transactions like sale or

(EM)
always pair original transactions with the following ones which are changing original
transaction status. From customer perspective,
supported by:
 Global Payments Europe
 Global Payments Czech Republic
 Global Payments Slovakia
 Global Payments Romania
 Global Payments Europe Hungary
 Global Payments Malta
This functionality is not supported by:
 KB SmartPay

Page 8 of 53
the transaction codes based on the EM functionality (EM applies only to financial
transactions, others without impact are not listed in table):
Transactions EM not available EM available
Sale 00 00
Preauthorisation 01 01
Incremental preauthorization Not available 07
Preauthorization Completion 02 22
Refund 04 04
QuasiCash 05 05
Reversal 10 10
Transaction cancellation 10* 21
*transaction cancellation without EM functionality is same as reversal last transaction cancellation.

1.2.3 Attended best practices

As we have successfully integrated over 80 companies, we tried to prepare for you
overview of mostly used integration combinations used by our integrators and
customers together with attended terminals.

Segment Configuration Commonly used features

Sale
Receipt printed by ECR
Transaction cancellation
Retail store Signature check on ECR
Reversal
Close day initiated from ECR
Close day
Sale
Receipt printed by POS
Transaction cancellation
Groceries Signature check on POS
Reversal
Close day initiated from POS
Close day
Sale
Preauthorization
Receipt printed by ECR
Hotel Preauthorization completion
Signature check on ECR
Car rental Transaction cancellation
Close day initiated from ECR
Reversal
Close day
Sale
Receipt printed by POS
Transaction cancellation
Restaurants Signature check on POS
Reversal
Close day initiated from POS
Close day
Quasi Cash
Receipt printed by ECR
Transaction cancellation
Casino Signature check on ECR
Reversal
Close day initiated from ECR
Close day

1.2.4 Unattended best practices

Segment Configuration Commonly used features
Preauthorization
Preauthorization completion
Self-service petrol Receipt printed by ECR
Transaction cancellation
stations Close day initiated from ECR
Reversal
Close day

Page 9 of 53
Chapter 0: INTRODUCTION

TMS connect
Sale
Receipt printed by ECR Reversal
Vending machines
Close day initiated from ECR Close day
TMS connect
Sale
Reversal
Close day
Receipt printed by ECR
Transport solution Token
Close day initiated from ECR
TMS connect
Variable Fare
VFadvice

1.3 Integration package provided by GPE

GPE provides wide range of additional tools helping to integrations to make swift
integration:
 Protocol specification (this document)
 terminal simulator
 ECR simulator
 DLL library for faster integration of attended devices
 Integration support by our experienced people

For more details or Q&A please visit: [Link]

1.4 Benefits for ECR and POST integration

The main reasons for integration are:
 fast transactions processing
 operator comfort (not necessary to coordinate two separate equipment units)
 transfer of responsibility for processing transactions from operator to cash
register system
 errors caused by human factor elimination

1.5 Integration risks

The integration risks:
 possibility of creating differing accounting balances of ECR and POST systems
 possibility of holding up operator or customer due to system de-synchronization
 analyzing non-standard behavior

The reason for the creation of the aforementioned states is usually a wrong
implementation of the cas
external influences (e.g. electromagnetic fields, incorrect voltage, mechanical damage
of equipment, etc.) reason, why GPE insists on the integration certification,
where our trained certification specialist will verify your implementation and confirms
the proper system behavior.
Page 10 of 53
1.6 Certification process
Based on your request we will grant you access to all necessary
documentation. With these details you can swiftly start your integration of GPE
interface.
During whole development GPE will provide you technical support. At the end
of integration leaflet, you can find test cases, which must be successfully passed
during our certification event. In the integration sheet, you can also find all mandatory
functions that need to be implemented in your system. Rest of services is optional.
Whether your development is finished, you can arrange certification date with
our certification specialist. Certification is usually placed in our headquarters in GPE
Prague, but if necessary, it can be managed remotely. With our testers you will pass
all mandatory test cases described in this leaflet. After successful certification you will
receive GPE certificate and your company will be listed as a certified partner.
Certification is not limited by country or customer. For more information please
visit [Link] (Czech version, for English version we will launch
[Link] soon.

Page 11 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

2 IMPLEMENTATION OF INTERFACE
The payment terminal and its architecture are classified to the category of
intentionally designed equipment. Its HW and SW does not allow for parallel
processing of multiple tasks. If then the payment terminal processes a task started
through a user interface of the terminal, the processing of another task cannot be
started through the cash register interface of the terminal and vice versa.
This characteristic also applies for the cash register interface itself; the new task (or
transaction) can only be begun in the case that the POST is not yet processing any
other task (i.e. the previous task has already been completed).

2.1 Before you start – terminal configuration

Because the hardware equipment available by cash register or machine technology is
not always the same, terminal application allows to configure the behavior of the
terminal against ECR. Except more sophisticated parameters like baud speed, IP
addresses or ports, GPE application provides following configuration options:

Name Description Values

ECR support Is ECR communication enabled? Yes / No
It defines, which system is responsible for

POST the call to verify a signature is made as part

Signature check of the processing of the transaction. POST/ECR
ECR signature verification message will appear
in ECR system and ECR is responsible for reversal
in case, that signature is not valid.
Parameter allows to configure, if the close day
Close day initiation POST/ECR
transaction will be initiated from POST or ECR.
It can be configured, whether transaction receipt
Receipt printing POST/ECR
will be printed on the ECR or POST.

If you asked GPE for testing terminal, do not forget to share with us requested terminal
configuration.

2.2 Available connection types

At present the RS232 serial interface and Ethernet TCP/IP (Wi-Fi is also supported)
connection can be used for the physical interconnection of the ECR and POST. In the
future it will probably be supported connection through USB.

2.2.1 RS232
The standard means of connection is done via a cable (for the connection see the
chapter Serial cable connection). The interface configuration used is:

Page 12 of 53
 Transfer mode: Serial, asynchronous, full-duplex
Format: 8 data bits, 1 stop bit, no parity;
Speed: 9600 bps
Data flow management: NONE

2.2.2 Ethernet (TCP/IP)

Standard Ethernet cable (with RJ45 on both ends) for physical connection of ECR and
terminal is used. The network speed 10Mb/s and TCP/IP protocol is used for terminals.
There are no sensitive data included in communication, SSL is not used so far. Picture
below shows scheme of the connection through the Ethernet. The terminal is a server
listening on the specified port and ECR is a client. In this version only one client is
allowed to be connected to the server.

Static IP ECR Static IP POS

[Link] [Link]
Static IP POS
ECR POST Port 2050
[Link]:2050 Trusted IP
[Link]
Switch
ECR host Authorization

[Link]
FireWall
Gateway
LAN
Internet

Picture: scheme of the connection through the Ethernet

In unattended design, the terminal act as a client and connects to the ECR
(Kiosk), which act as server, and send request.

Communication Settings
Because socket connection is used in TCP/IP, both sides have to be set correctly. On
the image upwards, server and client belong to the same network, but they can be in
different LAN.

Setting of ECR: destination IP address of server (terminal IP e.g. [Link])

destination port of server (e.g. 2050)
protocol: TCP/IP

Setting of Terminal: trusted IP of client (ECR IP e.g. [Link])

Port to listen (e.g. 2050)
protocol: TCP

Page 13 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

2.3 Interface interaction

Processing transactions between the cash register and payment terminal is carried
out in accordance with three interaction diagrams (RC, RCRC, RCARC) displayed on
the diagrams below. The processing logic is analyzed here the way in which it need to
be implemented in the cash register software.

The following run variables are used for all types of interactions:
RETRY_CNT retry counter (decremented)

maximum period for which POST must respond by some type of

RECV_TIMEOUT
message
The reason for the relatively long (with regard to continuity of processing on ECR)
maximum time limits for completing transactions (RECV_TIMEOUT) is the user inputs
(such as entering PIN, phone numbers, etc.) that block the POST (or the processing of
new requests from the cash register interface) and which cannot be shortened. The
processing of transaction itself is performed up to 5 seconds on average.

During each processing of a transaction the ECR must maintain the following values:
identifier of the logical terminal where the transaction was made
Terminal ID
(ECR obtains the value from the first response of the POST)

Transaction date and time of transaction. (for the duration of the transaction
Date & Time this value is constant)

Data field of Services for credit

replenishing and gift cards), which is constant for all transactions carried out within the
framework of a single cash register account (purchase), must be maintained by the
ECR for processing services for credit replenishing and gift cards.

2.3.1 General rules

[Link] Message continuity
The entire message must be delivered in 1 second (measured from first to last
character of the message).

[Link] Rules for the Ethernet connection

This part describes only rules valid for TCP/IP protocol. Because TCP/IP protocol can
be managed as a stage protocol it is necessary to specify the rules for the stage
changes (connection opened, connection closed).

Connection life cycle corresponds to type interactions defined later. Terms Open
Comm. Channel a Close Comm. Channel can be analogically used for TCP/IP
Connection opened / closed.

Page 14 of 53
Active socket connection without data if there is no relevant message received
within 5s, terminal closes connection. ECR should accept disconnection and start new
transaction as a new connection.

Closing of active connection in case the connection is suddenly closed from ECR,
terminal accepts disconnection. If unexpected error appears and the connection is
then closed, it is recommended to wait 1s delay before next connection starts.

For Unattended devices, there is Windows based component covering server

side of communication for both ends (ECR, Terminal). Terminal as client
connects to this service and connection is held as permanent. Service sends
periodical Heart Beat message to terminal every 5 seconds. If permanent
connection failed, terminal will reopen it again.

Restrictions
 Only one request can be managed by server at same time
 Only one client can be connected to server
 Only first request in queue is managed, others (max 2 requests in queue) are
refused with response message
 DHCP is not supported, fix IP addresses must be set

[Link]

Serial communication
There is no verification. It is based on physical connection.

TCP/IP communication
Client uses Server
verifies client IP, compares this IP against trusted IP in its parameters. If IP
verification will fail, connection is not accepted by server.

[Link] Handling exceptions

All exceptions in processing should be handled by the ECR in the following manner:
1. by sending a request to terminate the processing of the transaction task (not
supported)
2. by closing the communication channel
3. by blocking the communication interface for 60 seconds.

A failure of low-level functions for receiving and sending data, a deviation from the
declared sequence of processing or content of messages, etc.

Blocking the communication interface means a state, in which the ECR restricts the
initiation of any new transaction for a set time.

The aim of this protective measure is to allow the terminal to cancel the started task
and to return to the basic state.

Page 15 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

Before starting new connection, it is recommended to clear In/Out buffers for low-
level functions.

[Link] Message content with error values

If the message contains inaccurate values (for example missing Terminal ID, CRC,
different transaction date and time, etc.), the side that received such a message
should respond with a FormatError message (see chapter:[Link] FormatError
message).

Page 16 of 53
2.3.2 Interaction of RCARC type

Designated for the following transaction types: Sale, Refund, Transaction

cancellation, Sub-total, Close batch, preauthorization, quasi-cash, incremental
preauthorization and preauthorization completion. Interaction is a way of processing
identical to interactions of the RCRC type, only it is enhanced by the option to expand
the time necessary for transaction processing by sending a confirmation message
from POST to ECR.

Diagram 3

2.3.3 Interaction of RC type with Abort transaction

Abort transaction initiates canceling of current transaction but only if transaction flow
did not start online authorization yet. Request is always confirmed by Confirmation
message (ACK) sent by the terminal, but final decision is made by financial application

Page 17 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

according to flow process. If Abort is accepted (transaction is cancelled before online

authorization) then terminal finalize transaction by response with response code RC=
060 (Transaction was cancelled by the operator) otherwise transaction is completed
standard way. The timestamp in the header message must be taken over from original
request.

Page 18 of 53
2.3.4 Explanation of terms used in the diagrams

Description of activities
open Software opening of communication channel between ECR and POST
Comm. channel (including its configuration, deletion of entry queues, etc.).
close
Software closing of the communication channel.
Comm. channel
send Sending message requesting creation of transaction by the payment
Transaction Request terminal.
receive
Acceptance of any formally correct message.
Transaction Message
evaluate Evaluation of received message in the sense of message type and logical
Transaction Message check of values.
repeat Evaluation whether it should be repeated.
send
Sending of confirmation message. See chapter Confirmation message
Confirmation Message
send
Sending of Error in Format message. See chapter Error in Format message
FMTERR Message

Description of transitional states

YES Positive result of evaluation of condition.
NO Negative result of evaluation of condition.
(No Valid Confirmation Message) During the time limit (RECV_TIMEOUT) no
NO_VLD_CFM formally correct message was received. See chapter Formally correct
message
(Valid Confirmation Message) Correct Confirmation Message was received.
VLD_CFM
See chapter Confirmation message
A message informing ECR that the POST deemed the last message to be an
RCV_FMTERR_MSG
error and requests that the message be sent again.
During the time limit (RECV_TIMEOUT) a formally correct Transaction
NO_VLD_RSP Request or Transaction Request correct in content was not received. See
chapter Formally correct message
A formally and content-correct response to the Transaction request was
VLD_RSP
received.

Page 19 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

2.4 Processing statuses

The purpose of this chapter is to clarify the POST processing as a status device
regarding to cash register interface. Individual tasks (mostly transactions) are
simplified here on the level of events so that their relations are apparent.

Status description

OUTOF_OPERATION The system is out of operation.

POST is prepared to perform any transaction or user operation except for

transactions completing the credit top-up process (Confirmation) for the
BASIC_STATUS
credit top-up
changed by logging in. After reset POST returns back to this status.
POST can only process payment transactions, transactions for processing
gift cards and user operations or to complete the credit top-up process.
COMPLETION
The system status does not change by logging in. After reset POST
returns back to this status.

Description of Events

Sale, (Cancellation),
Return, Sub-total, Transactions described in the previous chapters.
Close day
Task initiated from User operation, which can be any task initiated by the POST user
POST through a user GUI of the payment terminal.
Turn on/off

The processing exclusively of payment transactions does not have a status.

OUT_OF_OPERATION

Switch On Sale, (Cancel), Refund,

Subtotal, Total
BASIC STATUS
Switch Off Task being started up from POST offer

Diagram 1

Page 20 of 53
2.5 Specifications for application protocol
This protocol is transparent for supported communications profiles (Serial or Ethernet).
This protocol is designed exclusively for ECR and POST communication.
Communication of both units is carried out in the form of unified messages. The
importance of individual messages is determined by their content. The protocol is
ASCII coded, the numerical values are entered by a big-endian convention and are
entered as a decimal unless otherwise indicated.

Used control characters:

<STX> 0x02 - text start

<ETX> 0x03 - text end
<FS> 0x1C - File separator
<GS> 0x1D - Group separator
<CR> 0x0D - Carriage return
<SPC> 0x20 - Space
<LF > 0x0A - \

Each message begins with the control character <STX>, which is followed by the
message header, optionally the data part, and ended with the character <ETX>.

Unified message format:

Length
STX (Start) 1
HEADER 36
DATA variables 0 65535
ETX (End) 1

header data part

[STX]B001[SP][SP][SP][SP][SP][SP][SP][SP]0703140914480000000A346F[FS]B1000[FS]T04[ETX]

data field
Example of an actual message without the data part.
<STX>B001S1APDA0514052908093800000000A5A5<ETX>

Example of an actual message with the data part.

<STX>B001S1APDA05140529084755000000091F01<FS>T00<FS>R060<ETX>

[Link] Formally correct message

A message enclosed by <STX> - <ETX>, which also gives the correct value of the
length of the Data part, CRC, Terminal ID, Date and time of the transaction, is
considered a formally correct message.

[Link] Confirmation message

The purpose of this report is the confirmation of an activity (confirmation or acceptance
of another message or processing activity. This message does not contain a data part.

Page 21 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

Example of Confirmation message:

<STX>B001S1APDA0514052808312000000000A5A5<ETX>

[Link] FormatError message

The purpose of this message is to indicate the acceptance of an incomplete or invalid
message (containing a value error of the CRC or of a field).

Example of message signaling the acceptance of a message with a value error of the
CRC:
<STX>B001S1BPOS5907031409142900010000B6B7<FS>R106<ETX>

Example of message signaling the acceptance of a message with a format error:

<><><>

[Link] HeartBeat
The purpose of this message is to check if permanent connection between TCP/IP
service and POST is still active. The message length is 2 bytes (0xFF 0xFF) and is
periodically repeated every 5 seconds. If POST did not receive it in defined time,
reconnection must be done by the terminal.

[Link] Protocol abbreviations

Overview of abbreviations used for indicating protocol field format:

Abbreviation Description

A Fields with Alfa characters (containing A-Z, a-z characters)

N Field with Numerical characters (containing only 0-9 characters)
AN field with Alfa numerical characters (0-9, A-Z, a-z)
V Field with visible ASCII characters (hexadecimal values 0x20 up to 0x7E)
VCR as V field + supplemented by line separators [CR] (hexadecimal value 0x0D)
VGS as V field + supplemented by separator <GS> (hexadecimal value 0x1D)
YN It can contain only Y character or N character

2.5.2 Message header

The following table describes the field of the message header:
Field Format Length Value

Information on protocol type:

Protocol
AN 2 
type
 For device messages1 supported correct value is

1
Device messages doplnit popis, co jsou device message
Page 22 of 53
 Protocol
N 2 Default
version
Terminal logical identifier on which the transaction will be made. During
sending the first Transaction Request, the ECR does not know this value.
Terminal ID AN 8 This is a reason why first message fills this field with 8 spaces (character
0x20). In the verification messages it uses the value obtained from the first
message from POST.
Date and Time of transaction. This value is same for all messages of a single
transaction. The value is formatted: YYMMDDHHmmSS,
where:
 YY year (last 2 numbers for 2017 only 17 is given) (00 to 99)
Date Time N 12  MM = month (00 to 12)
 DD = day (01 to 31)
 HH = hour (00 to 23)
 mm = minute (00 to 59)
 SS = second (00 to 59)
Field with tags of additional parameters. It has the character of a bit map in
which each bit signifies an additional parameter. The entry is hexadecimal.
For messages going from ECR to POST it always has a value of

For B2 protocol
the POST that Device messages (protocol D2) is supported by the ECR.
Tags Otherwise
AN 4
For messages going from POST to ECR:
Bit0: Request for check during a Sales
transaction.
= 0 → Signature not required for just completed transaction
= 1 → Signature required for just completed transaction
Bit 1-15: reserved
Length of message d
Length of
AN 4 without a data part. Entry: Hexadecimal, e.g: "001C" for length of data part
data
28.
Checksum of message data part. If the message does not contain a data
. Entry: Hexadecimal, e.g: "F6C8".
CRC16 AN 4
For a calculation, see chapter 4.1 Algorithm for calculating CRC16 in C
language.

2.5.3 Message data part

Message data part consist of data fields. Each data field begins with the character
<FS> followed by the field identifier and value.

Structure of the data part of message. field 1 + field 2 field N

Structure of data field:

Part Length

<FS> 1
Field identifier 1
Value Variable length

Example of data part:

Page 23 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

<FS>T00<FS>B100

(with two fields: transaction type and amount, with a total data length of 9 characters)

2.5.4 Rules for working with data fields

[Link] Breakdown of data part

The message data part can be broken down into individual fields according to separator
<FS>.

[Link] Order
The data fields can be arbitrarily arranged.

[Link] Unknown fields

Data fields with unknown identifiers are ignored.

Page 24 of 53
 2.5.5 Data fields of Payment Services
An overview of required and optional fields in relation to the messages of individual transactions:
Field
Transaction Msq
A B C D E F H I J K L N P R S T U a b d f i n t q**
Req       
Sale Resp           
Req     
Reversal Resp     
Req     
Refund Resp           
Req     
Preauthorization Resp            
Incremental Req   
preauthorization Resp             
Req      
Completion Resp           
Req 
Subtotal Resp    
Req   
Total Resp     
Req  
Offline upload Resp   
Req  
POST data printing Resp    
Req 
HOST Handshake Resp  
Req 
TMS connect Resp
Req 
Last TMS connect Resp   
Req  
Last TRN repeat Resp           
Req  
Token Resp    
Req   
Variable Fare Resp     
Req   
VF Advice Resp  
Req 
Abort transaction Resp  

Page 25 of 53
 Chapter 2: IMPLEMENTATION OF INTERFACE

Req   
Cancellation Resp     
Req     
QuasiCash           
Resp
Req   
Completion New            
Resp
Transaction Msq A B C D E F H I J K L N P R S T U a b d f i n t q**

** Used only by unattended devices

 - required field.
 - optional fields

List of used data fields:

Field
Field identifier Format Name Description
length
Optional field is designed for Unattended POS but can be used also by attended POS
Customer Language
A A 2 terminals. Customer language code (ISO639-1) sent by ECR. Example: cs, en, de, fr, sk
(Iso639-1)
etc.
Transaction amount defines the value of a transaction. It is given without decimal point.
B N 1 - 18 Paid amount Example: the amount "2000" is given for the amount 20.00 CZK (exception is for Hungary,
where it is 2000 HUF).
Maximum number of transactions processed by operation. Typically used for upload of
C N 3 Count offline transactions. It sends just defined number of offline transactions stored in
terminal. The rest will be send next time when initiated.
D AN 0 - 1000 Transport data Field containing addition information/data related to transport.
expiration date of a payment card in the month and year form.
E N 4 e
Example: 1017 for a card expiring in October 2017
Identification of completed non-cash financial transaction. It is used to identify the
F V 8 Authorization code
transaction when a claim for refund is made.
H V 16 - 64 Token, HASH of Card PAN Field containing hash of enciphered PAN (SHA-256)
Currency of a transaction. It is important for transaction receipt, but currency has no
Multicurrency currency impact on the Totals where in FID L is clear total of all transaction amounts. If this field
I N 3
codes is not included in message, terminal will use its default currency.
Format: numeric

Page 26 of 53
 Length: fix 3
Example of supported codes: 203 = CZK, 978 = EUR, 840 = USD, 826 = GBP, 643 =
RUB.
Indication of used card scheme product.
J V 2 - 10 Indication of card product
Example: Visa, Mastercard, etc.
Field contains information about terminal data asked to be printed on the ECR printer
Terminal prepares formatted receipt.

ID:
00 application decision what to print (e.g. can be selected from terminal MENU)
K N 2 Id of printed information
01 application parameters (min TID + comm data)
02 Receipt of the last financial transaction (merchant ticket)
03 Receipt of the last financial transaction (customer ticket)
04 EMV data of last transaction
05 - Subtotals
Field is a summary of transactions made sinc It
contains a constant prefix, numbers and sums of credit and debit transactions, as well
as Cashback withdrawals.

Format:
Prefix "001001"
Number of debit transactions 4-digit number
sign (+ / - ) and 18 digit number (last 2
Sum of amounts of debit transactions
digits are decimals)
Number of credit transactions 4-digit number
Sums of financial sign (+ / - ) and 18 digit number (last 2
L V 75 Sum of amounts of credit transactions
transactions digits are decimals)
Number of Cashbacks made 4-digit number
sign (+ / - ) and 18 digit number (last 2
Sum of Cashbacks made
digits are decimals)

Example:

“0010010002+0000000000002000000001+0000000000000100000001+000000000000030000”

Message contains following transactions:

Page 27 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

 2 debit transactions in the total amount of HUF 200000

 1 credit transaction for HUF 10000
 1 Cashback for CZK 300.00

transactions are considered to be credit transactions. an

transactions and subtraction from amount). Amount Cashback is considered to be debit

transactions, but Number of debit transaction is not changed (i.e. 1x Sale + Cashback =
500CZK + 300CZK => Total = 800CZK, Number=1). Multicurrency has no impact on the
totals (it is still simple total of all amounts).
If this FID is present in the ECR request, POST sends to ECR totals from AC or POST in
response If this FID is missing in
Alphanumeric information sent by ECR to identify each transaction by adding identifier.
Reference number
N AN 1 - 20 This identifier appears in transaction reports.
(transaction identifier)
Warning: FID_S or FID_N can be used, cannot be used together.
This number must be masked for security reason.
Example:
P V 9 - 19 Card number (PAN) "472925******135" (len=15)
"472925*******135" (len=16)
"472925*******328135" (len=19)
This field informs about processing result (of transaction or message). Defined codes
R N 3 Response Code
are in the chapter 2.5.6 Transaction response codes
Allows to add additional identifier related to each transaction, which will appear in a
S N 1 - 10 Invoice number
transaction report.
Defines the type of transaction that is to be (or is) processed. Following values
supported:

Transactions Value Info

Sale 00
T N 2 Transaction type Preauthorisation 01
Incremental preauthorization 07
Preauthorization Completion 02
Refund 04
QuasiCash 05
Reversal 10

Page 28 of 53
 Offline Upload 11
Abort transaction 12 Timestamp is the same as current Trn
HOST Handshake 13
TMS connect 14
Token 15
POST data printing 16
Repeat Last Transaction 17 Timestamp is the same as original Trn
Variable Fare 18
VF Advice 19
Last TMS connect 20
Transaction cancellation 21 Enhanced Matching version
Preauthorization Completion 22 Enhanced Matching version
Sub-total 65
Close Totals 60

Code of Region in the Field contains code defining the transport region. This field is used by GPE transport
U AN 4
Czech Republic solution only. Example: region Praha, Kladno etc.
Field contains information of chip application ID with leading information. The value of
a AN 12-24 Application ID (AID) AID is set by card associations.
Examples: "A0000000031010" or "A0000000043060"
Gives the amount, which the customer wishes to withdraw. It is given without decimal
places and without a separator (decimal point).
b N 1 18 Cashback amount
Example: the amount "20000" is given for the amount 200.00 CZK or EUR (exception is
for Hungary, where it means 20000 HUF).
Field contains added data need for transaction cancellation. Format: TID, PAN,
Data for transaction
Sequence Number and date separated by ;
Cancellation,
TID - the terminal ID where the original transaction was created, available on original slip
Preauthorization completion
PAN - last four digits of the originally used PAN, available on original slip.
d AN 15-32 and Incremental
Sequence Number - of the original transaction, available on original slip. Sequence
Preauthorization -
Number is 9 bytes long, in future can be up to 16 bytes.
8];PAN[4];SQN[9-
Date - YYMMDD when the original transaction was initiated. Available on the original
16];DT[6
receipt or from stored data.
This code page is used for receipt printing, data sent in FID_t. Possible values are:
CodePage info for printing
f AN 10 ISO_8859-1
reasons
ISO_8859-2

Page 29 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

Sequence number
i N 9 (Preauthorization + Fix 9  numeric unique identifier used for Preauthorisation and its Completion.
Completion)
Fix 12  numeric unique identifier of the financial transaction. Date and time if the
n N 12 Id of transaction authorization is used in format RRMMDDHHMMSS. ECR uses this ID with unique TID
so the whole unique identification of transaction contains 20 alphanumeric characters.
Field contains additional text with information about response. Format of text:
Text1; # where ID can be response code
Extra Text with add.
q V 1 - 100 Last TMS connect transaction returns extra information about applications, versions
information
(without application ID, just major a minor version) and the last TMS connection date +
time in format RRMMDDHHMMSS. E GPE_PAY:0107;

Client ID (either FID_S or Field allows to add additional information related to transaction, which is then used to
s N 1-10
FID_s) check the transaction via non-cash payment.
Field contains preformatted text for the printing of the transaction receipt by the ECR.
The text is formatted into lines. Each line ends with a separator <LF > = 0x0A. The line
contains formatting characters and/or constant value or directive.
Size of field is variable (max size = 3 KB). In all versions of protocol (B0,B1,B2) fid_t [max
. In new version (B2) of protocol where
Device Messages are defined, fid_t can also be used in Device Messages for printing
on ECR.

Format character:
\c - following value (constant or directive) is centered on the line
\b - following value (constant or directive) is in bold
t AN 1 - 3072 Text for printing of receipt
\s - following value (constant or directive) is printed in narrow (42 chars per line)

Directive #:
#{value} - value is ID of FID used previously in message (FID_P, FID_a, or FID_J).
- value Z means TID[8] from message header

Directive $:
${value} - value is name of printed block. This block is loaded in ECR for all tickets
- value:
PAGE - move paper with ticket (equivalent to \n\n\n\n)
SEPAR - -------------

Page 30 of 53
 ADDR - print address of merchant
CABA - print info text for Cash back
INFO - print info special text (not used)

Example1:

\b#{P}<LF >\cExp Date: 1205<LF >${SEPAR}<LF > AutorCode: 123456<LF >

5434 **** **** **04

Exp Date: 1205 \cExp Date: 1205<LF >
------------------------------------
AutorCode: 123456

Example2:

**** **** **** 1204<LF > Exp Date: 1605<LF > ${SEPAR}<LF > AutorCode: 123456<LF
>

**** **** **** 1204

Exp Date: 1605
------------------------------------
AutorCode: 123456

Page 31 of 53
Chapter 2: IMPLEMENTATION OF INTERFACE

2.5.6 Transaction response codes

If the value of the response code is from 0 to 10 including, then the transaction is
completed and accepted. If the value is different, message is not completed and is
rejected.

Overview of values and description of Response codes:

Codes of accepted transactions
00 - 10 Accepted
Codes of rejected transactions
050 General processing error
051 Unable to connect with Central Systems
053 A response from the Central System was not delivered
055 Declined by chip card without authorization
056 Declined by authorization host (online transaction)
060 Transaction was cancelled by the operator
061 Transaction was cancelled by the customer
062 Customer rejected transaction due to amount
063 Processing exceeded the designated time limit
070 Transaction was not cancelled
071 Currency not supported (Multicurrency)
080 No paper in the internal printer
100 Transaction not supported or not allowed
101 Invalid card
103 Error in message format (protocol error) *
106 Error in message CRC (protocol error) *
107 Error in MAC (protocol error) *
108 Terminal Busy (protocol error) *
110 The amount is not allowed
160 Totals on ECR, POST are equal, on AC finished with error
Totals on ECR, POST are not equal, on AC finished with
161
error
200 Mandatory field missing in request message
500 Internal application Error
* These errors belong to the transport layer of the protocol and it is not confirmed by ECR.

Values undefined in the table s, that transaction

was declined.

Page 32 of 53
3 VALUE ADDED SERVICES
GPE provides value added services to our customers to extend usage of payment
terminals for its business.

3.1 EET service (only for Czech Republic)

This chapter describes the additional information necessary to use EET functionality
of payment terminal. This part of document is designed according to Act
no.112/2016 Coll. [1]

Basic EET principals and recommendations

 ECR must inform POST about all EET payments.
 Recommended connectivity is RS232 (TCP/IP is also supported).
 Backup of all EET payments in ECR is highly recommended but it is not
mandatory for using EET service.
 If the ECR supports or implements the EET extension the implementation of
synchronization process (T46) is also highly recommended.
 ECR starts all transactions process.
 Multicurrency and DCC are out of scope of this version of document.

3.1.1 EET transactions

With EET service you are able to use following transactions:
EET Transactions Value Mandatory Info
EET Check 45  Get status of PT
EET Synchronization 46  Synchronize the transactions offline log
EET Payment 47  General transaction to register payment
EET Cash Refund 48  Opposite to EET Payment registration
Result of last TRN if the response was
EET Repeat Last Transaction 17 
not delivered to ECR.
EET Sale 00  Extended standard transaction
EET Reversal 10  Extended standard transaction
EET Refund 04  Extended standard transaction

There are several transactions which are extended by EET service and several new
EET transactions focused to cash operations. The EET transaction has to be registered
online only, but if a communication error occurs it can be registered in offline mode in
the terminal. These offline registered transactions must be uploaded to NEST (GPE
Gateway) as soon as possible. To keep the offline log of registered transactions only
in the terminals is highly risky. From that reason it is highly recommended to
implement replication backup also in an ECR. There are several levels of backup
described below (if you can accept appropriate degree of risk). For detailed information
about current implementation of offline level in the terminal please ask GPE.

Page 33 of 53
Chapter 3: VALUE ADDED SERVICES

Implementation level of offline EET log.

Level Description

No backup offline EET trx. in an ECR at all. In the case of terminal corruption all offline
1
transactions can be lost forever.
Offline registered transactions are store also in an ECR. If the terminal is corrupted the
HW can be changed regardless to EET offline transactions. These will be refreshed from
2
ECR backup during synchronize phase. The log will be cleared immediately after
successful close day (means executing close totals transaction).
All offline transactions are also stored in an ECR as the level 2, but the uploading of all
offline transactions are controlled and synchronized with an ECR. Online uploaded EET
3
transactions are returned as a list of EET trx. IDs. Offline records are cleared
consecutively at both devices.

3.1.2 Extended data fids of EET service

Standard card transactions extended by EET service. Fid e keeps all extra EET data.
Extension for EET
Transaction Msq
T R e o
Req  
EET Sale
Resp    
Req  
EET Reversal
Resp    
Req  
EET Refund
Resp    

3.1.3 Fids for other EET transactions

Fids for other EET transactions
Data fids for EET transactions
Transaction Msq
T R e p j o n
EET Req  
Check Resp   
EET Req  
Payment Resp    
EET Req  
Cash Refund Resp    
EET Req  
Repeat Last Trn 1 Resp     
EET Req   
Synchronization Resp   

1
This transaction is considered to use also for cashless transactions which are extended by EET service. The fid
n contains original timestamp of requested transaction.

Page 34 of 53
3.1.4 Fid definition
This table contains extended EET fids
Fid
Format Length Description
identifier
Collection of values which are separated to several parts according to EET
e collection Variable
requirements [2]. ([Link].1)
p N 1-4 Count of offline registered transactions (in terminal or in an ECR).
2 Max.
o List
AN (249) ; - ; -329.
j N 2 Original transaction type

2
fid o example: S1AP22350001160723141513;S1AP223500021607231

3.1.5 EET Check

This transaction is set by ECR to POST always if a cashier is logging into ECR system.
The result of this action is the POST status. This status notifies the ECR about ability
to use EET service successfully. In additional the transaction executes check of offline
EET transactions stored in the POST. Terminal inserts fid p with count of unregistered
offline EET transactions which are currently remain in its log. It can help and warn a
cashier in case that count of offline transactions is above than specified a limit on the
ECR. An ECR can send its count of offline transactions to a POST and this one can be
compared with count in the POST as a complementary check, but it is not necessary.

R Response Code Extended codes for the EET service

This part defines extended response codes regard to EET service:
 POST is ready for EET payment (RC = 000) or transaction was successfully
done and registered.

 New terminal if it possible to recognize (after physical HW change) (RC =

300)
ECR is expected to send all EET transaction marked as undelivered to POST
(described later in more details)

 It is not possible to accept EET transaction due to full of offline EET log (RC =
301)
It is expected clear offline log using standard process which executes upload
offline EET transaction from ECR and terminal to GP-Gateway.

 It is not possible to send undelivered EET transactions from PT to GP-

Gateway (internal non-communication problem) (RC = 302)
ECR is expected to store current EET transaction marked as undelivered
POST is expected to inform about situation  CRITICAL PROBLEM: hardware
replacement.

 it is not possible to count BPK or PKP in POST if required (RC = 303)

ECR is expected to store current EET transaction marked as undelivered POST
is expected to inform about situation  CRITICAL PROBLEM: hardware
replacement or check the settings in the Merchant Portal!

Page 35 of 53
Chapter 3: VALUE ADDED SERVICES

Extended response codes for EET service.

Codes of accepted transactions

00 10 Accepted no changes

Codes of rejected transactions

300 New terminal hardware (There is no offline log)

301 An offline trx. cannot be accepted due to full log
302 Internal problem with the offline log
303 Terminal cannot generate secure or signature code
350 Repeat last message is not available
360 Repeat last message: original transaction was not found

3.1.6 EET Synchronization of transactions

This message is used to synchronize offline logs between an ECR and terminal. An
ECR sends EET Synchronization request with original EET transaction data in fid e
according to table ([Link].2). Registration codes (BKP, PKP) will be completed by
terminal or GP-Gateway. The synchronization (If it is supported by the ECR) can be
sent to the terminals base on the situation:

 Manually by some key or menu on the ECR since new terminal installation
occurred.
 Automatically due to check message response code is 300 (New HW) and the
ECR has stored unregistered offline transaction).

The manual approach is better apparently since no unwanted automatic sync. process
can be started. Using of this transaction has two possibilities according to parameter
transaction treatments in request from fid e. For the current level of imp. on the
terminal site please ask for GPE.

 Refreshing transactions from an ECR offline EET log to terminal EET log. See
diagrams 1 and 2 below.

 Forwarding transactions from an ECR offline EET log through the terminal to
GP-Gateway. See diagram 3 below.

Page 36 of 53
 GP Gateway
ECR Terminal

ECR:Login POST:Closed

Log count 100

RQ:Check [T45]
POST status
new HW
RS:Check [T45]
R[300] or p[0]

RQ:EET Synchronization
T[46], e[{00=2},{01},{02},{03},{04-16},
{17}], j[47], Store the EET
offline record in
Repeat Nx the POST
RS:EET Synchronization
T[46], R[000]

1. Synchronization diagram: POST HW was changed.

GP Gateway
ECR Terminal

ECR: Close totals POST

RQ:Close totals T[60] The ECR is closed

There are some OK
offline records
The POST
Upload offline transaction
erases offline log
Repeat Nx

Transaction registered

The ECR erases Close totals

RS:Close totals
offline log
T[60], R[000] Close totals

2. Synchronization diagram: erasing log on POST site regardless logs on ECR.

GP Gateway
ECR Terminal

ECR: Close totals POST

RQ:EET Synchronization
There are some T[46], e[{00=3},{01},{02},{03},{04-16},
offline records {17}], j[48], Upload offline transaction

Upload max. 10 trx.

Remove max. 10 trx RS:EET Synchronization
T[46], R[000] o[10xTrxId] Transaction registered
There are some
offline records
RQ:EET Synchronization T[46] ... Upload offline transaction

Remove max. 10 trx Upload max. 10 trx.

RS:EET Synchronization
T[46], R[000] o[10xTrxId] Transaction registered
No offline
records
RQ:Close totals T[60] Upload offline transactions

The ECR erases Probably it can send

The POST
offline log remaining trx.
erases offline log
Transaction registered

Close totals
RS:Close totals
T[60], R[000] Close totals

3. Synchronization diagram: erasing the logs on both sites.

Page 37 of 53
Chapter 3: VALUE ADDED SERVICES

3.1.7 EET Payment and EET Sale

This transaction is sent by ECR to PT to require process of EET payment by cash or
card. Both transaction must be complemented by fid_e.

3.1.8 EET Cash Refund, EET Refund

These transactions are opposite to registered payment by EET Payment or EET Sale.
All values are taking as a positive. Positive or negative amount are recognized by the
transaction type. Specific set of amounts in fid e are not required for this transaction,
only mandatory sFids are required according to table below.

3.1.9 EET Reversal

This transaction does not have specific additional impact to processing than
transaction EET Refund or EET Cash Refund. This transaction is used by ECR only in
case the previous transaction by bank card requires the signature validation (tag 0 in
header is set to 1) and the signature mismatch with the card. Fid_e contains same
mandatory sFids as EET Cash Refund or EET Refund.

3.1.10 Fids structure

e EET data
- The fid contains all addition data which is required for EET registration regardless
payment method. The mandatory sFids are driven by type of message (it means
request/response).

The sFids are separated by group separator <GS> (0x1D). Some subfids are
conditional relative to another subfid (see the table of sFids e). The structure is

Structure of the sFid: <GS>[ {2B} sFid ][ {nB} value ]

Page 38 of 53
Format of the fid e
Request Response
sFid Description Format
mandatory mandatory
00 The EET transaction treatment (2.8.12) (2.8.11) (2.8.11)
01 A part of unique EET transaction ID AN (9-20) (2.8.11) (2.8.11)
02 Date and time of sales [YYMMDDhhmmss] N 12 (2.8.11) (2.8.11)
03 Total amount of sale N (1-12) 
04 Total amount for performance exempted from VAT N (1-12) 
05 Total tax base - basic VAT rate N (1-12) 
06 Total VAT - basic VAT rate (Conditional to 05) N (1-12) 
07 Total tax base - first reduced VAT rate N (1-12) 
08 Total VAT - first reduced VAT rate (Conditional to 07) N (1-12) 
09 Total tax base - second reduced VAT rate N (1-12) 
10 Total VAT - second reduced VAT rate (Conditional to 09) N (1-12) 
11 Total amount under the VAT scheme for travel service N (1-12) 
Total amount under the VAT scheme for the sale of used
12 N (1-12) 
goods - basic VAT rate
Total amount under the VAT scheme for the sale of used
13 N (1-12) 
goods - first reduced VAT rate
Total amount under the VAT scheme for the sale of used
14 N (1-12) 
goods - second reduced VAT rate
Total amount of payments intended for subsequent
15 N (1-12) 
drawing or settlement
Total amount of payments which are payments
16 N (1-12) 
subsequently drawn or settled
17 Type of registered payment (2.8.13) (2.8.11) (2.8.11)
18 Taxpayer's Signature Code (PKP) (2.8.14) (2.8.11) (2.8.11)
19 Taxpayer's Security Code (BKP) (2.8.14) (2.8.11) (2.8.11)
20 Fiscal Identification Code (FIK) (2.8.14) (2.8.11) (2.8.11)

Example of request uses EET fid e (amount 500.00 with combined payment method):
<FS>e<GS>0350000<GS>0441320<GS>05<GS>068680<GS>173<FS>

Example of response uses EET fid e:

<FS>e<GS>000<GS>01S1AP00250001<GS>02160815142203<GS>1903ec1d0e-6d…<GS>20 b3a09b52-
7c87…<FS>

Page 39 of 53
Chapter 3: VALUE ADDED SERVICES

3.1.11 The EET sFids of fid e

The table specifies mandatory sFids inside fid e for each EET transaction.

EET Mesage Data subfids for EET transaction

Msg
type
00 01 02 03 04-16 17 18 19 20
Req   
EET Sale
EET Payment
Resp    1 1 1

EET Refund Req  

EET Cash Refund Resp    1 1 1
Req  
EET Reversal
Resp    1 1 1
EET Req      
Synchronization Resp

1 sFids are mandatory only if they are not automatically involved in the receipt text.

3.1.12 The EET transaction treatment

This sFid precisely specifies how the transaction was processed (Online or Offline).
Offline marked transaction the ECR should store in log. Store or Forward values are
used only in synchronization phase. The ECR specify how the offline transaction
should be processed (only store on the terminal or online sent to GP-Gateway).

Value Meaning Direction Description

The transaction was registered online at the GP

0 Online Response: Gateway. It is not needed to store in the ECR backup
log.
The transaction was registered offline at the terminal. It
1 Offline Response
is recommended to store in the ECR backup log.
Only for Synchronization msg. The ECR wants to store
2 Store Request
this transaction to offline log in terminal.
Only for Synchronization msg. The offline EET
3 Forward Request transaction are sent to the GP Gateway directly and
checked at the both log (ECR, POST)

3.1.13 Type of registered payment

The table specifies elementary payment methods defined by GPE and it is intended
to future extension. These methods will be displayed in merchant portal view for each
transaction.

Id Method Description

0 Unspecified It is not specified at all.

Several payment methods in one
1 Combined
EET registration message.

Page 40 of 53
 2 Bank card It was used bank card
3 Cash It was paid by cash
It was paid by gift card or loyalty
4 Gift card
card
5 meal ticket It was paid by meal tickets
6 Voucher The voucher was used

3.1.14 Signature and security codes

Codes identify each payment on the EET server and they must be printed on a receipt.
If the transaction is registered online the FIK and BKP are returned. If the transaction
is offline registered (on the terminal or on the GP-Gateway, SFS is not available) the
PKP and BKP are returned.

These sFids can be presented in the response message as sFid value (i.e. it can be a
placed on any location of ECR tickets) or it can be automatically involved in receipt fid
t, it depends on the terminal settings. If the codes are involved in receipt they will not
be placed in sFid e in response. Right place on the ticket can be leaded by directive
corresponding to particular name of code ${FIK}, ${BKP}, ${PKP} or they can be
rendered directly into the text without any leading marks or they can be returned
simply only as a value of sfids (18,19,20). All codes are in printable format.

 Mandatory sFids for online registered transactions:

Name coding Length Description

BASE
FIK 39 Fiscal Identification Code
16
BASE
BKP 44 Taxpayer's Security Code
16

Examples:
FIK:b3a09b52-7c87-4014-a496-4c7a53cf9125-03
BKP:03ec1d0e-6d9f77fb-1d798ccb-f4739666-a4069bc3

 Mandatory sFids for offline registered transactions:

Name coding Length Description

BASE
PKP 344 Taxpayer's Signature Code
64
BASE
BKP 44 Taxpayer's Security Code
16
Examples:
BKP:03ec1d0e-6d9f77fb-1d798ccb-f4739666-a4069bc3
PKP: Ca8sTbURReQjjgcy/znXBKjPOnZof3AxWK5WySpyMrUXF0o7cz1BP6adQzktODKh2d8s
oAhn1R/S07lVDTa/6r9xTuI3NBH/+7YfYz/t92eb5Y6aNvLm6tXfOdE3C94EQmT0SEEz
9rInGXXP1whIKYX7K0HgVrxjdxCFkZF8Lt12XbahhAzJ47LcPxuBZZp6U6wJ2sWI5os3
KY9u/ZChzAUaCec7H56QwkMnu3U3Ftwi/YrxSzQZTmPTpFYKXnYanrFaLDJm+1/yg+VQ
ntoByBM+HeDXigBK+SHaxx+Nd0sSmm1Im4v685BRVdUId+4CobcnSQ3CBsjAhqmIrtWT
GQ==

Page 41 of 53
Chapter 3: VALUE ADDED SERVICES

3.1.15 Unique EET Transaction number

This number is only part of entire unique EET transaction number. Unique transaction
number is complemented by sFid 02 (see the table with fid e). Entire unique number
is constructed by {TID[5-16], SequenceNr [4], Date+Time [12] } in summary 21-32B.

3.1.16 EET Repeat Last Trn.

If the EET service is activated on the terminal it will not be possible to use automatic
transaction Reversal since the EET transaction was successfully registered in the SFS.
From that reason the transaction Repeat Last Trn. must be used. If the ECR does not
receive response message in defined timeout ECR should send message Repeat Last
Trn. If there is no response also for Repeat Last Trn. request the transaction has to be
checked in the transaction system of provider payment services. There is not possible
to resolve this transaction automatically. The Repeat Last Trn. can be sent after all
timeouts expire on the terminal (default timeout is 60 [response]+2x15s[confirmation]
= 90s). If the ECR sends the Repeat Last Trn. earlier than the defined timeout limits
the terminal can replay by codes R108 (terminal busy) or it can repeat the original
response again according to current processing phase.

[Link] Negative response message

The negative response code informs that the requested transaction was not found in
log or terminal was not able to send Last Transaction Response due to unexpected
reasons. It is critical state since there is no possible to retrieved signature and secure
codes for a payment on a receipt.

[Link] Positive response message

The response message c j

Other fids match with previous performed transaction and it contains original response
data belongs to the original transaction type.

Page 42 of 53
 GP Gateway
ECR Terminal

ECR Opened POST Opened

RQ:EET Sale T[00]

Confirmation RQ: Payment

RS:EET Sale RS: Payment OK

Timeout 90s T[00], R[000], e[{00},..{20}] EET Data
expires
X
No confirmation msg from ECR

Payment
RQ:EET Last repeat response Accepted all
T[17], n[160617….] timeouts
Payment expires
Confirmation
Accepted
RQ:EET Last repeat response T[17]
[R000], j[00], e[{00},..{20}]
Confirmation

4. Repeat last response diagram.

3.1.17 EET advices and recommendations

A) It is highly recommended to implement backup log of offline transaction in the
ECR system (Level 2 or Level 3). It can eliminate losses of offline registered
transactions inside a terminal when a terminal is unavailable to upload offline
transaction to GP Gateway (from different reasons).
B) We prefer to use serial communication channel since it is resistant to wrong
local Ethernet configuration or blackout of infrastructure.
C) It is necessary to take to account that upload all offline transactions can take a
little more time. The process of real upload can be driven by terminal or ECR.
Uploading offline EET transactions can be processed before or after closing
phase of ECR or terminal.

3.2 Transport additional information

There are additional response codes for Transport transactions which are: Token and
Variable Fare. POS reads only payment cars, tries to make ODA (Offline Data
Authentication) during Sale request to 0.00 CZK or 0.01 CZK and returns result of this.

Extended response codes for Transport

900 Offline accepted
901 Online processing request ODA successful
902 Online processing request ODA failed
903 Offline declined by chip card
904 Declined by internal error
905 Invalid card
906 Card on Deny List

Page 43 of 53
Chapter 4: APPENDICES

4 APPENDICES
4.1 Algorithm for calculating CRC16 in C language
The following code uses POST for calculating CRC16. Standard CCITT v.41 prescribes the
polynomial value: x^16 + x^12 + x^5 + 1.

const unsigned short ccittTable[256] =

{
0x0000, 0x1021, 0x2042, 0x3063, 0x4084, 0x50A5, 0x60C6, 0x70E7,
0x8108, 0x9129, 0xA14A, 0xB16B, 0xC18C, 0xD1AD, 0xE1CE, 0xF1EF,
0x1231, 0x0210, 0x3273, 0x2252, 0x52B5, 0x4294, 0x72F7, 0x62D6,
0x9339, 0x8318, 0xB37B, 0xA35A, 0xD3BD, 0xC39C, 0xF3FF, 0xE3DE,
0x2462, 0x3443, 0x0420, 0x1401, 0x64E6, 0x74C7, 0x44A4, 0x5485,
0xA56A, 0xB54B, 0x8528, 0x9509, 0xE5EE, 0xF5CF, 0xC5AC, 0xD58D,
0x3653, 0x2672, 0x1611, 0x0630, 0x76D7, 0x66F6, 0x5695, 0x46B4,
0xB75B, 0xA77A, 0x9719, 0x8738, 0xF7DF, 0xE7FE, 0xD79D, 0xC7BC,
0x48C4, 0x58E5, 0x6886, 0x78A7, 0x0840, 0x1861, 0x2802, 0x3823,
0xC9CC, 0xD9ED, 0xE98E, 0xF9AF, 0x8948, 0x9969, 0xA90A, 0xB92B,
0x5AF5, 0x4AD4, 0x7AB7, 0x6A96, 0x1A71, 0x0A50, 0x3A33, 0x2A12,
0xDBFD, 0xCBDC, 0xFBBF, 0xEB9E, 0x9B79, 0x8B58, 0xBB3B, 0xAB1A,
0x6CA6, 0x7C87, 0x4CE4, 0x5CC5, 0x2C22, 0x3C03, 0x0C60, 0x1C41,
0xEDAE, 0xFD8F, 0xCDEC, 0xDDCD, 0xAD2A, 0xBD0B, 0x8D68, 0x9D49,
0x7E97, 0x6EB6, 0x5ED5, 0x4EF4, 0x3E13, 0x2E32, 0x1E51, 0x0E70,
0xFF9F, 0xEFBE, 0xDFDD, 0xCFFC, 0xBF1B, 0xAF3A, 0x9F59, 0x8F78,
0x9188, 0x81A9, 0xB1CA, 0xA1EB, 0xD10C, 0xC12D, 0xF14E, 0xE16F,
0x1080, 0x00A1, 0x30C2, 0x20E3, 0x5004, 0x4025, 0x7046, 0x6067,
0x83B9, 0x9398, 0xA3FB, 0xB3DA, 0xC33D, 0xD31C, 0xE37F, 0xF35E,
0x02B1, 0x1290, 0x22F3, 0x32D2, 0x4235, 0x5214, 0x6277, 0x7256,
0xB5EA, 0xA5CB, 0x95A8, 0x8589, 0xF56E, 0xE54F, 0xD52C, 0xC50D,
0x34E2, 0x24C3, 0x14A0, 0x0481, 0x7466, 0x6447, 0x5424, 0x4405,
0xA7DB, 0xB7FA, 0x8799, 0x97B8, 0xE75F, 0xF77E, 0xC71D, 0xD73C,
0x26D3, 0x36F2, 0x0691, 0x16B0, 0x6657, 0x7676, 0x4615, 0x5634,
0xD94C, 0xC96D, 0xF90E, 0xE92F, 0x99C8, 0x89E9, 0xB98A, 0xA9AB,
0x5844, 0x4865, 0x7806, 0x6827, 0x18C0, 0x08E1, 0x3882, 0x28A3,
0xCB7D, 0xDB5C, 0xEB3F, 0xFB1E, 0x8BF9, 0x9BD8, 0xABBB, 0xBB9A,
0x4A75, 0x5A54, 0x6A37, 0x7A16, 0x0AF1, 0x1AD0, 0x2AB3, 0x3A92,
0xFD2E, 0xED0F, 0xDD6C, 0xCD4D, 0xBDAA, 0xAD8B, 0x9DE8, 0x8DC9,
0x7C26, 0x6C07, 0x5C64, 0x4C45, 0x3CA2, 0x2C83, 0x1CE0, 0x0CC1,
0xEF1F, 0xFF3E, 0xCF5D, 0xDF7C, 0xAF9B, 0xBFBA, 0x8FD9, 0x9FF8,
0x6E17, 0x7E36, 0x4E55, 0x5E74, 0x2E93, 0x3EB2, 0x0ED1, 0x1EF0
};

// ====================================================================
// unsigned short calcCRC16(unsigned char *data, unsigned short len)
//
// In: data - pointer to data from which CRC16 is calculated
// len - length of data from which CRC16 is calculated
//
// Out: -
//
// Return: CRC16

Page 44 of 53
//
// Test: calcCRC16((unsigned char*) "123456", 6) => 20E4
// ====================================================================
unsigned short calcCRC16( unsigned char *data, unsigned short
dlen )
{
unsigned short crc16 = 0x0000;
unsigned short len = dlen;

if (!data || !len)
return crc16;

while(len --)
crc16 = (crc16 << 8) ^ ccittTable[(crc16 >> 8) ^ *data ++];

return crc16;
}

4.2 Serial cable structure

Crossover cable design

Full connection (POST RS232-1):

Female DB 9 RJ 12 6/6
2 - 2
3 - 3
8 - 4
7 - 5
5 - 6

Energy-efficient connection for ECR (POST RS232-2):

Female DB 9 RJ 12 6/6
2 - 2
3 - 3
5 - 6

Page 45 of 53
Chapter 4: APPENDICES

4.3 Communication trace

SALE

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>140526124328000000167673
<FS>B1500<FS>T00<FS>S0123456789<ETX>
POST: Confirmation message(s)
<STX>B001S1APDA0514052612432800000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA05140526124328000000499D0E<FS>T00<FS>R000<FS>P472943*******143
<FS>F123456<SPC>B<FS>aA0000000041010<FS>JVISA<FS>n140526124333<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052612432800000000A5A5<ETX>

SALE (WITH RECEIPT PRINTING IN ECR)

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>1405261303310000000A0221
<FS>B5500<FS>T00<ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052613033100000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA05140526130331000001417FE9<FS>T00<FS>R000<FS>P472943*******143
<FS>F123456<SPC>B<FS>aA0000000041010<FS>JVISA<FS>fISO-8859-
2<FS>t26/05/14<SPC><SPC>13:03:31<SPC>001<LF >#{Z}<LF >${SEPAR}<LF >A0000000041010
<LF>VISA<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>
<SPC><SPC><SPC><SPC><SPC>(S)<LF><SPC>****<SPC>****<SPC>****<SPC>*143<SPC>
<SPC><SPC><SPC><LF>PRODEJ<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>
<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC><LF><xC8><xE1>stka<SPC>CZK
<SPC>:<SPC>55.00<SPC><SPC><SPC><SPC><SPC><SPC><LF>Autoriza<xE8>n<xED>
<SPC>k<xF3>d:<SPC>123456<SPC>B<LF >${SEPAR}<LF >Doklad<SPC>uchovejte
<SPC>pro<LF >pozd<xEC>j<x9A><xED><SPC>kontrolu<LF >${PAGE}<LF ><FS>n140526130336<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052613033100000000A5A5<ETX>

SALE WITH CASHBACK

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>140526131317000000104D6A
<FS>B3000<FS>b1000<FS>T00<ETX>

Page 46 of 53
POST: Confirmation message(s)
<STX>B001S1APDA0514052613131700000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA0514052613131700000049B82B<FS>T00<FS>R000<FS>P472943*******143<FS>F123456
<SPC>B<FS>aA0000000041010<FS>JVISA<FS>n140526131323<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052613131700000000A5A5<ETX>

REVERSAL

ECR: Transaction request

<STX>B001S1APDA051405290913090000001469BA<FS>B1500<FS>F123456<SPC>B
<FS>T10<ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052909130900000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA05140529091309000000090DC6<FS>T10<FS>R000<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052909130900000000A5A5<ETX>

REVERSAL FOR SALE WITH CASHBACK

ECR: Transaction request

<STX>B001S1APDA051405291028440000001BB7C9<FS>B1500<FS>b10000<FS>F123456<SPC>B
<FS>T10 <ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052910284400000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA0514052910284400000009F0DC6<FS>T10<FS>R000 <ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052910284400000000A5A5<ETX>

REFUND - MERCHANDISE RETURN

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>1405261349320000000A346F

Page 47 of 53
Chapter 4: APPENDICES

<FS>B1000<FS>T04<ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052613493200000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA0514052613493200000039B95E<FS>T04<FS>R000<FS>P472943*******143
<FS>F123456<SPC>B<FS>JVISA<FS>n140526134937<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052613493200000000A5A5<ETX>

PREAUTHORIZATION

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>1405261356480000000A64CA
<FS>B1000<FS>T01 <ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052613564800000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA0514052613564800000054F87B<FS>T01<FS>R000<FS>P472943*******143<FS>F123456
<SPC>B<FS>i001001230<FS>aA0000000041010<FS>JVISA<FS>n140526135653<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052613564800000000A5A5<ETX>

PREAUTHORIZATION COMPLETION

ECR: Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>14052614090300000015E68E<FS>B1000
<FS>i001001230<FS>T02<ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052614090300000000A5A5<ETX>
<STX>B001S1APDA05140526140903000000000000<ETX>

POST: Transaction response

<STX>B001S1APDA0514052614090300000039D9D7<FS>T02<FS>R000<FS>P472943*******143<FS>F123456
<SPC>B<FS>JVISA<FS>n140526140909<ETX>

ECR: Confirmation message

<STX>B001S1APDA0514052614090300000000A5A5<ETX>

Page 48 of 53
 CLOSE TOTALS

ECR : Transaction request

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>1405261417040000003A872E<FS>T60
<FS>L0010010007+0000000000000195000002+000000000000004000<ETX>

POST: Confirmation message(s)

<STX>B001S1APDA0514052614170400000000A5A5<ETX>

POST: Transaction response

<STX>B001S1APDA051405261417040000003F52C7<FS>T60<FS>R000<FS>L0010010007+000000000000019500
0002+000000000000004000<ETX>

ECR : Confirmation message

<STX>B001S1APDA0514052614170400000000A5A5<ETX>

COMMUNICATION TCP/IP (SALE)

-= (ECR open connection to POST) =-

From ECR ([Link]) To POST ([Link]) TCP:2050 [SYN]
From PORT ([Link]) To ECR ([Link]) TCP:2050 [SYN, ACK]
From ECR ([Link]) To POST ([Link]) TCP:2050 [ACK]
From ECR ([Link]) To POST ([Link]) TCP:2050 [PSH, ACK]

-= (ECR connected to POST) =-

-= (ECR REQ -> POST)=-

<STX>B001<SPC><SPC><SPC><SPC><SPC><SPC><SPC><SPC>09110618112000000014CBBF
<FS>T00<FS>B100<FS>S123456789<ETX>

From POST ([Link]) To ECR ([Link]) TCP: 2050 [ACK]

From POST ([Link]) To ECR ([Link]) TCP: 2050 [PSH, ACK]

-= (POST CONFIRM. -> ECR) =-

<STX>B001S1BP725809110618112000000000A5A5<ETX>

From ECR ([Link]) To POST ([Link]) TCP:2050 [ACK]

From POST ([Link]) To ECR ([Link]) TCP:2050 [PSH, ACK]

-= (POST ACTIVITY -> ECR) =-

<STX>B001S1BP7258091106181120000000000000<ETX>

From ECR ([Link]) To POST ([Link]) TCP:2050 [ACK]

From POST ([Link]) To POST ([Link]) TCP:2050 [PSH, ACK]

-= (POST RESP. -> ECR) =-

<STX>B001S1BP72580911061811200001003F0F55<FS>R001<FS>T00<FS>F432419<SPC>B
<FS>P472941*******145<FS>E1012<FS>JVisa<FS>n091106181301<ETX>

From ECR ([Link]) To POST ([Link]) TCP:2050 [PSH, ACK]

-= (ECR CONFIRM. -> POST) =-

Page 49 of 53
Chapter 4: APPENDICES

<STX>B001S1BP725809110618112000000000A5A5<ETX>

-= (ECR close connection) =-

From ECR ([Link]) To POST ([Link]) TCP:2050 [FIN, ACK]
From POST ([Link]) To POST ([Link]) TCP:2050 [ACK]
From POST ([Link]) To POST ([Link]) TCP:2050 [FIN, ACK]
From ECR ([Link]) To POST ([Link]) TCP:2050 [ACK]
-= (ECR disconnected) =-

Revisions history
applies to:
version date modified description
AT CAT
13.00 01.03.2018 R. Bryx Complete user guide redesign and minor fixes  
12.33 14.08.2017 P. Kotal Extended descriptions - -
Added Preauthorization completion transaction
12.32 07.08.2017 P. Kotal  
support
Added QuasiCash transaction  
12.31 25.07.2017 P. Perman
New response codes and note added  
M. Trita Offline upload number of offline transactions to
 
12.30 06.06.2017 upload
P. Perman Close day new optional field U  
12.29 11.05.2017 P. Kotal Add remark and information  
Correction of transaction description  
P. Kotal
12.28 28.04.2017  
P. Perman
EET Revision  
12.27 7/11/2016 M. Trita Last TMS connect  
VF Advice transaction, U tag changed, response
12.26 30/08/2016 M. Trita  
codes for transport transactions added
12.25 13/07/2016 EET specification additional information added  
12.24 6/6/2016 M. Trita Transport Data, Variable Fare transaction  
FIX - Correct format field A Language code, from N
12.23 26/4/2016 P. Kotal  
to A
Corrections unattended  
12.23 26/4/2016 P. Kotal
size = 3kB)
 
 
 
12.22 13/1/2016 P. Kotal  
 
 
New  
FID_N: Reference number definition added  
12.21 28/04/2015 M. D
description of VAS removed  
Changes for Hungary (amounts without decimal
places)
12.20 24/11/2014 M. D  FID_B (amount)  
 FID_L (totals)
 FID_b (cashback)

References
- CRC-16 CCITT v.41
- EIA RS-232
- Control characters / ASCII, ANSI X3.4, CCITT Recommendation V.3

Page 50 of 53
This document fully replaces the original protocol documentation for communication with the cash
register (Protocol_B_vX - where X is the version number).

Trace convention
In tracing the invisible signs are replaced by the indication of the sign (according to ASCII) in the square
brackets. Messages exceeding 1 line are divided and continue on the next line only after a tab.

Page 51 of 53
Chapter 4: APPENDICES

4.4 FAQ

A few tips and tricks:

1 It is recommended to have 2 seconds timeout between two following messages sent by ECR
(i.e. between Close Totals and Logout or Gift payment and Confirmation).
2 Check number (CRC) for messages without data part (len =0) should be 0 (0000). Some POST
versions use in message header of Confirmation (ACK) value A5A5 instead of 0000. It has no
impact on the transaction and value of CRC is not checked.

Page 52 of 53
5 REFERENCES
1. Act no. 112/2016 Coll., - The exact wording of the law Czech Republic
2. Electronic Registration of Sales - [Link]
specifikace

Page 53 of 53