You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I have noticed that the frontend cancelation endpoint doesn't modify the state of the order (into cancel), though that the same endpoint will decrement the coupon usage.
Given that this url is called by the user, there are 2 edge case situations that can occur:
The user visits the endpoint multiple times (locally reproduced by spamming the cancel button on the payment page): I was able to reduce the coupon code usage multiple times. Luckily the coupon usage counter cannot go below 0 and the usage limit of a coupon would be set to 1, so this issue shouldn't happen too often.
The user doesn't visit the cancelation endpoint, or hit it too late (because it is triggered after a call to the notify endpoint to put the order on cancel, not sure if this could happen). In this case, the coupon code usage will not decrement.
In the ideal case, the coupon decrement should happen when the order is changing its state to cancel or happen in a way that ensures the decrement count is guaranteed to be called once during cancelation.
The text was updated successfully, but these errors were encountered:
We have looked into this before and the tricky part is that we actually do process the cancel of the order inside the incoming MultiSafepay webhook to the notification controller, but sometimes this webhook can have a few seconds delay. So whenever someone clicks on the cancel button and we would process the decrement of the coupon on the webhook instead, it could be that their quote will not have the restored coupon inside it, because Magento restored the quote at the moment the coupon was not decremented yet. So someone could then see their quote restore, but their coupon not being returned.
They can still add the coupon back to the quote, but only after the webhook has processed the decrement. You could also argue for the reason why we do not decrement the coupon in both places, the incoming webhook and the Cancel controller, but sometimes the incoming webhook will process the decrement at exactly the same time and will result in double decrements due to race conditions.
I will look into decrementing the coupon when we cancel the order in the incoming webhook and come back to you with an update later.
I have noticed that the frontend cancelation endpoint doesn't modify the state of the order (into cancel), though that the same endpoint will decrement the coupon usage.
Given that this url is called by the user, there are 2 edge case situations that can occur:
In the ideal case, the coupon decrement should happen when the order is changing its state to cancel or happen in a way that ensures the decrement count is guaranteed to be called once during cancelation.
The text was updated successfully, but these errors were encountered: