We have recently had several occurrences where after a successful payment, the customer would navigate the browser back to the redirect page /ingenico/payment/redirect/.
Unfortunately, this causes that Block/Method/View::setOrderRedirected is called again, which means that the order status is being reset from "Payment received" back to "Payment pending". This results in paid orders being displayed as unpaid, which of course is a big concern.
Two thoughts about this:
If setOrderRedirected really requires an order status change, it must be verified that the order is eligible for such a status change: the payment should still be initialised, for example.
However, since AbstractMethod:: initialize already sets the status that corresponds with Pending payment, it looks like the requirement to change the status is not present. It also "feels" very odd, that the order status change is being triggered from a template file (this method is only called from two templates), as display should not manipulate data.
The best approach, in my opinion, is to move the addStatusToHistory call towards the controller Ingenico\Payment\Controller\Payment\Redirect, add a check for the PENDING_PAYMENT state and remove the order status change there.
Please let me know if this customer behavior should be prevented in another file, but we did not find it.
We have recently had several occurrences where after a successful payment, the customer would navigate the browser back to the redirect page
/ingenico/payment/redirect/.Unfortunately, this causes that
Block/Method/View::setOrderRedirectedis called again, which means that the order status is being reset from "Payment received" back to "Payment pending". This results in paid orders being displayed as unpaid, which of course is a big concern.Two thoughts about this:
If
setOrderRedirectedreally requires an order status change, it must be verified that the order is eligible for such a status change: the payment should still be initialised, for example.However, since
AbstractMethod:: initializealready sets the status that corresponds withPending payment, it looks like the requirement to change the status is not present. It also "feels" very odd, that the order status change is being triggered from a template file (this method is only called from two templates), as display should not manipulate data.The best approach, in my opinion, is to move the
addStatusToHistorycall towards the controllerIngenico\Payment\Controller\Payment\Redirect, add a check for thePENDING_PAYMENTstate and remove the order status change there.Please let me know if this customer behavior should be prevented in another file, but we did not find it.
Cheers