How to Customise Magento 2 Checkout for Higher Conversions

The majority of stores lose money that should have been theirs at the Magento 2 checkout. When a customer adds items to their cart, they have already decided what to buy. Because the checkout process is cumbersome, imprecise, or overly demanding, they depart. Not because they had second thoughts about the goods.

The issue of checkout abandonment is not related to marketing. It’s a configuration and user experience issue. The majority of the modifications are precise, quantifiable adjustments to how your checkout operates rather than drastic redesigns.

This post explains what those modifications are, which ones have the biggest effects, how to apply them in Magento 2, and why a developer is needed instead of an admin-panel change.

Knowing the precise drop-off locations in Magento’s default checkout is helpful before making any adjustments.

There are two steps in the standard Magento 2 checkout process: a shipping step and a payment step. Although useful, this two-page format is not ideal. To see what comes next, customers must finish one stage. It is frequently not possible to see delivery prices until step two. Prefix, middle name, suffix, company name, and fax number all of which are by default enabled are fields that the majority of stores do not require.

The experience is even worse on mobile devices. The default checkout was not designed with mobile devices in mind. Tap targets are tiny. You have to scroll to find the order summary. It can seem like a new page when it comes to the payment process.

These are not thoughts about Magento. On default Magento setups, these are the documented friction spots that result in drop-offs. Every one of them has a solution. The following fixes are arranged from most to least impactful.

This is the single easiest conversion improvement available in Magento 2 and the one most commonly misconfigured.

Forcing customers to create an account before they can buy is one of the most reliable ways to lose a first-time buyer. 

To verify or enable guest checkout: go to Stores > Configuration > Sales > Checkout > Checkout Options. Set Enable Guest Checkout to Yes.

While you are in that panel, also disable multi-address checkout if you do not need it: go to Stores > Configuration > Sales > Multishipping Settings and set Allow Shipping to Multiple Addresses to No. Most B2C stores never need multi-address checkout, and leaving it enabled adds unnecessary complexity to the checkout options the customer sees.

Magento 2’s default address form includes more fields than most stores need. Every unnecessary field is friction. Every friction point is a reason to abandon.

Go to Stores > Configuration > Customers > Customer Configuration > Name and Address Options. Review each field:

• Number of Lines in a Street Address — set to 1 or 2. Most UK addresses fit in one line.
• Show Prefix — set to No
• Show Middle Name (initial) — set to No
• Show Suffix — set to No
• Show Company — set to No unless you serve B2B customers who require company names on invoices
• Show Fax — set to No
• Show Telephone — set to Optional unless you genuinely call customers about orders

After saving, go to System > Cache Management and flush the Magento cache.

Reducing the form to the essential fields: name, email, address, and payment consistently reduces drop-off on the shipping step.

The most common reason for basket abandonment is unexpected expenses at checkout. It is doubtful that a consumer will finish the transaction if they get to the payment stage and find out there is an unexpected shipping fee. Many will depart and never come back.

In Magento 2, the issue is addressed in two ways.

First, update the cart page with a shipping estimate widget. This is supported natively by Magento, which may show the customer’s projected shipping charges based on their postcode before they start the checkout process. When the consumer can still change their basket to reach a free delivery threshold, this reveals the delivery cost at the ideal time.

Second, indicate your progress toward the order value threshold in the basket if you provide free shipping over a specific amount. Consumers react enthusiastically to “Add £X more for free delivery.” This is handled by a number of Magento 2 extensions, such as Amasty’s Free Shipping Bar. 

Combining Magento’s default two steps into a single page is the highest-leverage structural change available for checkout conversion.

On a one-step checkout page, the customer sees everything at once: address, shipping method, payment method, and order summary. They do not need to complete step one to discover step two. The cognitive overhead of “how many steps are left?” disappears.

Implementing one-step checkout via layout XML (developer approach):

Magento’s checkout layout can be overridden at Magento_Checkout/layout/checkout_index_index.xml. A developer can restructure the Knockout.js component tree to render both checkout steps in a single view. This approach requires no third-party extension and keeps the native checkout architecture intact, but it requires a confident Magento developer to implement correctly — particularly to ensure payment methods and shipping method validation work as expected in the restructured view.

Implementing one-step checkout via extension (merchant approach):

