Order status changes after batch capture on PayPal website

I just upgraded to ZC 1.5.1 from 1.3.8a. I use Super Orders and Edit Orders.

Everything *was* working just fine. Now I have the following problem with PayPal Express Checkout module. This does not happen with the PayPal Payments Pro module.

I just about always use two order statuses. When an order is placed the status is ALWAYS set to "pending". I change that status to "complete" when we have printed, (made any necessary changes,) and filled the order. The key is, we may change the order of ANY of those processes. The next day, I pull up all new pending orders and deal with them as necessary.

When customers checkout it is an authorization only. After we make any necessary adjustments to the order, I do a batch capture on PayPal's website. Sometimes this is only done every few days.

PayPal Express Checkout is then changing the order status back to pending. I know this is tied to the module settings. However, what I am looking for is for NOTHING to be done to an order status after I capture the funds. For various reasons we need do things out of order around here. There is no good time for an order status to be changed upon fund capture and I cannot find any option to for "do nothing".

Hoping someone can help me out. Thanks a million!

I haven't used the authorization option with paypal (express or otherwise). I realize the convenience of the batch capture. I was wondering though, is there an option within the cart to do this one at a time? Meaning to capture the payment of a single customer?

I'm wondering if the return communication from paypal that the payment was successfully received is what is forcing the ipn_handler/paypal express code to update the status to pending. If so, I would think that the line of code that checks/sets the status as a result needs an if statement that would look to the database/constant to not update the status under those conditions of if the status is >= to the status equivalent to pending and the setting is to authorize... So, in that case if the status was bumped up, that it would not return down, but if it had been set to something lower it would come up to pending. I believe I have seen this issue described elsewhere in the forum, but have no recollection on the resolution. Although I see a few related threads at the bottom of this one that mmight have an answer?

Quote:

---

Originally Posted by mc12345678

I realize the convenience of the batch capture.

---

Absolutely! :)

Quote:

---

Originally Posted by mc12345678

I was wondering though, is there an option within the cart to do this one at a time? Meaning to capture the payment of a single customer?

---

Yes, there is. But how slow and tedious. Especially after we've tasted the goodness of batch capturing and had no problem in 1.3.8a (or any of the other prior versions we used.)

Quote:

---

Originally Posted by mc12345678

I'm wondering if the return communication from paypal that the payment was successfully received is what is forcing the ipn_handler/paypal express code to update the status to pending. If so, I would think that the line of code that checks/sets the status as a result needs an if statement that would look to the database/constant to not update the status under those conditions of if the status is >= to the status equivalent to pending and the setting is to authorize... So, in that case if the status was bumped up, that it would not return down, but if it had been set to something lower it would come up to pending.

---

This is so totally what needs to be done. But how? I am clueless.

Quote:

---

Originally Posted by mc12345678

I believe I have seen this issue described elsewhere in the forum, but have no recollection on the resolution. Although I see a few related threads at the bottom of this one that might have an answer?

---

I searched around quite a few times. (And looked at the related threads at the bottom.) Unfortunately, I couldn't find any solutions. I'm going out of the country and someone else (who is not computer savvy) will be doing the order processing/batch updating on the website. I would love to fix this before I leave.

Many thanks!

Does anyone have any thoughts on where and what change this may need?

Quote:

---

Originally Posted by Three Sisters

Does anyone have any thoughts on where and what change this may need?

---

Came across a function in a paypal module that appears to either updte the value or at least capture the information to update it. By a little manipulation of the data that is returned by. It at the right place and may be able to solve this issue. The file is located in the includes/modules/payment/paypal directory. It has the wod update in the function. I didn't yet have a chance to find where the function is called to be able to identify the status returned by paypal to assist in the correction.

Quote:

---

Originally Posted by mc12345678

Came across a function in a paypal module that appears to either updte the value or at least capture the information to update it. By a little manipulation of the data that is returned by. It at the right place and may be able to solve this issue. The file is located in the includes/modules/payment/paypal directory. It has the wod update in the function. I didn't yet have a chance to find where the function is called to be able to identify the status returned by paypal to assist in the correction.

---

I sure appreciate your efforts... But - I have no idea how to find this stuff. I decided to put the files from vs. 1.3.8a and the new ones from 1.5.1 into DiffMerge to see what had been changed since the update. Alas. There are way too many changes for me to find and risk "fixing" this myself.

Can you tell me why the new version does this now when it didn't do it in prior versions?

Quote:

---

Originally Posted by Three Sisters

I sure appreciate your efforts... But - I have no idea how to find this stuff. I decided to put the files from vs. 1.3.8a and the new ones from 1.5.1 into DiffMerge to see what had been changed since the update. Alas. There are way too many changes for me to find and risk "fixing" this myself.

Can you tell me why the new version does this now when it didn't do it in prior versions?

---

My guess is that because it became more ZC centric and there probably were other security updates to apply. Afterall ZC 1.3.8 had significant security issues to begin with, let alone perhaps something with PayPal. I'll see if I can take a gander again to find what I had found before and possibly identify the work around for which you are looking.

