Posted by nattyweb on Fri, Dec 15, 2023 - 8:58am --- Updated: Dec 15 '23 - 9:06am

I'm exploring having the feature to allow anonymous checkout with Ubercart.

I can see there are several settings under admin/store/settings/checkout/settings for Anonymous checkout but this doesn't seem to stop creation of an account when an order is placed. Is this a feature or am I missing something?

With "Enable anonymous checkout" ticked, on completion of an (anonymous) order an account is created and this is still displayed:

Your order is complete! Your order number is 11.

Thank you for shopping at My Backdrop Site. A new account has been created for you here that you may use to view your current order status.

Login to your new account using the following information:

Username: (username shown)
Password: (password shown)

Return to the front page.

I can clearly disable display of the messages using the Completion messages config, but must an account be created? What is the philosophy behind this?

Having an account created when one wasn't requested is clearly an issue if that anonymous customer returns, as a prompt to login with an account using that address or to use a different email address. This is not good behaviour for a customer that has deliberately chosen not to create an account. 

Most helpful answers

Hello there,

Hello there,

It's an interesting requirement that might uncover an entire new class of customer, so I wouldn't necessarily discard it so fast.

There might be a whole universe of use cases for a "disposable" user id that helps to power "one shot" purchases. 

On that comes immediately to mind is the case with vending machines - and there's millions of those devices in this world.  Japan is carpeted with them.

Let's separate the WHY from the HOW and see where this leads.  I have just provided a WHY (vending machine).  What can people think of in terms of providing the HOW, which might involve:

Creating a workflow and associated module(s) that sends those emails to a common user id called "public" to which all purchase emails are assigned, with a  bitbucket email address and null password (similar to entering /sbin/nologin in /etc/passwd for a user that exists, but who cannot log in)? 

What do people think?

g.

----

Comments

Fri, Dec 15, 2023 - 9:06am by argiepiano

Yes, Ubercart (and most commerce modules I knew of in Drupal) create an account when an anonymous user checks out. If an account with that email existed, then the order is assigned to that account.  

Is the password really shown? That's weird. That shouldn't be happening.  

Fri, Dec 15, 2023 - 9:08am by nattyweb

Yes the password is shown.

I can choose to not 'Set new customer accounts to active' but that doesn't help with the issue that a customer explicitly does not want an account, as they will see if they return to place another order at a later time.

Fri, Dec 15, 2023 - 9:35am by DrAlbany

Anonymous checkout, from my understanding, is so that you can place an order without having to create an account first.

The system will need to track the order and the user details including payment details so an account will be created.

Sun, Jan 07, 2024 - 9:49pm by Graham Leach

Hello,

I don't really think there is such a thing as "anonymous checkout" in the context you desire with respect to Ubercart as the person making a purchase with that platform must identify themselves as part of the payment and fulfillment process.

In Ubercart, going way back, the original meaning of "anonymous" really meant "unauthenticated" as it was originally developed to enable public browsing of an eCommerce site and the placement of items for purchase/fulfillment *prior* to the somewhat burdensome biodata/profile/password cycle (i.e. authentication), to make the site more "sticky" and the potential customer more likely to go the distance with the (onerous) authentication cycle and make a purchase. 

A byproduct of the checkout process was the creation of a user profile, along with an associated password, which (I believe) can be made a "one shot" deal, or even just a link with an immediate demand for a new password. 

That's how my site works (shop -> buy -> email w/ new password link).

As for a totally anonymous checkout?  That's an interesting idea, but it needs a business case / use scenario (like, for example, the purchase of a non-physical item [a video game skin or weapon] paid for via some exotic and anonymous payment method [monero] which is then sent to a burner email address or an email forwarder that is then destroyed, along with all associated logs).  That's a pretty rare (and potentially highly suspect) scenario.

The above was never conceived in the original Ubercart design brief AFAIK.  

To accomplish this, you would need to seriously hack Ubercart (hard) or design something new (easier, probably) and have it developed for you by separate teams of remote journeyman coders as a work for hire intellectual property where no one remote team holds the entire solution.

Or you can adjust your expectations to the fact that when someone uses Ubercart AND chooses to make a purchase, a profile and password is created as a byproduct of the purchase process because Ubercart assumes that the client in question represents return business.

g.

Mon, Jan 08, 2024 - 6:47am by nattyweb

Thanks Graham. I didn't mean 'anonymous' as truly anonymous, just in the Backdrop sense of not authenticated (ie no user account created). My personal view is I agree with the functionality; I am simply reporting a requirement of my customer based on feedback from their customers (the people using the website to purchase physical items).

I guess this is a kickback by a minority that don't like to have yet another account on yet another website. I don't feel like trying to solve that rather larger issue!

Mon, Jan 08, 2024 - 7:28pm by Graham Leach

Hello there,

It's an interesting requirement that might uncover an entire new class of customer, so I wouldn't necessarily discard it so fast.

There might be a whole universe of use cases for a "disposable" user id that helps to power "one shot" purchases. 

On that comes immediately to mind is the case with vending machines - and there's millions of those devices in this world.  Japan is carpeted with them.

Let's separate the WHY from the HOW and see where this leads.  I have just provided a WHY (vending machine).  What can people think of in terms of providing the HOW, which might involve:

Creating a workflow and associated module(s) that sends those emails to a common user id called "public" to which all purchase emails are assigned, with a  bitbucket email address and null password (similar to entering /sbin/nologin in /etc/passwd for a user that exists, but who cannot log in)? 

What do people think?

g.

----