Code Monkey home page Code Monkey logo

Comments (5)

Anve94 avatar Anve94 commented on July 23, 2024 2

As a follow-up, I do believe moving towards website/store support is needed. To clarify why, let's imagine the following scenario:

Merchant has 3 website scopes: United Kingdom, Germany and Austria. In Germany and Austria, Adyen is used. In United Kingdom, another local PSP is used.

If I were this merchant, in the old flow (before 9.x) I would just:

  • Configure the Germany website scope for a German Adyen merchant account. Add the key, merchant account, other credentials to that scope and enable adyen_cc and adyen_hpp in the scope.
  • Do the same for Austria
  • Use the other PSP for United Kingdom according to their own requirements

Pretty straight forward: just configure the scope where it's needed and you're good to go.

In the new flow, as it stands, I would need to do the following:

  • Enable payment methods in the default scope because otherwise the recurring setup script doesn't enable any payment methods on the default scope
  • Configure the merchant account and appropriate credentials in the Germany and Austria scope. Configuring the payment method active field is not needed since it is inherited from the default scope.
  • Disable payment methods in the United Kingdom scope, and remember that for every new store in the future it should be disabled in that scope.

It's mostly this last part that's a bit irksome. In general I think it would be a cleaner solution if the recurring setup script would iterate over all the scopes, look for the payment methods config in that scope, and mutate the payment methods in that scope. This would be a win-win for everyone:

  • Developers/merchants that predominantly use the default scope can just enable the payment methods configuration in the default scope. The recurring script will only check that scope and configure all the payment methods in the default scope through the script.
  • If developers/merchants don't want to rely on the configuration fallback to much, they can just disable the payment method config field in the default scope, and enable it only for the websites/stores where it is relevant. This also prevents the issue where irrelevant stores not using Adyen will need to be configured explicitly to turn it off again and prevent inheriting from default.

from adyen-magento2.

RokPopov avatar RokPopov commented on July 23, 2024

Hi @dimitriBouteille, thank you for reporting this.

I have opened an internal ticket to address this issue. Once the PR introducing the fix is merged, this issue will be automatically closed.

Kind regards,
Rok

from adyen-magento2.

Anve94 avatar Anve94 commented on July 23, 2024

Hi @RokPopov, is there an ETA on this? Then I can determine whether I write my own fix for this or wait for the official update from Adyen.

from adyen-magento2.

Anve94 avatar Anve94 commented on July 23, 2024

As another follow-up, it just so happens that the default store scope for the merchant I'm upgrading adyen does not use adyen in that store. As a result, I either need to enable the payment methods in a store where Adyen is not used (making the configuration inaccurate), or fix the recurring data script.

In my case, we have the following setup:

  • Default scope (ID 0)
    • Website one (ID 1)
      • Is the default website
      • Store one (ID 1)
        • Is the default store of the website
        • Does not use Adyen
    • Website two (ID 2)
      • Store two (ID 2)
        • Does use adyen
    • Website 3 through 19
      • Various localized stores, some using Adyen and some not

The recurring script, which is run during every setup:upgrade, uses the scope store with a scope code of NULL and relies on the Magento scope resolver to determine the scope to read the payment/adyen_abstract/payment_methods_enabled from. This is problematic, since Magento resolves it to 1 which does not have Adyen enabled.

In the scenario above, we also do not want to enable Adyen for store scope 1 because:

  1. It will cause inaccurate configuration to be shown in the admin. Adyen is not used for this store but needs to have this configuration enabled to prevent issues with the recurring script
  2. While other payment methods will still be rendered, Adyen tries to load payment methods which either loads payment methods from the default scope (which we don't want) or produce a knockout js error (if no merchant account is configured).

I think long-term it would be great if Adyen can take a look at this flow again and offer proper multi-store support. In the interim, since I don't know if Adyen wants to adopt multi-store support, I am taking the quick route here and will patch the recurring script to enforce loading the config value from the default scope. This way, we can enable adyen in the admin/default scope, but still have it turned off for store 1 in the scenario above. This is still not ideal, since we need to configure adyen for every store that exists. With proper multistore support, it would be easier if we can just configure adyen on only the stores where it's needed. Now, we still need to make sure to explicitly configure adyen and turn it off in every irrelevant store, to prevent it from falling back to default.

Patch:

Context: Adyen assumes the PSP is enabled across the board and is lacking multistore support. When the default store configured (e.g. store 1, not store 0) does not use Adyen,
the plugin will disable all payment methods during every setup:upgrade, e.g. during every production release.
Issue: Adyen reads the payment_methods_active configuration through both an afterSave and during a Recurring script. There is no multi-store support for the recurring script.
While one may think the default scope configuration (with ID of 0) is read, this is not the case since the Magento ScopeResolver resolves the scope ID to the default website/store scope configured.
Let's say we have a website / store combination and the website is considered the default website and the store is the default store of that website. The store has an ID of 1.
The recurring adyen scripts will resolve to the store ID of 1 to read the config and determine if adyen payment methods are enabled. This is fine if Adyen is used in that store, but not fine if another PSP is used.
Enabling the configuration for store with ID 1 will produce knockout exceptions in the checkout (since Adyen should not be used here), and disabling it in store ID 1 will disable all payment methods every setup upgrade
since adyen only reads the active payment methods config from this store.
Resolution: Apply patch to ensure the recurring datascript reads the payment_methods_active configuration from the default/admin scope instead of resolving to the default store/website configured which
may not even use Adyen. This patch is still not ideal, since we'd expect adyen to be configurable on a per-store / per-website basis, instead of only in the global default scope.
Source: https://github.com/Adyen/adyen-magento2/issues/2596
===================================================================
diff --git a/vendor/adyen/module-payment/Helper/PaymentMethods.php b/vendor/adyen/module-payment/Helper/PaymentMethods.php
--- a/vendor/adyen/module-payment/Helper/PaymentMethods.php
+++ b/vendor/adyen/module-payment/Helper/PaymentMethods.php	(date 1716370283308)
@@ -168,7 +168,7 @@
         $enabledPaymentMethods = [];

         if (is_null($isActive)) {
-            $isActive = $this->configHelper->getIsPaymentMethodsActive();
+            $isActive = $this->configHelper->getIsPaymentMethodsActive('0');
         }

         foreach ($this->getAdyenPaymentMethods() as $paymentMethod) {

from adyen-magento2.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.