ecr interface via ethernet rs232 fs v26

Functional Specifications document for ECR Interface enrichment

Functional Specifications

External Device Interface Enrichment

version 2.6 29-03-2011

Confidential

1/31


Document HistoryVersion 0.0 0.1 1.0 1.1 Date 23 15 22 13 - 06 - 2008 09 - 2008 09 - 2008 04 - 2009 Description / Comments Initial Draft PreRealese First Release In Response Message field 6, Length is changed from 10 to 12. In Response Message field 9, a new response code 51 is added. The usage is to alert the Operator that a DCC transaction is in progress. In Response Message field 15 will contain (Jcc Environment) the net amount after the commission deduction In Response Message field 39 is added and will contain the Hosts response text message as received. In Response Message field 41 is added and will contain the card product name as it is printed on the receipt In Request/Respose Message field 3, Installment Purchase is added. #3.3.1: Data Link Layer improved for TCP and RS-232 protocols. #3.4.1: Purchase transaction with installments will be supported. #3.4.2: A new batch may be opened automatically after the successful completion of close batch settlement process on close batch transaction type. #3.5.1: Request body message has been improved and few notes have been added. ACK message differs on TCP and RS-232 protocols. #3.5.2 Request body message has been improved; two new fields have been added at the end of the field list. Clarifications on Batch Total Amount and Batch Total Count have been given. ACK message differs on TCP and RS-232 protocols. #4: A dependency on RS-232 protocol has been added. #5.1: Impact analysis on EFT/POS site has been improved with TCP specification clarifications. #3.5.1: Orig. Transaction Amount in EURO Currency field improved in Request Body Message. #3.5.2: Response Text Message and Orig. Response Code field have been improved. Two new fields have been added. #3.5.2: Payment Result Message returned by EFT/POS to ECR is now called Response Message. #3.5.2: Retrieval Reference Number field corrected to Variable and maximum size set from 8 to 12 bytes. #3.5.2: Net Amount in EURO Currency field comments changed as Final Transaction Amount after Commission and MarkUp, if Installments included. #3.5.2: DCC Exchange Rate including MarkUp field size changed from 9 to 10 bytes. Duplicate transaction added Payment and Print Receipt transaction types added Receipt ticket per transaction prepared to be returned Barcode type Code 39 feature added for tickets Various RCs added Modified a bit the Transaction Types: now 07 is Balance Enquiry and Duplicate is moved to 09. Added currency codes in both request and response, thus not hard-coding any more the currency to Euro. The extended ASCII character set is used for receipt Author / Reviewer P.J.G. P.J.G. P.J.G. J.D.V.

2.0

24 04 - 2009

P.J.G.

2.1

30 04 - 2009

P.J.G.

2.2

20 07 - 2009

P.J.G.

2.3 2.4 2.5

28 06 - 2010 26 11 - 2010 15 02 - 2011

P.J.G. P.J.G. P.J.G.

2.6

29 03 - 2011

Z.Z.

Confidential

2/31

Functional Specifications document for ECR Interface enrichmentcontent.

Confidential

3/31


Contents 1 2 3 Introduction .................................................................................................. 5 Scope ................................................................................................................. 5 Implementation .......................................................................................... 73.1 3.2 3.3 3.4 3.5 Solution Description .................................................................................... 7 Proposed Solution ......................................................................................... 8 Data Link Layer............................................................................................... 8 Flow Diagrams .............................................................................................. 12 Message Formats......................................................................................... 19

4 Dependencies ................................................................................................. 30 5 Impact Analysis ............................................................................................ 305.1 EFT/POS terminal site .................................................................................. 30 5.2 ECR site .................................................................................................................. 30

6 Acceptance of the Specifications ........................................................ 31

Confidential

4/31


1

Introduction

The EMV technology (Chip and PIN) was introduced by the Payment Industry in an attempt to offer fast and secure transactions using a credit or a debit card. The introduction of PIN though did not completely eliminate the need of requesting on-line authorizations which with the old dial-up POS terminals and during busy hours and peak periods results in the creation of long queues and a lot of frustrating customers especially in places like big supermarkets and department stores. A solution that can alleviate this problem is the deployment of IP Terminals that will communicate via the internet or via VPN channels with leased line connections. The security of these transactions according to PCI standards may be achieved with the deployment of PCI/PED EFT/POS devices using SSL v3.0 authentication. These devices should be EMV Level 1 compliant with EMV Level 2 certified application by VISA, MASTERCARD and AMEX. The first stage of this project will be to install such EFT/POS devices to merchants in stand-alone mode that will be able to perform transactions with magnetic and chip cards driven by the device interface (console). Terminals will support all known authorization type of transactions according to each Auth Host System specifications. The second phase of the project will be the enhancement of the EFT/POS functionality by adding an External Device interface. This External Device could be an Electronic cash Register (ECR) device that big stores or supermarkets usually use or a simple PC. The aim of this interface will be to speed up transactions and to reduce human actions and mistakes on EFT/POS site and at the same time minimize EMV certification time by using an already certified EMV/POS terminal and the cost of a possible upgrade of the Merchants hardware to meet EMVCo standards. All payment transactions will be driven by this interface to the EFT/POS, the communication with Auth Host will be handled by the terminal and responses will be sent back to the Merchants ECR interface with the status of all transactions. In addition this interface will provide merchant that have a lot of counters and a lot of transactions the ability to automate their reconciliation process by providing them the necessary information electronically. The type of transactions and functions addressed by this interface will be described in the next sections of this specification document.

