Hyvä Checkout 3.0 is here: what Magento merchants need to know before deciding when to migrate

Hyvä released Checkout 3.0.0 on 27 October, marking the first stable release of Hyvä Checkout built on Magewire 3.

For Magento merchants currently running Checkout 1.3.x, this isn't a routine patch-level update. The checkout moves from Magewire 1 to Magewire 3, brings new runtime requirements, and changes some of the extension points used by custom checkout integrations.

Hyvä has also built a migration bridge into the new release. The Hyva_CheckoutV1bc backward compatibility module is installed as a Checkout 3.x dependency and keeps components, templates and integrations written for Checkout 1.x working in almost all cases.

That makes the migration more manageable, but it doesn't remove the need to test every checkout integration.

There is also already a newer patch release. Hyvä Checkout 3.0.1 shipped on 2 November with additional compatibility fixes, so merchants migrating now should target the latest 3.x release rather than deploying 3.0.0 unchanged.

What changed in the architecture

The main change is the move from Magewire 1 to Magewire 3.

For customers, the checkout doesn't need to look fundamentally different. Most of the change sits underneath the interface in how components are resolved, state is handled and checkout integrations interact with Magewire.

The upgrade also changes some technical requirements:

• PHP: Checkout 3.x requires PHP 8.2 or newer;

• Tailwind CSS: Tailwind 2 is no longer supported, so the storefront needs Tailwind 3 or 4;

• Hyvä Theme Module: the minimum hyva-themes/magento2-theme-module version is ^1.3.16;

• Magewire: Checkout 3.x moves onto Magewire 3 instead of the Magewire 1 architecture used by Checkout 1.x.

For merchants, the practical implication is that the migration scope depends on more than the checkout package itself. PHP compatibility, theme dependencies and custom checkout modules need to be reviewed together.

The backward compatibility module reduces migration work

Hyvä's Magewire 1 backward compatibility module is designed to keep Checkout 1.x integrations running on Checkout 3.x while development teams migrate them to native Magewire 3 patterns.

The package is installed automatically with Checkout 3.x, so merchants don't need to add a separate compatibility package manually.

With the module enabled, most Checkout 1.x components continue to receive:

• Magewire 1-style PHP behaviour;

• Legacy JavaScript APIs and events;

• Checkout 1.x template compatibility;

• Magewire 1 behaviour for existing wire:model implementations.

This means a merchant doesn't need to rewrite every checkout customisation before beginning the migration.

But the compatibility module should be treated as a bridge, not proof that every customisation will behave exactly as it did on Checkout 1.3.

Which customisations still need attention

Hyvä's 3.0 upgrade guide identifies several areas that can't behave identically across Checkout 1.x and 3.x.

Magewire event observers

Observers using Magento events such as magewire_shipping_method_selected continue to work only while Hyva_CheckoutV1bc is enabled.

Before eventually disabling the compatibility layer, those integrations need to move to supported hyva_checkout_* events or component events.

Address form modifiers

Form modifier listeners typed specifically against Checkout 1.x address form classes are skipped in Checkout 3.x.

This matters for custom address behaviour such as additional validation, postcode integrations or other changes built around the previous form classes.

Merchants with customised billing or shipping forms should include these integrations explicitly in migration testing.

wire:model behaviour

On address and guest-detail forms, a plain wire:model remains deferred in Checkout 3.x.

Customisations that require an immediately reactive value, such as postcode lookup behaviour, need to use wire:model.live.

Changed method signatures

Several checkout classes and methods have changed signatures between 1.x and 3.x.

Overrides written against the previous signatures need to be reviewed and updated. Hyvä lists the affected classes and methods in the migration documentation, making this an audit task rather than something teams need to discover through production errors.

REST cart totals also behave differently

There is another change worth checking if external systems use Magento's cart totals APIs.

In Checkout 3.0, Hyvä's plugin on Magento\Quote\Model\Cart\TotalsConverter runs only on the storefront.

As a result, REST cart totals no longer include Hyvä's additional tax details and inclusive-tax shipping values. REST endpoints return Magento's standard totals behaviour instead.

For most customers browsing the storefront, this won't be visible.

For integrations that consume cart totals through REST and previously relied on those Hyvä-added values, it can affect the data they receive.

Action: include API-dependent tax, shipping, ERP and checkout integrations in your migration test plan instead of testing only the customer-facing checkout.

