Notice from PayPal - IPN Failing - Cannot Find Problem

[Dianne]

This email contains information on everything I have done to try to identify and resolve the problem described below.

We are using zen-cart version 1.5.1
Apache server with PHP v5.2.17 and MySQL v5.5.46-cll
The web host is Total Server Solutions L.L.C.

This concerns an existing store that has used PayPal for a number of years with no problems. The PayPal module is PayPal Express Checkout.

We got a notice from PayPal this evening stating the following:

Please check your server that handles PayPal Instant Payment Notifications (IPN). IPNs sent to the following URL(s) are failing:

http://obsessionwithbutterflies.com/...in_handler.php

If you do not recognize this URL, you may be using a service provider that is using IPN on your behalf. Please contact your service provider with the above information. If this problem continues, IPNs may be disabled for your account.

Thank you for your prompt attention to this issue.

This email from PayPal was sent at 10:05 PM Pacific Time.
We had one order come through which we assume is what triggered the email from PayPal (details below):

Payment Type: PayPal Express Checkout (instant)
Timestamp: 2015-12-27T14:10:23Z
Payment Status: Completed

NOTE: This is not a new store and previous orders did not trigger this notice from PayPal (example: there were orders on Dec 20^th and 21^st that did not trigger this notice). All payments on the site are through PayPal.


I checked includes/modules/payment/paypal/logs and the most recent file in it is dated 12-20-15 3:07:00PM. There is no file for the date in question (12-27-2015).

I checked the store’s myDebug-xxxxxxx.log and the most recent file is dated 12/25/2015 12:19:00PM. There is no file for the date in question (12-27-2015).

I ran the test using extras/ipncheck.php:

The test returned these results:

IPNCHECK.PHP - Version 1.3.9
CURL RESPONSE RECEIVED - Communications OKAY
IPN TESTING - Response Received via CURL -- COMMUNICATIONS OKAY


IPN TESTING - Confirmation/Validation response with fsockopen(): FSOCKOPEN() RESPONSE RECEIVED - Communications OKAY

Default method likely to be used for communications is: CURL, with the fallback method being FSOCKOPEN if possible.

Script finished.

I ran a test using extras/curltester.php and the results were:

You submitted the following fields and data:

Array
(
[field1] => This is a test
[statuskey] => ready
)
Data validation

Good

Your server IP address is: (removed)
Your system identifies itself as: Zen Cart(tm) - CURL TEST

Array
(
[url] => "http://www.zen-cart.com/testcurl.php"
[content_type] => text/html; charset=iso-8859-1
[http_code] => 200
[header_size] => 177
[request_size] => 212
[filetime] => -1
[ssl_verify_result] => 0
[redirect_count] => 0
[total_time] => 0.070407
[namelookup_time] => 0.028448
[connect_time] => 0.04826
[pretransfer_time] => 0.048338
[size_upload] => 37
[size_download] => 5797
[speed_download] => 82335
[speed_upload] => 525
[download_content_length] => 5797
[upload_content_length] => 37
[starttransfer_time] => 0.070339
[redirect_time] => 0
)

I do not see any problem with these results. Can you please help me to trouble-shoot to identify and fix the problem? I do not know why PayPal is saying IPN failed.

Thank you for anything you can share.

Dianne

[lhungil]

It appears you (or someone on your behalf) has installed a commercial module from Magnetic One to generate alternative URLs. It appears this third party module may be the source of the problem (trying to access "ipn_main_handler.php" results in a 404 with a message of "The requested URL /m1_seourls.router.php was not found on this server.").

I would suggest contacting the commercial vendor for support (or migrating to another module providing alternative URLs).

[frank18]

Suggest you do a test order and pay via PayPal with a CC which is not attached to your PayPal account. Then pls report back if the order has gone through in a normal fashion.

[mc12345678]

Another thing to add to lhungil's post is that the uri of the email doesn't include www. But when trying to access the site www. is applied. If it is expected that the site operate with www as the prefix for all addresses, then would suggest updating the paypal ipn link as well.

When I tried the ipn_main_handler.php using www as a prefix to the uri, there was no error message... Problem would be solved for paypal, can't say for anything else...

[lhungil]

Good eye (as usual) mc'numbers!

[frank18]

Another thing to add to lhungil's post is that the uri of the email doesn't include www. But when trying to access the site www. is applied. If it is expected that the site operate with www as the prefix for all addresses, then would suggest updating the paypal ipn link as well.

When I tried the ipn_main_handler.php using www as a prefix to the uri, there was no error message... Problem would be solved for paypal, can't say for anything else...

Yep, spot on!

[Dianne]

Wow - that was a keen observation on the www! Thanks.

I'll also say that the problem has not repeated itself when sales came through today.

In addition, we did testing ourselves on the PayPal checkout as suggested by frank18 and everything went fine. After making payment through PayPal, we were returned to the store's "thank you" page with no problems. No more warning emails were received from PayPal. We have not made any changes to anything, just going through the testing, so we don't know why the problem has not occurred again.

I'm scratching my head since we weren't able to duplicate the problem, yet clearly the www scenario is an indication of a problem, or at least a discrepancy that could cause a problem.

We do have the Magnetic One module installed. It's been there for years with no issues and no-one has made any changes to it. However, the www seems to have explained - at least in part - why the error message may have appeared in the first place.

I can see that the URL in the Paypal module DOES have the www, BUT, it says "if there is not already a URL specified, set the URL to [the one with the www]". What I don't know is if there was already a URL set in PayPal that does NOT have the www. I'll have the client look into that tomorrow.

