Hospitality Features

The following sections cover features of Worldpay Total Hospitality:

Bill printing at Table

This feature supports bill printing at the table, to enable the waiter or waitress to print the bill/invoice from the PED at the time of transaction processing.

Hospitality supports this feature for Sale transactions only; the EPOS application must provide the pre-formatted text of the bill to Hospitality as part of the Sale transaction input request in attribute 98.

You can see an example of Sale with Invoice Content requesthere.

Cash At Table

This feature supports cash at table payments means merchants can take cash payments using PED. There is no difference in the input sale request of Card and Cash

Hospitality introduces support for cash payment after the amount confirmation with a new screen introduced where customers have both options for CARD/CASH.

You can see an example of Cash at Table requesthere.

Cash Payment scenarios:

  • The Card/Cash and ENTER CASH AMOUNT screens time out after 60 seconds.

  • After a time out the screen display to PAY NOW, PAY LATER or CLOSE PAYMENT.

  • If you enter an amount less than the Sale amount an error will appear (Invalid Amount Txn Cancelled) and the transaction will be cancelled.

  • If you enter an amount equal to the Sale amount the transaction will be processed and no Change will be recorded.

  • For Split transactions, the total amount must be greater/equal to the split sale amount.

Multiple POS Support

Hospitality supports Transaction Requests from multiple POS devices. Each POS server must provide requests for unique table reference, a unique set of table numbers in each POS system.

File Mode

Existing behavior of application with file mode accepts requests with Unique identifier post-fix file name and provides responses back with the same post-fix .

For example: Input request file name is input123.txt than output will be generated with file name output123.txt by keeping unique post fix identifier.

Socket Mode

Works slightly different from file mode as there is configurable port which listens to POS for incoming requests. Multiple POS can make connections to the configured port and each incoming request from a designated POS will store the connection object. The response will be provided back to the POS by identifying that particular connection object.

Handling Duplicate request (same table number) from same or other POS systems

Whenever Hospitality receives requests from a POS it validates the incoming request and stores it in the queue. When the same or different POS sends request for same table number to hospitality then a busy notification response is provided to the corresponding POS.

Hospitality checks for availability of a request with table number and status in the queue. If the request with table number is already in the queue and its status is 'cancelled' or 'completed' then it is stored immediately otherwise a busy response notification is provided to designated POS.




3=42 (Busy Response)

Handling request of table closure with Multiple POS

Existing implementation of table closure polling (2=42) provides the status of all closed table. To support table closure polling from multiple POS you need to introduce an optional filter table field along with existing table closure polling requests. In this scenario multiple POS devices poll for their own tables.

SeePoll Request for Close TableandPoll Request for Specific Tablefor examples.

Cancel an already placed order/update transaction request in Multiple POS environment

Input request can be modified from multiple POS devices. To update or cancel order, pick that table number request from transaction list on PED and select Cancel Transaction from the Print/Pay screen.

The order will be cancelled and a response sent to POS.

Note: No receipt will be generated for Cancel order.

Cancelled response format:

3=9 (Cancel Response)

EPOS receipt with Multiple POS

An existing functionality to print data from the PED and each POS needs to provide a unique file name when connected through file mode and needs to provide data on different ports when connected in socket mode.

No Table Support

Enables the Hospitality application to process transactions without opening a table. This covers over the counter scenarios where customers directly place an order to the server. It also covers some hybrid scenarios where you have tables and some independent orders. In No-Table mode, payments requests are initiated from the POS system, not the PED, similar to a retail transaction request.

For No Table Transaction, Instance id will be broadcasted to each PED on hospitality home screen. Operator of POS system has to identify and supply instance id to propagate request to designated PED.

During initialisation of the PED the instance ID will be displayed at the header of home screen.

‘PAY NOW’ option in 'More option' menu is for only No Table Transactions. The requests having attribute ‘101=INST3’ will be processed through the Pay Now option.

For no table transaction Sale transaction requests will be modified as:

101=INST1 << ** INSTANCE NO. should be any numeric whole number value between 1 to 99 with prefix INST e.g. INST1.>>

Note: INSTANT NO should be any numeric whole number value between 1 to 999 e.g. INST1.

For no table transaction Refund transaction requests will be modified as:

101=INST1 << ** INSTANCE NO. should be any numeric whole number value between 1 to 99 with prefix INST e.g. INST1.>>

