The difference between the process for the other gateway and Braintree is quite wide, with a lot of extra steps. I can’t be alone in needing partial refunds, so if anyone has a smoother process I’d be really interested. Despite the Braintree limitation, I think there are still opportunities for streamlining this.
Braintree supports partial refunds, the transaction just has to have a status of settling or settled. That’s the difference between Braintree and something like Stripe.
Another thing as @subscriptiongroup suggested, is to have a more useful error message when trying to refund before settlment. The current one is a dead end that gives no clue that there is a voiding option via cancelling the order.
I’ve made a note of your feedback.
Many thanks for that tweak to the refund error message in the latest update! I imagine that will save a bit of confusion to some people.
Rather belatedly, I have found another problem with this, which makes manual partial refunds quite difficult, and explains why our bookkeeper has been having trouble reconciling.
Just now, we were asked to refund postage as the customer made two orders that can be merged. So I did a manual partial refund of the postage, and captured the new total. I happened to look at the order afterwards, and it seems the act of capturing also changed the order total a second time, and the new amount paid was shown as the amount captured, less the manual refund, not the original amount, less the refund.
I was able to put this right by editing the order manually, after putting it into Processing status. I don’t really like doing this, as it sends another email to the customer when it goes back to Processing. For postage, it would have been easier to have done a manual edit instead of a manual refund and then a manual edit. But that would not work for products which need to be put back into stock and the correct batch.
This is a great plugin in so many ways, but I’m afraid that because of these issues, we only have this plugin active for Apple Pay, for which we have no other option. We use another gateway for cards and Paypal.
Hi @tufty,
So are you saying that when the order is captured it’s better to not update the order total to reflect the captured total? If so, how would your accounting reconcile the difference between the captured total and the order total if the captured total was less?
Example:
Order total: $50
Authorized Amount: $50
Captured Total: $45
In your WooCommerce reports, the order total of $50 would be used which would not provide an accurate total of the actual amount your business received.
If you can shed some light on that scenario that will help us make any necessary updates that might better reflect the accounting practices of merchants.
Kind Regards,
Hi @mrclayton!
Well, for me it was unexpected behaviour that once I had set the order to the partially refunded status, and then went to capture it correspondingly, when I came back to the order it had changed. Obviously, one wants the amount captured to correspond to the net sale amount in WC.
In your example that seems to assume no change in the order itself. And in that case, yes, it makes sense to adjust the order total to match the captured amount. But I think that is less likely as a workflow because most stores will want the order to show an audit trail of what happened, as well as simultaneously putting items back into stock.
There are lots of ways to skin the proverbial cat here, starting with probably the least work:
1. Introduce a dialog at the point of manual capture so that if the amount captured is different to the order total, net of any manual refund, then the user can choose to create another adustment within the order, so that the amounts match. If the amounts already match, then just capture…
Order total: $50
Authorized Amount: $50
“Refund” requested $10 for product or shipping not wanted
New Order total $40
Manual Captured Total: $40
2. The most seamless experience I can think of, given what I understand of the Braintree framework, is to change the behaviour of the refund, so that if the order is authorized, not captured, the button for “Refund $10 via Braintree XXX Gateway” saves a new lower value for the capture amount that will be used later when the order is marked complete and captured automatically.
Thanks.
Hi @tufty,
Thank you for providing those insights. We are discussing the best way to proceed. Right now we are leaning toward creating a refund item in WC equal if the captured total is less than the order total.
This way the amounts will always add up as you have suggested.
Kind Regards,
Hi @mrclayton There is one issue with doing it that way, which is that it should require an assumption about tax. At present, the auto-refund amount ignores tax. But when making a refund, I usually need to refund the tax component appropriately too.
If the partial refund is related to a taxable item, then we will split the refund between the main amount and tax.
One approach to mitigate this scenario would be instead of silently creating a refund with no tax, make a dialog offering to alter the order amount with fields for splitting the total difference between order and captured amount between tax and value.
-
This reply was modified 2 years, 9 months ago by
tufty.
Hi @tufty,
I like your suggestion about splitting the capture amount across line items. To do this properly, the dialog would need to pretty much re-create the refund table where each line item is rendered along with qty, cost, total etc.
We’re debating if that added complexity is needed when the merchant could just capture the total and then create a manual refund to reflect the item totals and tax should the capture amount not equal the order total.
Kind Regards,
Hi @mrclayton, TBH, I don’t think all line items are necessary… Just two fields between main amount and tax, and if you felt like it, a checkbox to calculate automatically based on a tax field.
In other words, with a disparity of 12, the initial dialog would offer a prefilled main filed of 12 with tax field zero, which I would manually alter to 10 and 2.
or I’d check the auto box and type in 20% as tax amount, so it would auto populate the fields with 10 and 2.
Hi @tufty the problem with not including all line items is how do you then allocate the capture amount across items. Here is an example:
Order:
1 X T-shirt – $29
1 X Sweat Pants – $35
2 Day Shipping – $5
Tax – $5.52
Total – $74.52
Let’s say you only want to capture $40. If you only have a main amount and a tax amount, the plugin will have to make the judgement call on how to disperse the $40 capture amount across the items. The best way we have found to reconcile the order total and the capture total is via a refund. And the way a refund works is by applying the amounts to each line item like WooCommerc does it.
Thank you for your feedback, this has been a very helpful discussion and has given us a lot to think about as we look to implement your suggestions.
Kind Regards,
Hi @mrclayton, OK. I had thought that if users are aiming to be precise, they will already have done the allocation between products and shipping, and that this is fallback that can be treated as a simple and separate “reverse fee”.
For a simple change in the order to remove an item that is not required, I would definitely do that in the order, putting the item back into stock, and then the capture would be the same as the order. For a simple refund of the whole shipping fee, I’d probably do the same.
But for partial refunds, such as cheaper shipping, or a customer emails to say they forgot to apply a coupon. It’s a little more complicated, and it would be quite helpful to be able to apply that as a ‘reverse fee’, generated while capturing the final amount.
Hi @tufty,
You bring up an interesting point. If the order’s status is set to on-hold, then the order line items are editable. The merchant could just edit the line items, re-calculate the total then capture that new amount.
Perhaps that’s the best solution. Just set authorized orders to on-hold and allow the merchant to edit the line items then capture. The plugin won’t need to make any adjustments or set the new order total. That would certainly cut down on the coding complexity we were considering.
Kind Regards,
@tufty based on this discussion we are going with the following solution for now:
1. Authorized orders will be set to on-hold.
2. The order line item totals can then be edited since the order has an on-hold status.
3. Once the order total is re-calculated, that order total amount will show in the Braintree capture pop-up.
4. If the capture total is less than the order total, an alert will show reminding the merchant to adjust their order line items.
Kind Regards,
Excellent. The only things I can thinl of are about (a) the messaging to put on hold instead of immediate refund and (b) the way the variation to the authorized amount is dealt with, ie. can’t be increased.
@tufty the authorized amount will always be equal to the order total at time of checkout. Even if you, as the merchant, edits the order line items for a lesser total, you can always go back and change it back to the previous order total before capturing.
Basically the notice that the plugin will provide will show if the capture amount entered is less than the current order total. It will serve as a reminder for merchants to update the order line items to ensure proper accounting.
Kind Regards,
