The complete guide to Hyvä Checkout implementation
Hyvä Checkout is the single highest-ROI piece of the Hyvä product line. Mobile checkout completion lifts 8–15% across the builds we've measured. JavaScript payload at checkout drops ~70%. The visual + UX win is obvious to anyone who's hit the Magento default checkout on a mid-range Android.
But the implementation is more nuanced than the marketing makes out. This is the end-to-end guide — what goes in, what trips you up, and the realistic timeline.
What Hyvä Checkout actually is
A one-page Alpine.js checkout that replaces Magento's default Knockout + RequireJS multi-step checkout. The PHP backend (shipping rates, payment processing, tax calculation, order placement) doesn't change. Only the rendering layer does.
Installable two ways:
- On top of Hyvä Theme — most common; the storefront is already Hyvä, the checkout follows.
- As a checkout-only island on Luma — the rest of the site stays on Luma, only the checkout page is Hyvä-rendered.
Both work. The first is simpler because the styling system is already in place.
Pre-flight: what you need before week 1
- Hyvä Checkout license — billed by Hyvä Themes directly, ~£1,000–£3,000 per domain.
- Current payment + shipping + fraud module inventory — vendor + version + license status for each.
- List of any custom checkout fields — gift message, delivery instructions, VAT number capture, B2B fields.
- A test order baseline — record current mobile completion rate now, so you can measure post-launch lift.
Pre-flight is a 3–5 day exercise. Done before kickoff so week 1 is build, not admin.
Week-by-week implementation
Standalone Hyvä Checkout build (2–5 weeks total)
Week 1 — install + base styling
- Hyvä Checkout package installed (
composer require hyva-themes/magento2-default-theme-checkoutor equivalent for your license) - Brand-system Tailwind config applied to the checkout templates
- Address forms, payment-method selector, shipping-method selector all render under Hyvä
- Cart-summary block on the right rail (or whatever layout you've licensed)
Week 2 — payment + shipping integration
- Each active payment method re-templated for Hyvä Checkout
- Shipping carrier integrations re-templated where needed
- Tax + VAT calculation logic verified across applicable jurisdictions
- Saved-card / saved-address / guest-checkout flows tested
Week 3 — fraud + complexity layer
- Fraud / risk modules (Signifyd, Riskified, etc.) integration carried over
- Custom checkout fields added (gift message, delivery instructions, B2B fields)
- Order placement flow tested end-to-end with real test orders
- Schema.org Order + InvoiceableOrder structured data preserved
Week 4 — performance + accessibility
- Lighthouse mobile audit on the checkout page — 90+ as exit criteria
- Accessibility pass — keyboard navigation, screen reader, ARIA labels
- Cross-browser QA on iOS Safari, Android Chrome, desktop
Week 5 — UAT + cutover
- Pre-launch UAT with real orders on staging
- Conversion-rate baseline captured before cutover for measurable comparison
- Cutover Sunday off-peak, 30–60 minute maintenance window
- 72-hour post-launch monitoring with order completion rate watched in real-time
For a build on top of an existing Hyvä Theme, the timeline is typically 2–3 weeks. For a checkout-only-on-Luma build, 3–5 weeks because the integration touch points are non-standard.
Payment gateways — what works, what doesn't
Vendor-supported Hyvä Checkout integrations as of 2026:
| Gateway | Hyvä Checkout support |
|---|---|
| Stripe | Vendor-supplied |
| Adyen | Vendor-supplied |
| Klarna | Vendor-supplied |
| PayPal | Vendor-supplied |
| Worldpay | Vendor-supplied |
| Braintree | Vendor-supplied |
| Mollie | Vendor-supplied |
| Authorize.Net | Custom integration needed |
| Sage Pay | Custom integration needed |
| Most regional UK gateways | Custom — usually 1–2 week build |
For gateways without a vendor integration, a custom Hyvä Checkout payment-method module is typically a 1–2 week piece of work. We've built these for half a dozen niche gateways; the pattern is well-trodden.
Shipping + fraud — the under-discussed bit
Shipping carrier integrations usually carry over without much work — most are server-side rate calculations that don't touch the frontend. The exception is rate-at-checkout calculators that render UI in the shipping-method block (live rate display, delivery date pickers, click-and-collect locators). Each of those needs a Hyvä re-template — 1–2 days per integration.
Fraud modules (Signifyd, Riskified, Kount, ClearSale) usually have a frontend hook that fires during order placement. The hook itself works on Hyvä; the visible UI (e.g. a 3DS challenge iframe) may need re-templating depending on the vendor's integration approach. Allow 1 week for fraud integration testing across real orders.
B2B Checkout — the extra surfaces
B2B Magento (and Adobe Commerce B2B) has surfaces beyond standard B2C checkout:
- Purchase order number capture
- Multi-account ordering (placing an order on behalf of a different company contact)
- Negotiated-quote conversion (turning an existing quote into an order)
- Approval workflow (orders above a threshold need manager sign-off)
- Customer-segmented pricing display
- Requisition list quick-add
Each of these is a separate Hyvä template + flow. B2B Hyvä Checkout adds 2–4 weeks vs B2C Hyvä Checkout, and the QA cycle is meaningfully longer because you need real B2B test scenarios (multi-user, multi-company, etc.).
What blows up — in rough order
After ~15 Hyvä Checkout builds, the most common breakage points:
1. 3DS payment challenges. The 3D Secure iframe / popup behaves differently under Hyvä than Luma because the surrounding JavaScript environment changes. Allow specific 3DS test scenarios in UAT — a real card from a real bank, not just sandbox.
2. Adyen + Klarna co-existing. Both vendors have aggressive frontend JS that wants to control DOM around the payment method selector. When both are present, conflicts surface that don't appear with either alone. Test the combination explicitly.
3. Custom shipping rate calculators. Anything that renders live UI in the shipping-method block (delivery date pickers, click-and-collect, live courier rates) usually needs a Hyvä re-template the vendor hasn't shipped.
4. Customer group-specific pricing display. If your store shows different prices to logged-in vs guest customers, that logic re-applies at checkout. Edge case: a customer logs in mid-checkout and the price block needs to refresh without a full page reload.
5. Tax calculation surfaces in line items. Some jurisdictions require itemised tax display per line. Hyvä Checkout's default line-item template may or may not handle this depending on your Magento tax config. Check before assuming it works.
Performance — what to expect
Across our Hyvä Checkout builds:
- Checkout page mobile Lighthouse Performance: typically 88–95
- LCP on checkout: usually 1.5–2.5s on 4G mobile (vs 4–7s on Magento default)
- TBT on checkout: usually 100–400ms (vs 1500–4000ms on Magento default)
- JS payload at checkout: 400–700KB (vs 2–4MB on Magento default)
The JS-payload reduction is where the conversion lift comes from. On low-end Android, the parse-time alone for Magento default checkout JavaScript can be 3–5 seconds. Hyvä Checkout cuts that to under a second.
Conversion lift — what we actually see
Across implementations we've measured:
- Mobile checkout completion rate: +8–15% typical
- Desktop checkout completion rate: +2–5% typical (smaller because desktop wasn't as JS-constrained)
- Average order value: flat — Hyvä Checkout doesn't change the cart contents, just the friction to complete
- First-time vs returning buyer lift: bigger on first-time (slower devices, less patience for slow checkout)
These numbers are aggregates. Your lift will depend on your traffic mix (mobile %, device tier), prior checkout completion rate (higher baselines have less room to lift), and any custom flow complexity.
Hyvä Checkout pricing — the licence + the build
- Hyvä Checkout licence: ~£1,000–£3,000 per domain, billed by Hyvä Themes
- Standalone implementation (on top of Hyvä Theme): £8,000–£15,000, 2–3 weeks
- Standalone implementation (on Luma storefront): £10,000–£20,000, 3–5 weeks
- As part of full Hyvä Commerce build: adds 2–3 weeks + £8–15k to the Theme build
Per-extension cost adds-ons:
- Custom payment gateway integration: £2k–£6k per gateway
- Custom fraud module integration: £2k–£4k per module
- Custom shipping rate calculator re-template: £1k–£3k per calculator
- B2B-specific surfaces (quotes, multi-account, approvals): £5k–£12k combined
Should you wait for Hyvä Checkout 1.4?
Common question. The honest answer: Hyvä Checkout 1.3 is production-ready and the upcoming 1.4 release adds incremental features rather than fixing fundamental issues. Don't delay a high-ROI checkout migration waiting for a point release.
When 1.4 ships, the upgrade path is straightforward — composer update, regression test, deploy. We've never had a Hyvä Checkout upgrade take more than a sprint.
Next steps
- See the Hyvä Checkout service page for service detail
- Read Hyvä Commerce vs Hyvä Theme to understand the suite context
- Book a scoping call for a fixed-price quote against your payment + shipping module list
- Browse the Hyvä Checkout glossary entry for the technical primer