PayPal transaction data missing suddenly

I have version 1.3.9e and our site has been running for a long while with no changes.
Today I noticed that I was not getting the usual email notifications for orders.
I figured it was the usual Godaddy issues and ignored it because they typically correct such issues.

Later, I went in and viewed some of the transactions in Zen Cart and all the Transaction information normally populated in a table below the three buttons "Payment +" and "Purchase Order" and "Refund $" , there was no transaction data.
Instead it reads "No Payment Data Available"

I looked at the Zen Cart logs and found nothing.
I logged into PayPal and the transactions are there and marked "Completed". For some reason PayPal data is not being reflected back into Zen Cart

Any Ideas?

Sounds like you've changed which PayPal module you're using, and are no longer using Express Checkout, thus getting no data because it has no credentials to use for looking up the data.

As I mentioned, no changes have been made...none, zero.
There is no doubt it was a godaddy server issue. As it all started working the second I hit the submit button on the original post. The php mail was down as well. What was odd was that zen could still process the order. Not sure how a server can be half up.

I was wrong, the problem has not been fixed. A block of orders will have transaction data and then a block will not.

Our Zen had not been updated in a while, so I upgraded from 1.3.9d to e to f, g, and now we are running 1.3.9h. (wow, that was a lot of work) Unfortunately the problem persists. I'm not sure where to start or what to look at. What is involved with regard to data from PayPal being sent back and inserted into the database?
The database knows that the transaction occurred, by the presence of the order itself, but contains no PayPal transaction information.

I spoke with Godaddy twice and they see nothing. They did notice that I had hit my maximum allowed emails for the site for the day. Not sure how that could affect PayPal transactions

If you're talking about the gray section in your Admin orders screen, that information is pulled from PayPal's servers in real-time. It is looked-up on-demand. It uses the same credentials to login to PayPal as are configured in the Paypal module used when the payment was made on that order.
In this case I must assume you're referring to Express Checkout because that's the section of this forum that you've posted in.
And with PayPal Express Checkout, in that gray section it is not displaying any data stored on your server. It relies on being able to ask PayPal's server for the latest info. I suppose if the server is running slowly then it may not be able to display the data, in which case that section will not display any useful info.

It has nothing to do with emails. But if you're hitting email thresholds then you might have other problems going on with rogue activity on your server. http://www.zen-cart.com/wiki/index.php/Recovering_From_Hacks

Yes, I'm referring to the two side by side gray tables. When the data is present both tables are there. When the data is not, only the left table is there (but no data), and the right table is completely missing.

Are you saying that each time I look at an order, that data is pulled in a new?
Let's say there are two adjacent orders; order 1000 and order 1001. Each time I click details for order 1000 the Orders page has no transaction detail in the grey table. Each time I click details for order 1001, it always has the transaction detail. I have tried it over and over and the results are the same. So it does not appear to be anything related to server load.

Looking at my Payment modules, I have only "PayPal Express Checkout" installed

Yes, every time you look at it, the data is pulled in "a new".

If it's not showing the data, then it's unable to do the lookup, for whatever reason.

If there's something especially critical you need to see, all the info is available by logging into your PayPal account separately and looking at your transaction history. That's always your reliable fallback even if your store doesn't have the correct transaction number to do its lookup.

We are logging into PayPal to confirm the transactions are valid and completed.
But something has become intermittent. This morning all transactions were missing data. Then just after noon, transaction data was working again. At this point I have no leads

Any help would be appreciated.

The problem persists. A group of consecutive unrelated orders will have transaction data and then a group of consecutive unrelated orders will not have data. The groups can span from a few hours to say nearly a day.
For those orders which have no data, we will not receive an email Order confirmation from Zen Cart. We always receive the payment notification from PayPal.

split63:

For those orders which have no data, we will not receive an email Order confirmation from Zen Cart. We always receive the payment notification from PayPal.
That sounds like a problem is occurring at the end of the order process, and your store is aborting some of its final steps like recording the full response from PayPal and sending out the emails etc.
That sort of thing is not unsurprising if you're using addons which break normal operation, or if you've your customizations have introduced bugs which are causing the code to fail.
First steps: http://www.zen-cart.com/content.php?124-blank-page
Next steps: http://www.zen-cart.com/wiki/index.php/Troubleshoot_-_Diagnosing_Obscure_Issues
And of course, you said you're using v1.3.9e when there were bugfixes posted in 1.3.9f, 1.3.9g and 1.3.9h that would benefit your site, including several PayPal-related fixes.

