Feature: Verify Email

[scottcwilson]

Inspired by https://www.zen-cart.com/showthread.php?227024-Bounced-emails-Now-what-Suggestions-appreciated

Possible components:

• configuration flag in Admin > Configuration > Email (verify email? True/False).
• upon login (and perhaps throughout shopping experience) customer sees a banner saying "your email has not been verified."
• for unverified users, Resend verify email link in My Account area
• Admin > Customers > Customers indicates if email is verified.

[Zen4All]

Is this compatible with OPC, and modules like OPC, where a email address is not stored in the customer table, when using guest checkout?

[scottcwilson]

OPC (or any other mod) would need to be updated to interoperate with this, or people would have to be told not to use this feature if they modify their sites to not store email addresses.

[scottcwilson]

I suspect though that shops that use Guest Checkout would be unlikely to also want email verification.

[drbyte]

Considerations:

Zen Cart doesn't require email validation during checkout because that creates a barrier to completing checkout. Same reason for not requiring highly sophisticated password restrictions when creating an account (since no personal financial details are stored anyway.)

Unless the store is also a "membership site" which requires "regular login in order to access purchased content", such restrictive validation isn't critical for checkout.

It can certainly be well-argued that if the customer provides a non-working email address (especially a typo) that a "relatively important" component of the order-fulfillment experience is hindered.

So .. the point I'm making above is that "requiring an email verification process before allowing checkout" is probably undesirable.

In terms of "requiring email verification" in order to have ongoing access to something the store provides (which is outside the scope of Zen Cart core features, unless you're talking about "previous orders"), perhaps a plugin that offers the email request/response verification (essentially a double-opt-in of sorts) may be of community interest.

Another consideration might be a real-time-email-checker that tests whether the email "looks good" (simple pattern matching) or "actually is good" (live external verification service) or maybe "looks problematic" (pattern matching such as a blacklisted set of patterns the storeowner maintains) could be of interest. There are numerous 3rd party services which provide email-checking in real-time via a widget you can integrate into your site. If they simply refuse form-submission until valid then there's nothing much that needs changing/altering in ZC core code (save for maybe tweaking/specifying a form-id or field-id in a template file).

[wiztechinc]

Though I like the concept of a real time email checker, I just haven't seen this problem very much where it's been a major issue. Yes, folks make typos, leave spaces in (has that been corrected so they can't?), and more frequently actually can't remember what email address they use to begin with. But I do like the concept of verifying an email but allowing the order to go thru. I have had that exact experience in the past week. Not verifying shouldn't disallow anything but folks are getting used to the idea that verifying is necessary - and the more important places require it - such a financial institutions/companies. Helps to weed out fraud. Especially since I have had someone actually sign me up for all sorts of things in the past with my email address.

[dbltoe]

Just as the forum recently had problems with Yahoo Mail, we go in cycles with folks from sbcglobal, AT&T, AOL, Yahoo, etc not being able to see our hosting emails. In the majority of the cases, the emails are simply dropped in the bit bucket with no notification to either us or the customer. Often times, this happens in spite of us taking over the screen of the customer and going through the whitelisting process as them. Neither we nor the customer can attain success any better than half the time.

In our WHMCS for hosting, we require e-mail verification and have increased the requirement to the point of not fulfilling the order until the email is verified. So far, every order placed with an unverified e-mail has never come back with, "What happened?" Maybe we need to inform them that their failure to verify will automatically enroll them in AMWAY. :rofl:

It would be nice to be able to get around this but, we've come to know "it ain't gonna happen".

Seems to be one of those flowers that just ain't gonna make it in the bouquet,

[drbyte]

I'm going to recommend that this feature be handled via a plugin if it's really needed. There are many observer hooks that will allow this to be easily implemented without changing core code. (db changes might be needed to track special additional data requirements, but that's easily handled in a plugin also)

[torvista]

My experience is that I added a second email before I launched our shop. Since "everything" hinged on a correct email, it seemed a no-brainer to ensure it was correct.

But, still people get it wrong as they cut and paste the wrong address.

All that happens is we see bounced emails (so we call them) or they call us to say they haven't had any order confirmation. And since it turns out to be their fault, they can hardly complain.

So, is it worth "annoying" people that their email address is incorrect at the moment of registering?

Unfortunately yes, but not because I care about people getting their emails (I've got the order already, that's what matters), but because absolutely everything possible should be implemented to prevent support calls or time wasted editing numbskulls wrong email addresses. Once you scale up to a busy shop, it all matters.

[scottcwilson]

see #3845 as a partial mitigation against fat-fingering the email.

[torvista]

Recently there was an encouragement to add duplicate email entry to the core, https://github.com/zencart/zencart/issues/4803#issuecomment-1128786356

I feel that is old hat these days and think that the format of the email should be checked by javascript as the user types it in. Doing as much as possible to highlight an error when the user is editing any field is a fundamental aspect to good form design.

[lat9]

Doesn't adding the 'type="email"', as is done for the contact_us page, provide at least some of the functionality requested?

[torvista]

Yes, html5 uses a built-in regex for type email, but it will only flag a error on submit. I'm going to look at implementing a real-time check with a more comprehensive regex to flag an error while the user is still focussed in that field, and drop the email confirmation I have currently.