2

Scope

This document summarizes all our understanding for Hosts requirements concerning the acquiring payment services via magnetic and chip cards in big stores and hyper-markets. It actually addresses the functional requirements of the project as technical specifications of the proposed solution. There are no strict dependencies to particular hardware systems or products. This document also provides a high-level functional overview of the technical implementation. The objective of this document is not to explain the detailed technical and functional elements, but rather to provide to all partners the necessary understanding about the impact of the planned development to their systems compared to the existing configuration of their systems.

Confidential

5/31

Functional Specifications document for ECR Interface enrichment Any additional requirements and solution enhancements planned for subsequent phases are consequently outside the scope of this document. Note: This document mainly focuses on the interface specifications of the presented solution and the development particularities of the EFT/POS.

Confidential

6/31


3

Implementation

Merchants with Ethernet infrastructure in their stores can implement this solution. Each cashier desk consists of an ECR, either PC based or non PC based device. An EFT/POS device with LAN access may be installed on the same desk. Using the same Ethernet or WiFi network infrastructure, the ECR and the EFT/POS may be integrated for the purpose of payment transaction with a magnetic or chip card. An interface may be implemented between the EFT/POS and the ECR to satisfy such functionality. All payment transactions will be initiated by the ECR. ECR as a Frond-End system will manage all the services that the cashier may offer to the customer until the transaction is completed. Minimum human action by the clerk may be needed during the payment transaction execution to be conducted by the EFT/POS. Such actions will be the card presence for all transactions and the PIN entry for chip and PIN transactions. Transaction amount will be automatically calculated and transferred by the ECR to EFT/POS thus minimizing the possibility of financial errors by avoiding the manual capture of the amount on the EFT/POS.

3.1 Solution DescriptionNow days the number of transactions performed with magnetic and chip cards either credit or debit is getting larger and larger. Chip cards using EMV technology prevent acquirers by fraud transactions. New services are offered in various types of merchants and chip card is always the solution for the cardholder to feel safe about all these services, he pays with his card. On the other hand, time is a critical parameter for merchants like big stores or supermarkets concerning the payment process. Customers always will dislike queues that make them feel inconvenient. Printec, in Co-operation with Acquiring Banks, is ready to offer the alternative solution to their large customers. Ethernet networks may dramatically decrease the transaction processing time for even secure chip EMV cards with SDA or DDA or CDA security standards. Fast networks and 32-bit microprocessors may help on these needs. 32-bit EFT/POS terminals could be ideal for EMV processing of chip cards with Combined DDA authentication. ADSL connections provide a large bandwidth over 24MBps for simultaneous transactions between the merchant and the acquirer. Merchants with many point-of-sales may use either Ethernet or WiFi networks for their indoor infrastructure.

Confidential

7/31


3.2 Proposed SolutionBased on existing situation characteristics with its pros and cons, the idea is to extend the TCP protocol use between merchants and Acquiring Host System. Most of the big stores and hyper-markets have already the Ethernet network infrastructure due to the ECR devices they use. Each clerk located to each cashier operates the ECR device. An EFT/POS terminal with Ethernet connection ability attached to the ECR could be a proper solution for todays needs. Such devices offer peer to peer connection with the Authorization Host for performing all types of transactions with magnetic and chip cards via a secure channel using client & server SSL authentication over TCP protocol. Online transaction authorization times can be up to 6-8 secs over a safe tunnel with the online enciphered PIN support. Market is moving rapidly to debit transactions with PIN according to SEPA specifications that will be soon mandated in Europe zone.

3.3 Data Link LayerAccording to the following diagram all communications among all the participated elements of this implementation are based on TCP protocol. Especially, the communication between the EFT/POS and the Authorization Host is secured with the SSL protocol. The level of authentication can be declared according to the security standards that this implementation must fulfill. The only limitation on the communication level is the supported bandwidth of the whole network inside the store and for the connection with The Acquiring Host. This will be strongly dependent on the number of cashiers and the total number of simultaneous transactions that this network infrastructure should efficiently support. The schematic 1 below presents a store with a Retail System, a number of ECRs attached to that and the corresponding number of EFT/POS devices communicate with the Authorization Host for payment transaction authorizations, batch uploads and with the TMS for parameters download. Exception: In case the EFT/POS is not able to support simultaneous connections based on TCP protocol for both Auth Host and ECR interfaces due to software limitations of third party applications, the RS-232 protocol may be used for the ECR interface instead.

Confidential

8/31


Schematic 1: Network Diagram of the implementation

