PayPal not being VERIFIED when using fsockopen fallback

[edwardaux]

Hi ZenCarters,

I am helping a friend diagnose a problem with her store. She has been running with the store for many months accepting paypal payments with no problems. Starting yesterday, she found the following symptoms for Paypal orders:

• Cart is built-up and checked out with no probs
• Payment appears to go through Paypal with no problems
• User is redirected back to the shopping site successfully, however, they do not get given an order number.

I have turned on debug for the paypal module, and I have observed the following:

• I can see the inbound IPN request from Paypal arriving
• We get an error using https with curl, so fall back to using fsockopen
• The POST vars that are being sent back appear to be sensible, and look to be valid

However, the last few lines in the debug log are:

Feb 13 2012 15:59 -- IPN INFO (fs) - Confirmation/Validation response 

8
VERIFIED
0


Feb 13 2012 15:59 -- Breakpoint: 1 - Collected data from PayPal notification

Feb 13 2012 15:59 -- IPN WARNING :: Transaction was NOT marked as VERIFIED. Keep this report for potential use in fraud investigations.
IPN Info: 


Feb 13 2012 15:59 -- IPN FATAL ERROR :: Transaction did not validate. ABORTED.

The response from Paypal appears to be returning VERIFIED (not sure what the leading/trailing 8 and 0 are though), but for some reason ZenCart is deciding that it is invalid?!?

One other thing that I noticed that occurred at 2:30am yesterday morning (the problem started occurring after that) was the following error message in the logs:

PHP Warning:  PHP Startup: Suhosin Extension does not officially support PHP 5.2 and below anymore, because it is discontinued. Use it at your own risk. in Unknown on line 0

I've also noticed that the virtual server was restarted about that time, so I presume that the virtual hosting service may have upgraded something (I have an open ticket with them to find out what they did). Even so, I am having trouble reconciling the apparent output from the Paypal debug with the actual behaviour of ZenCart.

Any thoughts would be much appreciated. Note that we aren't using Express or PDT.

Thanks a lot.
edwardaux

[DrByte]

Yes, it looks like the server administrator upgraded various things on the server, and has introduced some incompatibilities. It's very possible that those incompatible configuration changes may be causing the scripts (that you said worked just fine before the server changes) to fail.

Best to notify the hosting company of the problems they've caused you.

If you choose to post a reply here, please be sure to answer all the questions in the Posting Tips section of the Reply page.

[edwardaux]

I am still debating with the hosting provide (they initially denied that the had performed any upgrades, but after I pressed them further they admitted that they did, in fact, perform a PHP upgrade, but the problem is with my code because it is 'old' - sheesh!)

Anyway, that discussion notwithstanding, I have a suspicion that they have installed a version of PHP without curl and SSL installed. One thing that puzzles me though, is that even if it falls back to the fsockopen approach, the data being returned from Paypal looks weird. All the doc that I have read indicates that an IPN postback response is supposed to be a single line saying 'VERIFIED', but as you can see from my previous post, it actually returns three lines:

8
VERIFIED
0

The ZenCart code that checks the status expects only a single line, and ultimately, this is why the order is not getting verified. So, while I am arguing with the hosting provider, my question is whether there is a valid case where Paypal is allowed to return three lines. For now, in the interest of getting back up and trading, I have changed the ZenCart code to use strstr() to look for VERIFIED, et al, but I am curious as to what may be going on here.

Any thoughts? Thanks a lot.

[DrByte]

It is possible that the fsockopen fallback implementation isn't properly collapsing the received input into a single line string before checking the response.
We'll inspect that for a future update. But do note that CURL is a much more reliable means of doing the communication, and should not be needing to fallback on fsockopen.

[edwardaux]

So, in case anyone is following along at home, it turns out that there was a bug in WHM EasyApache that caused Curl to be compiled in, and not CurlSSL.

A quick recompilation by the hosting provider, and everything is working again with ZenCart. It'd be nice if the hosting provider did a bit more testing before slamming it into prod, but anyway...

As a side note, for the ZenCart devs, it might be worth looking at the way the fsockopen fallback works. In my case, it definitely doesn't work due, as DrByte suggests, it not parsing the Paypal response correctly (I am still not sure why Paypal is returning three rows).

Anyway, thanks for your help and for a great product.

[DrByte]

Thanks for confirming that your root problem was fixed by having the hosting company properly configure their server.

As for the fsockopen fallback, we'll look into it in the future.