Hi,

We've been using v7.4.8 for at least a month and over the last 2-ish weeks we've been getting multiple customer complaints/queries that their orders are not getting a confirmation e-mail from the cart. Most orders go through fine. Some customers say the error page is displayed, suggesting a timeout in the payment handshake. We are seeing this with both Stripe (SCA-Ready API) and PayPal Checkout. I'm _guessing_ that it might be affecting 10% of our orders (sometimes the e-mails are sent as normal, and sometimes customers don't query it as we send them separate tracking etc e-mails later, when we process their orders, so we may not be getting a respresentative idea of the %age).

I've tried contacting Stripe support and referenced specific transactions that we've drilled down into. They say they can't tell precisely where delays are happening, whether on our side or on theirs, or in-between. E.g. I'm not sure if there is any dependency on how long the customer takes to fill in their card details once the Stripe payment form has been displayed, which would seem silly as people will often take some time to get the card number etc, or if it's all down to the 3DSecure etc etc processing after the customers have submitted the form and while our cart is waiting for the response.

Looking at Stripe's Dashboard you can trace the timestamps of a lot of events and the ones where customers have complained _seem_ to show Stripe responding in 1-2 seconds at every stage. I need to look into that more closely as you can also see all activity on the separate trace of the Stripe WebHook. The ones I've checked so far suggest that is also coming back very fast. I've seen one event sequence that had about 40 seconds before the 3DSecure process completed, but the '200 OK' response had already gone back to us.

I'm not sure if there is any useful logging we can enable within the cart to help us trace this, please, as it is the cart that seems to be timing out? It is difficult as it is an intermittent issue perhaps affecting <10% of our orders.

We've looked for an explanation on our server itself, e.g. CPU load issues etc and not found anything significant. (We're using a Windows Server host with IIS and one incident happened to have an IIS thread 'recycle' request around the time of the error, but increasing the time limit on that hasn't fixed the problem. We use MySQL and that also seems fine, with no other traffic apart from this store. It is a shared VPS but we've not noticed any unusal latency issues with other access to the site.)

It could be a wider Internet loading issue. The systems might be all fine but the glue across the Internet may be struggling...?

Thanks in advance for any suggestions!

Steve.

Pragmasis Limited
https://SecurityForBikes.com

Hi Steve
As it seems that the orders are all processed ok, it could be that it is the connection to the mail server that is the problem when trying to send the confirmation email. Could that be the case do you think? What have you got for the email setup?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Hi Vince,

Sensible idea but I don't think that's likely as it's a locally-hosted MailEnable server (i.e. on the same box/virtual machine) as our website and we don't think there are any loading issues on the machine.

If people simply entered the wrong e-mail address for themselves then that could go some way towards explaining it, obviously, but the relevant ones have all been OK (plus several of them have said they've been getting confirmations coming through OK from PayPal, for example).

Besides, it's not just missing e-mails as some of the customers have reported seeing the error screen displayed by the cart. That's what's making me think it's not an e-mail-related issue but the cart is not able to close the handshake with Stripe/PayPal within the time limit.

Is there any logging we can enable in the cart to flag up the timing on this?

I know I can change the IPN timeout on PayPal (in ppconfirm.php IIRC?) - Is there a similar setting for Stripe? That could be a bit of a temporary hack but it might give us a clue if it seems to remove/reduce the complaints coming in? ...And we could go from there, perhaps.

Thanks,

Steve.

Pragmasis Limited
https://SecurityForBikes.com

Hi Steve
In inccart.php if you search for this line...
if(callcurlfunction('https://api.stripe.com/v1/checkout/sessions', $sXML, $jres, '', $errormsg, FALSE)){
It's the last parameter "FALSE" where a timeout could be set, for instance...
if(callcurlfunction('https://api.stripe.com/v1/checkout/sessions', $sXML, $jres, '', $errormsg, 30)){
...would set a 30 second timeout. But not having a timeout would mean the connection would never time out, so it's not like you are increasing the timeout time.
You say some customers get an error screen, but does that have any meaningful information on it? Or maybe in the server log files, do you have any information about what the actual error is that is occuring?

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Hi Vince,
Thanks, and sorry for the slow reply. Understood.
No, sorry, only a few of the customers have mentioned any kind of error and, typically, they've not recorded any details beyond 'an error'. Grrr, I know.
I've not gone through the server logs, yet. I'll keep it in mind but, very interestingly, we've had no more reports of this issue from customers for the last week.
Who knows! It was feeling like some server performance or wider Internet latency problem so, perhaps whatever it was, has been resolved. We've not done anything on our server since minor tweaks plus reboot that did not fix it (i.e. problem reports continued after that). It was interesting that it was happening on Stripe and on PayPal.
We'll keep an eye on it and try to extract more useful info from any customers that report it in future.
Apologies it's one of those frustrating/unexplained ones :-(
Thanks again,
Steve.

Pragmasis Limited
https://SecurityForBikes.com

No problem Steve. Let me know if we can help.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Well, just after saying it all seemed to have settled down, we had two more customer complaints today and one of them was from an IT chap. Handy, as he was able to confirm several aspects, at last!

The cart is fine and it has been caused by a mail server behaviour change. Looking back through the SMTP logs I can see it happened on 1st May around 4pm as that is when the errors started. I didn't do anything to change the server or cart config but perhaps our ISP did something as 127.0.0.1 was subsequently disallowed via PHP mail(), which is what we have always used. "This mail server requires authentication..." was actually happening on every customer order confirmation after that, but only a small percentage of people noticed ;-) I didn't even notice myself with the testing I did as I'm on a local address as far as the mail server is concerned so it allowed order confirmations to come through to me ;-)

I've added an exception for 127.0.0.1 to the mail server SMTP outbound config so that should fix it.

...I don't know if you'd recommend switching to PHP Mailer instead of the mail() function? I don't really like having hardcoded passwords dotted around but otoh I don't want to make the server more vulnerable to spammers etc.

This seems like a solid diagnosis, at last.

Sorry for giving you a wild goose chase, as we'd say.

Thanks,

Steve.

Pragmasis Limited
https://SecurityForBikes.com

Hi Steve

quote:

---

...I don't know if you'd recommend switching to PHP Mailer instead of the mail() function?

---

Well probably yes, that would be a good idea. But then again if you've got a workaround now then is it necessary?

quote:

---

As it seems that the orders are all processed ok, it could be that it is the connection to the mail server that is the problem when trying to send the confirmation email.

---

Just sayin'.

Vince

Click Here for Shopping Cart Software
Click Here to sign up for our newsletter
Click Here for the latest updater

Hi Vince,

Ha, yes, I did remember you suggested the link to the mail server :-) Since the server itself was local that didn't seem likely, but the mail server to the outside world was a different matter. I was derailed by some customers mentioning an error page, but they were vague and it seems likely there was no error displayed at all. I should have taken that with a pinch of salt. Sorry! :-)

It turned out that it was the ISP guys that fiddled with the mail server setup, when I was moaning at them for removing the DNS PTR record. They added the PTR but apparently did some other fiddling that shouldn't have been necessary. Fix one thing; break another! Grrr. Hey ho, hopefully all working properly again now.

Thanks again,

Steve.

Pragmasis Limited
https://SecurityForBikes.com