3.3.1 Data Link Layer aspectsThe following diagram 1 below depicts the various states of the interface according to the standard transaction flow. EFT/POS 1 2 3 4 5 6 Session End Diagram 1: Transaction Flow with states At state 4, the ECR should wait for a maximum of 180secs timeout for the reception of the result message. In case of timeout, ECR must end the session immediately. For the result acknowledgement, the same policy has to be applied by each site, as already described in the beginning of this section. ACK Message Result Message ACK Message Connection Establishment Request Message ECR

Confidential

9/31

Functional Specifications document for ECR Interface enrichment Important Notice: Due to the fact that each site may be on a different state, the payment transaction may be completed by the EFT/POS, it is safer the ECR to be responsible for the cancelation of such suspect transaction with a new reversal transaction at a later time. This will prevent the merchant than debiting his customers with unforeseen transactions in case of synchronization errors of the interface or network communication problems.

3.3.1.1 TCP protocol aspectsAlthough, the TCP layer provides the status of transmitted bytes to the sender of the data (request body message), it is assumed more efficient, the receiver of the data to acknowledge its reception with a response (ACK - acknowledgement) message. This is followed in practice for any message sent by any site for a peer to peer connection interface over TCP layer. The sender has to wait for a maximum of 5secs for the acknowledgement. Only the proper message format as described in the following paragraphs of section 3.5 declares the acknowledgement message structure. In case of acknowledgements absence after the predefined timeout of 5secs or any acknowledgement data corruption, the whole session will be broken automatically by the sender of the request message.

Confidential

10/31


3.3.1.2 RS-232 protocol aspectsAsynchronous protocols like RS-232 do not guarantee the integrity of the data transmission. Therefore, messages are encapsulated with special characters at each edge, followed by a control character. This control character may be either LRC or CRC as derived by an algorithm where body message and the edge characters participate. Receiver acknowledges the positive or negative reception of the transmitted message by an or character. This acknowledgement must occur in a maximum of 5 secs by the receiver. The protocol characteristics like baud rate, parity, stop bit, number of bits and LRC, CRC algorithms may be determined on a project base by the co-operation of development teams for each EFT/POS and ECR device. Few useful aspects of RS232 communication specification are listed below:

ASCII 0x02: Character at the left edge of the body message ASCII 0x03: Character at the right edge of the body message ASCII 0x06: Notifies the positive acknowledgement for the reception of the transmitted body message by the sender. ASCII 0x15: Notifies the negative acknowledgement for the reception of the transmitted body message by the sender. Each character different than received as the acknowledgement character by the sender should be assumed as notifying a negative acknowledgement. Sender must repeat the transmission of the message in case of negative acknowledgement up to 3 times. IF this happens the transmission ends abnormally for both sender and receiver site. : This character is derived by the logical XOR among all characters compose the body message and the . IT always has the size of 0ne byte. : The calculation of this two-byte character is based on a polynomial that may vary. The polynomial has to be agreed between the development teams of each EFT/POS and ECR device. Baud rate proposed is 115,000 bps and data transamission is declared as 8N1.

Confidential

11/31


3.4 Flow DiagramsAccording to the implementation, EFT/POS is solely in charge for the payment services with card use. Therefore, all existing transaction types supported by the Acquirer Host should be able to be performed via the ECR interface. The list of supported transactions is divided in two categories: the authorizations and the batch upload process (settlement). Apart from them, a number of administrative functions may be initiated via this ECR interface. Next paragraphs of the current section 3.4 discuss all these categories.

3.4.1 AuthorizationsThe list of supported authorizations consists of the following transactions:

PURCHASE: The normal sale transaction with or without installments based on the transaction type code. VOID: Any sale or refund transaction may be canceled according to each original reference number, if this initial transaction-Id resides in the current batch of the EFT/POS. REVERSAL: Any transaction may be canceled by the ECR according to the System-ID as reference number. This may happen due to communication error in any previous transaction or synchronization error of the EFT/POS ECR interface. REFUND: The merchandise return transaction for both partial and full refund. COMPLETION/CAPTURE: The sale transaction authorized offline always with an approval code keyed by the clerk as obtained before by voice authorization. DUPLICATE: Latest transaction performed of any type may be reprinted as customer receipt copy.

The list of transactions may be easily extended in the future based on the proposed interface between the ECR and the EFT/POS. The interface specifications described in section 3 paragraphs may cover such requirements.

Confidential

12/31

Functional Specifications document for ECR Interface enrichmentEFT / POSTerminal Idle State Cashier Request Payment Transaction Initiation Cashier Transaction Processing . Yes PAN via ECR No

ECRCashier Idle State

Pay By card ?

No

Get Magnetic or Chip Card

YesTransaction Processing Initiate Payment transaction with Magnetic / Chip card Via the EFT / POS Authorization ? Offline

Online

Online Authorization Process

Transaction Completion

Payment Result

Wait for Payment Authorization result by the EFT / POS

Receipt Printout Cashier Transaction Completion Transaction End

Terminal Idle State

