Hyvä Checkout in Practice: Lessons from Projects in the Netherlands, Switzerland and Turkey

Notes from Hyvä Checkout projects on Magento 2 stores in the Netherlands, Switzerland and Turkey

The checkout is the one page on a Magento store where every slow second and every error costs money directly. I have implemented Hyvä Checkout on Magento 2 stores in the Netherlands, Switzerland and Turkey, and I have also worked on stores that run a Hyvä storefront with the Luma checkout behind it. Both setups can work. They fail in different ways.

This article covers what Hyvä Checkout actually changes, how the integrations that usually decide a project behave (PostNL, DHL and the payment providers), how I approach a migration from the Luma checkout, and when keeping Luma is the smarter call.

What is Hyvä Checkout?

Hyvä Checkout is a separate product from the Hyvä theme. The theme replaces Magento’s Luma frontend. The checkout replaces Magento’s default checkout: the large Knockout.js and RequireJS application that every Luma store ships.

It is built on Magewire, a Livewire-style component layer for Magento. Each part of the checkout (address, shipping methods, payment methods, totals) is a PHP component rendered on the server, with Alpine.js for the small interactive parts. When a customer picks a shipping method, the component updates on the server and sends back the changed HTML. There is no large client-side application to load, initialise and keep in sync.

Since November 2025 the Hyvä theme itself is free and open source. Hyvä Checkout is still a commercial licence: at the time of writing around €1,000 per Magento installation including the first year of updates, or part of the Hyvä Commerce subscription. Check hyva.io for current pricing before you budget.

Hyvä Checkout vs the Luma checkout fallback

A Hyvä store does not have to use Hyvä Checkout. The fallback module (hyva-themes/magento2-luma-checkout) switches the Hyvä theme off on the checkout route and loads the standard Luma checkout there, with RequireJS, Knockout and the Luma styles. Whatever works on a Luma store works there too.

	Hyvä Checkout	Luma checkout fallback
Rendering	Server-side components (Magewire) with Alpine.js	Client-side Knockout.js application via RequireJS
JavaScript on the checkout	Small	The full Luma checkout stack
Look and feel	Same Tailwind design system as the storefront	Separate Luma styling, maintained apart
Customising	PHP components and templates	Knockout UI components, mixins, layout XML
Third-party modules	Need a Hyvä Checkout integration	Luma-compatible modules work as they are
Licence	Commercial	Free, with the theme

The benefits that actually show up

1. A lighter checkout on mobile

The Luma checkout loads dozens of JavaScript files before a customer can type an address. On mid-range phones that is where the checkout feels slow: taps that lag, fields that jump while the page initialises. Hyvä Checkout renders the form on the server and ships far less JavaScript. You see it in interaction responsiveness (INP) on the checkout and in how quickly the first field is usable.

2. Fewer silent failures

Most checkout bugs I have fixed on Luma stores were invisible to the store owner: a JavaScript dependency that did not load in one situation, a mixin from one module overriding another, a shipping method that disappeared for logged-in customers. In one of those cases, fixing a single JavaScript dependency raised completed checkouts by 11% (the story is in my article on Magento conversion rate optimization). With server-rendered components there are far fewer moving parts in the browser, so there are fewer of these failures to hunt down.

3. Changes become cheap

Adding a field, reordering steps, showing a delivery promise next to a shipping method: on Luma that means Knockout templates, UI components and mixins, and a developer who knows them well. In Hyvä Checkout it is a PHP component and a template. Small checkout improvements stop being projects.

4. One design system

With the fallback, the checkout is a Luma island inside a Hyvä store: different CSS, different components, two places to change a button. Hyvä Checkout uses the same Tailwind design system as the rest of the store, so it looks and behaves like the store the customer just came from.

5. Your own steps and layout

Hyvä Default is a multi-step checkout, and the steps and their contents are defined in layout files you can change, including a one-page flow. Which one converts better depends on your customers, and you can test it rather than guess.

Hyvä Checkout integration: PostNL, DHL and payment providers

In practice the integrations decide the project, not the checkout itself. Before any estimate I list every module that touches the checkout and check each one against Hyvä’s public integration tracker and the vendor’s own Hyvä support.

PostNL

PostNL publishes a Hyvä Checkout compatibility module (postnl/module-hyva-checkout) that sits on top of its regular Magento 2 extension. It brings pickup points and delivery day selection into Hyvä Checkout. Two things I check on every project: the version pairing between the two modules, because the compatibility module requires a recent PostNL extension, and how the delivery options refresh when the postcode changes, because that is where customers notice delays.

DHL

For DHL Parcel there is a companion module (dhlparcel/magento2-plugin-hyva) for the DHL Parcel shipping extension, with the ServicePoint locator and, in the Netherlands, delivery time slots. It is young (first released in January 2026), so I test it against the exact versions in use instead of assuming it works. If you ship through Sendcloud, its DHL service points need Sendcloud’s separate Hyvä compatibility bridge. Other DHL integrations are separate products with their own Hyvä support, or none.

Payment providers

