Notifications will not proceed when the temporaryID not match with the origin order.

[djspacedevil]

Describe the bug
Notifications will not proceed when the temporaryID not match with the origin order.
-> Order with temporary ID: 6ce18650aaa8bd2dfafb70d06f14**** still not created.

But order exists and can match with the email address, customer data and order value over the adyen backend.
But in the database, the order have a different temp. ID in the s_order table.

To Reproduce
Steps to reproduce the behavior:
A lot of error notification in the s_plugin_adyen_queue.

1. Example from one entry, where we have an order, an payment in adyen, but matching not working.
   In table s_plugin_adyen_queue the temporaryID is ff4d55b2f9b657b9db1e2d6560d7****
   In the s_order the temporaryID is f10fd690de39451221e270254b58****

{ "class_name": "Adyen\\Core\\Infrastructure\\TaskExecution\\QueueItem", "id": 8104, "parentId": null, "status": "failed", "context": "", "serializedTask": "{\"amount\":{\"value\":5898,\"currency\":\"EUR\"},\"eventCode\":\"AUTHORISATION\",\"eventDate\":\"2026-01-25T08:19:46+01:00\",\"hmacSignature\":\"****\",\"merchantAccountCode\":\"****\",\"merchantReference\":\"ff4d55b2f9b657b9db1e2d6560d7****\",\"pspReference\":\"****\",\"paymentMethod\":\"mc\",\"reason\":\"****:7917:09\\\/2030\",\"success\":true,\"originalReference\":\"\",\"riskScore\":0,\"storeId\":\"1\",\"live\":true,\"additionalData\":{\"expiryDate\":\"09\\\/2030\",\"authCode\":\"****\",\"cardSummary\":\"****\",\"isCardCommercial\":\"false\",\"networkTxReference\":\"****\",\"cardFunction\":\"Consumer\",\"tokenization.shopperReference\":\"*****\",\"hmacSignature\":\"*****\"},\"class_name\":\"Adyen\\\\Core\\\\BusinessLogic\\\\Webhook\\\\Tasks\\\\OrderUpdateTask\"}", "queueName": "OrderUpdate", "lastExecutionProgressBasePoints": 0, "progressBasePoints": 0, "retries": 6, "failureDescription": "Attempt 1: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.\nAttempt 2: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.\nAttempt 3: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.\nAttempt 4: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.\nAttempt 5: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.\nAttempt 6: Order with temporary ID: ff4d55b2f9b657b9db1e2d6560d7**** still not created.", "createTime": "2026-01-25T07:19:47+00:00", "startTime": "2026-01-25T07:20:49+00:00", "finishTime": null, "failTime": "2026-01-25T07:20:57+00:00", "earliestStartTime": null, "queueTime": "2026-01-25T07:19:47+00:00", "lastUpdateTime": "2026-01-25T07:20:55+00:00", "priority": 100 }

Expected behavior

• Fallback check on ordernumber with email address.
• A function or CLI command to reprocess notifications retrospectively.
• Show order number again in adyen backend and make it searchable.

Additional context
We are increasingly seeing notifications in the Adyen plugin logs that are not being processed. However, there is no way to reprocess them or revise data for mapping to orders. In addition, there is no search function, which makes it difficult to find the order on Adyen using the order number. Currently, this can only be done via the email address or, if the notification works, via the PSP reference.

[adyen-integrations-support]

Hi @djspacedevil ,

Thank you for reaching out and for providing such a detailed description, examples, and logs. This is very helpful.

We have attempted to reproduce the reported behavior on our side, but without success.

That said, this situation can occur in a specific scenario that we have seen before and were also able to reproduce internally:

If you are using sub-stores / sub-shops, and different webhook URLs are configured per store in the Adyen Customer Area, it is possible that webhook notifications are delivered to a webhook endpoint that does not correspond to the store where the order was actually created. In that case, the plugin will not be able to find the order by the temporaryID, resulting in repeated retries and the error you are seeing, which is expected behavior.

This leads exactly to the behavior you described (“Order with temporary ID still not created”), even though the order itself does exist.

We have received similar reports in the past, and in those cases, the root cause was indeed multiple webhook URLs.

Could you please confirm whether you are using sub-stores / sub-shops?

Thank you in advance!

Kind regards

[djspacedevil]

Hello @adyen-integrations-support ,

we dont use a sub-shop. We rename/change the default german to a different language/country.
The problem is not on all orders. The most will handle correct. But we see also a lot of orders where this not working well.

Thats the reason why I suggest the change with the fallback.

Best Regards

[adyen-integrations-support]

Good afternoon @djspacedevil ,

Thank you for the additional details and clarification.

We are still actively investigating this behavior on our side and taking into account the information you shared. At this stage, we are continuing the analysis to better understand why the issue occurs only for some orders.

