lock issues prevent capture of payment
Opened this issue · 4 comments
hello,
In our high-traffic environment, it's often the case that a lock cannot be obtained, resulting in an uncaptured order.
Would it be possible to add the payment ID to the lock identifier to avoid errors with parallel payments, or could this lead to overwritten payments?
I've looked deeper into the case, and I think the lock is not the fault but "processing" is set to true, so a PaymentBeingProcessedException is thrown. When this happens in the PrepareAssertAction it repeats 100 times and then a redirect happen.
I'm not sure what happened after the redirect. The only thing I can say is that there is no capture call.
I'll try to provide more information, but at the moment I'm a bit limited in what I can debug and have to wait for the customer to provide me with new "failed" orders.
So after more debugging the problem seems to be that a google "Read-Aloud" assistant is accessing the order/{TOKEN}/pay link. this happened at all failed orders. And would also cause the multiple payment page init requests mentioned by the Saferpay customer support.
sorry for this confusing ticket
Hey Daniel!
I'm sorry for not getting back to you sooner. Could you tell me more about the traffic that you are having that causes this issue? It would help me to reproduce your issue. The main problem is related to the fact that some of your orders cannot be closed due to the locking exception. Did you try it out with the payment ID being part of the lock name? Can we make a fork of the code, try it out and see if the problem remains and if not, we will backport that change to the main repository?
Hi lukasz,
the lock is not the problem like I thought in the beginning. In the log where multiple messages about the lock but the problem is not there. sorry for the misleading information.
The real problem happens when the order/{TOKEN}/pay URL is called multiple times. Because in https://github.com/CommerceWeavers/SyliusSaferpayPlugin/blob/main/src/Payum/Action/AuthorizeAction.php#L53 every call to this URL overrides the Saferpay token on the payment.
If the user calls the URL in the browser there is no problem because he will finished the order with the last token, but like I mentioned in my last comment, the flow is that the user completes the order and is redirected to the payment page, but at the same time the "google read aloud" bot calls also the pay URL and this leads to a wrong token in the database. When the user finished the payment on the payment page and is redirected to the shop, the assert call uses the "last" Saferpay token which is not the correct one for the first payment page init call, so Saferpay returns a error response.
As quick fix we have blocked the Read-Aloud bot on the order pay route, after that the last response from the customer is that there are no more unfinished authorized payments.
But I think this workaround is not the correct approach because every other bot/app could call the URL in the background.
I think at this point there somehow should be a lock process, that the Saferpay init call is only processed once for each payment.
I hope this will help, for any questions feel free to ask :)