How to observe refund amount?

[BillJ]

I'm writing a plugin for 1.57c and among other things I need to observe the amount of a refund, preferably independently of the payment module performing the refund. I can see in admin/orders.php I could place a notifier into the "doRefund" action but it looks as though orders.php doesn't get visibility of the actual refund amount. The form containing the amount is generated and processed by the payment module itself.
Is there a generic way I can observe a refund taking place and see the refund amount or do I have to hook into each payment module individually (effectively ruling out making this a general plugin)?

[lat9]

That's normally a feature (the refund action) provided by the payment module itself. See the authorizenet_aim, paypaldp and paypalwpp payment modules for how they do it.

[carlwhat]

I'm writing a plugin for 1.57c and among other things I need to observe the amount of a refund, preferably independently of the payment module performing the refund. I can see in admin/orders.php I could place a notifier into the "doRefund" action but it looks as though orders.php doesn't get visibility of the actual refund amount. The form containing the amount is generated and processed by the payment module itself.
Is there a generic way I can observe a refund taking place and see the refund amount or do I have to hook into each payment module individually (effectively ruling out making this a general plugin)?

i am not sure what problem/situation your plugin is attempting to solve (and i am all for solving problems), but i do not see an easy way to do it. first, not all payment modules use the method _doRefund for doing a refund. so even if you created a PR to the base code and got a notifier in there, it would not be of value for those modules that do not use that method for doing a refund. in addition, each payment module seems to create its own payment table. something of which i have given some thought. it would be great if the there was a payments table that was independent of the payment module in use. and within that table, the payment module would be indicated. but i do not see that happening. furthermore the call to that method is in the admin/orders.php with only the order number being passed, ie:

           if (method_exists($module, '_doRefund')) {
              $module->_doRefund($oID);
           } 

and yet just looking at the base code for v158, at these methods, there are various different parms being used:

includes/modules/payment/paypaldp.php:1207:  function _doRefund($oID, $amount = 'Full', $note = '') {
includes/modules/payment/paypalwpp.php:863:  function _doRefund($oID, $amount = 'Full', $note = '') {
includes/modules/payment/authorizenet_aim.php:768:  function _doRefund($oID, $amount = 0) {
includes/modules/payment/square.php:1076:    public function _doRefund($oID, $amount = null, $currency_code = null)

if you dig a little deeper, you will see that the _POST fields used to calculate the amounts of the refund are slightly different in each module.

obviously no problem is insurmountable, this one might have a bunch of challenges.

best.

[BillJ]

i am not sure what problem/situation your plugin is attempting to solve (and i am all for solving problems)

The plugin is an integration for an external tax-handling service. It calculates the VAT for EU destinations, pays that VAT and bills the seller's account.
When a refund is made to the customer, I want to notify the service so when the seller refunds the customer including VAT, the tax-handling service refunds the VAT portion of the customer-refund to the seller's account.

I had seen indeed that every payment module handles its own refund, including capturing the refund amount in its own custom admin form. I was hoping some of the more experienced Zen Cart developers might have overcome this challenge before but perhaps it isn't all that common to need to observe a refund.

Obviously I can make it work on my own system because I know which payment modules I am using and can hack them about as much as I need to but I have avoided core code hacks up to this point and I would have liked to be able to contribute the module to the Zen Cart community that has been so supportive over the years.

[BillJ]

What I went with in the end, which seems least invasive and least "hacky", is to add a single line in the _doRefund() function in each of the payment modules I am using (PaypalDP and Square) which puts the refund info into a session variable on successful completion of the refund action. e.g. for Paypal:

$_SESSION['refund_info'] = array( "oID"=>$oID, "amount"=>$refundAmt, "reason"=>$refundNote, "currency_code"=>$curCode );

Then I created a new notifier in orders.php

Original:

          if (method_exists($module, '_doRefund')) {
            $module->_doRefund($oID);
          }

New:

          if (method_exists($module, '_doRefund')) {
            if( $module->_doRefund($oID) )
	            $zco_notifier->notify('NOTIFY_ADMIN_ORDERS_REFUND');
          }

Then I use the information in $_SESSION['refund_info'] within my observer for NOTIFY_ADMIN_ORDERS_REFUND.

I realise that not all payment modules implement _doRefund() but since there appears to be no standard, mandatory interface for refunds there will be no "one size fits all" solution. The problem now becomes one of documentation for the plugin installation but I'll worry about that once it's proven on my system and I'm thinking about publishing it.

[carlwhat]

its great that you got it working to your satisfaction. a few thoughts:

• i'm not a fan of modifying orders.php. that's a script that gets modified every release; so i would avoid doing it if you want to package it up for community use.
• using the notify/observer system is great when there is an existing observer. adding a new observer to orders for your own use makes little sense to me. if you want to stick with that process, i would create a PR on the github repo.
• perhaps it might be better to create a script in YOUR_ADMIN/includes/functions/extra_functions/vat_refunds.php with a function processVATRefund.
• i believe anything in the extra_functions would get auto-loaded.
• then, instead of setting a SESSION var, you can just call the function right then, ie in paypal,
  
  

  processVATRefund($oID, $refundAmt, $refundNote, $curCode); 

• in this way, you are only modifying each payment class with 1 line; which you are already doing. those classes tend to get modified far less than the orders.php script.
• the necessary processing gets done immediately as opposed to doing the necessary processing in the observer.

obviously you are free to do it how you see fit; but i a HUGE fan of not modifying core code, or at least minimizing it as much as possible.

best.

[BillJ]

Thanks for your helpful comments carlwhat. That would certainly work well and would be easier if it was only to implement my plugin.
I had it in mind that if I created a PR to add the notifier to orders.php for future Zen Cart versions and there was a general way to pass the refund info out of the payment modules (like the way I have done it or perhaps a better way) then there would be a fairly easy way for future plugins to observe a refund, without every similar plugin having to add an additional line to the payment module to call its own dedicated function. That's why I took the slightly longer way round by adding the notifier.

I'm still thinking how I could come up with a reasonably general solution to the problem to put in a PR so any suggestions would be welcome. I'm not a Zen Cart development expert but the further I go with it the more impressed I am with its architecture.