Once we have more information to share, we will get back to you with an update.

Thank you for your patience.

Best regards

[djspacedevil]

Hello @adyen-integrations-support

is there a possibility to send you some information, eg over the official support?
So that you can see which MerchantAccount is affected and what we have in our logs and database,
so that you can better see or found the reason for it?

BR

[adyen-integrations-support]

Good afternoon @djspacedevil ,

For now, the information provided here is sufficient for our investigation. If we require any additional details (such as specific information, logs, etc), we will let you know in this thread.

We are still analyzing the case internally to better understand how this could occur.

Thank you for your patience. In the meantime, we are actively working on this and will get back to you as soon as we have more information.

Best regards

[adyen-integrations-support]

Hello @djspacedevil,

Thank you for your patience,

The plugin works in the following way: during the payment process, it generates a temporary ID and creates a transaction in Adyen, sending the generated temporary ID as the merchant reference. When the order is saved in Shopware, the plugin uses the same value for the temporary ID. In the Authorization webhook, Adyen sends the same value as the merchant reference, and the plugin uses it to find the corresponding order.

From this workflow, it is unclear to us how the case occurs on your side, where the order’s temporary ID has a different value.

So far, the only situations we have observed in which the plugin cannot find an order by its temporary ID are when the order has not yet been created, but a webhook has already been received. This usually occurs with payment methods that require redirection to the payment provider. After the customer completes payment, they are redirected back to the shop, and the plugin creates the order then. In some cases, Adyen may send the AUTHORIZATION webhook before the customer has been redirected and the order has been created, which leads to this situation.

Since, as you mentioned, the created order’s temporary ID on your side has a different value, could you please provide the following information:

• Whether you are using any third-party plugins that might modify order data in the database.

• If you have noticed whether this happens only with specific payment methods.

• If possible, please provide us with a System Information ZIP file. (Open General Settings page in the plugin, scroll down, in the same sidebar, click on System Information, then Download report).

Note: To avoid sharing sensitive data on the public repository, please send the System Information file via email to adyen-support@logeecom.com

This will help us investigate the issue more effectively.

Kind regards.

[djspacedevil]

Hello @adyen-integrations-support

I have sent the email. Please keep me informed.

Best Regards

[adyen-integrations-support]

Good morning @djspacedevil ,

Thank you for providing the system information and the additional files.

We are currently reviewing the logs and the information you shared in order to better understand the behavior you are experiencing. Our team is analyzing this internally and will update you as soon as we have more information.

Thank you for your patience, and we will get back to you shortly with our findings.

Kind regards

[adyen-integrations-support]

Hi @djspacedevil ,

When the customer adds products to the cart and proceeds to checkout, Shopware 5 creates an order in the database with the order number set to 0 and a temporary ID value. When the customer completes the payment with an Adyen payment method, the Adyen plugin updates the temporary ID to the merchant reference value and calls Shopware 5 to save the final order data. As a result, when a webhook arrives for such a transaction, the plugin can successfully locate the order.

After analyzing the queue.json logs you provided, we concluded the following:

Some webhooks have "success": false. This occurs when the payment transaction associated with these webhooks was not successful (for example: Refused, Not enough balance, Blocked Card, 3D Not Authenticated, etc.). Since the payment was not successful, the plugin does not update the order’s temporary ID to the merchant reference. Therefore, when a webhook arrives with that reference, the plugin cannot find the order. The order already exists in the database with the initial temporary ID created by Shopware, but it will not be fully completed. This is the expected behavior of the plugin.

There are also webhooks with "success": true, but all of them have the OFFER_CLOSED event code. This event is sent when the payment session is abandoned, and the payment was not completed (https://docs.adyen.com/api-explorer/Webhooks/1/post/OFFER_CLOSED). In this case as well, the plugin does not update the order's temporary ID to the merchant reference because the payment was not successfully finalized.

Therefore, this behavior is expected. The plugin cannot find the order when a webhook arrives for transactions that were not completed.

If you have any additional questions, please don’t hesitate to reach out.

Kind regards

[djspacedevil]

Hello @adyen-integrations-support ,

Thank you for the explanation. But that doesn’t solve the problem.
We can see that we also have orders where the payment has been confirmed—meaning they’re valid—yet they still can’t be found because the temporary ID is incorrect.

We didn’t have this problem in older versions of the plugin, since the order number or an internal Adyen number served as a reference. The mapping was better. Therefore, I would appreciate it if, as a fallback, a payment could still be processed even if it goes through.

Best regards

[adyen-integrations-support]

Good morning @djspacedevil

At the moment, we are investigating under which specific conditions this scenario can occur.

We are also taking your suggestion into consideration regarding implementing a fallback mechanism to allow such payments to still be processed even if the standard mapping fails.

Let us review this in more detail, and we will get back to you soon with a more concrete response.

Kind regards