Unnecessary Braintree Apple Pay API Calls: A Magento 2 Performance Deep Dive

Unnecessary Braintree Apple Pay API Calls: A Magento 2 Performance Deep Dive

As e-commerce migration experts at Shopping Mover, we constantly monitor the Magento ecosystem for insights that can impact store performance and developer experience. A recent GitHub issue (#41113) has brought to light a significant performance concern within Magento 2's Braintree Apple Pay integration, affecting merchants who have this payment method enabled.

The Core Issue: Eager API Calls

The problem stems from the PayPal\Braintree\Block\ApplePay\AbstractButton constructor. Unlike its Google Pay counterpart, the Apple Pay button block eagerly initiates a call to the Braintree API to generate a client token. This happens unconditionally during the block's construction, even before Magento checks if the Apple Pay button should actually be displayed on the page.

Specifically, the issue author, sevka, identified that the following call stack is executed synchronously upon block instantiation:

Braintree\Http::_doRequest
PayPal\Braintree\Model\ApplePay\Ui\ConfigProvider::getClientToken
PayPal\Braintree\Model\ApplePay\Auth::get
PayPal\Braintree\Block\ApplePay\AbstractButton::__construct

This sequence leads to a live HTTP request to the Braintree gateway. This premature API call occurs in two primary scenarios:

• Every Product Detail Page (PDP) View: The Apple Pay button block is statically declared in catalog_product_view.xml, meaning it's constructed on every single PDP load, regardless of whether the button will eventually render.
• Mini-Cart/Cart Section Reloads: Similar behavior is observed when the cart customer-data section is recomputed, triggering the construction of the Apple Pay shortcut button.

Impact on Performance and API Usage

The consequences of this eager API call are noteworthy. Merchants with Braintree Apple Pay enabled experience an additional, avoidable live Braintree API request on virtually every PDP view and potentially other pages. While the client token is cached for the lifetime of that instance (meaning "one extra call per HTTP request" rather than per block instantiation), this still translates to:

• Increased response times for Product Detail Pages.
• Unnecessary load on the merchant's Braintree API usage, potentially impacting rate limits or billing.
• A degraded developer experience due to unexpected network traffic during page rendering.

The issue is classified as a performance/efficiency concern, not a functional bug, but its broad impact makes it critical for stores using this payment method.

A Clear Contrast: Google Pay's Lazy Loading

A key point of comparison highlighted in the issue is the Google Pay implementation within the same module. The PayPal\Braintree\Block\GooglePay\AbstractButton block handles its client token resolution lazily. Its constructor merely stores the injected authentication object, deferring the actual API call to the point where the token is genuinely needed—typically from the .phtml template, after isActive() has confirmed the button will indeed render.

Community Confirmation and Proposed Solution

The Magento community, specifically engcom-Hotel, has confirmed the reproducibility of this issue, validating the original report. This confirmation underscores the widespread nature of the problem. The suggested fix, mirroring the Google Pay implementation, involves refactoring the Apple Pay AbstractButton to store the Auth $auth object without calling it immediately. The actual resolution of the client token would then be deferred to the template, ensuring the Braintree API is only called when the button is genuinely intended for display.

For merchants and developers running Magento Open Source or Adobe Commerce with Braintree Apple Pay, understanding and addressing such performance bottlenecks is crucial for maintaining a fast, efficient, and cost-effective e-commerce operation. This insight serves as a reminder of the continuous need for optimization within complex payment integrations.