Contents

Purpose

This document aims to explain in detail how BK ES will migrate their Loyalty system from SessionM to RBI. Prior understanding of the RBI Loyalty API is required.

Assumptions

• SessionM is a third party Loyalty engine (like Salesforce is for CRM - Session M is for Loyalty)

• The BK ES apps (native) are provided by Airtouch, using BE integrations with Homeria for guests (including authentication) and delivery orders (menu, restaurant, prices), and with Airtouch for collection orders

• Both the Airtouch and Homeria back end services integrate with SessionM for loyalty

• User data and authentication of users is entirely managed by Homeria

• WinRest and Tillster call SessionM directly for Loyalty. There is no integration with Airtouch or Homeria

• Kiosks do not show the guest’s Loyalty Tier

• Rewards are configured in SessionM (Rewards Store)

• Offers/Coupons are just PLU’s with a set price, and they are not available on delivery so they are only configured in Airtouch

• Website is Homeria (both FE and BE)

• It is possible to authenticate SessionM transactions using an email address (there is an endpoint to retrieve the SessionM ID using an email address)

• The Airtouch app does not allow scanning offers to add them to the basket on the Kiosk or POS. Instead, there is only a static loyalty code to authenticate.

...

• To add offers while ordering on a kiosk, guests need to be logged into the Airtouch app, see the offer code and input it in the kiosk

Decisions

Points expiry

Loyalty Tiers

• We will disable downgrades from Superking to King during the migration, to avoid guest frustration

  • We propose during the migration (Phase 1-3) to change the requirements for users to move from Loyalty Tier 2 to Loyalty Tier 1 in Sanity to 6 months. In this way, no users would be downgraded Tiers during the migration. In this way, no Development work would be needed.

Cancellations and refunds

• There are no gaps with cancellations and refunds initiated by the POS, since they will use both the RBI and SessionM API’s

• For cancellations and refunds currently handled in SessionM, during the transition period support staff will continue to use SessionM and, in addition, will repeat the operation on the RBI Support Tool

• This will guarantee that cancellations and refunds result in the same loyalty points balance in both RBI and SessionM

Phase 0 (pre & cleanup)

During this phase, both user and loyalty data is kept synchronized between SessionM and RBI.

Change of plans in Phase: loyalty data will not be kept synchronized as guests will continue to burn on Session M, but in RBI we will only record earning transactions.

Plan

• Expected to run for weeks

• Guests will earn but not burn. Change of plans in March: guests will continue to burn, because RBIberia does not want to risk a drop in sales by preventing burn.

• All clients apps (Airtouch, Homeria, Winrest, Tillster) will continue to record loyalty transactions on Session M (no integration to RBI loyalty yet)

• Change of plans in March: all client apps will also send earn transactions to RBI (burn transactions will not be sent). The purpose is to test the RBI system’s performance and ensure that we record loyalty transactions accurately. During this phase, we will compare transactions between RBI and SessionM (although the loyalty points balance is not expected to match).

• Guest and loyalty data (including email addresses, loyalty points balance, loyalty tier and loyalty transactions) will be migrated from SessionM to RBI, as a one time data dump and load before Phase 1 starts

  • ACTION REQUIRED: review the point above. We need to delete loyalty transactions done up to this point as well

• The above will be accomplished by extracting data into CSV files which will be placed in an RBI S3 bucket, and ingested with a script. CSV files will need to be obtained from Homeria (user data) and SessionM (loyalty data including points balance, tier and loyalty transactions).

• At the end of the data migration above, RBI will provide a list of RBI Cognito ID’s, RBI Loyalty ID’s and email addresses for all users, to be imported by Homeria

• The RBI app is not live (all guests will use the Airtouch app)

• There will be no users created via the RBI apps (only via the Airtouch app or Homeria website)

• No need for rollback

Scenarios

Mobile order, click & collect

• Guest opens the Airtouch app

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Airtouch BE

• Airtouch BE updates SessionM

• Airtouch BE updates RBI Loyalty

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

Mobile order, delivery

• Guest opens the Airtouch app

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Homeria BE

• Homeria BE updates SessionM

• Airtouch BE updates RBI Loyalty

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

In-store order on a Tillster kiosk

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID / SessionM ID

