[GraphQL] molliePaymentMethods not using settings from adminhtml

[t-heuser]

Describe the bug If you get all the payment methods via the query molliePaymentMethods the field name is not translated into the language of the store/the title set in the Magento adminhtml is ignored. Also the query doesn't care about which payment methods I have enabled in the Magento adminhtml

Used versions

• Magento Version number 2.4.5
• Open source/Enterprise/B2b: Open Source
• Mollie version number: 2.17.0

To Reproduce

1. Set a different title for certain payment methods in Magento adminhtml
2. Disable some payment methods in Magento adminhtml
3. Execute the following query:

   query molliePaymentMethods {
   molliePaymentMethods {
   methods {
     code
     name
   }
   }
   }

Expected behavior The query uses the title I set in the Magento adminhtml for the payment methods. Only payment methods that are enabled in Mollie and Magento are returned.

Actual behavior No setting from the Magento adminhtml is respected. I have translated all the payment method titles seen below and disabled the method vouchers in Magento.

{
  "data": {
    "molliePaymentMethods": {
      "methods": [
        {
          "code": "applepay",
          "name": "Apple Pay"
        },
        {
          "code": "creditcard",
          "name": "Credit/Debit Card"
        },
        {
          "code": "klarnapaylater",
          "name": "Pay later."
        },
        {
          "code": "paypal",
          "name": "PayPal"
        },
        {
          "code": "banktransfer",
          "name": "Bank transfer"
        },
        {
          "code": "sofort",
          "name": "SOFORT Banking"
        },
        {
          "code": "giropay",
          "name": "giropay"
        },
        {
          "code": "voucher",
          "name": "Vouchers"
        }
      ]
    }
  }
}

Additional context In the Resolver you can see that the methods are directly fetched from Mollie and are not further processed.

[Frank-Magmodules]

HI @oneserv-heuser ,

We are happy to share that we've just released the new 2.18.0 version where we have fixed this issue.
Thank you for opening this issue and for the detailed issue report.

We are closing this issue now but please feel free to reopen the issue if this still occurs.