Cashier Idle State

Transaction Flow initiated via ECR

Note: It is in the flexibility of the application providers for both devices EFT/POS and ECR to extend their functionality in order to satisfy these merchants new services. This is strongly dependent to the data fields exchanged between the EFT/POS and the ECR. The schematic diagram of the data link layer for any authorization type is depicted in the following diagram 2. Each TCP or RS-232 session established by the ECR will perform a separate authorization type transaction according to the current list of supported types. ECR will always be the caller of any payment transaction handled by the EFT/POS. In case of consecutive authorizations, the interface claims that ECR will always establish separate sessions per authorization. In other words, in case the ECR wants to perform a reversal transaction followed by a purchase transaction, the first session will be for the reversal transaction and once closed then a new session will be established by the ECR for the purchase transaction.

Confidential

13/31


HOST 1 2 3 4 5 6 7 8 9 10 Auth. Response Session End Connection Establishment

EFT/POS Connection Establishment

ECR

Cashier Request ACK Message

Auth. Request

Payment Result ACK Message Session End Diagram 2: Authorization transaction EFT/POS must create a new TCP session with the Auth Host in order to get the online authorization approval of the transaction, if needed. In case of a TCP based ECR interface, this TCP session will be a simultaneous session with the current ECR session established in the EFT/POS. EFT/POS is solely responsible for the session management with the Auth Host. Section 3.5 discusses the relevant messages with their data fields in application protocol level that contain all the necessary information for the transaction authorization execution as initiated by the ECR device.

3.4.2 Batch Upload process - SettlementEnd of Day operation of the ECR includes the Batch Upload process of the EFT/POS also. This is the respective end of day operation usually called as settlement for the payment transactions performed by the EFT/POS with magnetic and chip cards. The following schematic flow describes the batch upload process as initiated by the ECR.

Confidential

14/31

Functional Specifications document for ECR Interface enrichmentEFT / POSTerminal Idle State Cashier Request

ECRCashier Idle State

Batch Upload Process Initiation Cashier End Of Day Processing . Print Analytical Transaction Report

Batch Record Process .. Initiate Batch Upload via the EFT / POS

NoLast Record ?

YesBatch Totals Process . Wait for Batch Upload Result by the EFT / POS

Payment Result

Print Batch Upload Result Cashier End Of Day Completion Batch Upload Completion

Terminal Idle State

Cashier Idle State

Batch Upload Flow initiated via ECR

Diagram 3 describes the batch upload process. EFT/POS must establish a TCP connection with Auth Host in order to settle its payment transactions. This batch upload process or settlement is similar to any authorization transaction executed by EFT/POS as initiated via the ECR interface.

Confidential

15/31


HOST 1 2 3


ECR

Cashier Request ACK Message Connection Establishment CloseBatch Request CloseBatch Response Session End Payment Result ACK Message Session End Diagram 3: Batch Upload process - Settlement

4 5 6 7 8 9 10

For the convenience of the cashier, the ECR may request to retrieve the current totals of the current batch of the EFT/POS. This will be accomplished with a separate settlement category transaction called Get Totals. This particular transaction may be useful in case the clerk would like to instantly reconcile the payment totals between the EFT/POS and ECR for amounts paid by card only. Section 3.5 discusses the relevant messages with their data fields that contain all the necessary information for both Batch Upload and Get Totals settlement transactions as initiated by the ECR device. The following diagram 4 describes the Get Totals transaction of settlement category.

HOST 1 2 3 4 5 6


ECR

Cashier Request ACK Message Payment Result ACK Message Session End Diagram 4: Get Totals - Settlement

Confidential

16/31

Functional Specifications document for ECR Interface enrichment EFT/POS replies back to ECR the total number of transactions and the net total amount for the current batch. Each EFT/POS may keep only one batch as opened-current. Once the current batch closes with the successful batch upload process, a new batch should be opened either by the EFT/POS console or via the ECR interface. Note: EFT/POS may open a new batch automatically via the ECR interface after the successful close batch/settlement process. This means that in case EFT/POS application supports the open new batch feature, there will be no need to wait for a separate open new batch request after the successful end of the close batch process. Open Batch menu option will only be enabled by the the EFT/POS console for the first batch of the EFT/POS device life cycle.

3.4.3 Administrative FunctionsAll non financial transactions usually called as administrative functions that are supported by the EFT/POS may be managed via the ECR interface also. Initially the ECR interface will support the console management, like open and close functions. Console will be useful for technicians in order to maintain the EFT/POS application and its parameters more efficiently. The following schematic flow describes an administrative function as initiated by the ECR.

Note: The list of supported administrative functions may easily be extended via this ECR interface with new or existing functions of the EFT/POS. This will require the proper development by both EFT/POS and ECR application sites. An administrative function may or may not require the EFT/POS communication with any Host. In the TCP or RS-232 communication data link layer, the interface between the EFT/POS and ECR will manage sessions with the same logic, like Confidential 17/31