• Airtouch app / Homeria should already have the static SessionM ID in the session

• Guest scans the SessionM ID on the Tillster kiosk and authenticates (this returns the email address)

• Guest fills up their basket and completes the order (this retrieves the basket price calculation)

• Tillster creates a loyalty transaction in SessionM

• Tillster creates a loyalty transaction in RBI

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

In-store order on WinRest POS

...

Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID / SessionM ID

...

Airtouch app / Homeria should already have the static SessionM ID in the session

...

Guest scans the SessionM ID on the scanner and authenticates (this returns the email address)

...

Guest/operator completes the order (this retrieves the basket price calculation)

...

WinRest creates a loyalty transaction in SessionM

...

Contents

Purpose

This document aims to explain in detail how BK ES will migrate their Loyalty system from SessionM to RBI. Prior understanding of the RBI Loyalty API is required.

Assumptions

• SessionM is a third party Loyalty engine (like Salesforce is for CRM - Session M is for Loyalty)

• The BK ES apps (native) are provided by Airtouch, using BE integrations with Homeria for guests (including authentication) and delivery orders (menu, restaurant, prices), and with Airtouch for collection orders

• Both the Airtouch and Homeria back end services integrate with SessionM for loyalty

• User data and authentication of users is entirely managed by Homeria

• WinRest and Tillster call SessionM directly for Loyalty. There is no integration with Airtouch or Homeria

• Kiosks do not show the guest’s Loyalty Tier

• Rewards are configured in SessionM (Rewards Store)

• Offers/Coupons are just PLU’s with a set price, and they are not available on delivery so they are only configured in Airtouch

• Website is Homeria (both FE and BE)

• It is possible to authenticate SessionM transactions using an email address (there is an endpoint to retrieve the SessionM ID using an email address)

• The Airtouch app does not allow scanning offers to add them to the basket on the Kiosk or POS. Instead, there is only a static loyalty code to authenticate.

...

• To add offers while ordering on a kiosk, guests need to be logged into the Airtouch app, see the offer code and input it in the kiosk

Decisions

Points expiry

• Phases 0 and 1 - doesn’t matter because RBI is not the master of loyalty

• Phase 2:

  • Import loyalty data including earn and burn transactions for the last two years (no points expiration data will be imported)

  • Run the loyalty points expiration on our side

  • Update the loyalty points balance to match SessionM

  • From this point onward, rely on the RBI loyalty points expiration process

Loyalty Tiers

• We will disable downgrades from Superking to King during the migration, to avoid guest frustration

  • During the migration (Phase 1-3) we will change the requirements for users to move from Loyalty Tier 2 to Loyalty Tier 1 in Sanity to 6 months instead of 1 month as it is today. In this way, no users would be downgraded Tiers during the migration.

• User will continue being able to go from Tier 1 (King) to Tier 2 (Superking) by earning 15000 points in 6 months on a rolling basis.

  • Session M will send this information to RBI

Cancellations and refunds

• There are no gaps with cancellations and refunds initiated by the POS, since they will use both the RBI and SessionM API’s

• For cancellations and refunds currently handled in SessionM, during the transition period support staff will continue to use SessionM and, in addition, will repeat the operation on the RBI Support Tool

• This will guarantee that cancellations and refunds result in the same loyalty points balance in both RBI and SessionM

Phase 0 - Test RBI Earning

Change of plans in March: loyalty data will not be kept synchronized as guests will continue to burn on Session M, but in RBI we will only record earning transactions.

The purpose of this phase is to test that the RBI Loyalty API is able to handle the load by processing earn transactions.

Plan

• Expected to run for weeks

• Guests will earn but not burn. Change of plans in March: guests will continue to burn, because RBIberia does not want to risk a drop in sales by preventing burn.

• All clients apps (Airtouch, Homeria, Winrest, Tillster) will continue to record loyalty transactions on Session M (no integration to RBI loyalty yet).

• Change of plans in March: all client apps will also send earn transactions to RBI (burn transactions will not be sent). The purpose is to test the RBI system’s performance and ensure that we record loyalty transactions accurately.

• During this phase, we will compare transactions between RBI and SessionM (although the loyalty points balance is not expected to match).

