Anonymous checkout and additional fields
 

Hi,

I set up 2 additional fields on my checkout page --

1) ship to residence checkbox

2) Purchase Order ID (if any)

These fields show up in the register_fields DB for 'registered users' - I do post processing with this information which appears for 'registered users' only.

I could 'force' registration and solve my problem, but want to have it available for 'anonymous' checkout customers as well.

Has anyone else had to solve a similar problem and suggest how to do so?

Thanks in advance for any ideas.

Re: Anonymous checkout and additional fields
 

Unfortunatelly QT decided in 4.4.x that anonymous customers are not customers and their info should not be saved in customers table(s). See this - http://forum.x-cart.com/showthread.php?t=56877&highlight=anonymous+bug. To me this is very serious flaw

Re: Anonymous checkout and additional fields
 

Thanks Steve for the info.

Re: Anonymous checkout and additional fields
 

Steve,


I wholeheartedly agree with you since we used to tell (in Terms) that if you gave us your email we could send you a monthly email, this included anonymous purchasers, and this really grew our mailing database and often resulted in sales. However I wonder if QT changed this because people were doing exactly what I was doing, and they thought anonymous customers didn't like it. As a an often "anonymous customer" on other peoples websites (one time purchaser) I would agree I don't want emails from every company I've ever purchased from.

So, in summary, I can see a need for both approaches to anonymous customer data being stored. Ideally it would be an option in the XC admin on how to handle it. That way if it suits your business model and customer demographic you could have it available.

just my two cents.

Re: Anonymous checkout and additional fields
 

There is a newsletter box (es) to opt-in for emails. This option (emails or not) should always be opt-in and not opt-out - some comanies are doing it as opt-out and this is wrong. So this solves the I want/not emails issue.

As for the anonymous customers info not being saved - again - a customer is a customer no matter what; their info should be saved. I don't think QT left it out because some XC stores use it to send out emails - after all how you operate your store is up to you. I think they just ran into a problem with the new way of using emails are username so just decided to drop off the anonymouos customers. Jon's way of saving the data works just fine.
I hope QT will reconsider this and put it back in. My opinion - serious flaw in the way XC works.

(at least QT has an oportunity to hear different points of view)

Re: Anonymous checkout and additional fields
 

I also agree with Steve - this was not an ideal change. A customer is a customer. A registered customer gets more capability to look at order history and not have to re-enter data, but from the shop owner's perspective, they are mostly the same. (Getting permission to use their email for purposes other than the placed order is another matter entirely.) The software can distinguish between the two in ways that make more sense.

I thanked Steve's post in the referenced thread. I am not sure how others who support this can weigh in on this functionality.

---

Re: Anonymous checkout and additional fields
 

I agree with all the comments in this post -- we need this functionality back. If there is a concern to 'not' include anonymous users as 'customers',let the admin decide and maybe a general setting could be implemented to

1) if NOT checked, don't add anonymous users to the customer table and

2) if checked, include them into the customers table with an Anon prefix like before.

I know suggested solutions are always 'obviously easy' when in reality, there can often be a lot of complexity --

Just adding my vote to the others for providing this support again.

Re: Anonymous checkout and additional fields
 

+1. Just wanted to add that I would like anonymous users to be saved just like a registered customer. Our old 4.1.6 cart worked that way and we were surprised it was changed when we upgraded to V4.4.5.

It would not do us any good if it was restored in the latest XC release; it needs to be a patch for older affected branches too.