Only display "refund manually" button after refund failure.

[LevinMedia]

Per Stripe: the only time a payment made with WooCommerce payments can be refunded manually should be after a refund via the gateway has failed.

cc: @allendav @thenbrent @bmccotter

[allendav]

This seems like a must-have for V1, right?

[LevinMedia]

@allendav yep!

[dechov]

We'll probably want to (conditionally?) enqueue some JS here to hide .do-manual-refund.

[dechov]

We'll want to track that there's been a refund failure in order meta, I think, as currently process_webhook_refund_updated only adds an a order note.

[jrodger]

currently process_webhook_refund_updated only adds an a order note.

That's correct. We also have an issue for expanding that behaviour to cover things like changing the order status (#601).

Tracking the refund failure in order meta would make sense, the only downside I can see would be the chance of the refund failing and then the webhook failing. That would leave the merchant with a refund failure transaction in their dashboard, but no way to resolve it.

As an alternative solution, would it be worth considering tracking the fact that the merchant simply attempted to refund through WCPay instead? The first time they try to refund, they would only see the "Refund with WCPay" button. The UI will update to show that the refund attempt was submitted successfully. Presumably the merchant wouldn't attempt to refund again, so we could show the manual refund button at that point. That would be more robust, but at the risk of making the UI more confusing.

Also, do we need to consider partial refunds as part of this? It's not something I've played around with much.

[thenbrent]

This issue is causing support tickets as mentioned in p6q7sZ-7TF-p2

[SiR-DanieL]

one customer has an issue with this in 3837596-zen

[DustinHartzler]

It happened in this ticket too: 3831519-zen

[dechov]

Likely cause of the issue in pbUcTB-f4-p2

[reykjalin]

Tracking the refund failure in order meta would make sense, the only downside I can see would be the chance of the refund failing and then the webhook failing. [...] would it be worth considering tracking the fact that the merchant simply attempted to refund through WCPay instead?

I don't think counting attempts is enough. What if they do a partial refund? Once the partial refund has been completed, they'd now see the Manual Refund button.

I guess we could reset the attempt counter once the webhook is successfully handled? But even then I think it'd be more robust to check for failures. Webhook delivery issues will always cause problems, no matter what we do about it.

That said, we could always count both the attempts and failures and somehow tally the numbers to make a more intelligent decision about which buttons to show.

The first time they try to refund, they would only see the "Refund with WCPay" button. The UI will update to show that the refund attempt was submitted successfully. Presumably the merchant wouldn't attempt to refund again, so we could show the manual refund button at that point. That would be more robust, but at the risk of making the UI more confusing.

I wonder what @LevinMedia's thoughts are on this UX. Is it better to:

• Possibly never getting the manual refund option in case of failures; or
• Seeing the manual refund option prematurely — or when the order has already been completely refunded?

Also, do we need to consider partial refunds as part of this? It's not something I've played around with much.

I think so. Just thinking about it I could see partial refunds messing with some of the proposed solutions.

I think the simplest one (least amount of edge cases) is the "only show manual refund after failure" approach. Other approaches might be more robust, but will require more detailed handling.

[LevinMedia]

I think the simplest one (least amount of edge cases) is the "only show manual refund after failure" approach. Other approaches might be more robust, but will require more detailed handling.

@reykjalin I agree - given that the likelyhood of a refund failing at the same time a webhook is low - I think we can move forward with this approach.

[tijosh]

Occurrence in 29406563-hc