• Guest and loyalty data (including email addresses, loyalty points balance, loyalty tier and loyalty transactions) will be migrated from SessionM to RBI, as a one time data dump and load before Phase 0 starts

• Change of plans in March: loyalty data is no longer required before Phase 0. Loyalty User ID’s should still be included in the user data sync described below that happens before Phase 0.

• Guest accounts will be synced between RBI and Homeria

• The above will be accomplished by extracting data into a CSV file which will be obtained from Homeria and placed in an RBI S3 bucket, and ingested with a script. SessionM data (loyalty transaction, expiration of points, tiers, etc) is not needed.

• At the end of the data migration above, RBI will provide a list of RBI Cognito ID’s, RBI Loyalty ID’s and email addresses for all users, to be imported by Homeria

• The RBI app is not live (all guests will use the Airtouch app)

• There will be no users created via the RBI apps (only via the Airtouch app or Homeria website)

• When users are created in the Airtouch app or the Homeria website, Homeria will call the RBI Create User endpoint to ensure that users are in sync. This endpoint will also create a Loyalty user in RBI.

• The endpoint above will be modified to respond with the RBI Loyalty ID, which will then be stored in Homeria to be used during Phase 1 to generate RBI OTP’s. The RBI Loyalty ID will then be made available by Homeria to the Airtouch app

Scenarios

Mobile order, click & collect

• Guest opens the Airtouch app

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Airtouch BE

• Airtouch BE updates SessionM

• Airtouch BE updates RBI Loyalty

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

Changes needed

...

RBI

...

• S3 data load script to be modified to capture loyalty data from SessionM also (which will result in creating a loyalty ID for each user)

• Data extract from RBI (currently only RBI Cognito ID's) to include RBI Loyalty ID

• New Identify endpoint that accepts an email address

...

SessionM

...

• Extract of loyalty data (loyalty points balance, tier and loyalty transactions)

...

Homeria

...

• Extract of user data (SessionM ID required to link with the above)

...

Airtouch

...

• Remove screens that will not be used (discussed separately)

...

Tillster

...

• Call RBI Loyalty API (Identify and Transaction Update)

...

WinRest

...

• Call RBI Loyalty API (Identify and Transaction Update)

Phase 1 (big bang)

Plan

• All client apps will use primarily RBI Loyalty, and SessionM as a backup in case a rollback is needed. Both RBI and SessionM should have the same loyalty transactions and points balance to start with

• This requires Airtouch, Homeria (because of the website and app/delivery), Tillster and WinRest to modify their software to introduce RBI Loyalty in addition to SessionM

• Airtouch app will use RBI loyalty codes for in-store identification, instead of SessionM codes

• Guests will continue to earn but not burn

• No rewards will be shown (reward configuration in Sanity will be done on phase 2)

• Registration and authentication on the Airtouch app or Homeria website will continue to use Homeria

• New users created on the app or website will be synchronized from Homeria to RBI using an existing endpoint (same that we used for BK PT)

• The endpoint above will be modified to respond with the RBI Loyalty ID, which will then be stored in Homeria to be used when calling the RBI Loyalty API. The RBI Loyalty ID will then be made available to the Airtouch app

Scenarios

Mobile order, click & collect

• Guest opens the Airtouch app

• App calls Get User Details from RBI, using the RBI Loyalty ID as input. This endpoint will retrieve loyalty points balance and loyalty tier

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Airtouch BE

• Airtouch BE updates RBI Loyalty:

  • Call Create Transaction using the RBI Loyalty ID

  • Call Transaction Update with an empty basked and set the transaction to CLAIMED

• Airtouch BE updates SessionM:

  • (optional) Call SessionM to retrieve the SessionM ID using the email address as input

  • Replicate the transaction above in SessionM

Mobile order, delivery

• Guest opens the Airtouch app

• App calls Get User Details from RBI, using the RBI Loyalty ID as input. This endpoint will retrieve loyalty points balance and loyalty tier

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Homeria BE

• Homeria BE updates RBI Loyalty:

  • Call Create Transaction using the RBI Loyalty ID

  • Call Transaction Update with an empty basked and set the transaction to CLAIMED

• Homeria BE updates SessionM:

  • Retrieve the SessionM ID (this step is not needed because the Homeria BE stores the guest’s SessionM ID)

  • Replicate the transaction above in SessionM

Website order (only delivery allowed)

• Guest opens the Homeria website

• Website calls Get User Details from RBI, using the RBI Loyalty ID as input. This endpoint will retrieve loyalty points balance and loyalty tier

• Guest fills their basket and completes the order

• As part of the order process, the website calls the Homeria BE

• Homeria BE updates RBI Loyalty:

  • Call Create Transaction using the RBI Loyalty ID

  • Call Transaction Update with an empty basked and set the transaction to CLAIMED

• Homeria BE updates SessionM:

  • Retrieve the SessionM ID (this step is not needed because the Homeria BE stores the guest’s SessionM ID)

  • Replicate the transaction above in SessionM (CLAIMED) with an empty basket

Mobile order, delivery

• Guest opens the Airtouch app

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Homeria BE

• Homeria BE updates SessionM

• Homeria BE updates RBI Loyalty

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

Website order (only delivery allowed)

• Guest opens the Homeria website

• Guest fills their basket and completes the order

• As part of the order process, the app calls the Homeria BE

• Homeria BE updates SessionM

• Homeria BE updates RBI Loyalty

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED) with an empty basket