Functional Specifications document for ECR Interface enrichment authorizations and batch upload process do in order to keep consistency on the data link layer level. Diagram 5 below depicts such an interface. HOST 1 2 3 4 5 6 Session End Diagram 5: Administrative function ACK Message Payment Result ACK Message EFT/POS Connection Establishment Cashier Request ECR

Confidential

18/31


3.5 Message FormatsAccording to the diagrams 2, 3, 4 and 5 of section 3.4 of the document, the data link layer of each established session per transaction in the interface consists of four states: connection, cashier request, payment result and close session. Especially, for cashier request and payment result states one request and one response/ACK message have to be exchanged for each state. Next paragraphs discuss both messages exchanged by the two sites and describe the format details of each message construction. The acknowledgement message results in as the response message of each state.

3.5.1 Cashier Request stateAccording to all diagrams of section 3.4 each process, either authorization or settlement or administrative is always initiated by the ECR. ECR will be the main frond-end user interface tool for the cashier clerk to manage all cashier operations plus the payment operations. During an operation ECR may call its attached EFT/POS via the TCP or RS-232 protocol interface and sends a request message. The body context of this request message is constructed by fields as listed in the following table 1. The respective data link layer aspects are presented in paragraph #3.3.1 of this document.

Confidential

19/31

Functional Specifications document for ECR Interface enrichment REQUEST BODY MESSAGENo Type Field Name 1 System Identification V, Present In

ALL

2 Field Separator 3 Transaction Type

F, M F,

ALL ALL

4 Field Separator 5 Orig. Transaction Amount 6 Field Separator 7 Account Number

F, M ALL V, M 00, 01, 02, V, M 03, 04, 06, V, O 08 F, M ALL V, C

8 9 10 11 12 13 14 15

Field Separator Expiration Date Field Separator Valid From Field Separator Orig. Refer. Number Field Separator Auth. Code

F, F, F, F, F, F, F, F,

M C M C M C M C

ALL ALL

ALL 04 ALL 03 ALL

16 Field Separator 17 CVV2 18 Field Separator 19 Contract/Room No 20 Field Separator 21 Start Date 22 Field Separator 23 Ext. Terminal Id

F, M F, C

F, M ALL V, C 00, 01, 02, 03, 06 F, M ALL F, C 00, 01, 02, 03, 06 F, M ALL F, C 08

Size Comments 32 System Id as maintained by ECR. (It may be used as a reference number for possible REVERSAL transaction, if supported.) 1 = ASCII 0x1C 2 Transaction type supported: 00 = Purchase 01 = Pre-Authorization 02 = Refund 03 = Completion or Capture 04 = Void 05 = Reversal 06 = Purchase with Installments 07 = Balance Enquiry 08 = Payment 09 = Duplicate 10 = Close Batch - Settlement 11 = Open New Batch (FU-Not Supported) 12 = Get Totals 20 = Enable Console 21 = Disable Console 22 = Keep Alive 23 = System Menu 30 = Print Ticket 1 = ASCII 0x1C 10 Transaction Amount (9999999V99). If not provided (empty), it will be requested by the EFT/POS. 1 = ASCII 0x1C 22 Card Number (PAN)(1). If not provided then card will be requested to be entered via the EFT/POS. 1 = ASCII 0x1C 4 YYMM Card Expiration date(1). 1 = ASCII 0x1C 4 YYMM Valid From date(1). (This field is valid solely for cards) 1 = ASCII 0x1C 4 Transaction Receipt Number. 1 = ASCII 0x1C 6 Transaction Approval Code. (This field is valid only for COMPLETION transaction) 1 = ASCII 0x1C 3 CVV2(1) should be present in case PAN is provided by ECR. 1 = ASCII 0x1C 9 Contract No. or Room No. (If not provided, it will be requested by the EFT/POS) 1 = ASCII 0x1C 8 DDMMYYYY Check-In date. (If not provided, it will be requested by the EFT/POS) 1 = ASCII 0x1C 10 Biller Terminal Id 20/31

Confidential

Functional Specifications document for ECR Interface enrichment 24 25 26 27 28 29 30 31 Field Separator Ext. Merchant Id Field Separator Ext. Reference Number Field Separator Receipt Content Field Separator Prepare Receipt Ticket F, M F, C F, M V, C ALL 08 ALL 08 1 10 1 16 1 999 1 1 = ASCII 0x1C Biller Merchant Id = ASCII 0x1C Reference Number provided by third part application = ASCII 0x1C Receipt data formatted in lines(2) = ASCII 0x1C 0: Transaction Receipt Ticket to be returned & NOT to be printed by the EFT/POS. other: Transaction Receipt Ticket will be printed by the EFT/POS. = ASCII 0x1C Language Id with default value 00 for local language = ASCII 0x1C Used to indicate the transaction currency using numeric values according to ISO 4217 (e.g. 978 is for Euro). If not provided (empty), it may be requested by the EFT/POS. = ASCII 0x1C

F, M ALL V, C 30 F, M ALL F, C 00, 01, 02, 03, 04, 06

