-
Notifications
You must be signed in to change notification settings - Fork 33
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Partial refunds causing issues #514
Comments
Further feedback from James on this: _I'd recommend that they don't save the order if no changes are necessary. If you modify processInvoice, processEmail, processCreditMemo to return a true/false if they actually did any changes to the order, you could use these as a flag. I've not tested this code but it would be something like this to completely ignore handleTransaction if a credit memo already exists with a matching txnId to the transaction Id._
_But I haven't had time to attempt to fix this and therefore test the above. I still have question marks over whether I'd need to create a transaction/update the payment or if the refund that's generated without the webhook does that. You don't need to set order status as much as the original developers thought. A long-standing annoyance with the extension is that it tries to change the order status after a refund or partial refund since Magento handles that itself. Magento will automatically close or cancel an order when certain criteria are met after a refund - see https://github.com/magento/magento2/blob/2.4-develop/app/code/Magento/Sales/Model/ResourceModel/Order/Handler/State.php - you don't need to set state/status - the only gap is the following criteria._
|
We are occasionally have issues issusing partial refunds on orders.
What happens is that (1) the refund goes through on checkout.com, (2) the credit memo is generated but when we view the sales_order later, the qty_refunded on the sales_order_item hasn't been updated, with other fields related to total refunded also being 0.
Except they were updated.
Have debugged this and the issue is being caused by the webhook overlapping with the refund process.
So,
I'm going to fix this with a plugin that prevents the order from being saved when it doesn't need to be saved, presumably on handleTransaction in TransactionHandlerService, but you know, it would be kind of cool if you could fix this yourselves too.
The text was updated successfully, but these errors were encountered: