Magento 2 Admin Order Creation: The Hidden Bug That Deletes Your Payment Data

Unmasking the Magento 2 Admin Order Creation Bug: Why Your Payment Data Vanishes

For Magento 2 merchants and developers, a smooth backend experience is crucial for efficient operations. However, a recently identified GitHub issue (#41006) sheds light on a subtle yet critical bug within the Magento Admin Panel's 'Create New Order' functionality. This issue, particularly impacting modern payment gateway integrations using client-side forms like hosted fields (e.g., Stripe, Braintree), reveals how a seemingly innocuous action—changing a shipping method—can lead to frustrating data loss.

The Root Cause: Aggressive DOM Reloads

The core of the problem lies in how Magento's admin order creation script handles updates. When an administrator changes the shipping method, or performs other actions like editing addresses, the system triggers a reload of several areas, including the billing_method section. This is managed by the setShippingMethod function in app/code/Magento/Sales/view/adminhtml/web/order/create/scripts.js:

setShippingMethod: function (method) {
    var data = {};

    data['order[shipping_method]'] = method;
    this.loadArea([
        'shipping_method',
        'totals',
        'billing_method'
    ], true, data);
},

The critical detail here is how loadAreaResponseHandler() processes this reload. It performs a wholesale replacement of the section's DOM via $(this.getAreaId(id)).update(response[id]). This means that even if the content returned by the server is identical to what's already rendered, the entire HTML structure for the billing_method area is destroyed and re-rendered.

The Destructive Impact on Client-Side Payment Forms

While this behavior goes unnoticed for Magento's bundled offline payment methods (like Check/Money Order or Bank Transfer), whose state is persisted server-side, it's catastrophic for payment integrations that rely on client-side JavaScript initialization. These include popular hosted fields or iframe-based solutions designed for PCI compliance. When the DOM for the payment form is replaced, any card data entered by the admin exists exclusively within the gateway's iframe and is never round-tripped through the Magento quote. Consequently, the re-mounted form appears fresh and empty, and any previously entered card data is irrevocably lost. This forces the admin to re-enter payment details after every shipping method change, leading to a poor user experience and potential order abandonment.

Why This Bug Remained Hidden

The issue's origin traces back to a 2018 commit (MAGETWO-94437 "Improve order creation flow"). The reason it wasn't reported against core earlier is likely due to the masking effect of offline methods. Since their state survives server-side reloads, the destructive DOM replacement was invisible to them, making the bug appear specific to third-party payment extensions rather than a core Magento UI flaw.

A Proposed Solution for a Smoother Admin Experience

The issue author, lbajsarowicz, has proposed an elegant solution: modify loadAreaResponseHandler() to conditionally skip replacing the billing_method area. This would occur only when a payment method is already selected and the set of available payment methods in the incoming fragment is identical to the one currently rendered. If genuine changes in payment method availability occur (e.g., due to minimum order amounts or shipping restrictions), the area would still re-render as expected, preserving necessary functionality while preventing unnecessary data loss. The author has also indicated they will submit a PR with this change, demonstrating the community's proactive approach to platform improvement.

This fix is crucial for Magento 2 Open Source and Adobe Commerce users, especially those leveraging modern payment gateways. It highlights the ongoing importance of community contributions in refining the platform, ensuring that complex integrations and core functionalities work seamlessly together for a robust e-commerce ecosystem.