Guest Checkout - challenges

\uD83D\uDDD3 Date

21 Sep 2023

\uD83D\uDC65 Participants

• Magdalena Dlugolecka

\uD83E\uDD45 Goals

• Review the complexities and challenges

Designs

Figma: Burger King

\uD83D\uDDE3 Challenges

1. Storing User Data- cognito-

   Based on the 2023-08-24 Guest checkout PoC works we go with the approach of not creating the User entity in the Cognito and DB. All Guest data will be stored in the Order DB entry.

Overall Complexity

1. Lots of services rely on user data, therefore there is a high level of dependency if we decided to store user information in User entries (record = sk= v0_User in monotable) - we’d have to figure out how other services can consume guest data

2. Database does not allow for adding multiple users with the same e-mail address (it’s not a problem anymore since we don’t store the guest data within the user entries in monotable)

3. We need to create functionalities that are usable for all markets and due to architectural differences per market (transition from whitelabel-gql to fulfillment-service, currently DE uses whitelabel-gql but will have to transition to fulfillment-service eventually) the code needs to be created in both places.

Legal Requirements

3. If we wanted to create fake users- we’d had to determine how to authenticate guest users (dummy sessions)- once user enters checkout, we create an account in the background, but the account would be created with a dummy email, their real email would be stored in meta of order entries -It’s be problematic if they did not finalize an order, because in this case we don’t have the right to retain their data- Decision was to store guest data in Order meta data.

4. We had to determine what to do with the session if a user abandons the checkout process- should we hold on to the cart data.

5. We cannot store guest information in our marketing tools- need to find an alternative way to provide them with transactional emails

   1. Transitioning transactional emails from Braze to AWS SES - dependency on another internal team- to do

6. Initially thought we should not pass data to mParticle but we have decided we’ll still collect events but with anonymous guestID, assuring that it does not get passed on to Braze.
   
   

Yet To be determined:

3. Decision on whether to allow a user to checkout as a guest with an email that's already registered

4. Legal copy for terms and conditions + Privacy Policy for a new static page

   1. Decision on consent- storing
      

      

5. User may be unable to inform the kitchen they have arrived if they abandon the confirmation page -User does not have any order reference number, and once confirmation is closed they cannot click I arrived, they have no way to retrieve this page. One solution is to send a unique link via email to retrieve the confirmation page, however this would require the token to be passed which increases the complexity. Another solution is to include a warning modal upon exit.

6. Instrumentation and adding appropriate events to track success metrics

7. Still a few non-critical designs and design adjustments are pending

8. Support Tool adjustment is not required at this moment as DE market users VR Payments directly to perform Customer Support actions, however it’ll be required for the loyalty launch if Support tool is intended to be used from that time on for refunds etc.

9. How to store user data on the FE, prevent certain functionalities that are dedicated for registered users (for example: loyalty, currently there’s a bug- skip requesting user account data for loyalty)

10. Adjusting whole frontend to serve guest user (so far adjusted only for registered users)

11. Other Frontend items…

12. Sign in flow

Additional considerations:

7. Showcase email for verification purposes to users to avoid errors in email addresses

   1. Allow for email address edit during the process

8. Marketing consent excluded - high complexity, how to process and store this data
   
   
   
   Some of the estimations are split into two parts whitelabel-gql (one large repo, one app, and fulfillment-service (separate services, easier mangement, clear domain borders). It's because some markets use whitelabel and some of them the fulfillment service or it's mixed. Because of that, we have the same functionalities in the two places. We could think about skipping the whitelabel part and implementing it only in the fulfillment service, but it requires the rollout of the fulfillment service. We have this movement in the plans: TRX-655: Tech Debt Fulfilment Service RolloutTO DO
   
   

✅ Action items

⤴ Decisions