Scope

This Standalone section is written for developers who are implementing the TruRating Application on traditional standalone or semi-integrated payment terminals and devices. TruRating has made every effort to ensure that the development and porting time is minimized. To this end, the development effort required for a target payment device is limited to integrating TruModule with the payment application.

Overview

The implementation of the TruRating Application on standalone devices follows the same architecture as all other implementations. TruModule is developed for the target standalone device in a manner described in this section. The prescribed development and porting ensure a relatively quick and error-free implementation of the TruRating Application.

For the standalone environment, both TruModule and TruService are the two distinct components that comprise the TruRating Application. In a standalone environment, TruModule is the lightweight component that is responsible for interacting with:

  • the payment application via triggers and data
  • the standalone display and keyboard via 1AQ1KR
  • the TruService component question and response messages via TSI.

TruService

Wherever possible TruService will be deployed in the cloud, which significantly simplifies development effort and time for implementation. Normally this would be the Cloud service operated by TruRating, but it could be deployed into a private cloud operated by the payment service provider if this is more applicable.

In situations where a standalone device runs predominantly offline or uses slow or intermittent GPRS connectivity then having TruService in the cloud or remote from the device may not be suitable. In these scenarios, TruRating will work with you to explore other architectural solutions.

Architecture

The following figure depicts the high level architecture of the TruRating application on a standalone device:

Standalone_Logical_Architecture
Figure 1: Standalone Logical Architecture

Implementation of the TruRating Application essentially boils down to implementing TruModule.

How TruRating works in a Standalone Environment

The TruRating application works in the following manner:

  1. On start-up, TruModule will request the activation status from TruService via TSI using the Query command. If the TruRating application is active, then TruModule will also pre-fetch the next question via TSI at start-up (if the pre-fetch capability is being used).

  2. The payment application executes as usual until it encounters a TruRating trigger point. This will be just before or during card payment.

  3. At this trigger point, TruModule requests the next question from TruService via TSI and displays it (if a question is returned) on the PED. TruModule waits for a single key response. TruModule also monitors a timeout for no response and will clear the rating question from the device when the provided timeout occurs.

  4. The TruModule will display the correct TruRating Acknowledgement from on the screen for the time indicated by TruService.

  5. TruModule records the rating in memory and the payment application continues with payment processing as usual

  6. The payment application continues to execute as usual until it comes time to print a receipt, it will append the TruRating receipt text to the bottom of the card receipt.

  7. The payment application continues to execute as usual until it comes to what would be an idle state when the payment application has finished the payment. The TruModule will now send the Rating and Transaction data to TruService via TSI.

  8. When pre-fetch is being used, directly after sending the Rating and Transaction data to TruService via TSI and receiving a response, the TruModule will request the next question from TruService via TSI in readiness for the next transaction.

  9. TruModule will store any question returned by TruService along with the acknowledgment prompts, receipt data and all other pertinent information (such as timeout values, and additional languages) in memory to be used in the subsequent transaction.

  10. TruModule will check the activation status with TruService via TSI when the TimeToLive value has expired. TruService will indicate the new activation state, and provide the new value for the time to live value. The new state provided by TruService is valid for the indicated time

Display Screens

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.

Customer Receipt

The payment application will print a TruRating receipt message at the end of the customer receipt. The point in the payment process where this is done is marked in the specification pages in this section as (Z). This receipt message is received via TruModule as part of the communication with TruService.

Minimum Standalone device requirements

There are some minimum requirements when implementing the TruRating Application on a traditional standalone payment device. The standalone payment device:

  • Supports a minimal file store - The ability to store a Rating, Current Question and Transaction Data either in a file or memory storage is required.
  • Supports TCP/IP - Communication between TruModule and TruService requires HTTPS socket support within MAC’ing. The communication channel may be over Ethernet, PSTN, WiFi, BlueTooth, GPRS etc.

Example code

Sample implementations of TruModule are available from TruRating in various commonly used languages.

Feedback