Hospitality integration

This section provides Hospitality interface descriptions to integrate magnetic and EMV chip and PIN cards transactions to EPOS applications.

Hospitality Integration Mode

Hospitality encapsulates banking magnetic and EMV payment card processing for integrating with EPOS applications. There are two types of interfaces available for integrating with Hospitality.

  • Hospitality Socket Interface: Provides a simple socket based mechanism to send transaction requests to Hospitality. Hospitality listens on a TCP socket for incoming transaction requests and provides a front-end to the attendant at the till to take chip or swiped card transactions.

  • Hospitality File Interface: Provides a simple file based mechanism to send transaction requests to Hospitality. Hospitality application polls an inbound directory for incoming transaction request and provides a front-end to the attendant at the till to take chip or swiped card transactions.

Note: For Cashback transactions, Hospitality application sends a cashback request in the file named “output-cashback-xxx.txt” and the corresponding response will be prepared in inputxxx.txt file where xxx is the unique identifier generated by the POS application. SeeCashbackfor more information.

Socket Interface

Hospitality application listens on a TCP/IP port number for transaction requests. Hospitality application opens all sockets in Server mode. The EPOS application should open the relevant sockets in Client mode.

The EPOS application should first establish a connection with the Hospitality (EVTInterfaceServer) application (e.g. request port 10000) and then send a transaction request.

Hospitality responds on the same connection to the transaction request e.g. if the transaction request is sent on socket 10000 to Hospitality by the EPOS application, Hospitality will send the transaction response back on the same socket connection.

The request message has the same format as in the file mode and similarly the response message has the same format as in the file mode.

Note: Configuration of pay at counter will be same as mentioned above except application creates a server to manage multiple instances. This server by default configured on host 127.0.0.1 and port 7000 and its configuration can be modified from property file payatcounter.properties (folder location - YESEFT/properties/payatcounter.properties). property.png SeePay at Counterfor more information.

File Interface

Since there can be multiple requests pending, and a response can be available for any pending request, a slight change is made in naming convention of Input.txt and Output.txt files. The input file must be named as Inputxxx.txt where xxx is the unique identifier generated by the POS application. The corresponding response will be prepared in Outputxxx.txt file.

For example: transaction reference can be appended to generate names like Input1234.txt.

SeeMultiple POS Supportfor more information.

Request/Response sequence

  • Submitting Sale Request

    • This will be normal sale request in the format as explained in section interfacing section at the beginning of the document. The request will also have the additional field “target reference” introduced for hospitality to set table number by which this request will be identified.
  • Request for polling status of submitted transaction

    • Set transaction type as 40 in request to check the status of a transaction. Set pre-set value and target reference of transaction (for which status is checked) in the field 97.
  • Request for polling status of submitted closed table

    • Set transaction type as 42 in request to poll all the Closed table request.
  • Response of polling request

    • The response for polling request will either get the result of transaction, in which case the response message will be in the format as explained in interfacing section at the beginning of the document. Since there can be multiple responses for a request as payment can be split, the response message for each transaction are separated by (--). If the transaction is not yet completed, transaction result field will either have a value of 44 (pending) or 45 (partially completed).
  • Response without any polling request

    • While using file interfacing, a response file (Outputxxx.txt) will always be prepared in output directory whenever the transaction is completed. Similarly for socket interfacing, a response message will be send back if the socket connection is still alive on which the original request was received.
  • Response of polling request of submitted transaction

    • The response for polling request will give the list of all Closed transactions. Transaction result field will have a value of 53=[], it contains all the Closed table response.