32 Field Separator 33 Language 34 Field Separator 35 Currency Code

F, M ALL F, C 00, 01, 02, 03, 04, 06 F, M ALL F, M 00, 01, 02, F, M 03, 04, 06, F, O 07, 08

1 2 1 3

36 Field Separator

F, M

ALL

1

Table 1: Cashier Request Message type. Note: The explanation of symbols in column Type is as follows: F = Fixed size V = Variable size = Mandatory field C = Conditional field O = Optional field. Note: Column Present In declares the transaction type codes that the specific filed should be present in the message context. (1): According to PCI standards, this field is strongly recommended to NOT be present in the message context. (2) The format of field No29 Receipt Content will be as follows: FJFJFJFJ FJ where: F declares the font as: B: double width font N: normal font C: barcode font (type Code 39 consists of ten (10) digits and two (2) sentinels) J declares each line justification as: L: left justification R: right justification C or other: centered justification declares the printable data content of this particular line of receipt. The maximum size of this data is 42 characters for normal font and 21 characters for

Confidential

21/31

Functional Specifications document for ECR Interface enrichment bold font. The extended ASCII character set is used (e.g. ISO-8859-2 character set for Latin-written Slavic and Central European languages or ISO-8859-7 for Greek). represents the line separator character as ascii 29.

Confidential

22/31


EFT/POS must reply back to ECR with an acknowledgement message with the following format in order to validate the request message reception. EFT/POS has the responsibility to perform this financial or administrative operation and reply back to ECR with its result. Notice: Acknowledgement message may be omitted by the protocol after the mutual agreement between both EFT/POS and ECR sites. Definitely, this is NOT the proposed logic to be applied in every case. TCP protocol case: This acknowledgement message is constructed by fields as listed in the following table 2. ACK MESSAGENo

Field Name Type 1 System Identification V,

Present In

ALL


F, M F,

ALL ALL

4 Acknowledgement

F, M

ALL

Size Comments 32 System Id as maintained by ECR. (It may be used as a reference number for possible REVERSAL transaction, if supported.) 1 = ASCII 0x1C 2 Transaction type supported: 00 = Purchase 01 = Pre-Authorization 02 = Refund 03 = Completion or Capture 04 = Void 05 = Reversal 06 = Purchase with Installments 07 = Balance Enquiry 08 = Payment 09 = Duplicate 10 = Close Batch - Settlement 11 = Open New Batch (FU-Not Supported) 12 = Get Totals 20 = Enable Console 21 = Disable Console 22 = Keep Alive 23 = System Menu 30 = Print Ticket 2 00= Message Acknowledged other= Message NOT Acknowledged

Table 2: Cashier Request Acknowledgement Message type.

Confidential

23/31


RS-232 protocol case: The reply message is solely consists of special character. The requested function may or not require a separate communication session to be established by the EFT/POS with another host. Financial transactions and batch uploads usually fulfill such a demand for Auth Host. This is also related to the EFT/POS parameters, like floor limit per card, since zero floor limits require online authorization of each payment transaction. Functions like offline transaction authorization and open or close console do not require any communication by the EFT/POS and they are completed offline by the device.

Confidential

24/31


3.5.2 Payment Result stateThis is the state that EFT/POS must update back the ECR for the result of the requested operation over the existing TCP or RS-232 session. According to aforementioned diagrams 2, 3, 4 and 5, EFT/POS must send to ECR the Payment Result message. The body context of this request message is constructed by fields as listed in the following table 3. The respective data link layer aspects are presented in paragraph #3.3.1 of this document. RESPONSE BODY MESSAGENo


Present In

ALL


F, M F,

ALL ALL

4 . of Installments

F, M

00, 01, 02, 03, 04, 06 00, 01, 02, 03, 04, 06

5 No. of Postdated Months

F, M

6 Terminal Identification 7 Field Separator 8 Batch Number 9 Response Code

V, M F, M F, M F, M

ALL ALL ALL ALL

Size Comments 32 System Id as maintained by ECR. (It may be used as a reference number for possible REVERSAL transaction, if supported.) 1 = ASCII 0x1C 2 Transaction type supported: 00 = Purchase 01 = Pre-Authorization 02 = Refund 03 = Completion or Capture 04 = Void 05 = Reversal 06 = Purchase with Installments 07 = Balance Enquiry 08 = Payment 09 = Duplicate 10 = Close Batch - Settlement 11 = Open New Batch (FU-Not Supported) 12 = Get Totals 20 = Enable Console 21 = Disable Console 22 = Keep Alive 23 = System Menu 30 = Print Ticket 2 Number of Installments: 00 = No Installments = Transaction Installments 2 Number of Months that 1st installment will be debited: 00 = No Buy-Now-Pay-Later MM = Postdated months of 1st installment 12 Terminal Id or Device S/N* 1 = ASCII 0x1C 3 Current Batch No. 2 Transaction Result - RC: 00 = Online Approved 01 = Offline Approved 07 = Admin Approved (for Keep Alive) 10 = Online Declined 11 = Batch Status Error

