VMS/VSaaS POS Integration Guide

This guide explains the fundamentals and challenges of VMS/VSaaS integration with point-of-sale (POS) systems.

In this report, we examine the pros, cons, and common challenges including:

• Point of Sale Overview
• Investigation and Auditing
• Text Overlay
• Local POS Insertion
• Centralized POS Integration
• Verifying Manufacturer POS Support
• PCI-DSS Compliance
• Self Checkouts
• Fragmentation of Cloud/Mobile POS

This is the third report detailing integration as part of our new VMS/VSaaS course starting in the fall.

POS Overview

Point of Sales (POS) systems, or 'cash registers', are common to just about every retail enterprise. Modern systems accomplish far more than just keeping cash organized and calculating change. POS systems keep an activity 'journal' that records net cash transactions, inventory turnover, and special activities involving the handling of cash such as opening the cash drawer, refunds, or price overrides.

Integrating video surveillance with the POS system combines video with the register's 'journal' events (e.g. completed sales, canceled sales, register opened, etc). This makes it easy to compare the register events with video evidence.

Not only does this integration aid forensic investigation, but it also discourages employees from engaging in hard to detect activity like 'sweethearting'.

Used For Investigation / Auditing

POS integration to a VMS/VSaaS is primarily used for theft investigation or auditing transactions, not for live monitoring, unlike many access and intrusion integrations. While many 3rd party VMS/VSaaS integrations have a graphical/user interface component for live monitoring, this is not a common use case with POS systems, which makes UI integration less of a challenge. Additionally, POS systems have significantly fewer rules, events, schedules, and I/Os than most access and intrusion systems.

Centralized POS API integration

The most common method for POS integration is the VMS/VSaaS connects to a centralized POS server to download or access transaction data across the retailer. Large retailers having many locations and thousands of POS stations use this method because they need a custom solution and already have the infrastructure in place to support it.

The resulting integration is a searchable event database. While atypical, some integrations also support real-time monitoring of transactions. The full scope of POS is available for this integration rather than simplified 'receipt only' data. Custom alerts (e.g. management receives an email each time a cashier hits the 'refund' button.) and exception report integrations (e.g. Video records all large refund transactions) are common.

The typical required data fields a VMS/VSaaS require for integration include:

Often, this integration is a custom software development project, and the cost can easily reach tens of thousands of dollars. However, these integrations are built to allow for remote auditing of thousands of transactions in real-time.

However, because many POS systems "batch" transactions in on-premise servers before transmitting them to a centralized server, integration needs to connect to local POS servers.

Local POS Connections

In practice, using API Integration, VMS/VSaaSes integrate POS transactions from local/on-premise servers and log them in the local video system database. Generally, this integration is called "transaction matching" and is sold as a prepackaged module from the VMS/VSaaS vendor. For example, Avigilon's POS Transaction engine ingests the register journal events into the VMS:

This allows for transaction data and video to be seen side-by-side. Searching for specific text or register events will return the coinciding video. This level of integration is more costly but easier to use compared with simple 'text overlay'. Three variations of this method are common, with most major VMS providers supporting one or more of the following:

• Port Sniffing: The VMS/VSaaS uses hardware or software-based port sniffer to pull POS data from the network. POS data packets are identified by header information and intercepted into the VMS for use. The quality of the sniffing device/software and ambient network traffic influence the effectiveness of this method. However, intercepting POS traffic may not always be successful.
• Direct Insertion: In some cases, the POS system may support a client API connection and permit a network connection between the POS register and the VMS/VSaaS. POS data is directly parsed into the VMS/VSaaS database. This requires more customization by the VMS/VSaaS manufacturer, as the API framework varies widely for each POS system.
• Serial Server: A serial server device is used as a hardware bridge, directly connecting the POS system traffic (e.g. sales, returns) with the VMS server. Usually, each register must have a serial server installed, and larger integrations can require many boxes to be installed. While it is frequently used because it works with many systems, and is similar to the Text Overlay method, it can be complex and more time to set up and maintain than other options. Moreover, serial connections are not secure or encrypted and are not commonly used at this time.

POS Database / API Integrations Vary Widely

Because each POS user has different business operations and tracking methods, the important data fields, or "metadata framework", will vary even when 2 similar customers are using identical POS systems (e.g. NCR, Micros, Square).

While the payment hardware (e.g. credit card reader, cash register) is identical, the POS data flow (e.g. how long POS events are buffered between upload "batches"), and exceptions or rules that are important, require different API integrations. This API development is commonly complex and beyond the programming capabilities of surveillance integrators/dealers.