In-store order on a Tillster kiosk

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID / SessionM ID

• Airtouch app / Homeria should already have the static SessionM ID in the session

• Guest scans the SessionM ID on the Tillster kiosk and authenticates (this returns the email address)

• Guest fills up their basket and completes the order (this retrieves the basket price calculation)

• Tillster creates a loyalty transaction in SessionM

• Tillster creates a loyalty transaction in RBI

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED)

In-store order on WinRest POS

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID / SessionM ID

• Airtouch app / Homeria should already have the static SessionM ID in the session

• Guest scans the SessionM ID on the scanner and authenticates (this returns the email address)

• Guest/operator completes the order (this retrieves the basket price calculation)

• WinRest creates a loyalty transaction in SessionM

• WinRest creates a loyalty transaction in RBI

  • Call Identify by sending the email address

  • Call Transaction Update (CLAIMED)

Changes needed

Phase 1 - Test RBI OTP

Plan

• All client apps will start using the RBI OTP to identify guests when making in-store purchases. To show the OTP during in-store orders only, both the Airtouch app and Homeria website need to call the Create OTP endpoint,. See documentation about this endpoint here: https://rbictg.atlassian.net/wiki/spaces/IBC/pages/4460904510/BK+ES+Loyalty+Transaction+-+API+Endpoints+Doc#%5BWEB%2FAPP%5D-Create-OTP

• Loyalty transactions will be done primarily on SessionM, and RBI after (earn transactions only).

• SessionM transaction history will not be migrated yet

• Registration and authentication on the Airtouch app or Homeria website will continue to use Homeria

• New users created on the app or website will continue being synchronized from Homeria to RBI using the same endpoint we used in Phase 0.

Scenarios

Mobile order, click & collect

No changes from Phase 0.

Mobile order, delivery

No changes from Phase 0.

Website order (only delivery allowed)

No changes from Phase 0.

In-store order on a Tillster kiosk

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID

• Airtouch app / Homeria website calls the RBI Get Loyalty Create OTP endpoint

• Guest scans the OTP on the Tillster kiosk

• Tillster calls the RBI Identify endpoint and uses the OTP to authenticate the guestTillster calls the RBI Get User endpoint in the background to retrieve the email address in the session (to use later during the SessionM transaction). Identify responds with a Transaction ID, RBI Loyalty User ID and the guest’s email address

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

• Guest completes the order

• Tillster updates SessionM, using the email address retrieved previously

• Tillster updates RBI Loyalty (this should be similar to what happens today on PLK ES):

  • Call Transaction Validate

  • Call Transaction Update (CLAIMED) with an empty basket

• Tillster updates SessionM:

  • (optional) Call SessionM to retrieve the SessionM ID using the email address as input

  • Replicate the transaction above in SessionM

• • Call Transaction Validate

  • Call Transaction Update (CLAIMED)

In-store order on a WinRest POS

• Guest opens the Airtouch app or Homeria website and asks to show the Loyalty ID

