Wrong order status after "complete"

[andriydeveloper]

Describe the bug Mollie changes the status of the order from "complete" to "processing"

Used versions

• Magento Version: 2.4.3-p3
• Open source
• Mollie version number: v2.29.1

To Reproduce Steps to reproduce the behavior:

1. Finish the order using the credit cart.
2. Make an invoice and change the order status to "complete" using API.
3. Mollie update order status using order API(bug)

Expected behavior Do not need to change status from complete to another one

Actual behavior Mollie changes status a few times from completed to processing

Screenshots On the screen, you can see how the history of the order.

Additional context I think the bug comes here: vendor/mollie/magento2/Model/Client/Orders/Processors/SuccessfulPayment.php:190 function: handleWebhookCall Solution for fixing: change this:

$this->setOrderStatus($order);
$this->orderRepository->save($order);

to

if($order->getStatus() != "complete"){
    $this->setOrderStatus($order);
}
$this->orderRepository->save($order);

[Frank-Magmodules]

Hi there @andriydeveloper , thank you for opening this issue.

I’m trying to reproduce this issue but can you expand the steps to reproduce a bit? What product type are you using? And what do you exactly mean by “Make an invoice” ?

Orders will be captured and invoices once the payment has been settled on Mollie's side. After this, the webhook will be hit and the order will be updated. Based on the screenshot of your comment history, it looks like some other process is running, as “Payment successful” is not an entry added by the Mollie module.

See below an example of a CC order on our env.

Thank you! The more comprehensive the details, the better we can address the issue.

[andriydeveloper]

Hi @Frank-Magmodules Please, validate a time when it happens.

In the example above

1. Mollie changes order status to "processing", when the order got paid --> Webhook erfolgreich aufgerufen, es dauerte 1,5 Sekunden 28. Juli 2023, um 18:45
2. Then we import the order to our ERP-System and change the order status to "complete".
3. Now nothing else should change the order status again.
4. For a reason, that we do not understand: Mollie extension changes order status again to "processing" a couple of days later --> Webhook erfolgreich aufgerufen, es dauerte 1,0 Sekunden 31. Juli 2023, um 16:34
5. Then this happens again for a third time: Webhook erfolgreich aufgerufen, es dauerte 1,0 Sekunden 1. August 2023, um 16:18

It happens after upgrading the mollie extension from 2.24.1 to 2.29.1

[andriydeveloper]

I think the problem is here: file vendor/mollie/magento2/Model/Client/Orders/Processors/SuccessfulPayment.php:190 it does not have any condition to check if the order was completed. Also, we can not apply any plugin for a function private function setOrderStatus($order): void because this is a private function. Rewriting the whole class is a bad idea :)

Please update your code to not change the order status if it was completed after getting new webhooks

[Frank-Magmodules]

HI There @andriydeveloper

We have tried to reproduce this on different environments and different settings but we can’t seem to reproduce this.

Now you mentioned this:

Then we import the order to our ERP-System and change the order status to “complete”.

Could you tell us more about this? You already told me that you are using the API for this, but what are the exact calls you are making? Do you create shipments for the order for example? Or is that all handled from your ERP?

As it all seems to be working as expected in a vanilla Magento shop, we are suspecting that there is something different in your system or that you are doing something unexpected. But we need more context to really understand what is going on.

[andriydeveloper]

@Frank-Magmodules I hope it will help. The updating status was triggered by ERP using vanilla Magento API service when we got the information that the order was paid.

URL: https://yourdomain/rest/V1/orders/140326/comments
method: POST
Payload:
{
    "statusHistory": {
        "comment": "azazzaa comment from API",
        "created_at": "2023-07-07  15:15:15",
        "parent_id": 140326,
        "is_customer_notified": 0,
        "is_visible_on_front": 1,
        "status": "complete"
    }
}

source: https://adobe-commerce.redoc.ly/2.4.6-admin/tag/ordersidcomments/#operation/PostV1OrdersIdComments

But I am pretty sure you will have the same bug after using this API:

https://yourdomain/rest/V1/orders/
method: POST
Payload:
{
  "entity": {
    "entity_id": 140326,
    "status": "complete"
  }
}

Source: https://adobe-commerce.redoc.ly/2.4.6-admin/tag/orders#operation/PostV1Orders

As I understand Mollie sends webhooks a few times Steps to reproduce:

1. Mollie updates the status to "pending" ---> the first webhook
2. send API query to change the status to "complete"
3. Mollie will update the status again to pending ---> the second webhook

Configuration: We are using the "order API" method type of payment configuration. https://github.com/mollie/magento2/wiki/Differences-Payments-API-&-Orders-API

I provided the solution to fix this issue. It does not work. We have the bug again. You do not have the allow to change completed orders

[andriydeveloper]

One more place where the order can change the status: vendor/magento/module-sales/Model/Order/Payment/State/RegisterCaptureNotificationCommand.php:68

[andriydeveloper]

Hi There @Frank-Magmodules I investigated everything from our side. We are doing nothing with the order, except the API rest/V1/orders/140326/comments to add a comment and change the status to "complete"

'statusHistory' => [
                'comment'              => 'Payment Successful',
                'is_customer_notified' => 0,
                'is_visible_on_front'  => 0,
                'parent_id'            => $orderId,
                'status'               => 'complete',
            ],

We did not change the order state. It worked perfectly until we updated the Mollie extension from 2.24.1 to 2.29.1. After updating some mollie process triggers to add a "Registered notification about captured amount" comment. Maybe it checks if the order state is the same as from Mollie's side, I don't know but I am sure that the order status should not be updated from complete to pending. It is fine if you update the order state but not the order status \Mollie\Payment\Model\Mollie::orderHasUpdate I give up

[Frank-Magmodules]

Hello @andriydeveloper, We appreciate your contribution of additional pertinent information to this matter. Our team has scheduled this issue for investigation, and we'll make sure to provide you with an update as soon as we have more information. Thank you for your patience here!

[andriydeveloper]

Hello @Frank-Magmodules Thanks a lot.

This is not our case but maybe it helps for debugging. Steps to reproduce:

1. make an order

2. success

3. fetch status from Mollie on the first time. The status changed to processing

4. Send Api to change state and status. It will change the state and status of the order to "complete"

   https://yourdomain/rest/V1/orders/
   method: POST
   Payload:
   {
   "entity": {
   "entity_id": 140332,
   "status": "complete",
   "state": "complete"
   }
   }

5. fetch the Mollie status again the second time. The status will be changed to processing again (bug)

[jamieolney]

I can confirm we have the same issue with an older version 2.24.0 the registered notification about captured amount comes in a second time later after a delay. This is usually under 10 minutes, but can be 30 minutes. This causes issues with order statuses if the order has been dealt with previously and changed. See example where we moved "To be printed" but then it moves back to processing We only have Apple Pay enabled using the payments API

[andriydeveloper]

Hello @Frank-Magmodules FYI: Together with Mollie v2.30.1 the error is gone

[Frank-Magmodules]

Hi There @andriydeveloper ,

We've invested additional time in our investigation and have considered the possibility that Mollie may have been triggering the webhooks again for a certain period following the significant issue we encountered with the Order_ID preg_match. However, it appears that this is no longer the case, and your issue is unlikely to occur again, as you've indicated in your latest comment. If you remain confident that this issue is resolved for now, please go ahead and close this matter.