This section for integrated systems is written for developers who are implementing the TruRating Application in systems where the POS and payment client applications are both resident on the POS register (Till) and have a communications link to enable the POS to invoke payment requests.
From the perspective of TruRating integrated systems have the following key differences to standalone implementations:
- Given the presence of an interface exposed by the payment application to the POS, there is scope to extend this with the additional POS event messages.
- Consequently there is an opportunity to display the question outside of the payment transaction - notably during the basket checkout process (dwell time).
- They are written in a wide variety of languages (Java, C#, C/C++)
The implementation of the TruRating Application in an integrated environment follows the same architecture as all other implementations. TruModule is developed as part of the Payment or POS application in a manner described in this section. The prescribed development ensures a relatively quick and error-free implementation of the TruRating Application.
For the integrated environment, both TruModule and TruService are two distinct components that comprise the TruRating Application. TruModule is the lightweight component that is responsible for interacting with:
- the payment application and optionally the POS application
- the PED display and keypad to execute the TruRating 1AQ1KR question command and display an acknowledgment message. TruRating normally refers to this in abstract terms as an “IDevice” interface.
- the TruService component question and response messages via TSI.
There is a wide range of architectures for Point of Sale systems, and so it is not possible to be dogmatic about where a TruModule implementation will fit into an existing system. The Design patterns specification describes a number of such architectures that have been encountered and the way that TruModule can be added in each.
In the majority of integrated systems, the best plan for the deployment of TruService is to use a cloud-based instance that is hosted by TruRating. This has the following specific advantages:
- It simplifies and reduces the cost of deployment
- It removes the need to provide local support for TruService
- It enables TruService updates to be automatically applied when approved.
There are occasional situations when TruService may need to be running locally, either for technical reasons (such as a remote store that only uses an on-demand dial-up Internet connection) or because of the merchant’s requirements (such as very specific security policy requirements).
TruModule via the payment application will display on the payment device screen TruRating images and text at specific points in the payment process. These are marked on the specification pages as (X) and (Y). These screens along with examples are described here.
Several possible versions of a TruRating message for the customer receipt are received by TruModule from TruService. TruModule selects one version for use according to whether the customer provided a rating or not, and makes this available to the payment application which prints the message on the customer receipt itself or passes it to the POS application for printing, along with the rest of the transaction’s response data. In the UML images in this section, the point where this is done is marked as (Z).
Sample implementations of TruModule are available from TruRating in various commonly used languages.