For no table transaction Cancel transaction requests will be modified as:

101=INST1 << ** INSTANCE NO. should be any numeric whole number value between 1 to 99 with prefix INST e.g. INST1.>>

Using Instance ID Hospitality will be able to identify PED on which no table transaction request needs to be route. Operator has to Enter/select instance id to initialize no table transaction.

Pennies Donation

Customers are invited to donate money to Pennies as part payments. They may be invited to Round Up their payment to a whole number, or to Top Up by adding a fixed amount. The rules that govern this process are determined by a configuration file.

Pennies maintains an internal database of all donations made and is able to reconcile these donations to those settled by the merchant. Pennies then handles the process of granting funds to charities, and manages related activities like monitoring and reporting.

Order Closure

This functionality is available to customers , only if 'Remote Table Closure' checkbox is checked in YESEFT Configuration :

  1. Order will be closed automatically when user initiate payment request : Hospitality application close order automatically only if table number not found in Hospitality application's queue. When user enter table number on PED then application store that table number in cache so that POS application can poll this table number to close order and send payment request to Hospitality application.

    You can see an example of close table polling requesthere

  2. Hospitality application will wait for 30 seconds to receive payment request from POS : PED will display loading screen after user enter table number in 'Enter Table Number' text-box while waiting for 30 seconds to receive payment request from POS. Hospitality application waits for maximum 30 seconds to receive payment request from POS.

    Time to wait for payment request from POS is configurable via key 'waitPaymentReqTimeOut' in '' (YESEFT/properties) and maximum time lies between 0 to 30 sec.

Default value of this timeout is 30 seconds.

Time for polling is every 1 or 2 seconds within maximum time configured from POS to wait for payment request.

Identify waiter from PED

This functionality allows the merchant to authenticate operator (Waiter) from PED before beginning the transaction. This helps merchants to keep records of payments taken by each operator and to determine who is logged into which device at a given time.

Hospitality application sends Waiter ID to POS in the output response attribute ‘104’ for all types of transactions (SALE/REFUND/CANCEL)

PED display screen to key in ‘Waiter ID’ on selecting below options from PED :-

  • Enter Table Number
  • Get Txn List
  • List Preset Txn
  • Reports

This functionality works in following sequence :

  • POS sends request to poll close tables in every x second
  • Operator enters 'Waiter ID' from PED
  • Hospitality application sends 'Waiter ID' entered from PED and 'Instance ID' in response of 'close table polling' request to POS
  • PED displays loading screen with message ‘Validating Waiter ID xx..’ while waiting for 5 seconds to receive a validation response from POS
  • POS receives Waiter ID information from hospitality application and validates it, then POS sends validation result to hospitality application in response.

Please find details of request and response here :

Waiter ID validation

Hospitality application waits for 5 seconds (maximum) to receive a validation response from POS. If it doesn’t receive a response within the desired time, then PED display message ‘Invalid Waiter ID xx..’. If POS returns valid (WAITERID1:VALID) response to hospitality application, then the application proceeds with the transaction and if POS returns an invalid response (WAITERID1:INVALID), then PED display message ‘Invalid Waiter ID xx..’.

Waiting time for 'Waiter ID' response is configurable from key 'waitWaiterIDTimeOut' in '' (YESEFT/properties).

'Identify waiter ID' from PED functionality is configurable from YESEFTConfig for both application and Instance level.

For configuration refers sectionHospitality Tab.


The Hospitality application provides Tokenization mechanism for card numbers.The Worldpay Total service creates a unique Token reference for a card present online approved transaction if the merchant is configured for token creation. Token references the cardholder's card details.

Token will be returned to POS in the output response attribute ‘61’ for all online approved sale and account verification transactions.

Tokens returned to POS in Account Verification transaction :

  • Tokens returned to POS in account verification transactions can be used to charge cardholder without a requirement to retrieve the PAN, or to have the cardholder present.
  • These tokens are supported for VISA and MASTERCARDS only.
  • Merchants must seek a verbal agreement with the customer/cardholder for doing an account verification transaction and using the same for charging the customer in later date.
  • Merchants are requested to make a note of the expiry date of the card while creating a token request. Even though the maximum validity of tokens is 6 months, the token transaction for an expired card cannot be successful.

Tokens returned to POS in Sale transaction : Tokens returned to POS in sale transactions can be used for cardholder's recognition and reporting.