Several well-regarded extensions simplify this without requiring developer-level layout XML work:

• IWD One Page Checkout — free, Composer-installable, compatible with Magento 2.4.7 to 2.4.9, Hyvä-compatible, and does not replace any core classes or templates (meaning it is lower risk to install alongside existing extensions). 
• Amasty One Step Checkout Pro — paid extension, Hyvä-ready (with Luma fallback checkout), supports major UK payment methods including Klarna, Stripe, Braintree, Opayo (Sage Pay), and Revolut. Well-established in the Magento ecosystem.
• MageComp One Step Checkout — paid, Hyvä-compatible, simpler feature set, good for smaller stores. 

When choosing between extensions, look for three things: explicit Magento 2.4.9 compatibility, Hyvä theme compatibility if your store is on Hyvä, and a list of payment methods that includes every gateway your store uses.

Payment method availability directly affects checkout completion. A customer whose preferred payment method is not available will abandon.

For UK stores, the essential payment methods Hyvä to support are:

Express wallets: Apple Pay, Google Pay, and PayPal Express allow customers to complete checkout in two taps using payment details already stored on their device. These are particularly effective on mobile, where entering card details manually is a significant friction point.

Buy Now Pay Later (BNPL): Klarna is the most widely used BNPL provider in the UK. For stores selling higher-value products, offering Klarna’s Pay in 3 or Pay in 30 Days option at checkout removes the payment barrier for purchases where the customer wants to manage cash flow. Klarna integrates with Magento 2 through an official extension.

Opayo (formerly Sage Pay): Still widely used by UK merchants for card payments, particularly in sectors where customers are familiar with the brand. Worth including alongside a more modern payment interface.

To add payment methods: Stores > Configuration > Sales > Payment Methods. Enable the relevant provider. Each provider’s Magento 2 extension handles the frontend integration.

One of the most difficult aspects of any mobile checkout process is typing a complete address. This phase is further accelerated by address autocomplete, where the form proposes and fills in the entire address after a few characters.

The default method for address autocomplete in Magento 2 is Google Places API integration. To load the Google Places script and hook into the address fields, a Google API key with the Places API enabled is needed, along with a minor modification to the checkout layout XML. GeoIP identification and Google address suggestions are included in a number of one-step checkout extensions, such as Aheadworks’ Smart One Step Checkout and Amasty’s One Step Checkout.

Magento’s native address book manages pre-filled addresses for returning logged-in customers without the need for an extension, making it ideal for companies on a tight budget. This dataset naturally grows when account creation is encouraged after the purchase rather than mandated before checkout.

Magento’s default checkout was not built with a mobile-first approach. On a standard Magento store on Luma, the checkout experience on a phone is noticeably worse than on desktop. This matters because a growing proportion of eCommerce traffic is mobile.

Specific mobile checkout improvements in Magento 2:

Large tap targets. Buttons, radio buttons for shipping methods, and form field tap areas should be large enough to select comfortably without zooming. The CSS controlling these is in your theme files.

Order summary visibility. The default Magento checkout hides the order summary behind a toggle on mobile. Make the order summary visible by default, or at minimum ensure the total is permanently visible at the bottom of the screen.

Keyboard type on form fields. Use inputmode=”numeric” on postcode and phone number fields so mobile keyboards automatically switch to numeric input. This is a small theme change that meaningfully speeds up form completion.

Autofill compatibility. Ensure form field name and autocomplete attributes match the standard values browsers use for autofill name, email, street-address, postal-code. A form that does not trigger browser autofill forces manual entry every time.

If your store is on Luma and mobile checkout performance is poor, this is also one of the strongest arguments for migrating to Hyvä. The performance difference on mobile between Luma and Hyvä is significant enough that checkout completion rates improve alongside page speed. Our Hyvä theme for Magento 2 guide covers this in full.

Trust signals security badges, returns policy, review counts, SSL indicators are most effective when placed at the decision moments in checkout, not at the top of the page where customers have not yet reached the point of doubt.

Effective trust signal placement in Magento 2 checkout:

