Communication Protocol
Protocol rules and flow
Communication is always started by the ECR, which sends the transaction request message to the terminal. For payments and refunds, the message includes the transaction amount.
All messages are exchanged in plain text, and the characters composing the messages are not altered in any way.
All messages include a LRC control byte. The LRC character is computed by executing an exclusive or any message byte, using as base value 0x7F.
Both terminal and cash registers validate incoming messages. Validation may fail for one of these reasons:
- Protocol error (invalid message code, invalid terminal ID)
- Parity error
- LRC error
If validation fails, a NAK is sent to the ECR.
Both the terminal and the cash registers repeat the message transmission. It is repeated up to three, on these events:
- The wait message time-out expiration
- NAK received
If the function is enabled, the terminal will verify that the terminal ID specified in cash register messages is equal to the one sent to cash register, or 00000000.
Application packet format
The format used for application packets is defined in the table below. These application packets refer to:
- Payment
- Reversal
- Refund
- Open session
- Close session
- Terminal status
- Send ticket
- Enable/disable ECR print
- Receipt reprint
This is possible due to all data being composed of application messages ASCII (0 to 127).
| Pos | Field name | Value | Type | Length (bytes) |
|---|---|---|---|---|
| 1 | Start of text | 0x02 | Binary | 1 |
2…N | Application message | Binary | N | |
N+1 | End of Text | 0x03 | Binary | 1 |
N+2 | LRC | Binary | 1 |
All the application-level packets have a physical confirmation message in response from the peer.
Procedure progress update packet format
During the procedures that imply a connection to the host, the terminal can transmit a message containing information about the progress of the current procedure. The messages are 20 characters long so that they can be easily displayed on the ECR display. The progress update messages do not require the physical confirmation message from the cash register.
| Pos | Field name | Value | Type | Length (bytes) |
|---|---|---|---|---|
| 1 | Start of heading | 0x01 | Binary | 1 |
2 | Message | Binary | 20 | |
22 | End of transmission | 0x04 | Binary | 1 |
Confirmation/refusal packet format
The confirmation/denial messages sent to the peer always have the following formats:
- Confirmation message (ACK)
| Pos | Field name | Value | Type | Length (bytes) |
|---|---|---|---|---|
| 1 | ACK | 0x06 | Binary | 1 |
2 | ETX | 0x03 | Binary | 1 |
| 3 | LRC | Binary | 1 |
- Refusal message (NAK)
| Pos | Field name | Value | Type | Length (bytes) |
|---|---|---|---|---|
| 1 | NAK | 0x15 | Binary | 1 |
2 | ETX | 0x03 | Binary | 1 |
| 3 | LRC | Binary | 1 |