Dr Byte.

We have had FEC and Super Orders installed for about two years.
However, we recently updated the site from 1.3.9d to e, to f, to g, and now we are at 1.3.9h.
Perhaps its something in one of these updates that is incompatible with the previous installs of FEC and SO?
I checked the recent log files and there is nothing of interest.

Also, I would expect a hard failure. The problem with the interaction/update theory is that half the time the transaction work and half the time they do not. And they begin working spontaneously.
Also, customers are not complaining.....and customers always complain. If they were seeing something as they finished the checkout they would surely email us.

Tracking down intermittent issues is always challenging. But the key is in determining what is unique to the group that work fine vs the group that don't. Lots of possibilities there. Plenty of things for you to investigate.

Dr Byte,

I have been looking for a pattern; Time of the day, international or domestic, order size and/or order amount. I see no pattern. Its been down for hours and only moments ago started working. Its maddening.
I could insert debug statements into key files to try to determine how far the transactions are getting in the Zen files. Which files should I look at and what are the key insertion points that such statements would be telling?

split63:

Its been down for hours and only moments ago started working.
Huh? "down for hours"?
This is the first that you've said your site has been down.
I must be missing something.

By down I mean that the transaction data is missing on all transaction during this period.
Poor choice of words

http://www.zen-cart.com/showthread.php?61199-Debug-Logging-PayPal

Thanks for the link. I turned the logging on and waited to capture both a good and bad transaction. Where bad is one which is missing transaction data on the order page. Looking through the logs, I see that the data that is missing on the order page is in the logs. The area of the logs were I noticed a problem is the sixth line below extracted from the bottom of the ipn_xxxx.log:

The error is: "Could not find matched txn_id record in DB. Therefore is new to us. "
This line, which is inserted between breakpoint 3 &4 is not present on a "good" transaction.

Aug 04 2012 11:01 -- CURL response: VERIFIED
Aug 04 2012 11:01 -- IPN INFO (cl) - Confirmation/Validation response VERIFIED
Aug 04 2012 11:01 -- Breakpoint: 1 - Collected data from PayPal notification
Aug 04 2012 11:01 -- Breakpoint: 2 - Validated transaction components
Aug 04 2012 11:01 -- Breakpoint: 3 - Communication method verified
Aug 04 2012 11:01 -- IPN NOTICE :: Could not find matched txn_id record in DB. Therefore is new to us.
Aug 04 2012 11:01 -- Breakpoint: 4 - Details: txn_type=unique ordersID = 0 IPN_id=0

If you're using Express Checkout, then the IPN logs will only reflect symptoms, not actual causes, because the IPNs which are sent for Express Checkout transactions are expected to find the completed transaction in your store in order to match up. The stuff you quoted simply confirms that the EC module wasn't able to complete the required tasks once the customer was done confirming payment at PayPal. You still need to track down what's different in your store vs all the other stores which work fine including those installed fresh with no customizations.

For each transaction there are 5 log files;
2 - PayPal_Curl_xxxx.log
2 - paypalwpp_Paypal_Action_xxxx.log
1 - ipn_xxx.log

Which of these would you think would be the one to focus on?

Also, once I got the logs, I turned off logging. Oddly enough the PayPal_Curl_xxxx.logs keep coming. They seem to be stuck on. THe other logs stopped.

I also compared the full install of 1.3.9h(source) to my site with winmerge.
I found files on my site which are not in the source....these all related to file copies, and to previously installed FEC and super order files.
The only file missing that was in the source and not on my site was

includes\modules\pages\tell_a_friend\header_php.php

Perhaps I missed it in the change list or maybe it was missing. Regardless, my site does not use the tell_a_friend feature.

I doubt if Super Orders is to blame here since it is an admin plug in and not used during transactions..
However, perhaps FEC is to blame? It is certainly involved in the check out process....though I'm not clear that it has anything to do with PayPal data. THe thought is that FEC worked fine with 1.3.9d, but with all the changes from d to h, maybe FEC is having a strange interactions. Again, nothing makes sense since it works fine about 60% of the time.