And yet, that would still be strange to have had no problems with PayPal for years, until the one yesterday with the warning message, and then no repeats of the problem - even though we have not changed anything. I don' know how to explain that.

Thank you everyone for your input. It looks like the cause may have been identified. I'll post again with any final information that I learn.

If you have any thoughts on what I shared today, I would appreciate knowing them.

Thanks!

[barco57]

Dianne, is ZenCartRetailer dot com your website?...you might want to remove it from your signature here on the forum. When I clicked on it, the browser won't let me go there, instead I get a "Reported Attack Page!" in firefox, in Chrome I get blocked also and see "The site ahead contains malware"

[frank18]

Wow - that was a keen observation on the www! Thanks.

I'll also say that the problem has not repeated itself when sales came through today.

In addition, we did testing ourselves on the PayPal checkout as suggested by frank18 and everything went fine. After making payment through PayPal, we were returned to the store's "thank you" page with no problems. No more warning emails were received from PayPal. We have not made any changes to anything, just going through the testing, so we don't know why the problem has not occurred again.

I'm scratching my head since we weren't able to duplicate the problem, yet clearly the www scenario is an indication of a problem, or at least a discrepancy that could cause a problem.

We do have the Magnetic One module installed. It's been there for years with no issues and no-one has made any changes to it. However, the www seems to have explained - at least in part - why the error message may have appeared in the first place.

I can see that the URL in the Paypal module DOES have the www, BUT, it says "if there is not already a URL specified, set the URL to [the one with the www]". What I don't know is if there was already a URL set in PayPal that does NOT have the www. I'll have the client look into that tomorrow.

And yet, that would still be strange to have had no problems with PayPal for years, until the one yesterday with the warning message, and then no repeats of the problem - even though we have not changed anything. I don' know how to explain that.

Thank you everyone for your input. It looks like the cause may have been identified. I'll post again with any final information that I learn.

If you have any thoughts on what I shared today, I would appreciate knowing them.

Thanks!

Pleasure, as always! Happy New Year Dianne.

[mc12345678]

Wow - that was a keen observation on the www! Thanks.

I'll also say that the problem has not repeated itself when sales came through today.

In addition, we did testing ourselves on the PayPal checkout as suggested by frank18 and everything went fine. After making payment through PayPal, we were returned to the store's "thank you" page with no problems. No more warning emails were received from PayPal. We have not made any changes to anything, just going through the testing, so we don't know why the problem has not occurred again.

I'm scratching my head since we weren't able to duplicate the problem, yet clearly the www scenario is an indication of a problem, or at least a discrepancy that could cause a problem.

We do have the Magnetic One module installed. It's been there for years with no issues and no-one has made any changes to it. However, the www seems to have explained - at least in part - why the error message may have appeared in the first place.

I can see that the URL in the Paypal module DOES have the www, BUT, it says "if there is not already a URL specified, set the URL to [the one with the www]". What I don't know is if there was already a URL set in PayPal that does NOT have the www. I'll have the client look into that tomorrow.

And yet, that would still be strange to have had no problems with PayPal for years, until the one yesterday with the warning message, and then no repeats of the problem - even though we have not changed anything. I don' know how to explain that.

Thank you everyone for your input. It looks like the cause may have been identified. I'll post again with any final information that I learn.

If you have any thoughts on what I shared today, I would appreciate knowing them.

Thanks!

Well, good to know that there have been no changes performed by the store owners/yourself, but when third party plugins get thrown into the mix, even if nothing changes with the software that was installed by the same owners/users, there are plenty of other things that could cause a bump in the road. FWIW, the file that lhungil identified originally appeared to be off of the domain's root not off the store. If you can verify that the file does currently exist there, then that may suggest something...

Also, and maybe this was to address some other "issue" I find it odd that if arrive at the domain that clicking on a link there takes me to a sub-folder for the store rather than keeping on the domain. One reason I find this odd, is because if I enter the domain with the file: m1_seourls.router.php, I get a not found with a 404 file not found. But.. If I try to access that same file from the "store" directory, I get a blank page... Modify the filename slightly to an incorrect name and I get some form of custom search box:

404 Page Not Found

This page may have moved or is no longer available.

Please try one of the following:

• Check the Web address you entered to make sure if it's correct.
• Try to access the page directly from the Store Home page instead of using a bookmark. If the page has moved, reset your bookmark.
• Enter keywords in the Search box and click the Search button. Or, browse through the many categories available at Store.
• If you are searching for a Help page, click the Back button on your web browser and select another Help page link or try entering different keyword combinations to find appropriate help topics.

Search: * Hint for webmaster: You can edit this text by editing m1_seourls.error.php in root directory of your store.
You will be redirected to the store search in 20 seconds

So kind of indicating that there could have been something else entirely outside of the control of the store owner that could have been modified, was in the process of being updated, or just didn't connect depending on how all of that additional software works... But hopefully although the problem hasn't appeared again, that the ipn settings on paypal have been modified to match the web address needed to access the ipn_main_handler.php file from the internet regardless of the internal file folder structure. It kind of is a central part of the store operation (at least collection of funds). :)

FWIW, I just tried to go to the address provided by PayPal in the OP, and it still is not resolving... It may be that they have "taken a break" from providing notification of the issue, but I just tried the same path and am still receiving the same error message.

As I recall when I have setup multiple sites for testing and then "moved" the one that was identified in PayPal it did take some time before they began sending me messages as they would try/retry for a period of time until finally saying "hey we need your help"...

Hopefully though, that setting can be easily modified there may still be something that is acting as a security barrier to not forward to the rewritten version of the file... Dunno, guess more to follow... :)