Loyalty API Migration - Technical Requirements

Key Concepts

• Partner: Will

• RBI Platform: The RBI M&O platform, app, and website for the brand.

  • RBI User: A user that exists in the RBI Platform.

• Loyalty Platform: The RBI Loyalty platform, runs independently from the RBI Platform.

  • Loyalty User: A user that exists in the Loyalty Platform. This user exists separately from the RBI User.

  • Point Burning: Spending loyalty points (crowns).

  • Point Earning: Earning Loyalty Points (crowns).

  • POS: Point of Sale.

  • OST: Order Selection Transfer is a mechanism in which given an identifier, we can trace it back to an order a user has started on another platform. Eg. the user starts an order on their mobile phone, and then it can be transferred to a Kiosk totem or cashier POS. Some of these are: OTPs, User UUID(RBI Loyalty User Id), User UUID (Base 10), Phone Number, Swipe Card Number (Not in use), PAN Number (Not in use).

  • OTP: One Time Password is one of the many OST identifiers we support. The user is given a temporary (15-minute) 6-digit code that can be traced back to the user’s order.

  • Identify: Process in which we exchange an OST for a new Loyalty transaction. Ideal for FE platforms where we want to allow guests to identify quickly without requesting all their credentials.

Phase 0 - User Synchronization

Details

Before the transition can happen RBI needs to have a full list of all the existing users and the relevant data (user and loyalty data) in the Homeria app and SessionM platform for them to be migrated to the RBI Platform and the RBI Loyalty Platform.

Below are the steps that need to be followed to ensure a successful user synchronization:

• RBI will provide an endpoint and keys to create a user in the RBI Platform.

  • This endpoint will also ensure the associated user gets created in the RBI Loyalty Platform, with its appropriate linkage to the RBI User.

  • Homeria must store and associate the returned RBI User ID and RBI Loyalty ID with their Homeria User.

• Homeria will make sure that any user created in the current system will be also created in the RBI Platform via the provided endpoint.

• Homeria will provide a CSV with all the user data from their system and all the user loyalty data from SessionM (eg. SessionM ID, Homeria User ID, points, balance, tier, and transactions).

• RBI will host these files in a private S3 bucket and create the necessary database records via a script run in a provisioned EC2 instance with the appropriate role.

  • RBI will not create duplicated users for those already created by the synchronization process.

  • RBI will update the Loyalty Points balance, tiers, and other Loyalty data for the users already created.

  • (Optional) I suggest Homeria disables Loyalty Earning, Burning, and Tier and Points expiration while this process takes place.

    • Check Phase 1 - Option A & B. Issue

• RBI will provide a CSV back with the correlation between the Homeria User, RBI User ID, and the RBI Loyalty ID to be imported by Homeria.

At this point, both RBI and Homeria should have their user databases in sync, with the correct associations between RBI IDs and Homeria User IDs with no downtime, and (if following the correct order) ensuring we don’t have any lost users while the user import process took place.

Assumptions

• This phase will run for weeks.

• User updates are not communicated to RBI. If any user data changes, once the RBI apps are enabled, they will roll back to the point where this migration happened. Issue

• Point expiration dates will not be migrated, a new date will be determined by RBI. Issue

• Point burning will be disabled on all platforms (Airtouch, Homeria, Winrest, Tillster).

• All client platforms (Airtouch, Homeria, Winrest, Tillster) will still utilize SessionM as the Loyalty Platform.

• The RBI Platform will not be live yet.

  • No users will be created on the RBI Platform.

  • All users will continue using the AirTouch app or the Homeria website.

• There’s no risk of data loss, so there’s no need for a rollback plan at this phase.

Changes Needed

In the Phase 1 and Phase 2, if we want to synchonize all the transactions/orders to RBI orders, which are stored in mono table, we need a daily sync for daily transactions/orders happened, we conducted this for PLK ES in the past. If we apply this somehow “offline“ sync, the created RBI orders won’t connected with corresponding RBI Loyalty Transactions (not needed)

Phase 1 - RBI Loyalty Enablement

Requirements

Loyalty points will not be in sync if during Phase 0 Homeria have Loyalty Earning, Burning, and Tiers expiration, and/or if Phase 1 begins at any time that it’s not immediately after the import process is complete. This means that at a later point, we’ll need to synchronize all users' Loyalty Points, Tiers, and any other user Loyalty data once again. The same conditions apply, there has to be some Loyalty downtime while the sync takes place.

Before Phase 1 starting, a data sync will happen to synchronize data for a small number of users, who have loyalty status(points) update.

Details

RBI Loyalty will become the primary Loyalty platform for the brand, but at the same time, all loyalty transactions on Homerias' side will be sent both to the RBI Loyalty Platform and SessionM.

There will be two main scenarios which require different interactions with the RBI Loyalty Platform:

Flow 1 - The FE client knows who the user is (Web / App):

Flow 2 - The FE client doesn’t know who the user is (Kiosks and POSs):

Rollback Plan

Given all transactions are still being reported to SessionM. Homeria and all other existing platforms must have mechanisms in place to switch the source of truth back to SessionM once again.

Scenarios

Mobile Order, Click & Collect

1. The guest opens the Airtouch Mobile App.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Airtouch, as part of the ordering process, starts a process on their BE.

5. Airtouch BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in Loyalty API Migration - API Endpoints | [APP] Create RBI Loyalty Transaction Airtouch

6. Airtouch BE creates a new Transaction in SessionM:

   1. How they do this is up to Airtouch, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Mobile Order, Delivery

