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:
line#200 $new_record_needed = ($txn_type == 'unique' ? true : false);
The code then flows down to the midsream breakpoint..
line#261
ipn_debug_email('Breakpoint: 5 - midstream checkpoint');
if (!(substr($txn_type,0,8) == 'pending-' && (int)$ordersID <= 0) && [B]!($new_record_needed[/B] && $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
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;
}
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.
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.
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
