Order Guard module - prevents duplicate orders and duplicate payment or invoice statements

v1.2.02026/09/30

The flaw has a variant that version 1.1.0 didn't detect: when the payment module creates the order AFTER payment, what gets duplicated isn't the invoice, but the order itself . Each remains internally consistent—the invoice with its line items and its payment reconciled—so none of the three previous criteria flagged it. On a real store with 143,649 orders: 29 carts with two orders, and of the 54 most recent, version 1.1.0 would have flagged zero .

• New criterion duplicate_order : There is another LIVE order in the same cart with a different reference. The reference is what distinguishes it from a split by package, which PrestaShop does intentionally and in which all orders share the same reference—therefore, a unique index on orders.id_cart is not the correct array. This is checked in actionValidateOrder , which is when a new order is detected, and in each subsequent check.
• New screen: Orders → Duplicate Orders. Review and fix those already in the store, which until now had to be done manually one by one. It doesn't look at RKROG_SINCE : that date is for live monitoring, and this is precisely the place to see the previous one.
• The classification is the important part of that screen , and it comes from order_payment.transaction_id , which is core and doesn't depend on the payment gateway: A is one payment and two orders—the excess is canceled, there's no extra money—, B is two separate payments—money needs to be refunded, and that's decided by a person—, and C is undetermined, which is only listed. Only case A is modified.
• And what it doesn't do, which is equally important : if the surplus has a numbered invoice, the invoice is not touched (that requires a correction), if a package has been sent out, nothing is touched, the gateway is never called nor is a return issued, and nothing is executed in batches without marking and confirming it.
• Simulating counts exactly the same as executing. The entire decision resides in analizar() `, which doesn't write anything; aplicar() only executes what has already been decided. The report balances by construction ( grupos = reparados + saltados + sin nada ) and the screen warns if it ever doesn't balance.
• Stock is measured, not assumed. The core system returns stock upon cancellation, but only if the previous state was relevant and the product isn't handled through advanced management. Stock is measured before and after, and only what hasn't been returned is replenished: adding stock just in case would result in a double return, which is worse than not returning it at all.
• The gateway reference becomes the FIRST lock key. On a server that only allows one GET_LOCK per session, only the first key is used, and with the shopping cart in front, the two gateway calls were locking different names: zero mutual exclusion, and the module was installed, active, and doing nothing. The gateway reference is the only one that arrives via both paths—the server-to-server notification usually comes without any of our parameters.
• Optional logging of taken locks ( RKROG_TRACE , factory disabled). Without it, discovering the above takes an afternoon: there was no way to see which key had blocked a request.