Overview

This section contains solutions and patterns for integrated systems. The patterns reflect the common current architectural use cases that exist and show the different ways in which TruModule and TruService can be implemented to deliver the TruRating experience.

Certain scenarios will limit the amount and accuracy of data collected, and will affect the response rate from customers due to the presentation time of the question.

Approach

These use cases reflect the currently active and common configurations for Integrated Systems. Due to the flexibility that TruService offers and the complex nature of the Payment and POS applications in the integrated space, further use cases will be added in future updates.

Since the PED is the device through which the rating question and rating response are collected this matrix is organized around the different ways in which Payment applications may support TruRating:

  1. Payment Application exposes only 1AQ1KR command
    (including the ability to cancel 1AQ1KR and display text like “Thanks for Rating”)

  2. Payment Application has implemented TruModule to support Payment Time ratings only

  3. Payment Application has implemented TruModule to support Payment Time ratings and exposes a GetRating command for Dwell Time
    (along with ability to cancel a Dwell Time rating)

  4. Payment Application has implemented TruModule to support Payment Time & Dwell Time rating with support for POSEvents

NOTE: The point at which TruRating receipt text is incorporated into the customers receipt can vary based on specific implementation details. The use cases here show the most common or default approach.

Design Patterns

Rate at Payment Design Patterns

Payment Application implements TruModule

Design pattern # POS Integration Trigger POS Events Characteristics
1: Rate on Payment Request Not Required Card Payment Request N Payment application supports rating at point of card payment via implementation of TruModule.
Rating always linked to a card payment with no ability to capture basket data. Minimal or zero POS integration
2: Rate on Card Presentation Not Required Card Presentation N Payment application supports rating at point of card presentation via the implementation of TruModule. Rating always linked to a card payment with no ability to capture basket data. Minimal or zero POS integration

Payment Application supports 1AQ1KR

Design pattern # POS Integration Trigger POS Events Characteristics
3: Rate ahead of Payment Request Required Card Payment Request Y Example of how rating at start of card payment can be achieved in environment where PED or Payment application only supports 1AQ1KR. In the scenario the POS implements TruModule and controls the rating process ahead of the payment process.

Rate at Dwell Time Design patterns

Payment Application supports 1AQ1KR

Design pattern # POS Integration Trigger POS Events Characteristics
4: POS resident TruModule Required Dwell-Time & Dwell-Time Extend N Rating process performed at dwell time in environment where PED or Payment application only supports 1AQ1KR. POS is responsible for implementation of TruModule and controlling the rating & payment process. POS events are optional.
5: POS resident TruModule supporting POS data Required Dwell-Time & Dwell-Time Extend Y Rating process performed at dwell time in environment where PED or Payment application only supports 1AQ1KR. POS is responsible for implementation of TruModule and controlling the rating & payment process. POS is used to control the rating trigger, with basket data being optional.
6: Middleware TruModule Required Dwell-Time & Dwell-Time Extend Y Rating process performed at dwell time through a piece of middleware that is integrated with the POS application and the payment application. Payment application or PED only supports 1AQ1KR and POS sends events, optionally including basket data. In this design pattern the middleware application co-ordinates the rating process for minimal POS changes.
7: Middleware TruModule with POS data Required Dwell-Time & Dwell-Time Extend Y Rating process performed at dwell time through a piece of middleware that is integrated with the POS application proxy or monitor and the payment application. Payment application or PED only supports 1AQ1KR and POS sends events, optionally including basket data. In this design pattern the middleware application co-ordinates the rating process and the use of the proxy or monitor for the POS application is used to avoid any POS application integration.
Custom solution for TruRating receipt support required

Payment Application has full TruModule including POS Events

Design pattern # POS Integration Trigger POS Events Characteristics
8: Payment app TruModule supporting POS data from POS Required Dwell-Time & Dwell-Time Extend Y Full implementation of TruModule is provided by the Payment application, including supports for POS events and basket data. POS continues to have single interface to the Payment Application but in addition sends POS events used by TruModule to control the rating process. In this example the POS is enhanced if required to support TruRating events.
9: Payment app TruModule supporting POS data from POS Proxy Required Dwell-Time & Dwell-Time Extend Y Full implementation of TruModule is provided by the Payment application, including supports for POS events and basket data. POS continues to have single interface to the Payment Application. To avoid POS development a proxy or monitor is used to generate the POS events used by TruModule to control the rating process.
A custom solution for TruRating recceipt support is required

Payment application has TruModule and exposes GetRating command

Design pattern # POS Integration Trigger POS Events Characteristics
10: Payment app TruModule with simple GetRating command Required Dwell-Time & Dwell-Time Extend Y Payment application provides an implementation of TruModule but support for dwell time rating is limited to a GetRating or similar command that the POS can call. In this both the POS and Payment application provide elements of TruModule with the POS responsible for passing POS events to TruService and triggering the rating process through the GetRating command provided by the Payment application.

Considerations

For each design pattern outlined above, both an architectural diagram and a UML sequence is provided. The UML sequence will reflect the preferred or most common sequence in the situation where several options exists. This means that there will be one or more variations on each design pattern - this is especially the case for Dwell Time ratings where POS events are passed to TruService since TruService can support receiving POS events individually or as a single block at the end of the transaction.

Each of the patterns that follow describes in more detail the relevant architectural design pattern. In most cases there are a number of variations within each design pattern due to the flexibility provided by TruService. Following is a summary of the range of variations on these design patterns that exist:

  1. POS events are shown being sent to TruService individually in real-time. TruService can accept all POS events in a single delivery at the end of the transaction, although this limits question trigger functionality.

  2. Control of Dwell Time Extend can vary between the Payment Application, POS Application or Middleware Application. Only one example is shown for each design pattern.

  3. Based on point 1 - the responsibilities of the POS or any middleware varies. The variation affects Payment Time & Dwell Time differently

  4. In these design patterns the GetRating command to TruService and GetTransaction command are always shown as two individual exchanges. TruService does support a single GetTransaction command that contains the rating data.

  5. Payment Time rating is generally linked to a Tender, while Dwell Time rating is generally linked to a transaction. This rule can vary for specific design patterns.

  6. TruService can still collect transaction data in applicable design patterns - even when no rating is collected.

  7. In some case the use of EndTilling to cancel the rating ahead of payment, could be deferred while non-card tendering takes place.

The design patterns and UML sequences do also reflect some of the basic rules for TruService:

  1. TruService must receive a minimum set of POS events in-order to determine when a question should be asked. The POS/Payment Application or Middleware Application must in turn be capable of supporting TruService informing them when a question should be asked for this function to be supported.

  2. If TruService does not receive a minimum set of POS events, then the POS/Payment Application or Middleware Application must determine when to ask the question based on internal data/triggers.

Feedback