By ZC centric I mean that it was probably considered that the issue should be handleable from the store side. The fact that PayPal may have also made changes that did not get corrected/updated in ZC well, as long as it functions in a way is minimum requirements. If through this or others work a functional improvement is identified, then perhaps it would make it into future versions, but it must be universal enough and not conflict with other design considerations. Otherwise it may be something for a specific cart only (ie. custom modification)...

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:

Code:

---

      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') {":

Code:

---

        //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...

Wondering...

Success?

Quote:

---

Originally Posted by mc12345678

Wondering...

Success?

---

Oh wow - I totally missed your post! And have been too busy to check back... Sorry - didn't mean to appear so ungrateful.

Will try working on it Monday. (Tonight's too late, and tomorrow is crazy full.) I'll let you know how it goes.

Thanks heaps!

Quote:

---

Originally Posted by Three Sisters

Oh wow - I totally missed your post! And have been too busy to check back... Sorry - didn't mean to appear so ungrateful.

Will try working on it Monday. (Tonight's too late, and tomorrow is crazy full.) I'll let you know how it goes.

Thanks heaps!

---

Well, I know it's rude to bump a post... :) But was definitely trying to provide assistance. Didn't think ungrateful, rude, or anything at all. Not knowing how many sales get processed, wanted to see that at least the code was available to attempt being processed if it was going to be used/tested/tried. All good on my side. In fact, only reason I'm responding is to let you know that all is good. :) And I guess to know if I should go to apply something similar elsewhere in the code.

Hope busy for because of the good things in life. I look forward to a yeah or neigh on it working.

OK - it's gonna take me a couple more days. I *was* super busy... Now I'm camping and there's not enough service here for me to do some of the work I planned to slip into this mini vacation. Oh well! Guess it's good to "un-plug" for a few days any how. :)

Will check back when I get home.

Quote:

---

Originally Posted by Three Sisters

OK - it's gonna take me a couple more days. I *was* super busy... Now I'm camping and there's not enough service here for me to do some of the work I planned to slip into this mini vacation. Oh well! Guess it's good to "un-plug" for a few days any how. :)

Will check back when I get home.

---

Noooo problem. :) enjoy nature, wish you good weather.

Quote:

---

Originally Posted by Three Sisters

OK - it's gonna take me a couple more days. I *was* super busy... Now I'm camping and there's not enough service here for me to do some of the work I planned to slip into this mini vacation. Oh well! Guess it's good to "un-plug" for a few days any how. :)

Will check back when I get home.

---

Quote:

---

Originally Posted by mc12345678

Noooo problem. :) enjoy nature, wish you good weather.

---

Status?

Quote:

---

Originally Posted by mc12345678

Status?

---

OK - Camping - done. International move - done. Now, back to work! :)

Very pleased to say that it worked perfectly. The change was breeze easy. The status remained the same ("complete - 5") after I captured the funds.

Thanks a million. I never would have figured out where and how to do that! I am really and truly thankful.

Quote:

---

Originally Posted by Three Sisters

"...Very pleased to say that it worked perfectly."...

---

Well, sadly, I just found out my site lost the ability to do an express checkout with PayPal - or just any checkout with PayPal. Went back to the original ipn_main_handler.php and the problem is gone.

Any thoughts?

Forgive me, it was my fault. I was using a seldom used PayPal account and didn't realize the card on the account was expired. At the same time another customer's checkout failed, but that one was because of a processor decline. It was purely coincidental that both failed after the file change.

I've tested further and at this point, all appears to work perfectly. So, I thank you again!

Quote:

---

Originally Posted by Three Sisters

Forgive me, it was my fault. I was using a seldom used PayPal account and didn't realize the card on the account was expired. At the same time another customer's checkout failed, but that one was because of a processor decline. It was purely coincidental that both failed after the file change.

I've tested further and at this point, all appears to work perfectly. So, I thank you again!

---

Sure?! :P

I do/did want to see that the reverse conditions also properly worked. That being, if in the sequence of working payments, etc. That if zc still had the item/purchase marked like pending and then the capture is done in paypal that the status does get updated like it is supposed to.

Scared me for a moment though. :)

Quote:

---

Originally Posted by 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:

Code:

---

      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') {":

Code:

---

        //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:

Code:

---

      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') {":

Code:

---

        //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.

This is just a quick note to mention that after upgrading to 1.5.5d, I have the same problem again. I remembered dealing with this before, so I pulled up this old post and am applying the same fix again. Here's hoping all goes well as before!

Quote:

---

Originally Posted by Three Sisters

This is just a quick note to mention that after upgrading to 1.5.5d, I have the same problem again. I remembered dealing with this before, so I pulled up this old post and am applying the same fix again. Here's hoping all goes well as before!

---

Huh... I thought it got incorporated to the store already. Didn't see any reports of it causing problems. Oh, maybe it got incorporated into ZC 1.6.0. I'll take a look.

Yup. Change was captured in ZC 1.6.0, the pull request is here which has somewhat simplified the neighboring code.