[PW-6860] Order cancelled in Magento but payment is correct in Adyen

[ifuents]

Describe the bug Order cancelled in Magento but payment is correct in Adyen.

To Reproduce Steps to reproduce the behavior:

1. Go to checkout and pay for order using Adyen Payment Method (Using Card Payments method)
2. Proceed with Payment and finish it successfully
3. Manually close de modal window before it closes by itself

Expected behavior: Order should not be cancelled and it should finish successfully

Magento version: 2.4.4

Plugin version: 8.2.2

Desktop:

• OS: Ubuntu 20.04.4 LTS
• Browser: Firefox 101.0.1 (64-bit)

Additional context After order is cancelled according to the steps to reproduce, Magento cron processes the Adyen Notification successfully and adds AUTHORISATION information to Order Notes (sales_order_status_history) but order remains cancelled.

Module is configured with default values. Payment Method used is Card Payments

[siimm]

Having exactly the same problem.

Running version 8.2.4 of Adyen module 2.4.2-p2 Magento version

It seems that at some point after authorisation in checkout, an ajax call is made to backend POST /rest/sv/V1/internal/adyen/paymentDetails with a payload of: {"payload":"{\"orderId\":\"<ORDER_ID>\",\"cancelled\":true}","form_key":"1vlmXXXXXXXXX"} based on this the backend cancels the order. However since it was actually successfully authorised, a success AUTHORISED callback is received and the order is actually paid for, but it stays in canceled state and status.

In case of correct behaviour a payload like this is posted to that endpoint: {"payload":"{\"details\":{\"threeDSResult\":\"ab<threeDencryptedvaluehere>c=\"},\"orderId\":\"<OREDER_ID>\"}","form_key":"XXXXXXXXXXX"}

had to revert the module to 7.x.x in order to continue receiving orders. This happens to about 20% of total adyen_cc orders It sounds a bit like some sort of race condition perhaps.

[RokPopov]

Hi @ifuents , @siimm

Thank you for reporting this issue. It seems like we are setting the order to cancelled in this code block and we are making a paymentDetails call in this line. Looks like we are not checking whether the call was successful before setting the order to cancelled state.

I have opened an internal ticket and we are further investigating this issue.

Meanwhile, could you confirm that this related to the 3DS2 transactions?

Thank you in advance.

Kind regards, Rok, Adyen

[siimm]

@RokPopov The problem seems to be related to 3DS2 transactions indeed.

My colleagues have identified that the closing of the 3D secure pop-up window. Submit button submits the payload and closes the window, during the closing, the cancel request is also fired (twice).

When the 3D secure window is submitted, it does total or 3 requests, first one is meaningful and other 2 are cancelling ones.

P.S. This caused 2 different flavors of orders - canceled state orders and reserved orders, which both start as cancelled and some move to reserved after AUTHORISATION callback is processed (while still having cancelled amounts in the totals fields).

[ifuents]

Hi @RokPopov!

Yes, in all our cases 3DS2 transaction is being used.

Thank you in advance. Kind regards.

[dronerdk]

We also face the issue if we create an admin order and use Adyen PayByLink. After the customer has paid the order will be cancel. You can see the comments from mangento here: The issue here is that the order get canced because customer dont have 3DS. But right after he pays with 3DS. but the order got cancled.

Jun 23, 2022 3:20:04 PM Canceled Customer Not Notified Adyen HTTP Notification(s): eventCode: AUTHORISATION pspReference: YYY paymentMethod: mc success: true reason:151731:0824:08/2023

Jun 23, 2022 3:18:05 PM Canceled Customer Not Notified

Order cancelled Jun 23, 2022 3:18:05 PM Pending Customer Not Notified Adyen HTTP Notification(s): eventCode: AUTHORISATION pspReference: XXX paymentMethod: mc success: false reason:3D Not Authenticated

Order Placed by Store Administrator Jun 23, 2022 2:57:52 PM Pending Customer Not Notified

[siimm]

Hi @RokPopov Providing some input on the case and how to reproduce it, perhaps it can help you:

It is possible to reproduce, when either Adyen API or success page on Magento loads slow.

• Open the 3DS2 window on checkout, submitting that window will fire an ajax call to /V1/internal/adyen/paymentDetails which will eventually return a redirect url (for success page) - the redirect is happening here: https://github.com/Adyen/adyen-magento2/blob/f814d4c095b04d775faced7bdad8f10866354612/view/frontend/web/js/view/payment/method-renderer/adyen-cc-method.js#L289

• Note that after submit in the modal is pressed, the modal contents will disappear, leaving only a cross to close the modal, until the ajax comes back with redirect link and redirect happens.

• In case the ajax request is processed for an extended period of time ~3 seconds or more, then this gives the customer the opportunity to press the cross on the modal - which immediately fires a cancelling ajax call, which is usually quick, as no API interaction is done there and the order is cancelled.

• However, since the first request was in progress at the same time, it will eventually finish and redirect customer to success page, with the order actually cancelled and money reserved.

Admin interface for that order looks like this:

The issue can be reproduced with ease, when https://github.com/Adyen/adyen-magento2/blob/f814d4c095b04d775faced7bdad8f10866354612/Model/Api/AdyenPaymentDetails.php#L85 method processing has some delay. Then it is very easy to submit the 3DS window and also close it afterwards.

