[ECP-9154][ECP-9491] Excessive calls (100+ per asset) to checkoutShopper assets

[SamJUK]

Describe the bug
The checkout is making an excessive amount of network requests to the https://checkoutshopper-test.adyen.com/checkoutshopper/assets/... domain. We are seeing over 100 requests each to dfp.1.0.0.html fingerprintjs2.js risk.1.0.1.js. See attached Google Drive link for example

On Safari this is causing a long running loader and a flood of console errors from fingerprintjs2.js There are too many active WebGL contexts on this page, the oldest context will be lost.
And on Chrome similar network activity without the console spam / long running loader.

To Reproduce
Steps to reproduce the behavior:

1. Navigate to checkout
2. Wait for payment methods to load
3. View Network tab and filter for checkoutShopper

Expected behavior
A single request for each checkoutShopper asset.

Magento version
2.4.6-p8

Plugin version
9.9.1

Screenshots
https://drive.google.com/file/d/1SMHvnWSeVb1_uUu2kl2iAn0mXvQVNXuF/view?usp=sharing

Desktop (please complete the following information):

• OS: MacOS 15.0
• Browser Chromium: 129.0.6668.89 + Safari 18.0

Additional context
From an initial quick look, it appears we are accidentally building the checkout component for every payment method instead of just once.

Placing a breakpoint on the subscribe method shows a subscription being bound for every payment method (101 times), even if they are not used on the merchants account.

If you place a breakpoint on the createCheckoutComponent method, you can step through and switch to the network tab and see another set of the js files being loaded.

https://github.com/Adyen/adyen-magento2/blob/main/view/frontend/web/js/view/payment/method-renderer/adyen-pm-method.js#L71

https://github.com/Adyen/adyen-magento2/blob/main/view/frontend/web/js/view/payment/method-renderer/adyen-pm-method.js#L86

https://github.com/Adyen/adyen-magento2/blob/main/view/frontend/web/js/view/payment/method-renderer/adyen-pm-method.js#L86

[Januszpl]

I can confirm reported issue. I will also add that
opening 3DS modal take ages and take a lot of memory as well.

In our case it is related to version:
version: 9.7.2

[PeteBED]

We originally thought this was part of the module update to 9.9.1 as we saw it first on our UAT environment. However today we're seeing this on production with version 9.5.2. Is this functionality pulled in dynamically by Adyen?

It causes crashes in iOS Safari and customers are leaving the site frustrated so it's critical for us to understand the issue.

We're generating so many requests that Adyen is responding with HTTP 429.

[Januszpl]

@PeteBED are you using onestepcheckout or standard Magento2 checkout?

[PeteBED]

@PeteBED are you using onestepcheckout or standard Magento2 checkout?

Using Amasty's one step checkout module.

[SamJUK]

Just to note, we are also seeing the same issue on the v8 version of the plugin (Magento 2.4.4-p11) albeit to a lesser degree (minus the performance impact).

I assume this is because of the abstraction in v9 from adyen-hpp-method -> adyen-pm-method

[JamelleG]

I can confirm that we're also encountering the same issue, which we only noticed during testing on Safari due to slow loading. This problem has also been previously reported here: #2581.

There is a temporary workaround to disable risk collection, but no permanent solution is available at this time.

[candemiralp]

Hello @SamJUK,

Thank you for reporting this issue. A similar issue was reported before on #2581, in which only virtual products were affected. Are you facing this issue on only virtual products or is this a broader issue on checkout?

FYI @Januszpl @JamelleG @PeteBED

Best Regards,
Can

[PeteBED]

All Config/Simple products here, no Virtual

[candemiralp]

Thank you @PeteBED. Let me try to reproduce the issue. I will get back to you soon.

[PeteBED]

Thank you @PeteBED. Let me try to reproduce the issue. I will get back to you soon.

If it helps the patch suggested in #2581 does resolve the issue for us as expected.

[SamJUK]

I would say disabling the risk checks is a valid short term workaround, although I am still keen on a proper resolution.

As the risk checks provide important functionality, especially heading into the Sales Period (Black Friday, Christmas, New Year etc). Where it is not uncommon to seem a rise in carding attacks.

[SamJUK]

@candemiralp is there anything unique to the AdyenCheckout component? It seems to be passing the exact same data for all payment methods.

Would creating a hash of the available paymentMethodsResponse, and storing it in a global context be a bit more of a robust workaround that would still allow risk checks to take place? Something like below, it seems to work in a local environment.

--- vendor/adyen/module-payment/view/frontend/web/js/model/adyen-checkout.js
+++ vendor/adyen/module-payment/view/frontend/web/js/model/adyen-checkout.js
@@ -21,7 +21,14 @@
         return {
             buildCheckoutComponent: function (paymentMethodsResponse, handleOnAdditionalDetails, handleOnCancel = undefined, handleOnSubmit = undefined) {
                 if (!!paymentMethodsResponse.paymentMethodsResponse) {
-                    return AdyenCheckout({
+
+                    const checkoutContextKey = Object.keys(paymentMethodsResponse.paymentMethodsResponse).join('');
+                    window.adyenCheckoutContexts = window.adyenCheckoutContexts || {};
+                    if (window.adyenCheckoutContexts.hasOwnProperty(checkoutContextKey)) {
+                        return window.adyenCheckoutContexts[checkoutContextKey];
+                    }
+
+                    return window.adyenCheckoutContexts[checkoutContextKey] = AdyenCheckout({
                             locale: adyenConfiguration.getLocale(),
                             clientKey: adyenConfiguration.getClientKey(),
                             environment: adyenConfiguration.getCheckoutEnvironment(),

[candemiralp]

Hello @SamJUK,

I wouldn't follow this approach as some payment methods might override the default event callbacks such as onAdditionalDetails or onSubmit.

Please check the following comment.

Best Regards,
Can

[candemiralp]

Hello All,

Thank you for your patience. We have introduced a POC to this issue and are looking forward for some pilot tests. Could you please share your insights on the PR #2770?

Best Regards,
Can

[SamJUK]

Thanks for getting through this so quickly Can!
We'll get it deployed to some pre-production environments in the next day or two and let you know.

[candemiralp]

Hello @SamJUK,

Thank you for testing it out. We are looking forward to hearing from you.

Best Regards,
Can