• SSL / secure payment badge next to the payment method selector, not in the header
• Returns policy summary one sentence, near the Place Order button. “Free 30-day returns” removes the risk perception at the exact moment the customer is deciding whether to commit
• Customer review count if you have a strong review rating, a brief mention near the order summary (“Trusted by 10,000+ customers” only if this is verifiable) reduces hesitation
• Delivery time confirmation showing “Estimated delivery: 2–3 working days” next to the selected shipping method removes the uncertainty that causes last-minute abandonment

Custom CMS blocks can be injected into specific checkout positions in Magento 2 using layout XML. This is a few hours of developer work, not a large project.

Checkout pages are the pages you can least afford to be slow. A slow checkout breeds doubt. Doubt causes abandonment.

Magento’s checkout page loads Knockout.js, RequireJS, and a significant JavaScript payload even on well-optimised stores. This is a structural limitation of the default Luma checkout architecture.

Performance improvements available without a theme migration:

• Full page cache does not cache the checkout page by default (because checkout is session-dependent). But static checkout assets JavaScript, CSS, images should still be served via CDN and optimised for delivery speed.
• Merge and minify JavaScript and CSS in production: Stores > Configuration > Advanced > Developer > JavaScript Settings and CSS Settings. Enable minification and merging in production mode.
• Reduce third-party script load on checkout. Marketing pixels, chat widgets, and analytics tools that fire on every page should be conditional, not loading on the checkout page unless they are essential to the checkout process.

For stores where checkout performance is a persistent issue and configuration changes are not sufficient, the structural answer is Hyvä Checkout.

Only when the customer hits Place Order or moves on to the next stage do the majority of Magento checkout forms validate information. This implies that a consumer fills out all the fields, clicks to continue, and then realises that their email address was missing the @ sign or that their postcode format was incorrect. They must go back, identify the mistake, fix it, and try again. Every one of those steps is an opportunity to give up.

As the customer fills out each form, real-time validation verifies that the entry is valid by turning the field border green and promptly indicating any problems with a brief inline message before the client proceeds. Rather than following a failed submission, the adjustment takes place immediately.

Real-time validation in Magento 2 is managed using Knockout.js’s validation binding. Some native validation rules are included in the default checkout; however, they only apply when the form is submitted, not when a field is blurred. Developers can modify the checkout layout XML to add blur event validation to every field, or they can use a one-step checkout extension that automatically incorporates this behaviour.

Check the options panel of the extension if your store is already using Amasty One Step Checkout or a similar extension. Most contemporary one-step extensions offer field validation on blur as a selectable option instead of requiring special development.

The order summary is not always accessible during the typical Magento 2 checkout procedure, especially on mobile devices. As they proceed through the address and payment boxes, customers often forget what they are purchasing. When a consumer is comparing the value of their basket to a free delivery threshold or a promotional discount, this generates a subtle but genuine source of doubt.

The customer is kept focused throughout the checkout process by a persistent order summary that is constantly shown as a sidebar on desktop and always available without scrolling on mobile. Additionally, it reduces the uncertainty that leads to late-stage desertion at the payment step by continuously confirming what is in the basket.

An order summary sidebar is already included in Magento’s two-step checkout on desktop. The sticky CSS rule on the summary container solves the problem of making sure it remains visible when the user scrolls a position without requiring an extension. The summary collapses by default on mobile devices. A little theme adjustment is necessary to make it expanded by default or to maintain a persistent total at the bottom of the screen.

The majority of extensions incorporate a configurable permanent order summary into their layout for one-step checkout solutions. Before presuming it is active by default, make sure this is enabled in your extension settings.

Checkout should be understood as a distinct factor from one-step checkout extensions if your store has already switched to the Hyŏ theme or plans to do so.

Launched in July 2025, Hyvä Checkout is a component of the Hyvä Commerce package. Instead of being an add-on, it completely replaces Magento’s built-in checkout. Because Alpine.js was used in its construction instead of Knockout.js, it is lighter, faster, and more structurally compatible with the frontend stack of the Hyvä theme.

When assessing one-step checkout extensions, this distinction is important because the majority of Magento 2 one-step checkout extensions are based on the Luma/Knockout.js checkout. They frequently need to activate a Luma fallback for the checkout page specifically when utilised on a Hyvä shop. This means that even though the rest of the store runs on Hyvä, the checkout page loads Luma’s JavaScript stack. On your store’s most crucial page in terms of sales, you lose the performance advantages of Hyvä.

