Guest Checkout Work Breakdown

System Architecture

• Transactional emails are moved from Braze to AWS SES

• Switch to AWS SES to send transactional emails

• Create email input field in Sanity

• Set up email subdomain structure

• Transactional emails have the same content

• Emails are sent from SES instead of Braze. This can confirmed by looking at the email subdomain

Haris / Magdalena

Authentication and Authorization

• Guest authentication is enabled

• Loyalty accounts checks are removed for guest users

• Develop a Guest Auth token since guests don't have accounts in Cognito or User DB

• Remove loyalty account check for guest checkout users

• Verify token generation and validation for guest users

• No error is triggered due to missing loyalty account

Magdalena

Data Security and Compliance

• Secure and compliant data storage

• Guest Token actions are limited and controlled

• Implement configurable time period for storing Guest Order data

• Add security measures to limit guest actions, implement a guard to restrict Guest Token usage

• Decide and implement logic for Guest Token removal

• Guest order data is removed after set period

• Allowed actions can be performed with Guest token - e.g. priceOrder, validateCommitOrder, commitOrder, getOrder, etc

• Unauthorized actions can’t be performed with Guest token

Magdalena

User Experience and Interface

• Complete frontend flows for guests users

• Implement event tracking

• Remove 'Save Card' option at Payment step

• Add modal to allow users to ‘Continue as a guest’

• Adjust data displayed in the order confirmation page

• Add new events and assure data flow to mParticle and Amplitude

• Guest users can’t save card

• Guest user is able to add email in modal and place order for all service modes

• Confirmation page display correct information

Magdalena

Legal

• Required legal disclaimers for guest checkout are in place

• Create a static page with guest checkout terms and conditions

n/a

Melina

• Creating Guest Token- To place an order as a Guest users require to have be authenticated on our platform. In order to do that we need to create a Guest Auth token. We can’t follow the current path for collecting it because Guests don’t have accounts in Cognito and in the User DB entries.

• Preventing the guest user from seeing app content dedicated for registered users only

• Add a security layer limiting actions allowed for the orders with Guest token. Actions allowed for example: priceOrder, validateCommitOrder, commitOrder, getOrder, etc

• Add configurable time period of storing the Guest Order data in the database. Configure to 10 year for DE

• Added Modal to continue as a guest

  

• Adjusted data on the confirmation page

• QA Testing
  

TRX-908 - Getting issue details... STATUS F

TRX-959 - Getting issue details... STATUS F

TRX-941 - Getting issue details... STATUS M

TRX-947 - Getting issue details... STATUS M

TRX-957 - Getting issue details... STATUS M

TRX-956 - Getting issue details... STATUS M

TRX-912 - Getting issue details... STATUS W
TRX-1010 - Getting issue details... STATUS W

TRX-1053 - Getting issue details... STATUS

25 Oct 2023

WORK IN PROGRESS

• Accommodate new transactional email communication with AWS SES instead of Braze

• Decide and execute when guest token should be removed, so no other order can be made with that token to guarantee anonymity

• Prevent error appearing on the success page due to loyalty account request and price call

• Review the tracking event coverage and naming conventions

• QA Testing

TRX-1006 - Getting issue details... STATUS

TRX-880 - Getting issue details... STATUS

TRX-962 - Getting issue details... STATUS

TRX-1040 - Getting issue details... STATUS

TRX-1052 - Getting issue details... STATUS

TRX-1057 - Getting issue details... STATUS

01 Nov 2023

TO DO

• Create a new static page for guest terms and conditions and link it in the flow

• Change copy to “choose payment' instead of “add payment” at the /cart/payment page
  

  

• Save Card Option Removed at the Payment step

  

• Implement tracking events to flow to Amplitude

• E2E QA Testing

TRX-948 - Getting issue details... STATUS

TRX-1015 - Getting issue details... STATUS

TRX-949 - Getting issue details... STATUS

TRX-1003 - Getting issue details... STATUS

22 Nov 2023

TO DO

Ability to handle guest checkout orders in the direct tool

TRX-910 - Getting issue details... STATUS

• Melina clarified that refunds are managed directly via VR Payment’s dashboard so there’s no need to handle guest checkout orders in the Support Tool

• Orders are identified in VR Payment’s dashboard using the order time, store ID and order value

Allows guests users to create account after placing order

• After enabling loyalty, we could offer guests to create an account by displaying the points that could have been earned.

Allow guests users to opt in for email marketing communications TRX-1008 - Getting issue details... STATUS

• Allowing guests to opt in for marketing communications would allow us to increase our contactable user base

• However, this requires checking with legal to ensure compliance with GDPR and local regulations

Allow operators to enable/disable guest checkout directly in Sanity and manage other related configurations

TRX-1009 - Getting issue details... STATUS

• Initially the feature will be controlled via Launch Darkly to perform A/B testing

• Once the feature is stable, we will look at moving the configuration into Sanity

I am passing on an inherited legal requirements document just to verify that everything stated there has been recorded correctly and nothing is missing.

/wiki/spaces/TRX/pages/4267018713

Information on the user-related data we are storing and what tools have access to it. Please consider the attached file and let me know if your team has any concerns. I am still collecting more information on how the Snowflake data is currently used. I know that we must pass on the transactional information there, but I'm not yet clear on what are the other analysis run using this data. Please let me know if your legal team would like to provide some input here.

We also wanted to consult whether the following case is acceptable from the legal perspective:

At the beginning of the mobile ordering flow a user needs to input the delivery address. That address gets passed onto the cart step if their selected service mode is delivery. Once a user enters the cart step, that's when they'll have to decide whether they want to check out as a guest or sign in/register. Also, in order to display an estimated delivery fee, we are sending this address data to our aggregators in order to provide a quote. Additionally, we are storing this information in our database in the order entry.

• Store locator (user inputs delivery address)

• Cart step (delivery price is calculated, user decides whether to checkout as a guest or register/sign-in)

Question: May we pass the address data to the aggregators and store it in our database before a user decides whether they wish to be a guest or sign in and before they place an order? Are we allowed to use this data for the purpose of providing a delivery fee quote?If that's problematic, we can simply decide not to disclose the delivery quote at this step and redirect them again to the cart page with provided pricing after a user selects "Continue as a Guest" and agrees to the required terms and policies. However, this will add an additional step of "returning to the cart", which we had initially eliminated in the Guest Checkout flow. Please see the flow below and let me know your thoughts. We can also jump on a call to review this if that's helpful.

Confirmation to link only the data privacy policy not any other terms in the modal? What about the terms of sale?

Continue as Guest button