Gaming interfaces for MICROS POS Products have been around since the late 1990s, and back in the ‘old days’ they were generally reliable, somewhat fast, semi-flexible, and indeed quite useful, but all-in-all pretty low-tech for the most part.
Gaming Interfaces to common Gaming Management Systems like Aristocrat, Konami, IGT, Bally were a revolution for MICROS POS when they first came about. Before they existed, it was mostly handwritten, and later computer printed Paper Comps. The guest would be handed these paper comps from the Casino Host or Pit Boss or another Casino Employee. Often, they were handwritten on paper pads akin to a Doctors Prescription pad (which are mostly extinct these days as well 
). The guest would then carry their comp to the restaurant and hand it to the server or cashier to redeem their comp. The POS system at one point had no way to validate these comps so they were accepted, literally at face value. The Audit process the following day was often a nightmare of sorting through 100s if not 1000s of paper slips and POS receipts, matching them up with carbon copies turned in by the compor (the person issuing, or authorizing the comp), and making sure nothing illegitimate was going on (i.e., POS Users using comps to pay for cash checks, and pocketing the cash, etc.)
The first iterations of gaming interfaces simply supported a way to validate that a comp was real, that it was still valid, hadn’t expired, and hadn’t already been used. The POS User would enter a # and a message was sent to an iSeries or something similar somewhere to be validated. If the response was positive, the comp would be accepted and used to pay for the guest’s meal. Very little other bells and whistles existed. In those early days the concept of letting guests earn “points” for play didn’t exist or was just becoming a concept around that time.
When Casino Player Clubs became common, Casinos in Las Vegas, and other areas, needed, and often demanded a way to let their guests redeem their points themselves. The concept of “Self-Comping” was born. Guests were given Player Cards and earned points for Casino Play. The early interfaces needed to be able to read those cards via the POS system’s magnetic card reader and send that identifying information to the player system. And not just allow the Self Comp, but also to lookup a guests current available Self Comp balance to make sure the guest could only redeem as much as they had in their account. The balance would be displayed for the POS User, and then they would redeem against that balance in dollars and cents, not in points. These initial legacy interfaces were very popular, and eventually became an absolute ‘necessity’ – Casinos rarely operate a POS system without them today. They were, however, never very impressive in terms of the User Interface/User Experience (UI/UX).
Here are a couple of examples, of what one of the original micros/gaming interfaces looked like:
At the time, they were the best that MICROS POS Products offered in terms of UI/UX. They were functional, but not very pretty
The legacy interfaces also operated on the backend using what, even back then, were antiquated communication protocols. That usually involved a TCP/IP “Socket” connection, using an IP Address and a Port. They weren’t all that secure, requiring no user credentials to connect and passing data unencrypted between the 2 systems. They also required that the connection be established from, at first the POS application server (8700 & 9700), and later a dedicated interface service host (introduced with SimphonyFE, and still commonly used today). This service host server would sit in the middle between the POS Workstations and the gaming system, passing the messages back and forth between them. If the connection was down for whatever reason that meant the interface was down for ALL the POS Workstations. The interface service host was a common point of failure for the legacy interfaces.
Today, OTMS offers a new generation of Gaming Interfaces, most using modern API’s provided by the Gaming System, that do not require a service host server at all. In most cases each POS Workstation makes its own calls into the Gaming System API independently, not requiring the service host to sit in the middle. This eliminates a point of failure by not requiring the service host. It also adds security as API’s require secure user credentials. Another benefit is that the data, passed between the POS Workstation can be encrypted, which adds to the security of the interface overall, and in many cases eliminates a potential PII (Personally Identifiable Information) risk due the data being secure, and also in that the logs can be configured not to include PII within them. In some cases, OTMS Interfaces actively look for, and eliminate PII from logs and other areas.
Below are some examples of what one of OTMS’s modern gaming interface UI/UX looks like.
Prompt to swipe player card
Note in the above image, that the guest’s basic information is displayed (all optional/configurable), including the Player Image (again, optional).
In addition to the guests information, ALL of the guests currently available comp benefits are displayed in 1 place, allowing the cashier to pick what they want to redeem, and in what order. No more multiple touchscreen buttons for each comp type. The UI/UX offers one-stop shopping for finding, displaying, and redeeming a guests comps.
The same/similar UI/UX is also available for Kiosks, making it simple and easy for guests to comp themselves when ordering from those Devices.
In conclusion, gaming interfaces have come a long way in the past 25+ years. The modern Extensibility methods provided by Oracle’s Simphony POS allow developers to utilize modern development practices, and modern technology advancements to provide a more well-rounded, and functional experience for the end-user.
Be sure to check out https://onthemarksolutions.com/Solutions/Gaming-Interfaces for more information, or send a message to sales@onthemarksolutions.net with any questions or customization needs.