Mollie, Adyen, Buckaroo, MultiSafepay, Pay., PayPal, Stripe, Klarna and Worldline all appear on Hyvä’s list of payment integrations, so most Dutch and Western European stores are covered, iDEAL included through their payment provider. Each integration is a separate module next to the provider’s own extension, with its own version requirements.

What differs between the Netherlands, Switzerland and Turkey

• Netherlands. iDEAL is the payment method to test first. Address entry should use postcode plus house number lookup; Postcode.nl has Hyvä Checkout integrations. Customers expect PostNL pickup points and a delivery day.
• Switzerland. Customers expect TWINT and PostFinance, usually through a Swiss payment provider such as Datatrans, Saferpay or Wallee. At the time of writing these are not on Hyvä’s list, so check with the provider first and budget for a custom Magewire payment component if needed. Several languages and CHF pricing on one installation also need testing per store view.
• Turkey. Card payments run through local gateways with 3D Secure redirects and instalment (taksit) options per card. Local gateways are not on Hyvä’s list either, so plan a payment component that handles the redirect back to the store and shows the instalment table correctly.

How I migrate from the Luma checkout to Hyvä Checkout

1. Inventory. Every module that touches the checkout: shipping, payment, address validation, custom fields, B2B fields such as VAT ID or PO number, gift options, tracking scripts.
2. Classify. Each module either works natively, has a Hyvä Checkout integration, or needs to be built. The third group sets the budget and the timeline.
3. Rebuild tracking. Data layer pushes from Luma checkout scripts do not run in Hyvä Checkout. The GA4 events begin_checkout, add_shipping_info, add_payment_info and purchase need to be implemented again and reconciled with the order data. It is also the right moment to send the purchase event server-side.
4. Test real money flows on staging. Every payment method in sandbox mode, failed and cancelled payments, the redirect back from 3D Secure, and every shipping method for every country you ship to.
5. Switch per store view. The active checkout is chosen in the configuration per website or store view, so you can move one market first, keep the Luma checkout on the others, and compare.
6. Measure for four weeks before the next change.

When the Luma checkout is still the right choice

Hyvä Checkout is my default for new Hyvä projects, but not every time. I keep the Luma checkout when:

• a payment or shipping module the business depends on has no Hyvä Checkout integration, and building one does not fit the budget yet;
• the store relies on a heavily customised one-step checkout extension that the operations and support teams know well;
• the launch date is fixed and the storefront is the bigger win: ship the Hyvä storefront first and move the checkout in a second phase.

A Hyvä storefront with a Luma checkout is a valid setup, but the cart becomes the handover point between two frontends. I wrote about that boundary in a case study on a Hyvä storefront with a Luma checkout.

What to measure before and after

Hyvä Checkout is a means, not the result. Before the switch I record a baseline, and four weeks after it I compare the same numbers:

• Checkout step completion, from begin_checkout to purchase, per device.
• Payment success rate per method, including failed and cancelled payments.
• INP and LCP on the checkout for mobile visitors, from field data and not only Lighthouse (see the Core Web Vitals guide).
• JavaScript errors on the checkout.
• Support emails and tickets about orders that did not go through.

For context: the Baymard Institute puts the average documented cart abandonment rate at about 70%, and 18% of US shoppers say they abandoned an order because the checkout was too long or complicated. A fast checkout that works for every customer does not solve all of that, but it is the part you control.

Hyvä Checkout checklist

1. Every checkout module listed and checked against the Hyvä integration tracker.
2. PostNL, DHL and other carrier modules on versions their Hyvä modules support.
3. Every payment method tested in sandbox: success, failure, cancellation, 3D Secure.
4. Address entry that fits the market, such as postcode lookup in the Netherlands.
5. GA4 checkout events rebuilt and reconciled with real orders.
6. A baseline recorded before the switch.
7. Rollout per store view, with the Luma checkout kept as the fallback until the numbers hold.

Frequently asked questions

Is Hyvä Checkout free?

No. The Hyvä theme has been free and open source since November 2025, but Hyvä Checkout is a separate commercial licence. A Hyvä store can use the free Luma checkout fallback instead.

Does Hyvä Checkout work with PostNL and DHL?

Yes, through compatibility modules: postnl/module-hyva-checkout for PostNL and dhlparcel/magento2-plugin-hyva for DHL Parcel. Both sit on top of the carrier’s regular Magento extension and need matching versions.

Can I use the Hyvä theme with the Luma checkout?

Yes. The fallback module loads the standard Luma checkout on the checkout route. It is a valid first phase, but you then maintain two frontends: the Hyvä store and the Luma checkout. The reverse also exists: Hyvä Checkout can run on a store that still uses the Luma theme.

How long does a Hyvä Checkout migration take?

It depends on the integrations, not on the checkout. When every payment and shipping module already has a Hyvä Checkout integration it is a matter of weeks; every module that has to be built adds to that.

Final thoughts

Hyvä Checkout makes the most important page of a Magento store lighter, easier to change and harder to break. The work is in the integrations: PostNL, DHL, the payment providers, and the market details that differ between the Netherlands, Switzerland and Turkey.

If you are planning the move, start with the Luma to Hyvä migration guide, or let me look at your checkout first: see my Magento and Hyvä work or the checkout conversion audit.