The key point of integration for TruRating is with the application controlling the customer facing payment device - since this is where the question is to be displayed. This is normally the payment application. In the integrated and semi-integrated space many payment applications expose an interface to the point of sale (POS) application to allow it to invoke card payments with a given transaction. This interface may allow the POS to pass basket and other transaction data to the payment application, or the interface could be enhanced to support this as part of TruRating implementation.

A TruRating installation can be significantly enhanced by incorporating support for POS events as part of an implementation. They add to the value of the ratings analysis and subsequent reports provided to the merchant and can be used to as part of the TruRating application to control the question trigger. Where POS events are provided ahead of the question being requested or as part of the question request (from TSI v240) this data can also be used dynamically to influence the question that the customer is given.

In situations where the implementation of the TruRating application is done through the POS application itself then often the POS events used by the TruRating aplication are commonly available.

The TruService interface supports the delivery of a small set of POS related events and data from TruModule. These events are used in several different ways:

  1. POS events can be sent by TruModule to TruService individually (POSEvent) in realtime. The data is collated by TruService and combined with the customer rating and other transaction data to provide enhanced analytics. The realtime events can be used by TruService (based on configuration) to trigger a rating question, with TruService notifying TruModule that a question is available within the response to the event.

  2. POS events can be sent by TruModule to TruService as a batch (POSEventList) before payment, after payment or the end of the transaction or payment. The data is collated by TruService and combined with the customer rating and other transaction data to provide enhanced analytics. From TSI v240 it’s possible to send the POSEventList batch within the Trurating question request itself to reduce the number of individual messages required - this is of course only applicable where the data is known at the point the question is requested (for example when question is requested as a card payment is started, but after all items have been added to basket and all discounts applied).

NOTE: TruRating preference is for POS events to be sent as batch using POSEventList and for this to be sent either ahead of the question being requested or within the request for the question.

Key Difference Betweeen POSEvent & POSEventList

THe main difference between the two is that POSEvent is used to allow TruModule to send events one by one as they occur, while POSEventList is intended to allow TruModule to send all data in a single message and therefore means that all POS related data being sent needs to be collected before POSEventList can be sent. The data that can be passed in each event is common between singular and batch but most fields are optional so they can be excluded if they are not know at the point the event is sent.

Types of POS event

The table below lists key POS events that can be passed to the TruRating application. Please review the schema for details on the data elements that are required when sending these events and which data elements are optional:

POS Event Description
POStartTransaction Marks the arrival of a customer at the till and the action that the attendant makes to indicate that a new transaction is underway. This may coincide with the scan of the first item in the basket. When sent as individual event TruService may trigger a rating question.
POSStartTilling Sent when the first basket item is scanned through. It may be repeated if basket scanning is restarted, or alterations need to be made to the basket after the checkout phase is deemed to have completed (EndTilling).
POSItem The ScanItem events marks the addition (or removal for a void) of an item to the POS transaction.
POSDiscount The POSDiscount events marks the addition (or removal for a void) of a discount to the POS transaction. A discount can either be linked to an item or to the basket
POSEndTilling Marks the completion of the basket processing. It is marked by the removal of the TruRating Question from the PED display where applicable).
POSEndTransaction The EndTransaction event is fired after payment (of whatever type) has been completed.

Example

The dwell time extend experience customer journey contains an example of the use of POS events to invoke a dwell time question.

Feedback