Hyvä Checkout is a paid, separately licensed checkout for Magento 2 and Adobe Commerce, built on Magewire, Alpine.js and Tailwind instead of Knockout and RequireJS. It replaces the Luma checkout, runs on Luma stores through theme fallback, and costs a one-time license fee plus the real work of porting your payment, shipping, and tracking customizations.
That last clause is where most projects get expensive. The license is the small number. What decides your budget is how much custom logic currently lives in your checkout and how many of your payment integrations already ship a Hyvä-compatible module. This guide covers the parts that the product pages skip: the compatibility gate you should run before you buy, what your customizations cost to port, how to keep analytics intact, and how to switch traffic over without a revenue dip.
What Hyvä Checkout actually is
Hyvä Checkout is a full replacement for Magento’s native onepage checkout. The native checkout renders through Knockout.js components and a UI component XML layer that most Magento developers can describe accurately but few enjoy extending. Hyvä Checkout throws that stack out and rebuilds checkout on Magewire, a server-driven PHP component framework in the Livewire tradition, with Alpine.js handling small interactions and Tailwind handling styling.
Practically, checkout state lives in PHP components. A step is a PHP class plus a .phtml template. Validation rules are declared as a $rules array on the component, with a matching $messages array for custom copy, and an Evaluation API cascades validation so a shopper cannot skip an incomplete step. If your team writes Magento backend code comfortably but has avoided checkout work because of the Knockout layer, that shift matters more than the PageSpeed number.
Three things Hyvä Checkout is not:
- It is not included with the Hyvä theme license. It is a separate commercial product with its own license key.
- It is not restricted to Hyvä theme stores. It runs on a Luma storefront through theme fallback, which makes it a legitimate standalone conversion project.
- It is not a full Adobe Commerce feature set. Gift cards, loyalty points, and the B2B suite sit in Hyvä Enterprise, a different product at a different price.
The four real options, compared
Most teams are not choosing between Hyvä Checkout and nothing. They are choosing between four paths, and the honest comparison looks like this.
| Option | License cost | Typical build effort | Performance ceiling | Best fit |
|---|---|---|---|---|
| Keep Luma checkout, optimize it | None | 20 to 60 hours of tuning | Limited by Knockout and RequireJS payload | Low order volume, minimal custom logic, no budget |
| One-step checkout extension | Roughly $200 to $600 per install | 20 to 80 hours to style and QA | Better UX, same underlying JS stack | Stores that need fewer steps, not faster code |
| Hyvä Checkout | €1,000 one-time, per Hyvä’s published pricing | 60 to 250 hours depending on customizations | Substantially faster, modern stack, supported roadmap | Stores with real order volume and mobile traffic |
| Custom headless checkout | None, but you own it | 400 hours and up | Whatever you build | Rare. Usually a mistake unless checkout is a genuine differentiator |
The distinction that gets missed: one-step checkout extensions change the number of steps. Hyvä Checkout changes the runtime. Compressing three steps into one on a slow stack still means the shopper waits on Knockout to hydrate before they can type. Both interventions can lift conversion, but only one of them fixes the mobile experience for shoppers on a mid-tier Android phone on cellular data.
Hyvä publishes performance claims of roughly thirteen times faster mobile checkout load than the standard Magento checkout, plus merchant case studies on average order value, cart abandonment, and A/B tested conversion. Treat vendor case studies as directional and measure your own checkout first. In our Magento and Hyvä work, the largest lifts come from stores where mobile is the majority of sessions and the existing checkout takes several seconds to become interactive.
What it costs, honestly
The license, as published by Hyvä at the time of writing, is a one-time €1,000 for a single Magento installation, covering unlimited domains and store views under that installation, and including the first year of support and updates. From year two, support and updates renew at €250 per year, or you can buy a five-year bundle up front. Confirm current pricing on Hyvä’s checkout page before you build a budget around it, because vendor pricing moves.
The project cost is the number your CFO actually cares about. Budget by counting customizations, not pages:
| Cost line | What drives it | Typical range |
|---|---|---|
| License | Fixed, per installation | €1,000 one-time |
| Base install and theming | Brand styling, responsive QA, content blocks | 30 to 60 hours |
| Payment method work | One line per PSP, more if no Hyvä module exists | 4 to 40 hours per method |
| Shipping and rates | Custom carriers, ERP-driven rates, delivery date pickers | 8 to 60 hours |
| Custom checkout logic | Tax exemption, address validation, gift options, age checks | 8 to 40 hours per feature |
| Analytics and tag parity | GA4 events, GTM container, ad platform conversion tags | 12 to 30 hours |
| QA and rollout | Cross-browser, device lab, staged traffic, monitoring | 30 to 60 hours |
A store with two payment methods, table-rate shipping, and no bespoke logic lands at the bottom of that range. A B2B store with an ERP shipping quote, a tax exemption flow, purchase order payment, and three ad platforms firing checkout events lands at the top, and should read the Enterprise section below.
The compatibility gate: run this before you buy
Do these five checks first. Each one has killed a checkout project that had already been approved.
1. Platform and PHP versions. Hyvä’s documentation lists support for Magento Open Source and Adobe Commerce 2.4.5 through 2.4.9 or higher, PHP 8.1 through 8.5, and Hyvä Themes 1.3.12 or newer. If you are on 2.4.4 or older, checkout is not your first project. Your upgrade is. Our guide to upgrading Magento to 2.4.8 and what actually breaks covers that sequencing.
2. Every payment method, by name. Support is broad across major providers, including PayPal, Adyen, Stripe, Braintree, and Mollie, wherever the PSP publishes a compatible module. Write down every active method in your admin, including ones enabled for a single store view, and confirm each has a current Hyvä Checkout integration. A method without one is a line item rather than a blocker, since the Frontend JavaScript Payment API exists so integrations can be built. You want that estimated before you sign, not discovered in week six.
3. Custom checkout logic inventory. List everything in your layout XML and custom modules that touches checkout: address validators, delivery date selectors, gift wrap, order comments, tax exemption uploads, B2B credit checks, subscription logic. Each item gets rebuilt as a Magewire component. The rebuild is usually cleaner than the original, and it is still work.
4. Adobe Commerce features in the flow. Gift cards, store credit, reward points, and the B2B suite are Adobe Commerce features, not Open Source ones. They are covered by Hyvä Enterprise rather than the standalone checkout license.
5. Tracking and consent. List every tag that fires between cart and thank you page, plus your consent management platform. This is the most commonly skipped check and the most expensive one to discover late.
What breaks, and what the rebuild looks like
Nothing “breaks” in the sense of throwing errors. Your Luma checkout customizations simply do not exist in the new checkout, because it is a different application. Anything built against Knockout components, checkout UI component XML, or Magento_Checkout JS mixins has no equivalent to hook into.
What replaces them is more direct. A custom field becomes a form field declared through the form modification API. A conditional step becomes a Magewire component with an evaluation rule. An AJAX endpoint plus a Knockout observable becomes a PHP method on the component. The tradeoffs that show up when adapting third-party Magento extensions to Hyvä apply here with one difference: in the theme, some extensions ship a compatibility module, while in checkout a payment integration either exists or you build it against the payment API.
Useful details that reduce surprises:
- Configuration lives under Stores, Configuration, Hyvä Themes, Checkout. The setting defaults to the original Luma checkout, so nothing changes until you switch it. Flush the cache after every change, because these settings are cached.
- There is an optional mobile-specific checkout controlled by a user agent regex, which lets you serve a different experience to phones.
- Recent versions added strict Content Security Policy support, multi-tab out-of-sync detection, and accessibility improvements, all documented in the Hyvä Checkout feature history. If you are working through a PCI DSS assessment, CSP behavior in checkout is worth reading closely before your assessor asks.
B2B and Adobe Commerce: where Hyvä Enterprise starts
If you run Adobe Commerce B2B, the standalone Hyvä Checkout license is not the whole picture. Company accounts, credit limits, purchase orders, approval rules, requisition lists, quick order, negotiable quotes, shared catalogs, and the Sensei-powered features are covered through Hyvä Enterprise, which Hyvä prices at €7,500 for the first year, €5,000 per year on renewal, with a five-year option. That bundle includes the theme, checkout, UI components, CMS, and admin tooling.
For a B2B merchant, that changes the math but rarely the answer. The B2B checkout is where your worst performance and your worst UX usually live, because it carries the most conditional logic: net terms, quote-derived pricing, per-company catalogs, and approval routing. Our feature-by-feature guide to Adobe Commerce B2B on Hyvä maps which features are covered natively, which need Enterprise, and which need custom work.
Analytics parity: the step teams forget
A new checkout is a new set of DOM events. Every begin_checkout, add_shipping_info, add_payment_info, and purchase event in your GA4 setup was wired to the old checkout’s markup or its Knockout lifecycle. Switch checkouts without redoing that wiring and your reporting goes quiet at exactly the moment you need it to prove the project worked.
Handle it deliberately:
- Export your current GTM container and document every trigger firing between cart and order confirmation, including ad platform conversion tags and server-side tagging.
- Decide who owns the data layer. Several Magento GA4 and GTM extensions support Hyvä natively, and Hyvä ships its own tag manager integration on the Enterprise side. Pick one source of truth rather than running two.
- Validate in staging with real test orders, checking event order, item arrays, revenue, tax, and shipping.
- Keep the old checkout live on part of your traffic during validation so you can compare event counts against a known baseline.
Be strict here for one reason: your rollout decision depends on comparing conversion between the old and new checkout, and you cannot compare what you did not instrument.
A rollout plan that does not lose orders
Never flip a checkout for all traffic on a Friday. The staged path below is what we use, and it works because every stage has a way back.
Stage 1: Staging parity. Both checkouts installed, new one enabled in staging only. Place real test orders for every payment method, every shipping method, guest and logged in, tax and non-tax states, and every custom flow on your inventory list. Confirm order emails, invoices, and ERP order push behave identically.
Stage 2: One low-volume store view. Enable the new checkout on your smallest store view first. You get production payment behavior, production fraud rules, and production traffic patterns at a fraction of the risk.
Stage 3: Mobile only, or a traffic split. The mobile user agent setting sends phones to the new checkout while desktop stays put. Mobile is usually where the gain is largest, so this stage often pays for the project on its own. Run it to a meaningful order count, not just a meaningful session count.
Stage 4: Full switch, with monitoring. Watch order volume per hour against the same weekday last week, payment failure rate by method, and checkout error logs. Keep the rollback documented as a config change and a cache flush, because that is all it is.
Acceptance checklist before you go to one hundred percent
- Every payment method places a real order and settles correctly, including refunds and partial captures.
- Shipping rates match the old checkout for a fixed set of test carts, including any ERP or carrier API quotes.
- Tax matches to the cent on your test cart matrix, including exempt customers.
- GA4 and every ad platform report the same purchase count as your admin for a full day.
- Order confirmation email, invoice, and downstream ERP or OMS records are identical in shape to before.
- Accessibility check on the flow, keyboard only, with a screen reader on at least the address and payment steps.
- Error states tested: declined card, expired session, out of stock during checkout, coupon no longer valid.
When not to buy Hyvä Checkout
Skip it, or defer it, in these situations:
- Your checkout converts fine and your measured problem is upstream, in category or product page speed. Fix the pages losing the traffic first.
- You are on Magento 2.4.4 or older. Upgrade first, then revisit.
- You are already committed to replatforming within the year. A checkout license on a platform you are leaving is money spent twice. If you are weighing that decision, we work across Shopify and Shopify Plus, Shopware, and BigCommerce as well as Magento, and we will tell you when leaving is the right answer.
- Your checkout is mostly a B2B quote-to-order flow that happens outside the storefront. The gain is real but smaller, and Enterprise licensing applies.
Frequently asked questions
Do I need the Hyvä theme to use Hyvä Checkout?
No. Hyvä Checkout runs on a Luma storefront through theme fallback, which is why it works as a standalone project. You need a Hyvä Themes package installed at a supported version, but your Luma storefront can stay. If checkout is slow because the whole frontend is slow, though, checkout alone treats one symptom. Our Hyvä versus Luma performance breakdown shows where the rest of the gain sits.
How long does a Hyvä Checkout implementation take?
For a store with standard payment and shipping methods and no custom checkout logic, four to six weeks including QA and staged rollout. Add two to four weeks for each significant custom flow, such as an ERP shipping quote, a tax exemption upload, or a bespoke payment integration built against the payment API. The scoping work is counting customizations, not counting pages.
Will Hyvä Checkout work with my payment gateway?
Most major providers are covered, including PayPal, Adyen, Stripe, Braintree, and Mollie, either through the PSP’s own module or a community integration. Regional and niche gateways are the ones to verify by name. Where no integration exists, one can be built against the Frontend JavaScript Payment API, which is a scoped piece of work rather than a blocker. Check every method in your admin, including ones enabled on a single store view.
Does Hyvä Checkout support Adobe Commerce B2B features?
The B2B suite, along with gift cards, loyalty points, and the Sensei-powered features, is covered through Hyvä Enterprise rather than the standalone checkout license. Coverage includes company accounts, credit limits, purchase orders, approval rules, requisition lists, quick order, and negotiable quotes. Budget for Enterprise licensing if any of those appear in your checkout flow.
Can I roll it back if conversion drops?
Yes, and you should plan for it. The checkout is selected by an admin configuration setting, so reverting to Luma checkout is a config change plus a cache flush. Keep the old checkout installed until the new one has held a full business cycle, including a month-end and any peak day your store has.
Where to go from there
Checkout is the last place a store should be slow and the last place to experiment without a rollback plan. If you want the compatibility gate run against your actual store, our team handles Hyvä development and migrations as the first US-based Hyvä partner, along with the Magento and Adobe Commerce work around it: upgrades, extension triage, ERP integration, performance. We keep a deep bench of technology and payment partners so questions like “does this gateway have a Hyvä module” get answered in a day rather than a sprint.
More on how our team works, or start at Bemeir. We build it, you sell it.
