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

Many people over many versions have complained of a "Please Wait" scenario that occurs for certain onsite payment extensions that come with OpenCart. This is still true for v1.4.9.5. The payment modules that come with OpenCart that use curl for payment processing are:

- Authorize.net AIM
- Paypal Pro
- Paypal Pro UK
- Sagepay Direct
- Sagepay US
- Perpetual Payments

The Assumed Problem
The curl process should work fine assuming there are no connection or timeout issues. The code for failure scenarios was not added to these modules. Since there is no timeout set, it just keeps trying.

The Proposed Solution
The first step is to add a timeout for the curl connection. Both for the connect itself, and the time it takes to process the message. This should be an almost instantaneous process normally. So I've added a 10 second timeout to both. Additionally, if there is a connection failure, I've set it so that the ajax message response will show the error. I've also added a log write for the error so that it shows in the system error log.

I've attached the zip file here that contains the patched versions for each of those files. If you are using one of these files with OpenCart v1.4.7 through 1.4.9.5, you should be able to simply replace the files in:
catalog/controller/payment/<filename>.php
on your server with the patched ones here.

I cannot test these as I don't have the error, nor do I have accounts with these processors, so I am relying on the users to let me know if this works to address the issues or not. Please reply in this forum with your results, good or bad.

This should hopefully show an error on the payment page with some helpful clue to fix the real issue causing the problem.

Q

A LATER VERSION OF THIS PATCH HAS BEEN INCLUDED WITH v1.4.9.6!
DO NOT USE THIS PATCH IF ALREADY USING v1.4.9.6

Thank you for this. I will install it later today.

The customer that I mentioned in the other thread tried to place her order again, and wasn't able to. This fix is badly needed.

Qphoria, I owe you an apology. The customer sent me her credit-card number and I tried to place the order on her behalf, and I wasn't able to. It then occurred to me that I could place the order via my old shopping cart (which is still active). The old cart told me that the credit card could not be verified. So the problem was with the card. It seems that the only problem with OpenCart was that it returned a prompt which wasn't informative enough.

About the generic information that I received from OpenCart -- "The transaction cannot be processed at this time" -- vs. the prompt I got from my old cart -- "The credit card could not be verified" -- I am wondering if OpenCart is accurately relaying the information it is getting from PayPal (I am using PayPal Pro).

We never experienced this problem on our old server which ran on Ubuntu 8.04LTS. We transfererred the store to a new server running Ubuntu 10.04LTS which subsequently has a newer version of php/mysql and we are now experiencing this problem. We have fallen back to sagepay form for the time being to keep trading.

I can only assume therefore that this is a problem with compatibility with a newer version of php.

I have this problem now on OC 1.5 with PP pro

These patches are not in 1.5.0 as i was still waiting for feedback from people who were trying them in 1.4.x

