Zapper Event Broker Redundancy Agent (ZEBRA) for Point-of-Sales Integration is a solution for point-of-sales system deployed in a Quick-service Restaurant (QSR) or Retail environment in order to facilitate Zapper payments and related services. This paper illustrates the technology of the ZEBRA product and describes its functional components and points of integration by which to interact to provide Zapper functionality. ZEBRA is a proxy-broker, middle-ware service that links the point-of-sale, produces bill-data to paying customers, aswell as checking goods through a merchant till-point suite for payment. The solution exposes end-points, corresponding to functions, corresponding with Zapper payment processing functionality.
Connecting a POS till-point to Zapper (via ZEBRA) uses a Communication Channel (to link the protocol) to a data Transformer (translating the data) in order to conform the point-of-sale data to a canonical model for consumption by Zapper services. The combination of a Communication Channel and a Transformer is a Pipeline. Pipelines facilitate directional communication between a POS till-point’s respective Zapper Enabled Display (ZED) and the date emitted from the POSS till-point during transaction processing.
Each Communication Channel disposes a technical integration type, e.g. TCP/HTTP (or other protocols that may be defined by the POS vendor) to hand-over data to a specific Transformer that recognises and adjusts the received data into conformity for Zapper services. Conformed data are availed to an Event Publisher, to which applications subscribe and consequently process specific functions within the Zapper functional bouquet.
Zapper functionality processes the Invoice and Payment from which to derive a response, i.e. payment facilitation and payment closure on the POS till-point, respectively. Implementing a full Zapper bouquet of payment services depends on the integration level with its corresponding POS data feed. The richness of this data has a direct bearing on the ability to provide Zapper payment functions.
ZEBRA is focused to meet any point-of-sales integration level as effectively as possible. The architecture of the solution is purposed for adaptation and modularity by accommodating a variety of functions exposed, in relation to the level at which the integration is possible.
Engagement with point-of-sales vendors or merchants require an integration level identification. The subsequent determination of the Communication Channel (as transport protocol of the data) enables the ability to connect to a POS till-point. Data conformity is achieved in the Transformer by conforming to the Zapper canonical model. Both the Communication Channel and/or the Transformer can be defined upon first contact, i.e. where no pre-defined facility is in place.
Accommodating a specific POS system in the data acquisition and the accompanying payment conformation (to close the open POS transaction) are items that Zapper consider integration components. These components are established by lean integration to achieve the basic required Zapper functionality. Zapper consults with POS vendors to implement these components as sensibly and in the most appropriate manner possible. Where data is obtained from a POS till-point, the least intrusive method, bearing the best data, is selected. On posting a payment confirmation back to the POS till-point, our approach is to accommodate the method desired by the POS vendor, as they are in control (and should remain so) of their system. For example, Zapper provides a web-hook method from which a post-back is sent to the POS till-point on receipt, or a specific queue can be exposed to POS polling by which to receive the notification, or it could be implemented into a database by a Zapper specified stored procedure.
ZEBRA installs on a Windows or Linux single board computer (SBC) either on Windows 10 or Jessie (Raspberry PI) respectively. The Windows deployment utilises a utility called Oxpecker to facilitate the remote upgrading of a ZEBRA node via Serengeti by scheduling the install files and the stopping and starting of the respective services. On the Linux platform there is no special intervention required to up/down-grade the ZEBRA node.
ZEBRA facilitates the provision of Zapper payment functionality to firstly accept a Zapper payment and then close the open POS transaction by receiving a payment confirmation. Payment confirmations are received by an appropriate method, i.e. SMS and SignalR and presented to a corresponding end-point for consumption. These are also printable via a printer connected to ZEBRA or ones associated to the respective till-point display via Bluetooth. The ZEBRA node is configurable via Serengeti, a user-interface disposed for system management and also for monitoring of status and performance. The Zapper Enabled Displays are also capable for displaying circular or specifically targeted material either on schedule or by condition.
A Zapper payment is facilitated via a Zapper Enabled Display on receiving a total POS tender type. The QRCode service (running on the) tablet receives data from ZEBRA in the canonical form and renders a QRCode on the display that is scanned by the customer from their mobile device. The QRCode bears the information to facilitate the transaction payment (merchant Id, Site Id and Amount) as well as the additional date such as inventory to enable conditioned-based voucher redemption on line-item(s).
Refunds on POS bills are facilitated by ZEBRA, using the presented bill items, to void the bill and request a refund via the Zapper back-office API end-point.
Payment closure on the POS system is facilitated by the confirmation message in response to a payment confirmation or failure. The message is transmitted via SignalR to the provided end-point, namely:
Web-hook (for HTTP Post)
Stored procedure (for database logging),
API implemented by the POS vendor (either push or pull/polling)
Media Manager is implemented in the Zapper Enabled Display as a circuit that plays a video outside of the payment processing screens. This media track can be customised for targeted and conditioned based advertisements. Tracks are exchangeable from Serengeti, i.e. remotely by an administrator.