[Patch] "Please Wait" for Authnet, PP Pro, Sagepay, Perpetua

lylet wrote: Without any alert emails set, JSON data was being corrupted by an error message when trying to send an email so the Ajax function could not properly parse the returned JSON data.

The fix for me was to edit the model/checkout/order.php file (around line #408) by adding the "if (strlen($email))" condition to the code below:

Code: Select all

		// Send to additional alert emails
		$emails = explode(',', $this->config->get('config_alert_emails'));
		foreach ($emails as $email) {
			if (strlen($email) > 0) {
				$mail->setTo($email);
				$mail->send();
			}
		}

If you're running anything newer that 1.4.8b you likely already have a similar fix in that file so you're probably dealing with a different issue than what I experienced.

OH wow, yea.. that was THE big bug of 1.4.8b.. no payment module would work due to that bug. Be sure you always read the associated "Official Bug thread for version xxxx" as that fix was promptly displayed in that thread as well as many others.

i have the spinning wheel " please wait " . I am 1.4.9.4

I used the patch but no luck . Can anyone help?

I know why we were getting stopped

Paypal Pro has a filter for fraud managment. My partner activated and it seems thats was causing the problem with the site

We removed it and it works fine now

I hope this helps you guys.

Can we have a patch to allow paypal pro to work with the filter for fraud managment in the future?

I have no idea what paypal uses to trigger the fraud measure. If you set me up with FTP access and reenable the fraud filter I can try to debug it.. but Paypal should be sending something back if that is the issue.

I am still seeing the "Please Wait" message on the Paypal Pro UK.

I have looked to see if curl was working by creating a test file in php and it is.

I am unable to see anything in the logs it appears nothing happpens which is most confusing.

Is there anyway to output what is happening maybe add some debug steps to see if the request is getting sent.

Very strange. I updated to 1.4.9.6 as I noticed the curl fix.

Any help would be greatly appreciated in debugging this matter as I am sure other people would like to track it down too.

Thanks

Matthew

After much digging around it seems that the livehelp module I had was conflicting with the Paypal module.

I only noticed it when I opened up firebug to look see if the actual request was being sent to paypal which is wasn't.

I did see a livehelp module running though so stopped this script and requests seem to be going through now.

I just need to make sure my details are correct!

Thanks for the info matt... seems there is still some figuring out to do with some sites

It appears that I too still seem to be struggling with the setup of paypal website payments pro UK.

I will post the errors to that though on a new/more related thread as I now can see it communicating with the server.

Thanks

I kept having the issue with the spinning circle and customers getting duplicates after the response back from Authorize.net would hang. I found the patch here in the forum that was made to catch the cURL errors, and it started displaying time out errors or error code 28, but the customers were still having the issue. I finally found out that my server didn't automatically add my sites to the cURL group so it wasn't even active for me. No wonder I had issues...all is fixed on my end.

We were running 1.4.9.4 for about 3 months without any issues. Yesterday, we started having the spinning ajax wheel with the 'please wait' dialog.

We're using Authorize.net AIM. We have ssl support enabled for Curl.

After reading through several forum posts and double and triple checking everything, I decided to upgrade our system to 1.4.9.6.

Now we have the latest 1.4.x branch but still have the same problem. However, we do get notified of the specific error.

Namely...
Any suggestions on the next step I should take?

I found the following information on the auth.net site. http://developer.authorize.net/faqs/#rrcauses

When Authorize.Net sends a transaction response to your server, the payment gateway waits 10 seconds for a response. If Authorize.Net does not receive a response from your server in 10 seconds, the payment gateway server will time out and display an error page. The first thing you need to check is the order that your script executes. It is very important that something prints to the screen before any other process is started. If your script prints to the screen first, Authorize.Net will recognize that you are receiving the information. The most effective method would be to PRINT the headers, and a line of text such as "Processing, please wait."

To resolve relay response time outs:
Verify your script permissions and the ability to accept an HTML POST.
Check that the script is not completing other functions before writing to the screen, such as writing to a database or sending e-mails.
See if there are different processes that are used in your script for approvals, declines or errors. Check each process to be sure that they will write to the screen before any other functions.
Check if your script is using redirects immediately upon receipt of the response from our servers. Redirects are discouraged because they can potentially interfere with the process.
Note: On occasion, timeouts will occur that are outside of the control of your script or our servers. Typical reasons for these timeouts are Internet traffic, merchant server overload or malfunctions, or Internet routing issues. Depending upon your server location and what route is used to send data, it is possible that you may occasionally receive a time out message.

The most frustrating aspect of this issue is that the site was working fine for 3 months with no problems. I have checked with the hosting provider and no changes were made on the server. I have checked with the auth.net account and no changes were made there either. Neither did anyone make any changes to the site. The issue just popped up which confounds reason because SOMETHING HAD TO CHANGE for this to break. I just can't figure out what the change was.

Yes, namely something that is causing an error. There was patch in the forums that would at least display the error code instead of just the spinning circle...it's an error catch script for cURL. Even though you have cURL turned on, it still may be giving you errors and at least the code might give you some direction.

Well, I have some good news and some bad news. The good news is that we no longer have the issue. The bad news is I can't concisely explain how the issue was fixed.

I do not have direct communication with the hosting company but rather I have been going through another developer who currently hosts the site. According to him, he contacted the host company and had the issue escalated because in addition to our problem, other sites on the same server were also experiencing strange delays and errors. For instance, WordPress would fail if you tried to install a plugin from within the WordPress control panel.

According to the developer, the hosting support guy made a DNS change. I can't get further information on what kind of change was made. However, it might have been they simply restarted the local dns daemon... or possibly flushed the dns cache... which a restart does also.

Now I venture into an area I don't know much about. Curl evidently will cache dns lookups. Maybe there is something that is causing the dns cache to become unresponsive? Or it times out too quickly? Again, this is a grey area to me.

If others are having a similar problem, try restarting the local machines dns daemon.

Other possible things to try.

In the authorize_net.php file in /catalog/controler/payment/ around line numbers 101 through 110 maybe try adding these options to see if you get any different results.

Set CURLOPT_DNS_USE_GLOBAL_CACHE to false.
or possibly...

try different lengths for CURLOPT_DNS_CACHE_TIMEOUT. (I believe 120 seconds is the default.)
Whether those will work or not, I have no idea. However, I believe taking a closer look at DNS as a potential culprit could lead to finding the solution.

UPDATE v1496.1 in first post

I've updated the file to use the 1.4.9.6 updates plus increased the timeout from 10 to 20, but really if you are hitting 10 it is more likely that you will never connect due to firewall or curl errors. This version is the same as the files in 1.4.9.6 but only has the doubled timeout, no need to update if already running 1.4.9.6

We're still having a problem on 1.5* with this...

Please help, my client is considering moving away from OC and i really dont want them to

NB it seems to affect mac users on safari more than anything?

For us it was a server issue and not related to OpenCart. If it's an option, you might try another server.

Did you figure out what it actually was though?

I'd prefer to get my current server changed than move everything to a new one!

Thanks man!

I don't specifically know because I had to go through a third party and did not talk directly to the hosting company. Supposedly they cleared the dns cache on the hosting machine or the dns cache on the server that hosted dns for our particular server. Essentially the dns lookup was failing and was taking too long to complete.

That was the issue..?

Hmm..

It turns out that I did need this fix. Thank you.