[FEATURE REQUEST] Refund should only be created with state 'refunded' when it was actually processed by Mollie

[Swahjak]

Describe the new feature

A clear and concise description of the new feature.

Describe the solution to be implemented

Given the following recent issues https://github.com/mollie/magento2/issues/720 I was wondering if there could be situation where a refund would only reach the 'refunded' state when it is actually refunded. Magento does support having 3 states on a refund (open, refunded, closed) so from that perspective it should be possible. It seems like the Mollie Payment API also supports this out of the box, but the Orders API seems to be limited (based on the docs, haven't actually looked into it).

Why? Because when something goes wrong, we can visually confirm (but also grammatically) if a refund has been processed in Magento (or even received by Mollie).

Edit: A bit more context:

In Magento, a refund can go through a number of statuses; open, refunded, canceled. The bug from earlier exposed a vulnerability in which refunds (credit memos) were created but not actually refunded (read; not pushed to Mollie at all). By putting a refund in the status 'open' and not moving it to 'refunded' until the actual action is performed at Mollie, we as a company keep a grip on our refunds.

Backend changes A clear and concise description of the new feature in the backend.

Frontend changes A clear and concise description of the new feature in the frontend.

Additional context Add any other context or screenshots about the feature request here.

[Frank-Magmodules]

HI There @Swahjak ,

Thank you for raising this matter. Although we've had a direct conversation, I wanted to provide a clear summary of your question:

During the refund process, adhere to the following steps:

1. Create an “open” refund.
2. Send the actual refund to the Mollie platform.
3. Update the open refund to “refunded” as its final state.

Is my understanding right? We will put this on our planning to see what’s possible here. Once we have an update we will get back to it.

[Swahjak]

Correct, and thereby providing a way to visually (but also programmatically) 'check' if a refund has been processed (without needing Mollie access).

[Frank-Magmodules]

HI There @Swahjak ,

Thank you for bringing this issue to our attention. We apologize for the delayed response. After investigating, we found that the request is more complex than it initially appeared. Here are the two scenarios:

• When the order is created using the Payments API, the default refund method on the payment method instance is called.
• When the order is paid using the Orders API, the process occurs in the sales_order_creditmemo_save_after event.

Both actions occur within the same transaction. To achieve the desired outcome, we would need to delay the refund call to Mollie until after the initial credit memo has been created. This would require implementing a cron job or a background queue, both of which would prevent immediate feedback to the end-user and significantly increase system complexity.

Therefore, we have decided not to implement this solution at this time. If a simpler method becomes available in the future, or if there are changes in the development of the Order and Payment APIs within Mollie, we will reconsider this. So, given the current complexity, we must decline and will be closing this issue for now.

[Swahjak]

Hey @Frank-Magmodules,

Doesn't Mollie trigger a webhook when a refund has processed? Or does it trigger when the refund was created? Looking at the timeline in Mollie on a refunded order I would say it is the first. Given that a webhook is received it would make sense to create all credits on a 'open' state? Maybe on the sales_order_creditmemo_refund event?

[Frank-Magmodules]

Hi There @Swahjak ,

Again, thank you for your reply on this. We investigated this option more, but we bumped into a few issues. We would skip this for the Orders API as it’s deprecated. This would be possible for the Payments API. However, when the webhook comes back from Mollie, we need a way to determine which credit memo we need to update with certainty. The moment we refund we are in a transaction and the refund isn’t saved yet, so we don’t know the corresponding ID. We could generate a random ID, add that to the credit, and save it in the metadata of the Mollie payment. But how do we save it to the credit?

Orders in Magento have an extra “additional_information” column where you can dump information, the credit does not have this. We could add an extra column, but this requires a migration of this table, and merchants with large tables do not prefer this as this brings down the site which can take a long time.

If we choose that either way, we might bump into issues where the webhook is already coming back from Mollie while the order and credit still are being saved, which might cause race conditions.

In summary, there are several obstacles to overcome. Given that this feature isn't in high demand, we don't plan to pursue it further at this time. However, we truly appreciate your input and collaboration!