Page 1 of 1

Bad Customer Email Domain Causes Order Confirmation to Fail

Posted: Thu Jun 16, 2016 7:37 am
by mkp007
If a customer enters an email address where the domain is not valid and then "confirms" the order, the "processing" alert is presented and then disappears and then that is it. The confirmation page is not displayed and the contents in the cart remain. It appears to the customer that the order did not go through when in fact it did.

Take for example: mark@comcast_.net where it should be mark@comcast.net

As the order is processing, it conducts the payment transaction, and then I assume it tries to send the customer an email confirmation. For whatever reason it stops there. Is there a confirmation step in the PHP that is failing. Note, when this happens, I do not get the confirmation email of the order. So it quits right when it tries to send the email to the customer. Also note, mark44444xxxxx@gmail.com will work because the domain part is valid.

Any ideas are greatly appreciated.

Re: Bad Customer Email Domain Causes Order Confirmation to F

Posted: Thu Jun 16, 2016 8:00 am
by IP_CAM
This one could be of help, a little at least:

Email confirmation, free, OC v.1.5.x:
This vqmod extension is going to add email confirmation field under email field
when user register account,register when checkout and guest checkout.
http://www.opencart.com/index.php?route ... n_id=16956
---
Image
---
Good Luck!
Ernie

Re: Bad Customer Email Domain Causes Order Confirmation to F

Posted: Thu Jun 16, 2016 1:48 pm
by mkp007
Thanks Ernie. This will help. I will see if it is compatible with my current extensions.

I'm curious if anyone else with 1.5.6.4 can replicate this error. Note, that for "In Store" payments (such as cash or check) it will go to the confirmation page (but no emails sent), but for credit card payments, it fails.

I would like to know why it fails and if the code can be tweaked to give the customer a message at confirmation that the email they entered was invalid and to print the receipt for their records.

Or better yet, check the email domain after it is entered. Such as: nslookup –type=mx gmail.com

source: http://www.labnol.org/software/verify-e ... ess/18220/

This is pretty easy through command prompt. Simply type "nslookup", then "set type=mx" and then any domain. You can see below the results of testing "comcast_.net", "comcast.net" and "gmail.com". Pretty straight forward, if you get a "non-existent domain" then notify customer to enter a valid email address. In summary, modify the extension that compares the email address, and if they match, perform a nslookup –type=mx domain.com to see if the domain is valid.

C:\Users\Mark>nslookup
Default Server: dsldevice.attlocal.net
Address: 192.168.1.254

> set type=mx
> comcast_.net
Server: dsldevice.attlocal.net
Address: 192.168.1.254

*** dsldevice.attlocal.net can't find comcast_.net: Non-existent domain
> comcast.net
Server: dsldevice.attlocal.net
Address: 192.168.1.254

Non-authoritative answer:
comcast.net MX preference = 5, mail exchanger = mx1.comcast.net
comcast.net MX preference = 5, mail exchanger = mx2.comcast.net
> gmail.com
Server: dsldevice.attlocal.net
Address: 192.168.1.254

Non-authoritative answer:
gmail.com MX preference = 10, mail exchanger = alt1.gmail-smtp-in.l.google.COM
gmail.com MX preference = 30, mail exchanger = alt3.gmail-smtp-in.l.google.COM
gmail.com MX preference = 40, mail exchanger = alt4.gmail-smtp-in.l.google.COM
gmail.com MX preference = 20, mail exchanger = alt2.gmail-smtp-in.l.google.COM
gmail.com MX preference = 5, mail exchanger = gmail-smtp-in.l.google.COM