1. The guest opens the Airtouch Mobile App.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Airtouch, as part of the ordering process, starts a process on Homeria’s BE.

5. Homeria’s BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in Loyalty API Migration - API Endpoints | [APP] Create RBI Loyalty Transaction Airtouch

6. Homeria’s BE creates a new Transaction in SessionM:

   1. How they do this is up to Homeria, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Online Order, Website

1. The guest opens the Homeria website.

2. The app calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc) for display purposes.

3. The guest places an order.

4. Homeria, as part of the ordering process, starts a process on their BE.

5. Homeria’s BE creates a new RBI Loyalty Transaction

   • The details of the endpoint and example payload can be found in Loyalty API Migration - API Endpoints | [APP] Create RBI Loyalty Transaction Airtouch

6. Homeria’s BE creates a new Transaction in SessionM:

   1. How they do this is up to Homeria, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

In-Store Order

PART 1, Homeria & Airtouch

The Guest opens the Airtouch App or Homeria website, then navigates to the page where their Loyalty Identifier is displayed.

Airtouch App / Homeria website calls the Create OTP endpoint. This call will be made with an order list in the payload.

• The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | [WEB/APP] Create OTP

1. The code has to be automatically refreshed.

2. The FE has to poll the Get OTP endpoint every around 10 seconds to detect if the code has already been used, the status is claimed.

   1. The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | [WEB/APP] Get OTP

3. If the code has already been used, display a modal acknowledging the successful transfer to the guest, and immediately generate a new one.

4. If the code request fails, the FE has to display some sort of feedback to the user prompting them to try to get a new OTP code again.

5. All the edge cases, process feedback to the user, and polling have to be implemented and handled by Airtouch and Homeria.

6. The OTP code will be displayed both in a QR and plain text format.

PART 2, Tillster Kiosk

1. Guest inputs the OST provided by the app:

   1. Scanning the QR Code.

   2. Manually introducing the plain text OTP code.

2. Tillster calls the RBI POST Identify endpoint and uses the OST to identify the guest.

   1. If the guest wants to use offers, they would input their code directly into the kiosk. These offers are not configured in RBI.

   2. posType: Tillster

   3. The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | [In Store] Identify RBI Loyalty User

3. Tillster calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty User Id. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc).

   1. We need the email address to use later during the creation of the SessionM transaction.

   2. The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | Get RBI Loyalty User

4. The guest places an order.

5. As part of the ordering process, the In-Store flow for Kiosk integrating with RBI is initiated:

   1. The guest finishes their order and proceeds to checkout.

   2. Tillster calls the POST Validate RBI endpoint. unnecessary

   3. Tillster calls the PUT UPDATE RBI endpoint.

      1. OPTION A: All the items for the order with each item’s price.

      2. OPTION B: A single mock item with the total price of the order.

   4. The Transaction will have the status of CLAIMED.

   5. The Transaction channel will have the value of restaurant.

   6. Any other information about the order is optional, but it’s recommended to include the most we can for any potential debugging purposes (eg: Payment method, payment amount, etc).

6. Tillster creates a new Transaction in SessionM:

   1. How they do this is up to Tillster, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

PART 2, Winrest POS

1. Guest inputs the OST provided by the app:

   1. Guest scans the OTP on the WinRest QR reader

2. Winrest calls the RBI POST Identify endpoint and uses the OST to identify the guest.

   1. If the guest wants to use Offers, they would ask the cashier to add the offer code to their order. These offers are not configured in RBI.

   2. posType: Winrest

   3. The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | [In Store] Identify RBI Loyalty User

3. Winrest calls the GET User Details from the RBI Loyalty Platform, using the RBI Loyalty ID. This endpoint retrieves the RBI Loyalty data for the user (name, email, point balance, tier, etc).

   1. We need the email address to use later during the creation of the SessionM transaction.

   2. The endpoint details and example payload can be found in Loyalty API Migration - API Endpoints | Get RBI Loyalty User

4. The guest places an order.

5. As part of the ordering process, the In-Store flow for Kiosk integrating with RBI is initiated:

   1. The guest finishes their order and proceeds to checkout.

   2. Winrest calls the POST Validate RBI endpoint. unnecessary

   3. Winrest calls the PUT UPDATE RBI endpoint.

      1. OPTION A: All the items for the order with each item’s price.

      2. OPTION B: A single mock item with the total price of the order.

   4. The Transaction will have the status of CLAIMED.

   5. The Transaction channel will have the value of restaurant.

   6. Any other information about the order is optional, but it’s recommended to include the most we can for any potential debugging purposes (eg: Payment method, payment amount, etc).

6. Tillster creates a new Transaction in SessionM:

   1. How they do this is up to Tillster, but they should already have all the user and order data.

   2. The transaction must be an equivalent of the already created order in the RBI Loyalty Platform.

Phase 2 - Reward Enabled

Scenarios

Mobile Order and Online Order

The only difference from Phase 1 is that in step 5, the Rewards need to be added in the payload sent to Create RBI Loyalty Transaction endpoint.

In-Store Order

In-Store Order PART 1

The only difference from Phase 1 is that in create OTP in the website/App, the Rewards need to be added in the payload sent to Create OTP endpoint.

In-Store Order PART 2

The only difference from Phase 1 is that in step 5, the Rewards need to be added in the payload sent to Update/Claim RBI POS Loyalty Transaction endpoint.

Changes Needed