Skip to content

Custom payment methods are always available when using new Payment Provider Gateway #33869

Open
@t-heuser

Description

@t-heuser

Preconditions (*)

  1. Magento 2.3.4
  2. A custom payment method created according to the instructions
  3. The payment method must have an availability validator which always returns false

Steps to reproduce (*)

  1. 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 (*)

  1. The method should not be available as the default validator always returns false.

Actual result (*)

  1. 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

  1. 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.
  2. Overwrite the Adapter::isAvailable() method and manually call the validator.
  3. 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”.

Metadata

Metadata

Assignees

Labels

Area: PaymentsComponent: PaymentIssue: ConfirmedGate 3 Passed. Manual verification of the issue completed. Issue is confirmedPriority: P2A defect with this priority could have functionality issues which are not to expectations.Progress: dev in progressReproduced on 2.4.xThe issue has been reproduced on latest 2.4-develop branchTriage: Dev.ExperienceIssue related to Developer Experience and needs help with Triage to Confirm or Reject it

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions