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 are all automatically enabled fields on the form that most 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. In 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 most frequently misconfigured conversion enhancement in Magento 2 and the simplest to do.

One of the most effective methods to lose a first-time consumer is to require them to register an account before they can make a purchase.

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. Before the consumer starts the checkout process, Magento’s native support allows it to show the projected shipping charges based on the customer’s postcode. 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. 

The most effective structural modification for checkout conversion is to combine Magento’s standard two phases into a single page.

The customer can view the address, delivery method, payment method, and order summary all at once on a one-step checkout page. To find step two, they don’t have to finish step one. “How many steps are left?” is no longer a cognitive burden.

Using layout XML to implement one-step checkout (developer approach):

The checkout layout in Magento can be changed in Magento_Checkout/layout/checkout_index_index.xml. To present both checkout phases in a single view, a developer might reorganise the Knockout.js component tree. This solution preserves the native checkout architecture and doesn’t require a third-party extension, but it needs to be implemented correctly by a competent Magento developer, especially to guarantee that payment methods and shipping method validation function as intended 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.

Checkout completion is directly impacted by the availability of payment methods. When a customer’s preferred payment option is unavailable, they will give up.

The necessary payment options that UK retailers must accept 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 Amasty’s One Step Checkout and Aheadworks’ Smart 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. 

The default checkout in Magento was not designed with mobile devices in mind. The checkout process on a phone is far worse than it is on a desktop in a typical Magento store on Luma. This is significant as a rising percentage of eCommerce traffic comes from mobile devices. 

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 mobile performance difference 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, return policies, review counts, and SSL indications work best when they are positioned during the checkout process, not at the top of the site where shoppers are still unsure. 

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.

You can’t afford to be slow on checkout pages. Doubt is bred by a delayed checkout. Abandonment results from doubt.

Even on well-optimised stores, Knockout.js, RequireJS, and a sizable JavaScript payload are loaded on the Magento checkout page. The default Luma checkout design has this structural flaw. 

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.

Checkout should be understood as a distinct factor from one-step checkout extensions if your store has already switched to the Hyvä 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ä storefront, 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. Mobile-specific checkout improvements developer-led theme changes
8. 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.

• 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
• 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

Most Magento stores lose a predictable amount of revenue at checkout not because their products are wrong, but because their checkout asks too much of the customer. The changes in this guide address the specific friction points where that revenue is lost.

Some of these changes take minutes in the admin panel. Others need a developer. The order to tackle them is consistent: start with what you can do today, then bring in development resources for the structural improvements.

KiwiCommerce’s Adobe Commerce Certified team has been optimising Magento stores since 2016. If your checkout needs work, from configuration fixes to a full Hyvä Checkout implementation, the team can assess your current setup and give you a clear view of what to do and in what order.