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
There is a small bug with the payment method Twint with classic magento - I have not tested with the other methods - in headless integration (graphql) no problem :
On the test environment, if the client goes to /adyen/return twice, the page /checkout/success is displayed the second time.
On the production env, if the customer clicks Cancel payment, the success page is displayed.
The problem between the two environments is slightly different but the source is the same: the function Adyen\Payment\Controller\Return\Index::validateRedirectResponse().
validateRedirectResponse :
When calling the /adyen/return for the first time, this function returns false.
On the second call, there is a check using the isResponseAlreadyProcessed function to verify whether the payment has already been processed or not. The problem is that isResponseAlreadyProcessed returns true.
The isResponseAlreadyProcessed function is based on the order history to know if the reference PSP reference exists in the comments. On the second call, there is a comment with the PSP reference and returns true without checking if the payment is valid, canceled, ...
if (str_contains($comment, $pspReference) !== false) {
returntrue;
}
}
returnfalse;
Here is what happens globally :
First call to /adyen/return
Save order history with PSP reference
validateRedirectResponse return false
Redirect to /cart with error
Second call to /adyen/return
isResponseAlreadyProcessed returns true because the PSP reference exist in order comment history
validateRedirectResponse returns true
Redirect to /checkout/success with canceled error -_-
To Reproduce
In testing environment :
Place order with Twint method
Cancel payment
/checkout/cart page is displayed with error (payment canceled)
Call /adyen/return with same arguments
/checkout/success is displayed with error (payment canceled)
In production environment :
Place order with Twint method
Click on Cancel payment in Twint interface
/checkout/success is displayed with error (payment canceled)
Between the production and test env, there is a difference since on the production environment Twint or Adyen makes two calls to /adyen/return, I do not know why:( Here is an example of the logs in production :
[2024-10-17T10:12:24.531466+00:00] AdyenLoggerTest.ADYEN_RESULT: Processing redirect response Ctx|[]| Extra|{"uid":"2a8c72f"}|
[2024-10-17T10:12:25.108650+00:00] AdyenLoggerTest.ADYEN_RESULT: Updating the order Ctx|[]| Extra|{"uid":"2a8c72f"}|
[2024-10-17T10:12:25.170563+00:00] AdyenLoggerTest.ADYEN_RESULT: The order cannot be cancelled Ctx|[]| Extra|{"uid":"2a8c72f"}|
[2024-10-17T10:12:25.298058+00:00] AdyenLoggerTest.ADYEN_RESULT: /vendor/adyen/module-payment/Controller/Return/Index.php Ctx|{"result":false,"HTTP_REFERER":"https://pay.twint.ch/"}| Extra|{"uid":"2a8c72f"}|
[2024-10-17T10:12:25.378610+00:00] AdyenLoggerTest.ADYEN_RESULT: Payment for order 25000147608 was unsuccessful, it will be cancelled when the OFFER_CLOSED notification has been processed. Ctx|[]| Extra|{"uid":"2a8c72f"}|
[2024-10-17T10:12:27.556453+00:00] AdyenLoggerTest.ADYEN_RESULT: Processing redirect response Ctx|[]| Extra|{"uid":"f685fca"}|
[2024-10-17T10:12:27.959283+00:00] AdyenLoggerTest.ADYEN_RESULT: Duplicate response detected. Skipping processing. Ctx|[]| Extra|{"uid":"f685fca"}|
[2024-10-17T10:12:27.959642+00:00] AdyenLoggerTest.ADYEN_RESULT: /vendor/adyen/module-payment/Controller/Return/Index.php Ctx|{"result":true,"HTTP_REFERER":"https://pay.twint.ch/"}| Extra|{"uid":"f685fca"}|
Expected behavior
If customer cancel payment, page /checkout/cart must be displayed in all cases with error (e.g: Payment canceled).
Magento version
2.4.5-p10
Plugin version
9.8.0
The text was updated successfully, but these errors were encountered:
Hello !
There is a small bug with the payment method Twint with classic magento - I have not tested with the other methods - in headless integration (graphql) no problem :
/adyen/return
twice, the page/checkout/success
is displayed the second time.Cancel payment
, the success page is displayed.The problem between the two environments is slightly different but the source is the same: the function
Adyen\Payment\Controller\Return\Index::validateRedirectResponse()
.validateRedirectResponse :
When calling the
/adyen/return
for the first time, this function returnsfalse
.On the second call, there is a check using the
isResponseAlreadyProcessed
function to verify whether the payment has already been processed or not. The problem is thatisResponseAlreadyProcessed
returnstrue
.The
isResponseAlreadyProcessed
function is based on the order history to know if the reference PSP reference exists in the comments. On the second call, there is a comment with the PSP reference and returnstrue
without checking if the payment is valid, canceled, ...adyen-magento2/Controller/Return/Index.php
Lines 198 to 216 in e3af5ed
Here is what happens globally :
/adyen/return
validateRedirectResponse
returnfalse
/cart
with error/adyen/return
isResponseAlreadyProcessed
returnstrue
because the PSP reference exist in order comment historyvalidateRedirectResponse
returnstrue
/checkout/success
with canceled error -_-To Reproduce
In testing environment :
Twint
method/checkout/cart
page is displayed with error (payment canceled)/adyen/return
with same arguments/checkout/success
is displayed with error (payment canceled)In production environment :
Twint
methodCancel payment
in Twint interface/checkout/success
is displayed with error (payment canceled)Between the production and test env, there is a difference since on the production environment Twint or Adyen makes two calls to
/adyen/return
, I do not know why:( Here is an example of the logs in production :Expected behavior
If customer cancel payment, page
/checkout/cart
must be displayed in all cases with error (e.g: Payment canceled).Magento version
2.4.5-p10
Plugin version
9.8.0
The text was updated successfully, but these errors were encountered: