Skip to main content

Guest Customer Checkout

Overview​

Problematic - Auth0 & MAU (Monthly Active Users)​

Auth0's monthly price is defined by the amount of unique number of MAU by tenant.

This means that if we include our guest customers into Auth0's User Pool, every guest checkout performed will count as +1 on the MAU calculation.

We've checked the previous year's guest customers on rapha.cc, and the number can get high enough to become a problem in our monthly bill.

Proposal​

This document explains the Auth0 proposal on guest checkout both in current Hybris & future CommerceLayer solutions.

The main idea is to use the Hybris-CommerceLayer guest checkout capabilities, where the guest customer is saved as an internal user on both framework's databases, and not including them into Auth0's User Pool.

Only when the customer decides to register, this will be included in Auth0.

Guest Checkout in Hybris​

The following diagram (available in Gitlab repo) represents the guest checkout flow in Hybris

Hybris Checkout

  1. New pre-checkout page to give the available options (Login, Signup, Guest)
  2. If guest chosen, the process remains as-is:
    • Email captured on 1st step
    • Customer temporary created in Hybris
  3. Option to register after order is placed - This would trigger the signup via Universal Login
  4. Customer created in Auth0's User pool
  5. (and 6) On the callback to Hybris, we have a different scenario from the signup flow, where we transform the temporary user previously saved as a registered one

Guest Checkout in Hybris​

The flow described on the diagram (see Gitlab) represents the guest checkout using CommerceLayer

CommerceLayer Checkout

  1. New pre-checkout page to give the available options (Login, Signup, Guest)
  2. If guest chosen, redirect to CommerceLayer hosted checkout (depending on the requirements, this might be our own fork, self-hosted)
    • Customer provides an email
    • Order is placed under a prospect-guest user
    • If there's yet another purchase as a guest user, with the same email, the customer appears as “guest - repeat”
    • See below for further information regarding types of users in CommerceLayer
  3. Option to register after order is placed - This would trigger the signup via Universal Login
  4. Customer created in Auth0's User pool
  5. On the callback to FE's React app, we will also have a different scenario from the signup flow, sending a request to CommerceLayer's API to transform the current guest user to registered

A view into CommerceLayer's Customers​

It is worth mentioning that CommerceLayer has a very flexible approach for guest users. From their own documentation:

Prospect customers are those that didn’t place any orders yet. A prospect becomes ‘acquired’ when they place their first order. Customers with more than one order become ‘repeat’ customers.

This means that every customer is part of two subsets, attending to their

  1. Status of their registration (guest / registered)
  2. Orders placed (none / one / more than one)

In the example below, felix.guest@rapha.cc is a guest customer that hasn't placed any orders yet

CommerceLayer Types of Users

And in the next one, for example, john.kilpatrick@rapha.cc is a registered customer that has placed 3 orders so far, while fabrizio@commercelayer.io is a guest user with more than one order placed.

CommerceLayer Types of Users

Final thoughts on CommerceLayer guests​

To summarise, CommerceLayer allows guest users to place orders, and if the same email is used for subsequent orders, this is grouped under the same guest account (Hybris doesn't).

If the customer decides to become a registered one after n previous placed orders, we would be able to bring their order history back.