Confidential

25/31

Functional Specifications document for ECR Interface enrichment 12 = Offline Declined (Not Allowed) 13 = Offline Declined (Installments) 14 = No Transaction match 15 = Close Batch Succeeded 16 = Close Batch Rejected/Failed 17 = Balance NOT Available 30 = User Break 31 = Console Timeout 32 = Card Presence Timeout 40 = No Connection - Please Try again 50 = HOLD Reset Payment Result Timeout 51 = Bad Magnetic Track Data(2) 52 = DCC Alert EFT/POS alerts ECR operator that a DCC transaction is in progress 90 = System Menu Return 95 = SCR slot busy / Card presence 96 = SCR Possibly Tampered 97 = SCR Disconnected from Vx700 98 = Unknown Transaction/Function 99 = Cashier Request Format Error = ASCII 0x1C Total Transaction Amount before Redemption. (9999999V99) For transaction type 07 this is the result of balance enquiry For transaction types 10 and 12 this is the Batch Total Net Amount (S9999999V99), if reconciliation approved. = ASCII 0x1C 0= Transaction without Redemption 1= Transaction with Redemption = ASCII 0x1C Final Transaction Amount after Redemption (9999999V99) = ASCII 0x1C Transaction Reference Number as provided by Online Authorization process = ASCII 0x1C Transaction Receipt Number, if approved. For transaction types 10 and 12 this is the Batch Total Transaction Counter. = ASCII 0x1C Transaction Approval Code

10 Field Separator 11 Original Amount or Batch Total Net Amount

F, M V, C

ALL 1 00, 01, 02, S10 03, 04, 06, 07, 10, 12

12 Field Separator 13 Loyalty Redemption Indicator 14 Field Separator 15 Modified Amount 16 Field Separator 17 Retrieval Reference Number 18 Field Separator 19 Trans. Refer. Number or Batch Total Counter 20 Field Separator 21 Auth. Code 22 Field Separator 23 Account Number 24 Field Separator 25 Expiration Date 26 Field Separator 27 Cardholder Name 28 Field Separator 29 DCC Transaction

F, M F, C F, M V, C F, M V, C F, M F, C

F, M V, M F, M F, F, M F, F, M V, C F, M V, C

ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 04, 06, 08 ALL 00, 01, 02, 03, 04, 06, 10, 12 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, Confidential

1 1 1 10 1 12 1 4

1 6

1 = ASCII 0x1C 4 Only the last 4 digits of PAN will be provided. 1 = ASCII 0x1C 4 YYMM Card Expiration date 1 = ASCII 0x1C 40 Cardholder Name provided by Track1, if read. 1 = ASCII 0x1C 10 Final Transaction Amount in DCC Currency 26/31

Functional Specifications document for ECR Interface enrichment Amount 30 Field Separator 31 DCC Currency 32 Field Separator 33 DCC Exchange Rate including MarkUp 34 Field Separator 35 DCC MarkUp percentage 36 Field Separator 37 DCC Exchange Date of Rate 38 Field Separator 39 Response Text Message 40 Field Separator 41 Card Product Name 42 Field Separator 43 Original Response Code 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 04, 06, 10 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 04, 06, 10 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 00, 01, 02, 03, 04, 06 ALL 10, 22 ALL 00, 01, 02, 03, 04, 06, 07, 10, 12 ALL (9999999V99) 1 = ASCII 0x1C 3 ISO Numeric Currency Code of DCC 1 = ASCII 0x1C 10 999V999999 1 = ASCII 0x1C 8 99V999999 1 = ASCII 0x1C 4 DDMM date of DCC details 1 = ASCII 0x1C 200 Authorization Host Response Text Message (This field will be present for online processing only) 1 = ASCII 0x1C 24 Card Product Name as printed on the transaction receipt 1 = ASCII 0x1C 3 Authorization Host Response Code (This field will be present for online processing only) 1 = ASCII 0x1C 6 DDMMYY date of 1st installment will be debited (This filed is optional, if postdated months presented in this message context) 1 = ASCII 0x1C 10 Final Transaction Amount after Commission and MarkUp, if Installments incl (9999999V99) 1 = ASCII 0x1C 999 Transaction Receipt Ticket data content(1) 1 = ASCII 0x1C 1 Defines current batch status as declared for particular acquirer. 1 = ASCII 0x1C 3 Used to indicate the transaction currency using numeric values according to ISO 4217 (e.g. 978 is for Euro) 1 = ASCII 0x1C

F, M F, C F, M V, C F, M V, C F, M F, C F, M V, C

F, M V, C F, M V, C

44 Field Separator F, M 45 1st Installment Date F, C

46 Field Separator 47 Net Amount 48 Field Separator 49 Transaction Receipt Ticket 50 Field Separator 51 Batch Status 52 Field Separator 53 Currency Code

F, M F, C F, M F, C F, M F, C F, M F, M

54 Field Separator

F, M