• Airtouch app / Homeria website calls the RBI Get Loyalty Create OTP endpoint

• Guest scans the OTP on the WinRest QR reader

• WinRest calls the RBI Identify endpoint and uses the OTP to authenticate the guestWinRest calls the RBI Get User endpoint in the background to retrieve the email address in the session (to use later during the SessionM transaction). Identify responds with a Transaction ID, RBI Loyalty User ID and the guest’s email address

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

• Guest completes the order

• WinRest updates SessionM, using the email address retrieved previously

• WinRest updates RBI Loyalty (this should be similar to what happens today on PLK ES):

  • Call Transaction Validate

  • Call Transaction Update (CLAIMED) with an empty basket

• WinRest updates SessionM:

  • (optional) Call SessionM to retrieve the SessionM ID using the email address as input

  • Replicate the transaction above in SessionM

Changes needed

...

RBI

...

• Develop the Get Loyalty OTP endpoint (takes an email address and generates a Loyalty OTP valid for 15 minutes)

• Develop the Get Email Address endpoint (takes a Loyalty OTP and retrieves the guest’s email address, needed to authenticate the guest with SessionM)

...

Airtouch

...

Changes needed

Phase 2 (rewards)

Plan

• Configure and enable RBI rewards in Sanity

• (To be confirmed) Configure the generic PLU for rewards

• RBI rewards become active on the Airtouch app and the Homeria website, and guests are able to redeem them when making collection, delivery or in-store orders (requires the app to retrieve rewards from RBI)

• Reward redemption should use the RBI Loyalty API version that was customized for RBIberia: RBI Iberia | Loyalty POS/Kiosk Integration

• Client apps no longer call SessionM (these will be disabled using feature flags)

Changes needed

Phase 2 - Test RBI Loyalty

Plan

• During this phase, RBI will become the master for loyalty data, and SessionM will be used as a backup in case we need to roll back.

• When Phase 2 starts, we need to import the last two years of loyalty transactions from SessionM, to make history available to guests (on the Airtouch app now, and when they later switch to the RBI app). The import process will be as follows:

  • All loyalty (earn) transactions made to date will be voided. We need to void instead of deleting, because data in Snowflake cannot be deleted.

  • An extract will be taken from SessionM, covering the last two years of transactions and the current loyalty points balance. Each transaction record needs to include the date and time when the transaction took place, loyalty points, whether earn or burn, channel, if the burn is due to spending rewards of points having expired.

  • The extract will be loaded into RBI, after which the expiration points feature will be switched on. RBI will migrate users without loyalty point expiration balance. From this point onward, rely on the RBI loyalty points expiration process. RBI will expire all loyalty points that were accrued over 6 months ago, rounded to the nearest month end.

  • At this point the RBI loyalty points balance will not match SessionM’s because it doesn’t have the full transaction history. So we will calculate the loyalty points balance on RBI based on the total of transactions and compare with the current SessionM balance for each user.

  • Finally, we will record a single remediation transaction per user with the difference, to make the loyalty points balance in RBI match SessionM.

• Airtouch app and Homeria website will need to call the Get Loyalty User endpoint, using the RBI Loyalty User ID as input. Get Loyalty User will return RBI loyalty points balance, tiers and guest email.

• Rewards will be configured in Sanity.

• Configure the generic PLU for rewards

• RBI rewards become active on the Airtouch app and the Homeria website, and guests are able to redeem them when making collection, delivery or in-store orders (requires the app to retrieve rewards from RBI)

• Reward redemption should use the RBI Loyalty API version that was customized for RBIberia: RBI Iberia | Loyalty POS/Kiosk Integration

Changes needed

Phase 3 (white label app migration)

Plan

• The BK ES website (currently Homeria) will be replaced with the RBI white label website by pointing the BK ES domain(s) to RBI servers

• The BK ES app (currently Airtouch) will be replaced with the RBI white label app by releasing to the App Store and Google Play Store

• Over time, older versions of the Airtouch app will stop being used

• When the number of Airtouch users reaches an agreed threshold, force update will be enabled

• When the number of Airtouch users reaches an agreed threshold, Homeria and Airtouch back end systems can be switched off

Changes needed

...

RBI

...