Request/Response details for pay at counter

Request/Response details for 'No table' transaction in pay at table

Token transactions are supported with No Table (pay now) in pay at table mode and in pay at counter mode.

Split Payments

The Hospitality application allows total billing amount to be split across desired payment methods (card/cash) directly from PED.

It supports custom split where cardholder can enter split payment amount of there choice on PED in situations where some wish to pay more or less than others and also equal split where application split total bill amount equally amongst number of diners.

If sale amount can not be equally divided amongst number of diners when operator selects 'Equal Split' from PED then application calculate split amount as follows:-

  • Total amount :- 20 GBP
  • Number of people :- 3
  • Split payment amount 1 :- 6.6 GBP
  • Split payment amount 2 :- 6.6 GBP
  • Split payment amount 3 :- 6.8 GBP

For custom split PED display screen to enter split payment amount and for equal split PED display screen to enter number of people.

If user selects ‘Pay now’ option from PED for all split payments, then Hospitality application send response of all partial payments in one output response to POS.

If user selects ‘Pay later’ option from PED after completing few split payments , then Hospitality application returns output response for completed partial payments and save payment request in queue with remaining sale amount and status 'Partially complete'. User can pay remaining amount later.

If user selects ‘Close Payment’ option from PED, then Hospitality application mark status of that transaction as 'complete' and POS can send new payment request for that table.

Sample Request to Close Payment

For configuration refers sectionHospitality Tab.

Account Verification (AVR or Zero Auth)

The Account verification transaction verifies the card, the cardholder and associated account status without affecting the cardholder’s available balance.

This transaction can be used to verify the card when, for example, opening a ‘Tab’ at the bar and restaurant.

Account verification transactions are supported in Pay at Counter mode and with 'No table transactions' in pay at table mode. It accept only contact mode card tender i.e. chip and mag. stripe.

The Worldpay Total Service creates a unique token reference from successful account verification transaction if the merchant is configured for zero auth and tokenization functionality. This token can be used by merchants to charge the cardholder by providing the appropriate charge indicator in the Sale with Token transaction.

Request/Response details for pay at counter -Sample Request for Charging an Account Verification Token.

Request/Response details for 'No table' transaction in pay at table -Sample Request for Charging an Account Verification Token

Pay at Counter

This feature allows the merchant to provide a payment request for fixed payment devices connected at the counter. In this mode, the Hospitality application does not queue transactions to be selected from a menu on the device - instead the transaction is immediately presented on the device and the cardholder is prompted for payment.

Hospitality instances can be defined as Pay at Counter or Pay at Table - instances cannot support both modes of operation at the same time.