Q,
The patch would help for any connect issue with curl, but more than likely (as I've found out myself) it's probably due to the server config with the host - probably a mysql connect_timeout is too low or something similar with apache, php, etc.

I had an recent, out of the blue type of issue with a client... on any order/checkout they would receive a confirm email from Authorize.Net, but their customers never saw the Checkout-Success message, so they kept submitting the same order and getting charged.

I installed the 1.494 patch (to be safe I bumped the timeout to 20), and then started digging around in the AuthNet admin. I knew it had to be a response return issue, so I looked under Settings > Direct Response and noticed the delimiter was set to not be required on a return response - set to NO, I changed to Yes. As the authorize_aim.php code requires comma delimited for return responses (set to TRUE).

Also, I found the Response/Receipt URLs - both the Default and Default Relay Response URL were set to: http://xxxxxxxxx.com/index.php?route=account/account

To be safe there, I left the default, and changed Default Relay Response URL to: http://xxxxxxxxx.com/index.php?route=checkout/success

I ran a few tests, and no more delayed return responses - it was lightning quick on checkout. So one or all of the things I listed above might have worked to fix the issue Hope that helps.

Every payment processor has an Admin Settings for each account, if anyone is having problems with return responses hanging, I suggest to start there first and make sure it's configured to work with OC or whatever cart used. After that check your server logs or ask your host to look into what's causing the hangs.

Here's some tidbits I copied from the AuthNet admin for reference below, they've got some good documentation on their site too:

Direct Response

If you use Advanced Integration Method (AIM) to submit transactions to the Payment Gateway, you can use the Direct Response settings to define the format of the transaction response returned by the gateway.

Direct Response Delimiter
Specify if the transaction response should be delimited, the delimiting character, and the encapsulation character (if needed).

Response/Receipt URLs
The Payment Gateway verifies the URL specified in the post string against the URLs in this list. If the URL provided does not match one of the values on this list, the transaction will be rejected. If no URL is provided, the Default URL value will be used.

boonjackmedia wrote:Q,
The patch would help for any connect issue with curl, but more than likely (as I've found out myself) it's probably due to the server config with the host - probably a mysql connect_timeout is too low or something similar with apache, php, etc.

I had an recent, out of the blue type of issue with a client... on any order/checkout they would receive a confirm email from Authorize.Net, but their customers never saw the Checkout-Success message, so they kept submitting the same order and getting charged.

I installed the 1.494 patch (to be safe I bumped the timeout to 20), and then started digging around in the AuthNet admin. I knew it had to be a response return issue, so I looked under Settings > Direct Response and noticed the delimiter was set to not be required on a return response - set to NO, I changed to Yes. As the authorize_aim.php code requires comma delimited for return responses (set to TRUE).

Also, I found the Response/Receipt URLs - both the Default and Default Relay Response URL were set to: http://xxxxxxxxx.com/index.php?route=account/account

To be safe there, I left the default, and changed Default Relay Response URL to: http://xxxxxxxxx.com/index.php?route=checkout/success

I ran a few tests, and no more delayed return responses - it was lightning quick on checkout. So one or all of the things I listed above might have worked to fix the issue Hope that helps.

Every payment processor has an Admin Settings for each account, if anyone is having problems with return responses hanging, I suggest to start there first and make sure it's configured to work with OC or whatever cart used. After that check your server logs or ask your host to look into what's causing the hangs.

Here's some tidbits I copied from the AuthNet admin for reference below, they've got some good documentation on their site too:

Direct Response

If you use Advanced Integration Method (AIM) to submit transactions to the Payment Gateway, you can use the Direct Response settings to define the format of the transaction response returned by the gateway.

Direct Response Delimiter
Specify if the transaction response should be delimited, the delimiting character, and the encapsulation character (if needed).

Response/Receipt URLs
The Payment Gateway verifies the URL specified in the post string against the URLs in this list. If the URL provided does not match one of the values on this list, the transaction will be rejected. If no URL is provided, the Default URL value will be used.

Thanks for the info. I am a little unclear on what you did then. Are you saying your authorize.net account needed to be updated? There is no code in the module pointing to the account/account path.

But aside from that, the module overrides those settings:
$data['x_delim_data'] = 'TRUE';
$data['x_delim_char'] = ',';
$data['x_encap_char'] = '"';
$data['x_relay_response'] = 'FALSE';

Even if those settings in your authnet account are set differently
And AIM doesn't use response/receipt urls since it is server to server.

My authnet account has never updated those fields..
my urls are empty/default
my delimiter option is set to FALSE, but since the code passes TRUE and COMMA, it comes back with commas
And my relay response is blank and the code sets it to false

I have no problem with the built-in authorize.net module

ok I was able to find a user with this problem and get access to their host. I've fixed the please wait now. The issue is that there is a curl error being returned but not captured, so it just throws an exception which causes a json error.

Now i capture the error and return it back to the browser. The issue in this case was that curl was not compiled with SSL so it couldn't access the https address that is used. Update your 1.4.9.5 files with the files in this zip and it should fix your issues, or at least give you the proper feedback.

Did you forget to attach the files or are you talking about the ones you posted on April 7th? I'm having this exact problem with PP Pro on V. 1.4.9.3 - will your solution work with this version? I gotta get this up and running asap! You're help is really appreciated

Thanks!!

The zip in the first post was updated. Yes it will work with any 1.4.8 or 1.4.9.x version

I used the patch a few weeks ago, which worked fine. I repatched it with the newer version of it, and the problem has returned. In retrospect i should have left it alone, but it appears the old patch was the working one.
This error has returned now

2011-06-20 8:13:52 - PHP Unknown: Function split() is deprecated in /var/www/vhosts/tilingsupplies.co.uk/httpdocs/catalog/controller/payment/sagepay_direct.php on line 233

I thought split was changed to explode in the previous patch?

davidthurston wrote:I used the patch a few weeks ago, which worked fine. I repatched it with the newer version of it, and the problem has returned. In retrospect i should have left it alone, but it appears the old patch was the working one.
This error has returned now

2011-06-20 8:13:52 - PHP Unknown: Function split() is deprecated in /var/www/vhosts/tilingsupplies.co.uk/httpdocs/catalog/controller/payment/sagepay_direct.php on line 233

I thought split was changed to explode in the previous patch?

I fixed it in sagepay but forgot sagepay_direct
Reattached fixed version of the zip.

This patch doesnt seem to work for me. I am using 1.4.8b and I still get the Please Wait spinning icon. The transaction goes through but it does not redirect. And Therefore doesnt remove the items from the shopping cart either. But it does record the transaction.

adesignl wrote:This patch doesnt seem to work for me. I am using 1.4.8b and I still get the Please Wait spinning icon. The transaction goes through but it does not redirect. And Therefore doesnt remove the items from the shopping cart either. But it does record the transaction.

The end result, regardless of getting a popup warning or not, seems to be because curl isn't compiled with openssl so it doesn't handle https urls. Contact your host and have them check that curl is compiled with ssl

Qphoria wrote:

boonjackmedia wrote:Q,
The patch would help for any connect issue with curl, but more than likely (as I've found out myself) it's probably due to the server config with the host - probably a mysql connect_timeout is too low or something similar with apache, php, etc.

I had an recent, out of the blue type of issue with a client... on any order/checkout they would receive a confirm email from Authorize.Net, but their customers never saw the Checkout-Success message, so they kept submitting the same order and getting charged.

I installed the 1.494 patch (to be safe I bumped the timeout to 20), and then started digging around in the AuthNet admin. I knew it had to be a response return issue, so I looked under Settings > Direct Response and noticed the delimiter was set to not be required on a return response - set to NO, I changed to Yes. As the authorize_aim.php code requires comma delimited for return responses (set to TRUE).

Also, I found the Response/Receipt URLs - both the Default and Default Relay Response URL were set to: http://xxxxxxxxx.com/index.php?route=account/account

To be safe there, I left the default, and changed Default Relay Response URL to: http://xxxxxxxxx.com/index.php?route=checkout/success

I ran a few tests, and no more delayed return responses - it was lightning quick on checkout. So one or all of the things I listed above might have worked to fix the issue Hope that helps.

Every payment processor has an Admin Settings for each account, if anyone is having problems with return responses hanging, I suggest to start there first and make sure it's configured to work with OC or whatever cart used. After that check your server logs or ask your host to look into what's causing the hangs.

Here's some tidbits I copied from the AuthNet admin for reference below, they've got some good documentation on their site too:

Direct Response

If you use Advanced Integration Method (AIM) to submit transactions to the Payment Gateway, you can use the Direct Response settings to define the format of the transaction response returned by the gateway.

Direct Response Delimiter
Specify if the transaction response should be delimited, the delimiting character, and the encapsulation character (if needed).

Response/Receipt URLs
The Payment Gateway verifies the URL specified in the post string against the URLs in this list. If the URL provided does not match one of the values on this list, the transaction will be rejected. If no URL is provided, the Default URL value will be used.

Thanks for the info. I am a little unclear on what you did then. Are you saying your authorize.net account needed to be updated? There is no code in the module pointing to the account/account path.

But aside from that, the module overrides those settings:
$data['x_delim_data'] = 'TRUE';
$data['x_delim_char'] = ',';
$data['x_encap_char'] = '"';
$data['x_relay_response'] = 'FALSE';

Even if those settings in your authnet account are set differently
And AIM doesn't use response/receipt urls since it is server to server.

My authnet account has never updated those fields..
my urls are empty/default
my delimiter option is set to FALSE, but since the code passes TRUE and COMMA, it comes back with commas
And my relay response is blank and the code sets it to false

I have no problem with the built-in authorize.net module

Yes the Authorize.NET settings had relay codes in there for use with an internal payment system they use. Yes those fields need to be blank, unless otherwise needed - not used for Opencart. The point was for people to check their Authorize Admin Settings, which could be causing issues with OC.

BTW the new Patch files attached to this thread are working fine.
I bumped the timeout settings to 20 (AIM default) for a few clients with crappy ISP service.

Mike

did not work for me

can it be curl_setopt($curl, CURLOPT_TIMEOUT, 60);

I'm experiencing the same problem. I never get past the spinning please wait notice, but the payment gets processed by Paypal. The shopping cart never empties.

I don't believe that this is related to curl being compiled with SSL. Here's my curl info:

#curl -V
curl 7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: GSS-Negotiate IDN IPv6 Largefile NTLM SSL libz

#curl https://api-3t.paypal.com/nvp
ACK=Failure&L_ERRORCODE0=81002&L_SHORTMESSAGE0=Unspecified%20Method&L_LONGMESSAGE0=Method%20Specified%20is%20not%20Supported&L_SEVERITYCODE0=Error

Opencart 1.4.8

Lyle

The issue for me was invalid JSON data being sent to the Ajax confirmSubmit() function in pp_pro.tpl. My store was setup with the following settings:

Admin -> System -> Settings -> Mail:
Alert Mail: Yes
Additional Alert E-Mails: <blank>

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: 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.

Because I've got a bad memory and may need this again in the future, here's how you can see what is being returned to the Ajax function. Add the "complete" section in the code below in the view/theme/xxx/template/payment/pp_prol.tpl file (not recommended on your live site): Hope this helps someone.

Lyle