Pay@Table Integration
The workflow for a typical Pay@Table transaction is as follows:
- The customer will indicate to the staff that they are ready to pay the bill
- A staff member grabs a Pay@Table terminal and enters in their operator ID and the table number
- The terminal connects to the restaurant POS server via HTTP and requests the amount for that table
- The POS server returns the amount to the terminal
- The terminal asks whether the customer would like to pay the full amount or split the bill
- If split bill is chosen, the customer enters the amount to pay
- The terminal then prompts for the card, account type and PIN or signature
- Once approved, the terminal prints the receipts and posts the transaction result back to the POS server
Traditional forms of integration (including integration using the TTA) have one disadvantage which is that during the transaction process, the POS is locked up such that it can't be used until the transaction is completed. Depending on your environment, this disadvantage may or may not be a problem. In a supermarket, for example, customers expect to line up and have their goods scanned followed by a payment but in a busy restaurant where there may only be one POS at the counter and a queue of customers trying to pay at the end of lunch, the lock up can be a problem.
To counter this, we have added additional modes to our Mobile Integration application; Restaurant mode (Pay@Table), Bar mode and Retail mode. These additional modes are discussed here.
Before starting the development work, please refer to our pay@Table certification criteria document .
Tyro Pay@Table Simulator
We have developed a test harness that POS vendors can use to develop and test their Pay@Table implementations with. The tool is a Java Command Line Interface (CLI) program that can generate the same messages that are generated by a terminal operating in Pay@Table mode.
The software archive is attached and instructions for use are contained within the archive.