Pay at Counter functionality is supported with P400 pinpads only - once this pinpad is selected for the instance from the YESEFTConfig utility the instance will operate as Pay at Counter. The host IP address and port on which pay@counter server executes is defined via configuration file (YESEFT/properties/

EVT Server: The module of hospitality receives requests from POS application and manage multiple instances.

Hospitality Server: Hospitality server communicates with P400 PED.

Whenever any new request comes for the particular instance, let’s say for instance 1 then EVT will go to connect with Hospitality server running on IP address and port mentioned in the property file.

IP address recommended to be local host '' and port can be modified.


A Pay at Counter Input request must include attribute 107=INST&lt;&lt;Inst No. or Identifier&gt;&gt;(for ex: INST1, INST2, INST3) to specify a specific Hospitality instance, connecting to a specific PED. Only one request at a time is processed for each instance, and if a new request comes before completion of an existing request for that instance, then the Hospitality application provides the busy response to POS

Busy Response:

3=42(Busy notification)

If the P400 PED is not configured or connected when the Hospitality application receives an input request to Pay at Counter an error message is sent as a response back to POS.

Error Response:

3=11 (Error response code)

Request/Response details -Sample Request and Response for Pay at Counter


Cashback service comes into play when a cashback amount is added to the original sale amount. For instance, if a customer has paid the original sale amount via debit card, then the customer is presented with an option to obtain a cashback. This cashback amount is then given to the customer in cash. Debit card cashback is offered either by banks or schemes like VISA, Mastercard, American Express to cardholders.

Cashback transactions are supported in Pay at Counter mode and with 'no table' transactions (Pay Now) in pay at table mode.

It accepts only contact card tender i.e. chip and mag. stripe.

Example - On the bill of 18.99 pounds customer might ask for twenty pounds cashback, then the customer would pay a total of 38.99 pounds with a debit card and receive 20 pounds in cash.

Cashback Benefits :

  • Reduces cash banking for Merchants.
  • It is a useful way for customers to obtain cash as it helps them to avoid visiting a cash machine and avoid associated additional charges.

Pay at counter Request/Response details -Cashback

Offline transaction approval

This feature allows merchants to process transactions offline. This is useful if the till has lost connection with the Worldpay Total service and cannot send transactions to Worldpay for online authorisations.

It is supported by chip cards for sale transactions only.

You must have a merchant terminal to support this functionality.

In offline processing, the payment device verifies the issued card data and the offline stand-in limit. These factors cause the payment device to approve or decline the transaction.

The risk and liability of any chargebacks and consequences from transactions that have not been sent online to the issuer are yours - the merchant's.

Sending receipts to socket

Hospitality application sends all transaction receipts to POS application on TCP/IP socket for P400 and V240m both PEDs. This functionality works with pay at table and pay at counter both.

The receipt port is a separate port value to the interfacing port and intra message ports configurable through the YESEFTConfig utility.

This functionality can be configured from YESEFTConfig. Follow configuration stepshere

Sending Transaction messages to POS

Hospitality application sends transaction messages to POS on TCP/IP socket for all transactions processed in pay at counter mode. This functionality works with pay at counter (P400) and 'No table transactions' with pay at table (V240).

The POS application connects to the designated IntraMessage port in client mode to receive and respond to messages. The IntraMessage port is a separate port value to the interfacing port and receipt ports configurable through the YESEFTConfig utility.

Intra message port example :-

  1. 8001 - Instance 1
  2. 8002 - Instance 2 .....

IntraMessage port messages are in the form of key value pair starts with the info: character (Hex. 69 6e 66 6f 3a) and are terminated with the character 99=0 (Hex. 39 39 3D 30). Messages can be changed by changing the value of keys in property file placed at location YESEFT\properties

Example :- Message for remove card –> info:REMOVE_CARD99=0

These messages are in asynchronous mode advise progress of the transactions and require no response from the POS application.

This functionality can be configured from YESEFTConfig. Follow configuration stepshere.

Types of messages/transactionsMessage on port e.g. 8001,8002
PED displays 'Worldpay Total'info:PED CONNECTED 99=0
PED displays ‘Loading Configuration’info:LOADING CONFIGURATION99=0
PED displays ‘Gratuity Offer’ screeninfo:GRATUITY REQUEST99=0
PED displays to select gratuity amountinfo:GRATUITY AMOUNT = <amount>99=0
PED displays ‘Donation Offer’ screeninfo:WOULD YOU LIKE TO DONATE <amount> FOR PENNIES CHARITY?99=0
PED displays ‘Thank You For Donating’info:THANK YOU FOR DONATING =<amount>99=0
PED displays 'DCC Transaction offer'info:DCC OFFER - <DCC Conversion>99=0
PED displays ‘Enter PIN’ screeninfo:ENTER_PIN99=0
PED displays ‘REMOVE CARD’info:REMOVE_CARD99=0
Sale & Refund Transactioninfo:PLEASE WAIT99=0
info:AUTH CODE:<<auth code>>99=0
Cancel Transactioninfo:CANCEL APPROVED99=0
info:PLEASE WAIT99=0
Error Messages:At the time of Keychange :
At the time of Initialisation
info:MID_or_TID MISSING...99=0
At the time of Transaction Processing
info:CVV INVALID99=0
Error codes from kernel if any problem occurs at pinpad/card level

Transaction level configuration of Cashback, Gratuity and Donation

The Hospitality application allows merchants to control behaviour of Cashback, Gratuity & Donation at transaction level.

This functionality is available in pay at counter and pay at table both modes.

POS application can avail this functionality for respective payment configuration only if it is configured at TID/MID level.

POS application can send below three values in attribute 114 that represent transaction level configuration :

  • C – Representing Cashback
  • G – Representing Gratuity
  • D – Representing Donation
  • N - Represents merchant did not want to prompt for any one of the above

For example of pay at counter Request/Response details refer -here

For example of 'No table' transaction Request/Response details refer -here

Fixed Gratuity

This functionality helps merchants to send a fixed gratuity amount as a part of sale request and they can send the gratuity amount irrespective of gratuity configuration enable at TID level.

This functionality is available with pay at counter and ‘'no table transactions’’ with pay at table modes.

POS application must send value ‘G’ in attribute 114 of input request along with attribute 115 which represents the gratuity amount.

Pay at counter Request/Response details -Fixed gratuity

'No table' transaction Request/Response details -Fixed gratuity

Updating payment request/billing items :

The Hospitality application allows merchants to update sale requests that already exists in Hospitality queue. Merchants can update payment requests in queue with status ‘Partially complete’ and ‘Pending’. Billing items and sale amount both can be updated using this functionality.

Merchants can also update payment requests in middle of pay at table user flow before transaction's status changes to 'Auth in progress'. Transaction status changes to 'Auth in progress' on selecting 'pay now' at below screen :


Sample Request and Response

This functionality is available in pay at table mode only.

Automatic Download of Datasets and Properties :

The Hospitality application has the ability to download the dataset and property files silently without manually restarting application. Application attempt to download the latest updates once in every 24 hours. A scheduler will run automatically every 24 hours. Time to trigger scheduler is a part of Merchant Dataset in tag : 'APICallTime'.

If HPA application unable to connect with the WPT central service in the first attempt , it will retry 2 more times in an interval specified in the Merchant Data Set tag : 'APICallTimeInterval'

The Hospitality application sends requests to WPT services for downloading EMV config files (PED configuration) and dataset files if datasets and EMV configuration download flags are enabled at WPT services.


  1. Send the list of terminal IDs (TID) to Account Manager/ Client Delivery Manager and Support Team ( requesting to flag terminal ids for datasets and EMV config files update. Our team will then enable flags on our WPT services servers and confirm when done.

Below are list of files that are downloaded from WPT services if flags are enabled at WPT services :

  • EFTAcquirerDataset
  • EFTIssuerDataset
  • EFTMerchantDataset
  • terminal.CTLS.emv
  • terminal.emv

Automatic download of datasets and properties will take place only when PED is not in use. While downloading files from WPT services "Updating Configuration" message will display on PED for a few seconds if configuration update not available and in a few minutes if configuration update is available on WPT services.

This functionality is applicable for P400 and V240m both.

Get Pinpad serial number :

The Hospitality application provides functionality to get Pinpad serial number (PTID) of the connected PED and this is only applicable for P400 PEDs and in pay at counter scenarios.

Request/Response details -Get Pinpad Serial Number

Screensaver :

The Hospitality application supports screensaver functionality wherein customer able to display image on PED when PED is connected to HPA application and in idle state. This functionality is applicable for both V240 and P400 PEDs. PED able to display only one image.

Below are the steps to be followed for configuration:-

  • Stop HPA application
  • Place image at location - YESEFT\screensaver
  • The image should be in JPG format and should follow naming convection image_1.jpg
  • Dimensions of the image should lie between 160 * 240 to 320 * 480
  • Size of the image should not be greater than 20 kb
  • Restart HPA application
  • Application initialized successfully with screensaver image displaying on PED.

  • In pay at counter mode, the application shows screen saver until PED receive transaction requests from POS application.
  • In pay at table mode, the application shows screen saver until user press any button on the PED or on screen.

Check Pinpad Connection :

The Check pinpad connection request can be used to check the PED is connected with HPA application or not. This functionality is applicable with pay at counter mode.

Request/Response details -Check pinpad connection

X and Z report :

The X report returns the current transaction totals in the terminal batch in an XML format and the Z report returns the current transaction totals from the terminal batch in an XML format and also closes the terminal batch. This is an online function only.

  1. Pay at counter mode :- Hospitality application supports the transaction request in this mode and sends report in output response to EPOS application

  2. Request/Response details -X report

  3. Request/Response details -Z report

  4. Pay at table mode :- PED display option of 'X report' and 'Z report' on clicking 'more options' at the home screen and PED prints report on one click.

Disable Pennies for contactless :

This functionality allows merchants to disable donation prompt for all contactless transactions and for chip & pin card application prompt donation after card insertion. This is applicable for both pay at counter and pay at table. This is configurable at instance level from ''bulk configuration'' and ''YESEFT configuration'' batch file both. This functionality works irrespective of donation enabled at Merchant level during the time of boarding.

For configuration refers sectionGeneral Tab