Critical Issue – Reservation ID Handling and Order Deletion

[antoniocarboni]

The payment module is exhibiting two critical and unacceptable behaviors affecting order integrity:

Premature Reservation ID Generation:
The module creates a reservation ID as soon as the customer is redirected to the payment gateway. This leads to the generation of a large number of reservation IDs even when the checkout is abandoned or the payment is not completed. These IDs remain locked and unusable, causing unnecessary overhead of available reservation IDs.

Order Deletion After Payment with a Different Method:
When a customer recovers their cart and completes the checkout using a different payment method (e.g., bank transfer), the module initially used (e.g., Qenta) still proceeds to delete the order after a timeout or webhook.
This has resulted in completed and paid orders being permanently deleted from the Magento database, which is extremely serious and unacceptable behavior in an e-commerce system.
A payment module should never delete an order, especially not one that was completed with another method.

Expected Behavior and Best Practices:

If the customer switches to another payment method or recovers their cart, the module must not interfere with the order process.

At most, the module should mark its own transaction as expired or cancelled, but must never delete the order in Magento.