mc12345678:
Not sure this is the location where this goes, but seemed like it. I haven't gone and done any test transactions, but looked like the right place.
So, if you open the ipn_main_handler.php located in the store's main directory go find (in ZC 1.5.1) line 454 that in this area looks like:
if ((int)$new_status == 0) $new_status = 1;
if (in_array($_POST['payment_status'], array('Refunded', 'Reversed', 'Denied', 'Failed'))
|| substr($txn_type,0,8) == 'cleared-' || $txn_type=='echeck-cleared' || $txn_type == 'express-checkout-cleared') {
>
> and insert the following code the line below the one that ends with "-cleared') {":
>
> ```
//mc12345678 Start Override new_status
$sql = ("select orders_status from " . TABLE_ORDERS . "
where orders_id = '" . (int)$ordersID . "'");
$old_status = $db->Execute($sql);
if ($new_status < $old_status->fields['orders_status']) {
$new_status = $old_status->fields['orders_status'];
}//mc12345678 End Override new_status
Then if you test one transaction like you normally process or hope to prevent from occurring (from within PayPal whatever group transaction/processing that identified this situation) where the status of the order has already been bumped up to something past processing before the above test. (It may seem a little complicated for the setup, but...)
What the above is expected to do is, allow normal processing of an authorized payment, except if the calculated new order status (which if defined in the database is that value or a value of 2 I think is the default status) is less than the current status then basically the status is not updated. This is based on the principle that increasing order status is approaching a "final" desired state. There is no specific hard rule on that aspect, other than if you review the maximum and minimum values in some areas such as downloads and in the specific max/min area.
Let me know if that works for you. The assumption was that the paypal function ipn_update_orders_status_and_history is also called to make this happen in the setup that you have.. The code may need to go elsewhere; however, I'm not in a position to test those conditions.
Let me further state, test this at your own risk. I do not claim responsibility for any negative results. Ideally this could be done in a test environment rather than real payments...
Okay, since that worked, it would be good to add a little something, because this section of code applies to more than just the action you need it for. I haven't looked over the code more to see howmuch work it would be to separate this section out and to maintain the functionality, but I'm thinking that the code should look like this to ensure that all addressed functionality in this section will be maintained and that only the clearing process that has been a problem would stay changed as desired. So, the code should now look like this:
So, if you open the ipn_main_handler.php located in the store's main directory go find (in ZC 1.5.1) line 454 that in this area looks like:
if ((int)$new_status == 0) $new_status = 1;
if (in_array($_POST['payment_status'], array('Refunded', 'Reversed', 'Denied', 'Failed'))
|| substr($txn_type,0,8) == 'cleared-' || $txn_type=='echeck-cleared' || $txn_type == 'express-checkout-cleared') {
and insert the following code the line below the one that ends with "-cleared') {":
//mc12345678 Start Override new_status
$sql = ("select orders_status from " . TABLE_ORDERS . "
where orders_id = '" . (int)$ordersID . "'");
$old_status = $db->Execute($sql);
if ($new_status < $old_status->fields['orders_status'] && (substr($txn_type,0,8) == 'cleared-' || $txn_type=='echeck-cleared' || $txn_type == 'express-checkout-cleared')) {
$new_status = $old_status->fields['orders_status'];
}//mc12345678 End Override new_status
This way items that fit the status of any of the following:'Refunded', 'Reversed', 'Denied', or 'Failed' will be handled/downgraded as applicable. The additional code as compared to the previous is provided in red.
