Solving the Phantom Express Checkout Section in Magento 2.4.x Payment Step

Solving the Phantom Express Checkout Section in Magento 2.4.x Payment Step

Magento 2 store owners and developers often encounter subtle UI glitches that can impact user experience and conversion rates. One such issue, recently highlighted in a Magento 2 GitHub issue, involves an unexpected "Express Checkout" section appearing on the checkout payment step, even when all associated Payment Services (like PayPal Smart Buttons, Google Pay, and Apple Pay) are explicitly disabled.

This particular bug affects Magento Open Source and Adobe Commerce installations running version 2.4.x, specifically when the magento/module-payment-services-paypal module is at version 2.16.0. The regression was pinpointed between versions 2.14.0 and 2.16.0, indicating a recent change introduced the problem.

The Unwanted UI Element

The core of the problem manifests as an empty "Express Checkout" title and subtitle ("Or proceed with the standard checkout") rendered at the top of the payment step, but crucially, with no actual payment buttons in between. This creates a confusing and unprofessional look, suggesting functionality that isn't available.

Deep Dive into the Root Cause

The detailed analysis provided in the GitHub issue reveals a fascinating interplay between PHP configuration and frontend JavaScript logic. The issue stems from the view/frontend/web/js/view/payment/group.js file, which contains a function called expressMethodEnabled(). This function is responsible for determining whether the Express Checkout group should be rendered.

Originally, this function would check for the presence of an express key within the window.checkoutConfig.payment object for methods like payment_services_paypal_smart_buttons, payment_services_paypal_google_pay, and payment_services_paypal_apple_pay. Up to version 2.14.0, this worked by accident: the PHP configuration providers (e.g., GooglePayConfigProvider) only emitted the express array when the payment method was actually enabled.

However, a refactoring in version 2.16.0 changed this behavior. Specifically, Model/GooglePayConfigProvider.php and Model/ApplePayConfigProvider.php were updated to emit the express configuration unconditionally. Even when a method is disabled, getExpressPaymentConfig() now returns ['isVisible' => false]. The JavaScript logic, which simply checks for the presence of the express key (!!_.get(window.checkoutConfig.payment[method], 'express', false)), evaluates !!{isVisible: false} as true. This misinterpretation leads to the empty Express Checkout section being rendered.

The Proposed Solution and Workaround

The issue provides a clear and concise fix by modifying the JavaScript logic to check the actual visibility flag instead of just the key's presence. The suggested change for expressMethodEnabled() is:

return methods.some((method) => {    return _.get(window.checkoutConfig.payment[method], ['express', 'isVisible'], false) === true;});

For merchants and developers needing an immediate solution before an official patch is released, two workarounds are available:

• JavaScript Mixin: Create a JS mixin for Magento_PaymentServicesPaypal/js/view/payment/group to override the expressMethodEnabled() function with the corrected logic above. This is a targeted and clean solution for frontend customization.
• Module Disablement: Completely disable the Magento_PaymentServicesPaypal module if Payment Services are not being used on the store. While effective, this might be too broad if other parts of the module are needed.

This detailed bug report and its proposed solution are invaluable for the Magento community, offering a clear path to resolve a frustrating UI anomaly. It underscores the importance of meticulous frontend development and configuration management in complex e-commerce platforms like Magento 2. For those undergoing Magento migrations or managing existing stores, understanding such nuances is crucial for maintaining a seamless customer experience.