One Renderer per Payment Method: A Merged Fix for Adyen's Magento 2 Plugin

A detailed bug report, a five-line patch, and two approving reviews in the Adyen payment plugin for Magento 2.

Réponse courte

The Adyen Magento 2 plugin registered two checkout renderers for any payment method listed in both txVariants and customMethodRenderers. The fix skips the generic renderer whenever a custom one exists, so each method gets exactly one. It was merged as PR #3332 and closed issue #3329.

The problem

Adyen/adyen-magento2 is Adyen's payment plugin for Magento 2. The checkout builds a list of payment renderers in view/frontend/web/js/view/payment/adyen-methods.js.

The issue report traced the bug precisely. The file pushed a generic adyen-pm-method renderer once for every entry in txVariants, and then a custom renderer for every entry in customMethodRenderers, with no check for keys present in both. On version 10.10.2, the reporter counted 14 of 17 custom renderers that also appeared in txVariants, including PayPal, Apple Pay, Google Pay and Amazon Pay.

According to the report, Magento then created two component instances under the same name. The extra one stayed alive and kept re-mounting on every quote refresh. For PayPal, the report described a failure where the SDK could load without the order currency and reject the payment with a currency mismatch.

The fix

const customMethodRenderers = window.checkoutConfig.payment.adyen.customMethodRenderers || {};
// Push payment method renderers for alternative payment methods
Object.keys(adyenTxVariants).forEach((index) => {
    if (customMethodRenderers[index]) {
        return;
    }

    rendererList.push({
        type: index,
        component: paymentMethodComponent

txVariants itself is left intact, because custom renderers that extend adyen-pm-method still read from it through getTxVariant().

By the numbers

• Repository: Adyen/adyen-magento2, 167 stars (Nov 3, 2026), PHP, MIT
• Files changed: 1
• Lines: +5 / -1
• Commits: 5 (2 from the PR author, 3 maintainer merges of main)
• Opened: Aug 21, 2026. Merged: Oct 28, 2026. Time to merge: 68 days
• Review: 2 approving reviews, including one from the maintainer who merged it

How the review went

An automated reviewer suggested a simpler check: test customMethodRenderers[index] for truthiness instead of calling Object.prototype.hasOwnProperty. The follow-up commit adopted that, which is the version shown above.

Two reviewers approved the change in early October. At the end of the month a maintainer brought the branch up to date with main (three merge commits) and merged it. Their closing note: "Thank you for your contribution! This PR has been merged and will be released soon."

Takeaways

• A good bug report does most of the diagnosis. Here, the job was to turn it into the smallest correct change.
• Guarding the loop, rather than editing the configuration data, kept behavior intact for renderers that depend on txVariants.

FAQ

Does this change which payment methods appear at checkout?

No. Every method still gets a renderer. Methods with a custom renderer now get only that one, instead of the custom renderer plus the generic one.

Where can I read more?

See the pull request and the original issue.

Le but

Checkout bugs are expensive because they hide inside race conditions. A narrow guard that removes the duplicate at its source is easy to review, easy to revert, and easy to trust.