Wrong Invoice / Order State currupt

[simonmaass]

Describe the bug We cannot really pin point the problem but can only describe the bug at the moment. We will try to collect more data over time...

We have noticed that a couple of orders are getting currupt after wrongfully created invoice.

The payment process looks fine looking at the comment history:

Mollie webhook log:

But as you can see, the order was created on the 10.06 but there is an order status update on the 12.06:

The order is now currupt as there is an invoice but the order items are not correctly labeled as "invoiced":

Possible ideas what the problem might be: 0€ priced products? Just an idea...

Used versions

• Magento Version number(eg 2.3.5): 2.4.6-p5
• Open source/Enterprise/B2b: OS
• Mollie version number (Check configuration): v2.37.0

To Reproduce Steps to reproduce the behavior: Cannot really pin point the bug at the moment...

Expected behavior The order should have the correct state "Processing" with a propper invoice.

Actual behavior "Currupt" order state as you are not able to create annother invoice nor are you able to propperly ship the items...

What is strange is that there is not webhook on mollie side that is responsible to trigger the "again" new processing state on the 12.06....

[Frank-Magmodules]

Hi @simonmaass,

Thank you for opening this issue. Could you please try to reproduce the problem with the same order in a staging or development environment? I haven't been able to replicate it on our end. Could you also clarify the product type for the "Rezeptgebuhr" item line? Additionally, I noticed that the item status for what seems to be a simple product is set to backorder, maybe this can also influence this process?

Additionally, if you can reproduce the issue on a clean/vanilla Magento instance, please share the details with us directly so we can assist you further. You have our contact information. 😊

[julia211091]

I have the same problem, using 2.38.0. I just found around 10 orders from last weekend which have that problem. Status in Magento: Pending payment, status in reality: paid. It concerns all payment methods. Mollie backend shows the same order twice: the older order is paid/authorized, the newer order is open. In Magento, for the older payment, the invoice is created

, but as there exists a newer "open" payment, the status in Magento is still "Pending payment". I cannot confirm that it just concerns backorder products. I have checked the orders, some products have backorder status, but I also have orders where no backorder products are contained. I also checked the backorders settings in the products. Some have "allow qty below 0", some have "no backorders". I added screenshots from mollie backend and magento backend as an example. Unfortunately I cannot provide a test system right now, so hopefully @simonmaass can. Regards Julia

[Quazz]

Manual fixes for these orders would be to do something like the following:

Search for the order by order_id in mollie_payment_transaction_to_order table.

I'm guessing you will have multiple entries here (likely 2) for the affected orders.

The earlier entry should contain the correct transaction_id

Copy that and paste it in sales_order table for the correct order.

Now open that order in magento backend and click on "fetch status" under payment information.

For some reason, in certain circumstances more than one transaction is started. The first one successfully finishes; but then a second entry is logged which puts the order on "pending" (and cancelled after a while if you have auto cancel enabled)

[Frank-Magmodules]

Hi @simonmaass and @Quazz, could you please share the debug log and possibly the access log as well? With the current information, I'm unable to reproduce or identify the issue. Let's investigate this together.

[Quazz]

Hi @simonmaass and @Quazz, could you please share the debug log and possibly the access log as well? With the current information, I'm unable to reproduce or identify the issue. Let's investigate this together.

Is there a way to send this privately since it contains personal information of customers?

I see a lot of activity in the debug log concerning the orders that have issues, even long after the order has been processed already.

[simonmaass]

I haven't been able to replicate it on our end. Could you also clarify the product type for the "Rezeptgebuhr" item line? Additionally, I noticed that the item status for what seems to be a simple product is set to backorder, maybe this can also influence this process?

Rezeptgebühr is a "virtual" product. I dont believe the "backorder" should have any impact...

[julia211091]

I have every day several of that issues. I enabled last night the debug mode of the mollie extension. I will send you the mollie.log file via mail. Which access log you're looking for? the server log? Or system.log? Regards Julia

[Frank-Magmodules]

Thank you for sending over your debug log, @julia211091. I will review it and get back to you shortly.

[Frank-Magmodules]

Hi there @julia211091 , @Quazz and @simonmaass , could you check if you maybe have the loading screen enabled?

The functionality has been deprecated a while ago, but it’s still available: SELECT * FROMcore_config_dataWHEREpath= 'payment/mollie_general/loading_screen'

We suspect that this screen is the cause of these issues. To be more precise: When users use the “back” button after making the payment and going back to this page. You can disable it by removing the record from your core_config_data table.

[simonmaass]

Hey @Frank-Magmodules , we are using magento via API with a PWA as frontend. I am not sure what this config does but it seems like it is a frontend user related feature that is not impacting us. PS. also the feature is disabled

[julia211091]

Hi @Frank-Magmodules , the value was indeed set to 1. I just removed the record and will give you a response tomorrow if there were any new issues in the next 24 hours. But as I updated the extension lately, it is most likely the case. Regards Julia

[Quazz]

@Frank-Magmodules

Thanks, deleted the value from DB. Will monitor the situation; it didn't happen very frequently so might take some time.