• Point the BK ES domain(s) to RBI servers

• Replace the Airtouch app in the App Store and Google Play Store with the RBI white label app

...

Airtouch

...

• Switch on force update when the number of app users is low enough

• Switch off BE when number of app users is low enough

...

Homeria

...

• Switch off BE when number of app users is low enough

...

Tillster

...

• No changes

...

WinRest

...

• No changes

RBI Endpoints

The RBI Loyalty API endpoints are documented here: Loyalty API

In addition, these will also be used:

...

Name

...

Input

...

Output

...

Get Loyalty OTP

...

RBI Loyalty ID

...

Loyalty One Time Passcode (valid for 15 minutes, suitable to call the Identify endpoint)

...

Get User Details

...

RBI Loyalty ID

...

Email address, loyalty points balance and tier of the guest

Open questions

• Whether expiring points is required, and if so in which phase(s)

  • Points expiry

    • Proposal not to expire points either on RBI or SessionM, to avoid potential discrepancies

    • This is possible to configure in SessionM

    • ACTION: Valentina to confirm whether this is possible or requires development

    • In RBI Loyalty, points will be configured to expire after 6 months of the points’ issue date, grouped to the end of the month. This means that points accrued on the 15^th of January would expire on the 30^th of June

    • ACTION: Zaira to confirm with RBIberia Legal whether the privacy policy needs to be updated to reflect the monthly grouping

• How do we handle scenarios where guests change loyalty tiers?

  • Loyalty tiers

    • Proposal to disable downgrades from Superking to King during the migration, to avoid guest frustration since they won’t be able to burn

    • Upgrades from King to Superking still allowed

    • ACTION: Zaira to confirm whether this is possible on SessionM

    • ACTION: Valentina to confirm whether this requires development

Next actions

...

Phase 0:

• Confirm that we can retrieve loyalty data from SessionM to be ingested by RBI (Miguel-Romero, Almudena)

...

Phase 1:

• Confirm that the existing user sync endpoint can be modified to return the RBI Loyalty ID in addition to the Cognito ID (Miguel-Romero, Almudena)

• Confirm that Get User Details returns the loyalty points balance and tier (Silva, Carlos)

• Share testing environment details with all vendors (Lopes da Costa, Valentina)

• Provide example payloads for endpoints not documented in the standard Loyalty API documentation (Francisco Paglia)

Phase 2:

...

Fraud Scenarios sign off

Our loyalty program for PLK was adjusted to consider the following:

• Points should only be assigned when order is delivered or picked up

  • If the transaction is burn only - points are substracted when order is placed

  • If the transaction is earn only - points are assigned when order is delivered or dropped off

  • If the transaction is earn + burn -

    • Output is user earnt points are > than burnt points - points are adjusted when order is delivered

    • Output is user burnt points > that earnt points - points are adjusted when order is placed

Since Homeria and Airtouch do not have this functionality configurable, RB Iberia has accepted this edge fraud case for phase 2 until we switch to white label app, i.e. all points will be awarded as payment is placed. RBIberia acknowledged on April 4th 2024 -

Phase 3 (white label app migration)

Plan

• The BK ES website (currently Homeria) will be replaced with the RBI white label website by pointing the BK ES domain(s) to RBI servers

• The BK ES app (currently Airtouch) will be replaced with the RBI white label app by releasing to the App Store and Google Play Store

• Over time, older versions of the Airtouch app will stop being used

• When the number of Airtouch users reaches an agreed threshold, force update will be enabled

• When the number of Airtouch users reaches an agreed threshold, Homeria and Airtouch back end systems can be switched off

Changes needed

RBI Endpoints

The RBI Loyalty API endpoints are documented here: Loyalty API

In addition, these will also be used:

Open questions

• Data Dump at the End of Phase 1

  • Pending on understanding the structure and size of the data dump to be sent from SessionM to RBI at the end of Phase 1 for script to be worked on

Change Log

• In March 2024 there were two changes of plans:

  • To continue to burn rewards throughout Phase 0, to minimise impact on sales. This means that burn transactions will be sent to RBI, and the loyalty points balance will not match between RBI and SessionM

  • To change the Loyalty API interface allowing authentication with an email address, to reduce the number of calls made by POS/Kiosks