Overall Complexity

How to save these customers in the database and how to handle the case when such customers return again for an additional purchase.

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

   1. Eventually, based on the 2023-08-24 Guest checkout PoC works we went 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.
      

2. Database does not allow for adding multiple users with the same e-mail address

   1. (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) , this posed a need for code duality since the code needs to be created in both places.

How to treat guest users?

3. Our initial approach required creating a “fake/dummy” user for the guests- in this case we’d had to determine how to authenticate guest users (dummy sessions)- that’d involve creating an account in the background, once user enters checkout, 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

   1. 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- yet to do
      

6. Initially we thought we should not pass data to mParticle but we have decided that 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

   1. recommendation: to optimize conversion that’d be advisable
      

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

   

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 on the “I arrived” button, they have no way to retrieve this page.

   1. 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.

   2. Another solution is to include a warning modal upon exit.
      

6. Instrumentation - adding new events capturing new user interactions
   

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, so far adjusted only for registered users)
   

10. Modifying sign in flow to a modal is quite complex

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

Milestones