This is completely avoided by Hyvä Checkout. Because it uses the same Alpine.js stack as the Hyvä shopfront, all pages, including checkout, perform consistently.

KiwiCommerce’s Hyvä Bronze Partnership covers Hyvä Checkout implementation alongside Hyvä Theme builds. Our Hyvä Theme Development service covers both. For an overview of the full Hyvä Commerce product suite, our Hyvä Commerce guide explains the difference between Hyvä Theme, Hyvä Checkout, and Hyvä Commerce.

If you have a standard Magento 2 store and limited developer time, tackle improvements in this order:

1. Enable guest checkout: admin panel change, five minutes, measurable impact on first-time buyers
2. Remove unnecessary form fields: admin panel change, ten minutes, reduces friction immediately
3. Add shipping estimate to cart page: admin configuration or minor extension, removes the biggest reason for surprise abandonment
4. Add express wallet payment options: each gateway has its own extension; follow the extension’s documentation
5. Add Klarna or another BNPL option :particularly valuable if your average order value is above £50
6. One-step checkout: extension or developer-led layout XML change; do the admin fixes first before adding extension complexity
7. Real-time field validation: check your one-step checkout extension settings first; may already be available as a configuration option
8. Persistent order summary: CSS sticky fix for desktop; small theme change for mobile
9. Mobile-specific checkout improvements: developer-led theme changes
10. Address autocomplete: Google Places API integration or extension-level feature
11. Hyvä Checkout: if your store is on Hyvä or planning to migrate; this is a developer project, not an admin change

KiwiCommerce’s Adobe Commerce Certified team has worked on checkout optimisation across a wide range of Magento 2 stores, from admin-level configuration changes to full Hyvä Checkout implementations.

Our approach always starts with a Magento Code Audit for any checkout project that involves code changes. The audit identifies what is currently configured, which extensions are in the checkout stack, and whether the planned changes conflict with anything already in place. Configuration changes that look simple in isolation can create unexpected results when they interact with existing extensions or custom modules.

For stores that need a full checkout rebuild, one-step checkout, Hyvä Checkout, or custom checkout logic, our Magento Development Services team handles the implementation and tests against every payment method and shipping configuration before any change goes to production.

Post-optimisation, checkout performance is monitored as part of our Magento Support Services retainer so improvements are maintained as Magento updates and extensions change over time.

For a broader look at what affects Magento performance beyond checkout, our Magento 2 Performance Optimisation Guide covers the full picture. Speak to the KiwiCommerce team about your Magento checkout.

• Checkout abandonment is a UX and configuration problem most fixes are specific, measurable changes, not redesigns
• Enable guest checkout if it is not already active it is the single fastest admin-panel conversion improvement
• Remove unnecessary form fields via Stores > Configuration > Customers > Customer Configuration > Name and Address Options
• Show delivery costs before the payment step surprise costs at payment are the most cited abandonment reason
• One-step checkout via extension or layout XML is the highest-impact structural change for most stores
• Express wallets (Apple Pay, Google Pay, PayPal Express) and Klarna are essential for UK stores particularly on mobile
• Real-time field validation catches errors as the customer types, not after a failed submission check your one-step checkout extension settings before assuming custom development is needed
• A persistent order summary keeps customers oriented throughout checkout and reduces late-stage doubt at the payment step
• Address autocomplete reduces mobile form friction significantly
• Most one-step checkout extensions use Luma/Knockout.js and require a Luma fallback on Hyvä stores Hyvä Checkout avoids this entirely
• Tackle admin-panel changes first; involve a developer for layout XML, extension integration, and Hyvä Checkout

The majority of Magento sites lose a consistent amount of money at the point of sale; this isn’t because their items are flawed, but rather because the checkout process demands too much of the user. The exact friction points where that revenue is lost are addressed by the modifications made to this guide.

In the admin area, some of these modifications require minutes. Others require a developer. Starting with what you can achieve now and then bringing in development resources for the structural improvements is a consistent approach to addressing them.

Since 2016, the Adobe Commerce Certified team at KiwiCommerce has been improving Magento stores. The team can evaluate your present setup and provide you with a clear picture of what has to be done and in what order if your checkout needs improvement, from configuration adjustments to a complete Hyvä Checkout implementation.