Overview

This document contains a detailed description of the journey that RBI guests should experience when placing orders in-store, covering POS and Kiosk scenarios.

...

• Whether the market uses open offers (i.e. offers that can be redeemed by guests who are not signed in). In markets that don’t allow open offers, its not possible to redeem offers while signed out. Closed offers are offer that are only available to guests that are signed in.

• Whether the market allows redemption of multiple offers or multiple rewards in the same order. In markets that do not allow multiple offer/reward redemption, the UI (on the RBI app and Kiosk) must make it clear to guests when they are replacing an existing selection with a new selection.

• Whether the market uses QR code scanners. If not, the POS and kiosk UI must allow ooerators/guests to enter the loyalty or offer codes manually.

• (Kiosk only) Whether the market allows offer selection using the Kiosk UI. This decision has been shown to have a PNL impact, so some markets don’t want this to be an option.

Scenarios

Customer Journey Scenarios - POS

Customer Journey Scenarios - Kiosk

API Integration

The scenarios above are accompanied by the Loyalty API - ReferenceDeveloper Guide documentation, which details the different endpoints needed to integrate POS, Kiosk or other systems to the RBI platform.

Using the API endpoints should follow this pattern:

...

Call the Identify endpoint using either the Loyalty Code or the unique code generated when offers/rewards are pre-selected

...

Call the Transaction Validate endpoint to check that the contents of the basket is valid. The endpoint will return errors in multiple scenarios documented here: Loyalty API - Error List. For an optimal guest (in the case of kiosks) or operator (in the case of POS) experience, our recommendation is to call Transaction Validate every time the user changes the offers and/or rewards contained in the basket. If network latency is an issue, integrators have the option to call this endpoint only once prior to payment. If Transaction Validate does not return errors, the loyalty transaction is expected to succeed in the last step below.

...

If the guest has made changes to rewards in their basket, call the Transaction Update endpoint which will update the guest’s loyalty points balance. Note that the Transaction Update endpoint returns less detailed error information than Transaction Validate in case it fails, which means they need to be called separately.

...

Collect payment from the guest

...

Call the Transaction Update endpoint with a status of CLAIMED, which will close the loyalty transaction and permanently alter the guest's loyalty point balance.

...

If you are ready to use the Loyalty API, you can start here: Loyalty API - Getting Started.

In general, the API integration follows the same pattern for both POS and Kiosk applications:

• Call Loyalty API v1 - Identify once per scan and keep track of all the offers and rewards that were added to the basket (remembering to call Loyalty API v1 - Void on the second and subsequent scans);

• Call Loyalty API v1 - Update with a status of PENDING when a reward is added to basket to update the guest’s loyalty points;

• Call Loyalty API v1 - Validate prior to collecting payment, to ensure that the combination of offers and rewards in the cart do not trigger any rule evaluation errors;

• Call Loyalty API v1 - Update with a status of CLAIMED to conclude the Loyalty transaction after payment has been collected;

• Call Loyalty API v1 - Void if the guest cancels the transaction at any point.