Description
Preconditions (*)
- Magento 2.3.4
- A custom payment method created according to the instructions
- The payment method must have an availability validator which always returns false
Steps to reproduce (*)
- Get the available payment methods for a quote via MethodList::getAvailableMethods(). You can also use graphql as the resolver for the "available_payment_methods" field from a cart calls this method.
Expected result (*)
- The method should not be available as the default validator always returns false.
Actual result (*)
- The method is always available.
Cause of the problem
The cause of the problem is that Adapter::isAvailable() gets called from MethodList::getAvailableMethods(). The Adapter::isAvailable() method then tries to get the infoInstance as seen on line 290. If it's null it will not execute the availability validator from the validatorPool which would return false.
The infoInstance is ALWAYS null in this case as the method instance gets freshly created from it's factory. The MethodList::getAvailableMethods() sets the infoInstance AFTER it calls the Adapter::isAvailable() method. So there is no way the validator gets called when using the new Payment Provider Gateway.
I guess this issue was never found as all of magentos payment methods are using the deprecated AbstractMethod class. I think this should be fixed asap as the method MethodList::getAvailableMethods() MUST work for all payment methods, especially if they're implemented the way they should be and not with deprecated classes.
Possible workarounds
- Create a patch for MethodList::getAvailableMethods() and move line 76 below line 74.
This is definitly nothing I want to do as I have no idea about the side effects on other payment methods using the deprecated model. - Overwrite the Adapter::isAvailable() method and manually call the validator.
- Add an observer for "payment_method_is_active" event.
I will do this until this issue is fixed.
Please provide Severity assessment for the Issue as Reporter. This information will help during Confirmation and Issue triage processes.
- Severity: S0 - Affects critical data or functionality and leaves users without workaround.
- Severity: S1 - Affects critical data or functionality and forces users to employ a workaround.
- Severity: S2 - Affects non-critical data or functionality and forces users to employ a workaround.
- Severity: S3 - Affects non-critical data or functionality and does not force users to employ a workaround.
- Severity: S4 - Affects aesthetics, professional look and feel, “quality” or “usability”.