Table 3: Payment Result Message type. Important Note: Calculation of values for fields Batch Total Counter and Batch Total Net Amount should be managed by EFT/POS according to the specifications of the protocol interface between the EFT/POS and the Acquirer Host. Usually, we have:

Batch Total Counter is the sum of purchase, offline and refund transactions that they have NOT been voided. Batch Total Net Amount is the sum of all transaction amounts where purchase and offline transaction amounts are added, whilst refund transaction

Confidential

27/31

Functional Specifications document for ECR Interface enrichment amounts are deducted. (WARNING: This value is signed (declared as S10) as its value can be either positive or negative.) The 2-digit field named Response Code describes the result of the transaction performed by the terminal. Such a result may declare: 1. an Approved transaction 2. a Declined transaction 3. a HOLD request Apart from System Identification that determines the reference number of each transaction as maintained by the ECR, a UTN (Unique Transaction Number) may be retrieved out by the contribution of the following fields as ordered below: 1. Terminal Identification (Field No6) 2. Batch Number (Field No8) 3. Trans. Refer. Number (Field No19) Transaction may be approved or declined, either online by the Auth Host or offline by the terminal itself locally. The HOLD request may be used in order to inform ECR that EFT/POS requires extra time for the transaction processing completion. Therefore, whenever the ECR receives a payment result with a HOLD request as response code, the ECR should reset its timeout for payment result. EFT/POS should be aware of the timeout value configured for that on the ECR also. ECR must reply back to EFT/POS with an acknowledgement message with the following format in order to validate the request message reception. ECR after the transmission of this acknowledgement closes automatically the current session. (1): Please see note (2) for table 1 of paragraph #3.5.1. (2): RC51 notifies the ECR that magnetic track data of the card could not be read properly. (This RC is valid only for magnetic cards.) ECR must advise the user to pull out his card from the card slot. Response message with RC51 should be assumed as a notification response by the Vx700. ECR must reset its response timeout counter and wait again for the final transaction response message. VX700 will wait for a predefined timeout of 30secs the cardholder to take the card from the slot. In this way, the magnetic data of the card will be read properly and transaction will be automatically initiated for the Vx700 without the need for a new request sent by the ECR. Vx700 will process the transaction and reply back to ECR with a valid response message.

Confidential

28/31


TCP protocol case: This reply message is constructed by fields as listed in the following table 4. ACK MESSAGENo


Present In

ALL


F, M F,

ALL ALL

4 Acknowledgement

F, M

ALL

Size Comments 32 System Id as maintained by ECR. (It may be used as a reference number for possible REVERSAL transaction, if supported.) 1 = ASCII 0x1C 2 Transaction type supported: 00 = Purchase 01 = Pre-Authorization 02 = Refund 03 = Completion or Capture 04 = Void 05 = Reversal 06 = Purchase with Installments 07 = Balance Enquiry 08 = Payment 09 = Duplicate 10 = Close Batch - Settlement 11 = Open New Batch (FU-Not Supported) 12 = Get Totals 20 = Enable Console 21 = Disable Console 22 = Keep Alive 23 = System Menu 30 = Print Ticket 2 00= Message Acknowledged other= Message NOT Acknowledged

Table 4: Payment Result Acknowledgement Message type. RS-232 protocol case: The reply message is solely consists of special character.

Confidential

29/31


4 Dependencies

Both EFT/POS terminal and ECR should be able to get a static IP address. Gateway and Subnet Mask configuration parameters are may be valuable concerning the local area network configuration settings to be declared. Each ECR should be configured to communicate with only one specific EFT/POS device. This will be managed by the IP address declaration of each device. In case RS-232 protocol used, both EFT/POS and ECR devices should be equipped with an RS-232 port (Tx, Rx, GND signals available).

5 Impact AnalysisThe following paragraphs describe the impact of the new functionality on the whole project implementation as follows:

5.1 EFT/POS terminal siteThe whole POS application development will rely on the following standards:

LAN interface will be configurable on the EFT/POS. Terminal should be able to perform transactions, either by its console or by the LAN interface or by both ways. Mandatory fields not set via the message context of the interface will be prompted to the user for input by the proper device interface (console magnetic card reader - smart card reader). Only limited administrative functions will be enabled via this interface. Duplicate transaction and System Menu should be available for the clerk directly via the EFT/POS console, even if EFT/POS console is locked for other authorization transactions. The Ethernet communication module of the EFT/POS must be able to establish simultaneous connections with both Auth Host and any External Device (i.e. via an ECR interface) on separate sessions. Session with ECR has to remain active, while a separate session with Auth Host will be enabled. LAN settings, like: receiver IP address and port, calling IP address and port, Payment Result phase timeout of caller for the External Device interface should be configurable. (Important Clarification: Calling device will always be the ECR device and receiver device will be the EFT/POS unit).

5.2 ECR siteTo be completed by the ECR vendor accordingly .

Confidential

30/31


6 Acceptance of the Specifications

Confidential

31/31

ecr interface via ethernet rs232 fs v26

Documents

response message field

requestrespose message

ack message

response code field

message formats

request body message

hosts response text

payment result message