Hey, I'm due to launch a tiny e-commerce store for a client, it is a very simple Laravel app using the shipped auth, single product purchase, redirecting to Stripe Checkout.js for transactions... typically after picking a product, a user will be asked to log in if they're not already authenticated... if they aren't a member they'll obviously need to register... all purchasing related routes are behind the standard auth middleware.
In the background, it is a simple One (User) to Many (Orders) relationship.
Now the client has asked for guest checkout and I've been researching a few different approaches, I can't make up my mind and would love some community input
Guest users are created as actual users and are actually authenticated, maybe with an is_guest flag against their account... If they're recognised as a guest then we can create conditionals to hide authenticated content (such as buttons to log out) and also write custom auth middleware that satisfies "is authenticated but is a guest" ... This approach is the least amount of work and is great for migrating the guests to actual users (simply by setting a password at the end of the order process)... but muddles up the frontend by trying to hide authenticated content from guests.
Opening up the checkout processes by removing the auth middleware and allow orders to be created by non-users... we would need to remove required from the user_id field on the orders table. A nullable email field would be added to the orders table to allow for assigning orders to guests.
Create a separate guests table to keep users and guests completely separate, the orders table could be adapted to a polymorphic relation allowing both Users and Guests to create orders, keeping orders assigned to an ID of an actual person. If a guest creates an account we can migrate their data into the users table.
Option 3 seems to be the best approach. Any thoughts on this?
All of your options seem sensible with pros and cons as you've described. One consideration would be that you are planning on storing a guest users email address to correlate guest users orders together.
As a guest I probably dont want to give you this information (otherwise they would probably register) I just want to go to checkout, put in my card details, delivery details, etc so my order is processed. If I come back to buy again I dont care about my previous orders.
You could then have a single user (maybe named guest) that cant be logged into but could be used for your user_id foreign key in orders or make it nullable but then you cant use native database protection that you normally get for things like cascading deletes.
The other option would be to have 2 order tables. One for registered users and another for guest purchases.
I would move your purchase routes outside of the auth middleware rather than having custom middleware for guest/ authenticated users.
Feels like blasphemy posting a link to another Laravel tutorial here on the Laracasts forum, but... Checkout the below link to a YouTube video from the series "Laravel E-Commerce". This specific video is called: Allow Guest Checkout, so hopefully it will help.
Thanks for your input, I probably should have said its a digital product so the email address would be a fairly standard request.
I definitely need to be able to identify an entity against an order, it's not about anonymity, it's about quickly checking without the hassle of creating an account.
It's a good point that they probably don't care about past orders, this helps remove any complexity about assigning their orders at a later date.
Thanks for this it has some good points but doesn't really touch on the design of the database, I guess I'll need to go back a few videos for that. Still has some good points to consider.
@lunah - from the additional context you have all the information needed to create a user in your users table even for guests (bar randomly generating a password).
I would urge you to take a ride in a paying visitor to your site. Assuming I am a guest and I buy some content but then lose it, how do I get it back? If you sent them a link to the content what prevents them sharing the link with friends losing you potential revenue?
What I would consider is when a guest buys something you very clearly state here is the download link but it's a one time download unless you want register (and implement a say to expire the link)... if you do you can download as much as you want but we need to verify your account. Then you can use the built in functionality
