Originally Posted by
DrByte
The problem is that the store doesn't have record of the order, and the IPN handler is merely confirming the same fact that the OP posted initially.
Exactly, and this is/was reflected in these two lines.
Jun 01 2015 15:24 -- IPN NOTICE :: Could not find matched txn_id record in DB. Therefore is new to us.
Jun 01 2015 15:24 -- Breakpoint: 4 - Details: txn_type=unique ordersID = 0 IPN_id=0
The txn_type=unique is used to set the $new_record_needed flag, as such:
Code:
line#200 $new_record_needed = ($txn_type == 'unique' ? true : false);
The code then flows down to the midsream breakpoint..
line#261
Code:
ipn_debug_email('Breakpoint: 5 - midstream checkpoint');
if (!(substr($txn_type,0,8) == 'pending-' && (int)$ordersID <= 0) && !($new_record_needed && $txn_type == 'echeck-cleared') && $txn_type != 'unique' && $txn_type != 'echeck-denied' && $txn_type != 'voided') {
Which fails/passes the checks and produces the "since it is not new" output on line#262
Code:
ipn_debug_email('Breakpoint: 5 - Record does not need to be processed since it is not new and is not an update. See earlier notices. Processing aborted.');
break;
}
Originally Posted by
DrByte
Can you explain how you came to that conclusion?
Now the way *I* see it, is that the code should never have gotten to line#262 on account of the $new_record_needed being set (How could the record new and not new at the same time?).
Granted, I could be reading that code wrong. - multiple nots and ands tend to confuse me unless I write them myself ;-)
As there are no further debug outputs I am assuming the code has simply died or exited at this point, and the "new record" simply isn't being created. Either way, I didn't follow this path any further, on the basis that *something* was amiss to cause the contradictory debug output.
I then compared this code with the code from an older version of zencart and noted a number of differences in the testing/checking being performed, and "jumped" to the conclusion that the OP *could* be using the older code (that still has the same debug outputs), and if that were the case, then updating to the newer/current code could invoke a solution.
Originally Posted by
DrByte
I think the real problem here is that something is happening in the store's checkout operations, AFTER the PayPal steps occur, and that "something" is causing the PHP code to abort before the data is saved and emails are sent, etc.
This also makes a lot of sense. The only difference being that you are figuring something is *happening* to cause this, while my assumption is/was the $new_record_needed flag/test has somehow gone haywire causing the checkout operations to not realise that a new record needs to be created in the 1st place.
Originally Posted by
DrByte
Tests I'd do include going through a full checkout purchase and seeing what exactly does happen, as far as the customer sees.
And also, turn on the PayPal debug logging, and look at (and post) the PayPal_xxxxxx.log files for the specific transaction, not the ipn_xxxxx.log files.
As would I, but currently we/I only have the debug output presented here, and a relatively cursory look at the code that would produce the output results given.
Then not being able to make an accurate diagnosis (other than *something* is amiss) and assuming that
"PalPal Express checkout rev1.5.4" is the current/latest version of the module(s), the only other real possibility is back to the ipn_handler.
I 'ignored' (or didn't consider) the possibility of the problem being with the checkout functions themselves, on the basis that this was a 'sometimes' problem (I think I may have misread that though), or that if it was a problem with the checkout functions it would *probably* affect all all checkouts regardless of payment method, and probably it would be all the time, rather than 'sometimes'
Admittedly, I've had to make an assumption or two (and a little bit of guesswork) to come to this 'conclusion', but right or wrong, that is how I got there.
Cheers
RodG
Bookmarks