We are creating a marketplace app where guests can buy items sold by various vendors, in one order. Once the sellers receive the order, they can fulfill it on their seller dashboard which allows them to put in tracking info. This triggers an email to the customer!
This flow works fine for a User who has an account on our site. However, we have been receiving feedback that it would be nice to have a guest checkout, and that creating an account may deter some people from purchasing. We were able to allow guest users to add items to cart, and can easily build a way for guests to input critical information like customer address, name and email. However, given Bubbleâs temporary user policy, this data would delete after 3 days since they are not a registered âUserâ.
This works for the initial purchase, seller notification and customer confirmation email. However, if the seller ships and inputs the fulfillment information for the items after 3 days for a temporary user, the database would have already deleted the the info to auto fill address, email and name- leading to an incomplete fulfillment flow and probably a lot of confusion on both the seller and customer side.
Is there any way to address this? Is the only way to have the user log in?
You can assign a temporary password (and save it on their usertype) for guest buyers and use create account for someone else to create their accounts before the checkout.
This flow will fix the problem, and if they used the same email to sign up in the future use that temp password to update their login info with the new entered password.
Hi! thanks for the response, I really appreeciate it
A couple questions:
what would be the best way to assign a temporary password? Is this assigned to âCurrent Userâ or is this created after thr âCreate Account for someone elseâ action?
my understanding is that when using the âCreate account for someone elseâ function, we will need to input the Current users email, that we can have them input into a field. Is this correct?
Is there a specific way to link a temporary password to an account we crrate for someone else?
in the scenario that they try to sign up in the future, wont they just be blocked from signing up because the account alrrady exists? Is there a way for them to get their temporary password and go through the password reset process themselves?
Do not do this before checkout, since, after the user is navigated to the Stripe checkout (assuming you are using stripe for payment processing) it is possible for the user to cancel and not proceed with the checkout, so in that event you will have created data in the database unnecessarily and used some WUs in doing so (small amount yes, but things add up and so keep the strategy of a penny saved is a penny earned).
Instead rely on a Stripe webhook to indicate the payment is successful and then create the account in the backend. User doesnât need to be on the app at all. In order to create the account with correct details ensure you are capturing from the webhook the email used in the Stripe checkout.
You do not need to create a temporary password and save it to the user data type if you do not expect the user to return again and have a need to sign into the site for any reason, but if you do expect them to return and use the site for things related to tracking their order, then you would want them to be able to login, so you could take the approach of saving a temporary password on the user data type, or use the workflow action for assign a temporary password and email it to them, or have a default temp password for all guest users and send an email with a link that will take them directly to an area of the app where they can change their password and have the current password (ie: temp) be pre-filled and then they can just add their own password using the change password workflow action and related UI elements needed. Alternatively, can use the magic link login, but those only last for up to 24 hours I believeâŚbut regardless, lots of different ways to skin the cat in regards to getting the guest user to be able to login to their account if needed.
One thing as well, since the user can return without ever logging in and may purchase again, still as an unknown guest, you can in the backend workflows ensure that if the creation of a new User fails because the email, which is using the email inputted into Stripe checkout, already exists, then use the checkbox for return user if user exists so you can associate all necessary data to that existing âguest userâ.
Make sure when the webhook is received, after creating account in that backend workflow that you email the user the account details and method you choose for how they can login and change their password.
You also want to anticipate the possibility that a user will purchase from stripe checkout and be redirected back to the app after successful payment, so you can based on the URL parameters you add for successful payment redirect cause a signup/login popup to appear to get them to signup on their ownâŚIn an app I have built the webhook trigger will have a 2 minute delay to give the user that chance on the page to signup via the popup and if after 2 minutes they do not then the backend workflow will sign them up
HI! I will try out this method. We actually have a âyes/ noâ Has been Ordered field that works only once the stripe transaction is successful, so we could use that as a similar condition for âsigning someone else upâ
Should I be able to see a user I have signed in using the âCreate an account for someone elseâ step in my backend User data base? I have put together a trial guest check out using this method, but do not see the new user created on the app data. Not sure if this is because it is still considered an anonymous user when they have not logged in personally? If it is still considered an anonymous user, will the data delete again in 3 days?
Additionally, your advice about potential returning users is super helpful. Does the âcreate account for someone elseâ automatically assign them a temporary password? Or does that still need to be an extra step?
I was able to get a user created in my database using the âCreate an Account for someone elseâ
However, now I am also running into an issue where Stripe is throwing an error for the âCharge the Current User stepâ where I get an error saying âAn email is needed to complete this transactionâ.
I looked in the language tab of bubble to understand where this warning was coming from and found this
My workflow for Charging a User points to âCurrent Userâs emailâ. However using the debugger, it seems that field is empty. I am not sure if that is privacy reasons- but my current privacy settings let others see email since the seller will often need it, so I donât think this is the issue.
Is there an extra step I need to take to let bubble know that this newly created user is âCurrent Userâ?
Sounds like you are using the Stripe Plugin. The plugin has limitations not imposed by Stripe but by how Bubble built the plugin. If you connect to Stripe directly through API you can set it up to work as you need.
Ah I see- we would have rewire quite a bit on our site to use the API, but it may be worth it!
Appreciate your input. In lieu of this we set it up where we have a âGuest checkoutâ where people input their info, we assign them a temporary password, âsign the user upâ , âlog the user inâ and then put the input info into their respective fields. We will have to add messaging that clicking âSubmitâ will automatically create an account- but at least it is low effort on the userâs end. We will alo have to be clear that when the user logs in again they will have to use reset password to override the temp password
I think we may switch over to API if we see that people are resistant to the idea of having an account (even if they didnât have to do work to physically create one)
Do you know if there is any way to manually set the âemailâ field to my guest userâs email using the âMake changes to current user stepâ? Since I create an account for this guest email, being able to then assign that email to the âCurrent Userâ could solve a lot. This would allow me to have the user in my database, without having to formally log them in or sign them up.
I think just putting the messaging on the checkout that an account is created is fine, and that way you do not need to rebuild things now for use with the API. Just add in functionality to send them an email, direct link to a change password page in app (doesnât need to be a dedicated page - in my apps I send to dashboard where auto popup with change password) auto fill the temp password.
Thanks so much for all the input and help. I think we will do it as you suggested for now, and explore the possibility of using the API as we scale up! Appreciate all the time you have taken to answer our teamâs quesitons