Checkout 1.x is still available, but 3.x is now the current line

Hyvä now documents two Checkout release lines:

• Checkout 3.x: Magewire 3, current release line;

• Checkout 1.x: Magewire 1, previous release line.

The important distinction is that Checkout 1.x hasn't disappeared, but Hyvä no longer positions it as the long-term default.

Its current guidance is to use Checkout 3.x for new projects and upgrade existing stores, while staying on Checkout 1.x where a dependency still requires it.

That makes migration timing a risk-management decision rather than a reason to treat 1.3.x and 3.x as equivalent long-term choices.

How to evaluate your migration timeline

For most Magento merchants, four factors should determine the timing.

Customisation exposure

Start by identifying how much checkout-specific code you actually have.

A relatively standard implementation with supported payment and shipping integrations may move through the compatibility layer with limited code changes.

A heavily customised checkout deserves a deeper audit of:

• payment integrations;

• shipping integrations;

• address forms and validation;

• custom Magewire components;

• checkout events;

• template overrides;

• REST-dependent integrations.

Hyvä recommends testing every checkout integration in development or staging after the upgrade.

Platform requirements

Before touching the checkout, confirm that the rest of the stack can support it.

Checkout 3.x requires PHP 8.2 or newer and Tailwind 3 or 4. Hyvä Enterprise implementations also need versions of the Enterprise Checkout and B2B packages that support Checkout 3.x.

This can turn what initially looks like a checkout update into a wider dependency upgrade.

Peak-season risk

The checkout is one of the most commercially sensitive parts of the storefront.

If a heavily customised production store is already inside a peak-season change freeze, moving its checkout architecture simply because 3.x is available can create unnecessary risk.

A better approach is to scope the migration now, validate it in staging and schedule production deployment for a controlled release window.

At the same time, merchants shouldn't use peak season as a reason to defer the migration indefinitely. Checkout 3.x is now Hyvä's current release line.

Development roadmap

If checkout work is already planned, aligning it with the Magewire 3 migration can reduce duplicated development.

New components should be written for Magewire 3 and can opt out of the compatibility layer using Hyvä's native v3 approach.

That is particularly relevant when adding new payment methods, custom forms or checkout features that would otherwise need to be developed first against the previous architecture and migrated later.

What Magento merchants should do now?

Actions to take:

• Confirm your current version: identify whether the store is on Checkout 1.x, a previous 1.4/3.0 beta or Checkout 3.x;

• Audit checkout customisations: list payment, shipping, form, Magewire, template and API integrations before estimating the migration;

• Check platform requirements: confirm PHP, Tailwind, Hyvä Theme and Enterprise dependencies can support Checkout 3.x;

• Test with v1bc enabled: migrate a staging environment first and verify the existing integrations through the backward compatibility layer;

• Review known incompatibilities: pay particular attention to Magewire event observers, typed form modifiers, reactive wire:model behaviour and changed method signatures;

• Test the entire transaction journey: cover guest and logged-in checkout, addresses, shipping, tax, coupons, payment methods, redirects, order placement and post-payment behaviour;

• Use the current patch release: merchants migrating now should start from the latest Checkout 3.x version rather than 3.0.0.

Conclusion

Hyvä Checkout 3.0 is a meaningful architecture transition, but it has been designed so merchants don't need to rebuild their checkout from scratch to adopt it.

The backward compatibility layer lets most Checkout 1.x integrations continue running while teams move custom code to Magewire 3 over time. At the same time, there are enough changes around forms, events, API behaviour and platform requirements that the migration still deserves proper staging and regression testing.

For a straightforward implementation, that path may be relatively short. For a heavily customised Magento checkout, the better approach is to audit dependencies first and choose a production window based on the commercial risk of the store.

The important decision isn't whether to move towards Checkout 3.x. Hyvä now identifies it as the current line.

The decision is how to migrate without putting checkout stability at risk.

About On Tap

On Tap is a growth-focused eCommerce consultancy helping mid-market and enterprise merchants improve their digital commerce operations. Our Magento and Hyvä specialists help merchants plan upgrades, assess custom integrations, test checkout changes and reduce migration risk across complex eCommerce environments.

If you're assessing Hyvä Checkout 3.x or want to understand what the Magewire 3 migration means for your current checkout, get in touch.