1

I'm currently developing an Ecommerce application and am trying to figure out how best to add a 'guest checkout' feature. The 3 main models that I am wrestling with to add this feature are Address, User, and Order. An Address needs a User, and an Order needs both an Address and a User.

For our guest checkout we don't want to force someone to create an account but with the current schema, that won't work.

The only two options I can think of right now are:

  • Create a guest account in the Users table and every guest checkout will create a new Order and Address tied to that.
  • Make the Address and Order FK constraint on the User be optional.

Has anyone had experience with this or can think of a better option?

Thanks

  • What makes a user a 'guest'? If you are shipping them a physical item that they pay for and emailing them a confirmation etc then whats missing? a password? choose a random one and email it to them – Ewan Apr 13 '18 at 11:30
2

Both options will work well, with the following inconvenience:

  • The guest account requires different behavior: the application must ensure that a guest user shall not be able to see or modify previous addresses, in order to ensure the privacy of the other guests.
  • With both options, you'll end up acumulating multiple variants of some guest addresses, thus inflating unnecessarily the database over a longer period of time.
  • With both options, your application logic will also have to manage the history problem: once an order is shipped, the shipping address should no longer change, because it could create inconsistencies (tax calculations, shipping cost settlement, claim management if for example a registered user doesn't receive an order that was shipped a some time ago but subsequently updates the address of the account). This would require some versioning logic for addresses.

However, if you look closer at the lifecycle of the persistent objects, another alternative emerges:

  • in reality, there are two different kind of addresses:
    • the current preferred addresses that a registered user can manage (including deleting obsolete ones)
    • the shipping addresses used for an order and that have to be kept untouched once the order was shipped
  • use the account and (preferred) addresses only for registered user.
  • use the order with an optional FK constraint to a registered user account
  • add shipping name and address fields in the order (in the header if you have multi-item orders):
    • For unregistered users you manage the address directly in the order,
    • For registered users, you copy the selected address into the order.
    • Once the order status is "shipped" you do no longer allow to change the order address fields
  • If after some years you want to clean old orders (or if you have to because of the GDPR), you just throw them away and you'll automatically get rid of all the useless embedded one-time shipping addresses. The preferred shipping address continue to live their own life: these are active addresses linked to (in principle) active accounts.
  • 1
    First, thank you for your very thoughtful and concise answer. I think I get what you're saying. I just want to clarify your third proposal (the one that sounds the most reasonable to me) there would be not FK relationship between an Order and an Address, just the needed fields. That frees up me having to even having to create an Address for a guest user. Brilliant! Thank you so much for your answer. – Rnice4christ Apr 12 '18 at 21:23
  • note: you should keep all the 'obsolete' billing (and prob shipping) addresses to prevent fraud by a user ordering stuff and then changing their address to a fake one. – Ewan Apr 13 '18 at 11:28
  • @Ewan yes indeed. To simplify my answer, I assumed billing address is shipping address. This is not the case in B2B or in B2C when gifts can be ordered). Anyway, as soon as shipping and billing are in the scope. The address used at the time of the business event need to be kept unchanged as evidence in case of litigation, for accounting, and for tax reporting (e.g. tax schemes may vary depending of country/state/region). Mandatory retention period can even be required by applicable laws. – Christophe Apr 13 '18 at 12:02
  • sounds like you know your stuff to me – Ewan Apr 13 '18 at 12:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.