Verifying Manufacturer POS Support

While almost all manufacturers 'support' PoS, the level of support can vary dramatically:

• Dozens of POS providers exist and each VMS may only support integration with a few of them. Make sure to verify if the POS system is explicitly supported.
• VMS manufacturers use multiple means to integrate with POS systems, depending on the POS provider. A VMS may only support serial servers for one type of POS but direct server integration with another. Even if a VMS supports the POS in use, verify the type of integration to understand the cost and complexity of deployment.
• POS integrations may only be supported with Windows OR Linux-based VMS servers/clients, not both.

Moreover, because many POS systems are provided as a service, the POS vendor may charge for initial setup and ongoing configuration changes if cameras or VMS/VSaaS are updated.

Text Overlay

Historically, the most common method to integrate POS with video systems was overlaying text on the field of view of the camera. This is level of integration is uncommon, due to additional hardware requirements, and data/cybersecurity concerns, however, legacy systems may still be in use in small retail operations.

POS data is overlayed on top of the video stream much like time/date stamps are displayed on cameras. This method 'injects' an image of the register journal onto the camera recording.

However, finding unique register events is difficult because the text itself is not searchable; it is a combined part of the video image. Most often, this function is a separate box installed between the recorder, camera, and the POS station printer.

Text injection/Screen Capture is used for small deployments, where only a few registers are located and when review is infrequent.

In practice, it can be done with any video system, regardless of its support for a particular POS system. To overlay POS text information with an IP-based system, the intermediate device IP POS Server (a serial to ethernet data converter) translates the register's journal data and integrates it into the recorded video stream.

However, text overlay blocks part of the camera field of view and can be challenging to read, especially with high activity behind the text. Also, transaction text is only linked to a single camera, which limits usability in locations where multiple camera angles are used to capture transactions.

PCI-DSS Requirements

The POS industry standard for Transaction and Data Security is PCI-DSS. The standard describes all of the minimum requirements for data security during payment, it exists to aid merchants to decrease vulnerabilities and protect cardholder data. PCI-DSS primarily focuses on surveillance and access control at data-center locations or physical areas where credit card data is stored.

While POS integration includes transaction data (e.g. type of transaction, dollar amounts, etc.), it does not include credit card information or cardholder details, so VMS/VSaaSes should not need PCI compliance. However, PCI recommends monitoring and inspecting POS payment terminals for skimming devices and other forms of tampering, but does not specifically require cameras.

Self Checkouts

Self-checkouts are becoming more popular for retailers, but surveys have shown that shoppers are more likely to steal items at a self-checkout. Having an integration between the self-checkout POS and an Enterprise VMS/VSaaS could be more important for retailers than ever before. Because they effectively operate as a standard cashier/register lane, there should not be a significant difference in the integration of self-checkout POS with video systems.

Online Sale Pickups

A modern POS operation that adds complexity when integrating with video systems is 'Bought Online, Pickup In-Store' or 'BOPIS'. While the systems are integrated through a central POS server, because the purchase is made at a different time and place from when the sale is completed, and customer name verification is commonly required by retailers, the VMS/VSaaS integration may require additional database fields and camera assignments.

POS Fragmentation/Cloud-Hosted POS

Historically, almost all POS terminals were provided by 5 or fewer companies (e.g. NCR, Micros) in the past decade many mobile/cloud-hosted POS systems have emerged (e.g. Square, Toast, Revel, Upserve, etc.) While some of these systems are directly connected to cloud services over the Internet and do not have local methods for transaction integration to video, many will use a local PC/server to buffer transaction data in case of Internet outages. VMS/VSaaSes integration to the cloud or local data sources will vary based on the POS provider.

Cloud-hosted or managed VSaaSes are positioned well to integrate mobile POS because they are connected to the Internet. Most offer integrations to cloud-hosted PoS, using centralized API integration, but because POS integration is a niche feature they commonly only support 1 or 2 providers. For example, Verkada and Rhombus each only support 1 POS vendor, while supporting many more single-sign-on, notification, and access control integrations.

ATM Integrations

Integrating ATM systems follows a similar centralized API integration, with similar transaction data as a POS register journal. The primary differentiation is that banks/banking information is highly regulated, and receiving access and maintaining access to APIs for transactions are much more difficult than retail. Moreover, as many banks operate globally, there are multiple security/privacy regulations and practices that may need to be addressed.