Our solution in order to make it work was to add a flag (semaphore like) whenever the submit is made and when closing the modal, we look at that flag and decide whether to send cancel request or just to close the modal. Regards, Siim

[siimm]

one more update, which helps a lot when reproducing:

• it is even easier to reproduce this by throttling the network speed from browser dev tools. So cases like this happening on production environment are just customers with bad connection speed.

It is quite hard to create a workaround for the phase where 3DS2 window is silently processing "something" and no callbacks to Magento are made yet, during that time (before the modal goes blank) it is impossible to prevent users from closing the popup additionally.

[RokPopov]

Hi @siimm,

Thank you for the details provided and the suggested solution. I can confirm I have been able to reproduce the issue and opened an internal ticket for this. We highly appreciate your suggestion and it will definitely be taken into consideration.

Thank you in advance,

Kind regards, Rok, Adyen

[frqnck]

Hi all,

Pre v8, the 3DS stuff was via redirect but then for some reason Adyen decided to impose that ill conceived modal workflow without, it seems, much testing. Wondering actually if Adyen has any acceptance testing in place?

This resulted in loads of very unhappy shoppers and a headaches for everyone involved.

Meanwhile those affected (or better Adyen) should disable that modal and use the old redirect method, see https://github.com/Adyen/adyen-magento2/issues/1260

We released a hot-fix on our instances which stopped the erosion… but seriously why was that variable hardcoded to True in the first place?

[RokPopov]

Hey @frqnck!

Thank you for your feedback, this is much appreciated! We decided that the plugin should support 3DS2 natively as we would like to encourage this flow. Therefore, we decided to hardcode the $requestBody['additionalData']['allow3DS2'] to true. However, the issue at hand is that clicking the X button to close the popup modal is triggering the code in the adyen-payment-modal.js, which was introduced with this PR as an answer to this Issue. With the mentioned PR, we are hardcodingrequest.cancelled to true so that the order is closed and the shopper can select another payment method without having to refresh the checkout page. However, with slow internet connections, the shopper can still press the X button even after submitting the payment. Therefore, the /payment-details call is already made to Adyen platform and after that, the order is cancelled in Magento. To omit that possibility, I have written a fix which hides the X button within the popup modal, so the shopper doesn’t have the possibility of cancelling the order after the /payment-details call is already made. At this point, Magento waits for the response from Adyen and doesn’t cancel the order.

What do you think of this approach and would you have any suggestions?

Kind regards, Rok, Adyen

[frqnck]

Hi @RokPopov,

Thank you for the feedback.

Using modals on these checks is an additional opportunity to loose conversions. That ´X’ close button in the midst of finalising a payment is another distraction we would rather not have... The less opportunities to cancel at this stage, the better — inline provides less friction esp on mobile devices and that’s what we suggest sticking with.

Having the choices to return to this would seem preferable to us so for the time being we will keep our patch in place.

What is the best option to test 3DS? The Adyen test cards don’t seem to be 3DS?

[tieroom]

We are on plugin version 8.3.4 (Magento 2.4.4-p1, PHP 8.1) and still seeing these. All seem to be CC transactions that have passed 3DS2.

[gauravharshranosys]

We are using Adyen version 8.3.4 and we got the latest merge in code, but still, this issue is occurring. The payment was made through "Alternative Payment Methods (Google Pay)".

[Nuranto]

We have regularly the same issue with Adyen 8.4 and Magento 2.4.5

[Nuranto]

reproducible on 8.5

[Krielkip]

We are having this with Dutch Ideal which does not have 3DS2

Oct 2, 2022 1:04:18 PM Canceled Customer Not Notified
Adyen HTTP Notification(s):
eventCode: AUTHORISATION
pspReference: SGC335BMNXN[...]
paymentMethod: ideal
success: true
reason:null

Oct 2, 2022 12:55:39 PM Pending Customer Notified

Oct 2, 2022 12:55:39 PM Customer Not Notified
Adyen Result response:
authResult: RedirectShopper
pspReference: SGC335BMNXN[...]

Oct 1, 2022 9:49:04 PM Canceled Customer Not Notified
Adyen HTTP Notification(s):
eventCode: AUTHORISATION
pspReference: VTX4XQ32549[..]
paymentMethod: ideal
success: true

Oct 1, 2022 9:47:44 PM Canceled Customer Not Notified
Adyen Result URL response:
authResult: Authorised
pspReference: VTX4XQ32549[..]
paymentMethod:

Oct 1, 2022 9:44:06 PM Pending Customer Notified

Oct 1, 2022 9:44:06 PM Customer Not Notified
Adyen Result response:
authResult: RedirectShopper
pspReference: VTX4XQ32549[..]

[tieroom]

Still getting these on 8.6.0

[Nuranto]

I hope I'm not talking too fast, but it seems it is fixed in 8.7.0

[Morerice]

Hi all,

This issue should be resolved when it comes to card payments. However, we are still seeing some occurrences of it when using other payment methods, which is why this issue is still open.

Thanks, Jean Adyen

[tieroom]

@Morerice Brilliant, I'll make sure to get 8.7.0 installed before bugging you again 🙂

[Morerice]

Hi all,

As of 8.9.0, the issue should also be resolved (due to https://github.com/Adyen/adyen-magento2/pull/1802) on all other payment methods that involve a modal.

Thanks, Jean Adyen