What is Hyvä Checkout? the Magento checkout replacement, explained
Hyvä Checkout is a Magento 2 module from Hyvä Themes B.V. that replaces Magento’s default two-step checkout with its own checkout built on Magewire, Alpine.js and Tailwind CSS. It is licensed separately from the Hyvä storefront theme, and it can also run on a Luma store. I often use it as the first step for stores that want a faster checkout before they move the rest of the theme.
- Separate product from Hyvä Themes: own license, own SKU
- Replaces stock Magento_Checkout via standard layout overrides
- ~50% checkout LCP improvement on real-merchant data
Hyvä Checkout, in one paragraph
Hyvä Checkout is a Magento 2 module that replaces the customer-facing checkout with a version built on Magewire (a PHP component layer for Magento), Alpine.js and Tailwind CSS. Hyvä Themes B.V. launched it in 2022 as a separate product, so it is not included in the Hyvä theme licence. It runs on Magento Open Source and Adobe Commerce, and it does not need the Hyvä storefront theme to be installed. The backend stays the same: quote, totals, addresses, payment and shipping are still Magento’s own. What changes is the front end, which drops jQuery, RequireJS and Knockout from the checkout page.
How Hyvä Checkout actually works
Four things I check on every store before quoting a Hyvä Checkout install. They tell me whether it will install clean or need extra adapter work.
-
01
Replaces the Magento_Checkout front end
The default Knockout and UI Component checkout is swapped for Hyvä’s own templates. The Magento backend (quote, totals, addresses, customer data) is not touched. Only what the customer sees changes.
-
02
Server-rendered with Magewire, Alpine for small UI bits
Forms, totals and validation messages are rendered in PHP templates and updated through Magewire components, which talk to the server when a field changes. Alpine.js handles small things like toggles and step changes. There is no big client-side state machine and no Knockout view models to debug.
-
03
Uses the standard shipping and payment flow
Shipping rates come from the normal Magento carrier rate request, tax and discounts from the normal quote totals collection, and payment methods from Magento’s payment method config. So any method that works in Magento can work here. The only question is whether it has a front-end component for Hyvä Checkout.
-
04
Custom payments need a front-end adapter
Many common payment providers already have a Hyvä Checkout integration, from Hyvä or from the provider itself. A niche or custom gateway needs a small adapter that renders the payment form, validates it and handles place order. The backend payment logic does not change. I list every payment method on the store before I give an estimate.
Four scenarios where buying Hyvä Checkout makes sense
Not every store needs it. These are the four situations where I recommend it to clients.
-
Hyvä-themed store still on Luma checkout
You moved the storefront to Hyvä but kept the old Luma checkout. That is usually the slowest page left on the store:
- Catalog and product pages are fast, the checkout is still slow
- Mobile users drop off at checkout more than desktop users
- The checkout still loads the full Luma JavaScript stack
- Shoppers move quickly through the catalog, then wait at the payment step
-
Store that needs a faster checkout before peak season
Peak season is coming and you want a faster checkout without rebuilding the whole theme:
- Most revenue comes from mobile visitors
- Analytics show many shoppers leaving between cart and payment
- Existing PSPs (Stripe / Braintree / PayPal) have native adapters
- A checkout-only project is smaller than a full Hyvä theme migration
-
New Hyvä build, buy bundle license
A new Magento 2.4.x build going live on the Hyvä theme. I plan the checkout in from the start:
- Theme and checkout come from the same vendor and follow the same release cycle
- No separate checkout project after launch
- The checkout uses the same Tailwind setup as the rest of the theme
- One set of front-end skills covers storefront and checkout
-
Stuck on third-party One-Step-Checkout
The store runs an older one-step checkout extension and it has become one of the heaviest modules on the page:
- Updates for new Magento 2.4.x releases arrive late
- It adds more jQuery and Knockout on top of the default checkout
- You keep paying for support but the extension is not improving
- Hyvä Checkout can do a one-step layout without a third-party module
Four mistakes I see merchants make
Common, costly, and avoidable. These are the patterns where teams burn weeks of dev time or money on the wrong assumption.
-
Buying Hyvä Themes but skipping Hyvä Checkout
The single most common, and most expensive, mistake. Stores buy the Hyvä Theme license for the storefront LCP win, then keep the stock Magento checkout to "save" $1,000. The result: a sub-1s storefront feeding into a 5s checkout, which conversion data shows is worse than a uniform 3s site. The checkout license pays for itself in < 60 days of additional captured revenue on most B2C stores.
-
Forgetting custom-payment adapter cost
Migration budgets often line-item the Hyvä Checkout license but forget that any custom or niche payment method (regional bank gateways, BNPL providers, manual-review wallets) needs a 1-3 day Hyvä Checkout adapter on top. If the store has 3+ custom gateways, that’s a week of dev hidden in the budget. Always inventory payment methods upfront.
-
Running Hyvä Checkout alongside a third-party OSC
Mageplaza / Amasty / IWD One-Step-Checkout modules patch `Magento_Checkout` at the same hook points Hyvä Checkout does. Trying to keep both installed produces JS errors, broken validation, and silent quote-collect-totals failures. Decision rule: pick one. If you’ve bought Hyvä Checkout, fully disable and uninstall any third-party OSC before deploy.
-
Treating it as part of the Hyvä Theme purchase
Hyvä Checkout is a separate product with a separate license, even though it’s sold by the same company. The Theme license does NOT include the Checkout. Many merchants only learn this when they ask their dev team why the checkout still looks like stock Luma after the storefront migration. Read the license SKUs upfront.
Six practical questions about Hyvä Checkout
The questions merchants and dev teams ask before signing the PO. Tap any question to expand.
Is Hyvä Checkout the same product as Hyvä Themes?
No, they are two separate products from the same company (Hyvä Themes B.V.) sold under two separate licenses. Hyvä Themes is the storefront theme (PLP, PDP, header, footer, mini-cart). Hyvä Checkout is a standalone module that replaces Magento’s default checkout UI. They are designed to work together but you can run either one without the other, Hyvä Checkout works on Luma stores too, and Hyvä Themes works with the stock Magento checkout (just slower). Most teams buy both as a bundle for the discount, but the licenses are accounted for separately on your invoice.
How much does a Hyvä Checkout license cost in 2026?
Hyvä Checkout is sold as a one-time, per-store license at roughly $1,000 USD (pricing has shifted modestly since the 2022 launch, check hyva.io for current numbers). Bundle pricing with a Hyvä Themes license typically saves 15-25% off the combined cost. The license is one-time, not subscription, you own that major version forever. Major version upgrades (e.g. v1.x to v2.x) are usually included in active license windows or available at a small upgrade fee. There’s no per-seat charge, no per-transaction fee, no telemetry phone-home.
Does Hyvä Checkout work with Adobe Commerce B2B features?
Yes, Hyvä Checkout supports the core Adobe Commerce B2B flows: company-account checkout, shared catalogues, requisition lists, negotiable quotes, and purchase-order payment method. The B2B-specific UI adapters ship with the module. Edge cases (custom approval workflows, multi-step purchase orders, EDI integrations) often need additional adapter work, budget 1-2 weeks of dev for a complex B2B store. The module does NOT replace Adobe Commerce’s B2B backend logic; it only replaces the customer-facing checkout UI on top of it.
How hard is it to migrate from Mageplaza or Amasty One-Step-Checkout?
Easier than most teams expect, because Hyvä Checkout already provides a 1-step UX out of the box, you’re removing the third-party module rather than replacing feature-for-feature. Typical migration: (1) inventory custom fields the OSC was capturing (gift message, delivery date, PO number); (2) port those fields into Hyvä Checkout’s extension API; (3) fully disable + uninstall the third-party OSC; (4) deploy + smoke-test all payment methods. Total: 1-3 weeks for a single-store, longer if there are 5+ custom fields or non-standard payment flows. Don’t try to run both modules at once, they will conflict.
Will my custom payment method work with Hyvä Checkout?
It depends on whether someone has written a Hyvä Checkout adapter for it. The big global gateways (Stripe, Braintree, Authorize.Net, Adyen, PayPal, Klarna, Afterpay/Clearpay) ship with built-in adapters. Regional gateways (PayU, Razorpay, Mercado Pago, iyzico, etc.) often have community-contributed adapters, check the Hyvä marketplace or the gateway vendor’s GitHub. Truly custom or in-house gateways need a new adapter, which typically takes 1-3 days of dev: register the method, build the Tailwind + Alpine UI form, wire validation, hook the place-order callback. The Magento-side payment integration logic stays exactly the same.
How does Hyvä Checkout compare to PWA Studio’s checkout?
Different categories of solution. PWA Studio is a full headless storefront stack, React + GraphQL, decoupled from Magento’s PHP frontend entirely; its checkout is one part of that stack. Hyvä Checkout is a server-rendered (PHP/PHTML) module that replaces only the checkout, leaving the rest of Magento’s frontend pipeline intact. Hyvä Checkout ships in 3-6 weeks for an average store; a PWA Studio rebuild ships in 4-9 months. Hyvä Checkout uses ~10 KB of Alpine; PWA Studio ships hundreds of KB of React. For most mid-market merchants, Hyvä Checkout delivers 80% of the conversion lift at 20% of the cost, PWA Studio is the right answer only if you’re committing to a full headless rebuild for other reasons (omni-channel, app-store deploy, mobile-app reuse).
Plan a Hyvä Checkout rollout with someone who’s shipped 40+
Adobe-Certified Magento + Hyvä developer. Hyvä Checkout installs typically run 3-6 weeks for a single-store with stock payment methods, longer if you have custom gateways. Quote in 24 hours, fixed-price, IP transferred to you. Message me on WhatsApp (+91 84012 70422) or hit the button below.