Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Order status incorrectly resets when navigating back after payment success #26

Open
lphilippo opened this issue Sep 29, 2021 · 0 comments

Comments

@lphilippo
Copy link
Contributor

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.

Cheers

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant