Hire Hyvä Developers / Extension and Checkout Compatibility Checklist

Printable buyer tool · Compatibility register

Hyvä Extension and Checkout Compatibility Checklist

Use this checklist before an estimate, design sign-off, or release plan. It turns hidden storefront dependencies into named compatibility decisions, evidence, acceptance tests, owners, and residual risks.

By Nina Kavulia, Principal Analyst at B2B TechSelect.

Last updated: August 28, 2026 · Sources checked August 28, 2026

Buyer tool. Not affiliated with Hyvä Themes or Adobe Inc.

Working rule: do not accept “Hyvä compatible” as a complete answer. Record which version, route, state, module, product, and configuration was tested, who tested it, what evidence was stored, and what happens when it fails.

A Luma fallback can be a controlled temporary path for selected routes, including some checkout configurations, but it changes the frontend stack on those routes and needs separate styling, script, analytics, performance, accessibility, and release tests.

Check 01 · Eight steps

Build the register before the estimate is treated as fixed

The register is a current-state inventory and a decision record. Update it whenever the scope, package version, checkout, external service, or route behavior changes.

Freeze the estate baseline
Record editions, versions, stores, themes, Hyvä products, environments, owners, and the date of the inventory.
Inventory customer routes
List every page, state, account area, checkout path, and fallback route that must keep working.
Inventory modules and custom code
Record packages, versions, custom modules, overrides, widgets, JavaScript, styles, and current owners.
Map checkout and external services
List payment, shipping, tax, fraud, address, consent, analytics, search, and account dependencies.
Choose a compatibility path
Classify each item as native, covered by a compatibility module, custom adaptation, temporary fallback, replace or retire, or test pending.
Prove the decision
Link documentation, code review, vendor evidence, reproduction steps, a fixture, or a working demonstration.
Define route acceptance
Write functional, visual, accessibility, performance, analytics, SEO, failure, and recovery tests for critical routes.
Approve scope and residual risk
Name the owner, estimate, dependency, exception, release condition, rollback path, and buyer approver for every open risk.

Check 02 · Decision key

Use one of six compatibility paths

Do not choose a path from a marketing label alone. Confirm the exact version, configuration, route, source, evidence date, and responsible owner.

Register fields: Current item · Compatibility path · Decision evidence · Acceptance evidence · Ownership and residual risk

A. Native or already compatible

The required behavior works on the target Hyvä products without a separate compatibility module or custom adaptation.

□ Exact version confirmed
□ Required configuration confirmed
□ Critical routes demonstrated
□ Upgrade and support owner named

B. Compatibility module

An official, vendor, community, or supplier module adapts the extension to the target Hyvä setup.

□ Package and source recorded
□ Maintainer and support path recorded
□ Version constraints checked
□ Code and route tests completed

C. Custom adaptation or rewrite

The pod changes templates, layout, JavaScript, styling, APIs, or module behavior for the required route.

□ Work boundary written
□ Code owner named
□ Estimate and dependencies recorded
□ Maintenance and upgrade duty written

D. Temporary Luma fallback

A selected route loads a traditional Magento theme while the rest of the storefront uses Hyvä.

□ Exact routes listed
□ Styling parity tested
□ Scripts and analytics tested
□ Performance and accessibility tested
□ Exit or long-term ownership decided

E. Replace or retire

The current function moves to another product, becomes native, changes process, or leaves scope.

□ Business owner approved
□ Data and behavior migration written
□ Customer impact reviewed
□ Rollback or recovery path defined

F. Test pending

Evidence is not yet strong enough to choose a path. Keep the item open and time-box the proof task.

□ Question written
□ Fixture or environment available
□ Owner and due date set
□ Estimate carries a clear assumption

Check 03 · Estate baseline

Record the conditions around every module

A package name is not enough. Store views, custom themes, product versions, configuration, inherited code, and external services can change the answer.

Platform and products

□ Adobe Commerce or Magento Open Source edition and exact version
□ PHP, search, database, cache, and hosting versions relevant to storefront work
□ Current theme and parent theme
□ Target Hyvä Theme version
□ Hyvä Checkout, UI, Enterprise, Commerce, CMS, or other target products
□ License, package access, update, and support owners

Store shape

□ Websites, stores, store views, domains, locales, currencies, tax regions
□ B2C, B2B, B2B2C, marketplace, or mixed journeys
□ Logged-out, logged-in, company-account, sales-rep, and admin-assisted states
□ Shared catalogs, customer groups, contract pricing, quotes, purchase orders
□ Peak periods and release blackouts

Code and content

□ Composer packages and lock file
□ Custom modules, theme overrides, preferences, plugins, observers, and patches
□ CMS blocks, widgets, Page Builder content, email templates, and generated assets
□ RequireJS, Knockout, jQuery, custom JavaScript, Alpine.js, and third-party tags
□ Tailwind configuration, component sources, fonts, images, and icons
□ Content security policy rules and exceptions

Evidence environment

□ Production-like data shape without exposed customer secrets
□ Current Luma or legacy reference store
□ Hyvä test store and exact package set
□ Safe payment, shipping, tax, fraud, and integration test accounts
□ Browser, device, network, accessibility, and performance tools
□ Repository, issue tracker, decision log, and evidence location

Check 04 · Route map

Test pages, states, and failure paths

Add every custom route. Repeat rows when behavior changes by store view, customer group, device, payment, shipping destination, or feature flag.

Blank route and state inventory.
Route or state	Current functions and dependencies	Target path	Evidence, owner, acceptance
Home and campaign landing	Widgets, personalization, consent, tags, media: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Search, suggestions, and no results	Search service, tracking, redirects, filters: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Category, filters, sort, pagination	Layered navigation, merchandising, SEO: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Product detail and configurations	Options, bundles, subscriptions, stock, media: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Cart, mini cart, coupons, totals	Pricing, promotions, tax, shipping estimate: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Checkout and payment return	Steps, methods, fraud, addresses, errors: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Account, orders, returns, saved items	Login, SSO, order data, reorders, RMA: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Company and B2B account routes	Roles, catalogs, quotes, approvals, requisition lists: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
CMS, blog, store locator, custom route	Content source, forms, maps, embeds, data: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________
Error, empty, loading, offline, timeout	Recovery, messages, logs, retries, support: __________________	□ A □ B □ C □ D □ E □ F	Owner: __________ Evidence: __________ Acceptance: __________

Check 05 · Module register

Record one decision per module or custom function

Split a module into separate rows when its storefront functions need different compatibility paths.

Blank extension and custom-code decision register.
Item, source, version	Routes and behavior	Path and proof	Work, test, risk
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______
____________________________	____________________________	□ A □ B □ C □ D □ E □ F Evidence: __________________	Owner: ______ Estimate: ______ Acceptance: ______ Risk: ______

Common extension groups

□ Search, recommendations, merchandising, reviews
□ Product options, bundles, configurators, subscriptions
□ Pricing, promotions, loyalty, gift cards, store credit
□ Account, SSO, company, quotes, requisitions, approvals
□ CMS, widgets, blog, locator, chat, forms
□ Analytics, tag manager, ads, consent, personalization
□ SEO, feeds, redirects, structured data, sitemaps

Current-code groups

□ Custom PHTML, layout XML, blocks, view models
□ Theme inheritance and overrides
□ RequireJS, Knockout, jQuery, mixins, custom JavaScript
□ Alpine.js and Tailwind sources
□ Inline scripts, content security policy, third-party embeds
□ Patches, forks, abandoned packages, undocumented changes
□ Generated, copied, or agency-owned assets and code

Check 06 · Checkout deep check

Follow totals, identity, payment, and recovery end to end

Test combinations, not only individual methods. Checkout behavior can change by customer state, cart content, address, currency, store view, device, external response, and return path.

Identity and address

□ Guest and logged-in checkout
□ Registration, login, SSO, password reset
□ Company user, sales representative, role, approval
□ Saved, new, international, military, and invalid addresses
□ Address validation, autocomplete, phone, tax identifier
□ Privacy, consent, marketing choice, terms acceptance

Cart and totals

□ Simple, configurable, bundle, virtual, downloadable, subscription
□ Minimum and maximum quantities, backorders, out-of-stock change
□ Coupon, promotion, gift card, store credit, reward, loyalty
□ Customer-specific price, shared catalog, quote, purchase order
□ Tax, duty, rounding, currency, shipping, surcharge, discount
□ Totals refresh when address, method, quantity, or stock changes

Shipping and pickup

□ Each carrier, service level, table rate, free shipping
□ Store pickup, split shipment, multi-address, delivery slot
□ Restrictions by country, region, product, weight, stock, customer
□ Quote, timeout, no-rate, changed-rate, and retry behavior
□ Labels, delivery estimates, instructions, and order display

Payment and fraud

□ Each card, wallet, bank, invoice, finance, purchase-order method
□ Token, saved payment, 3-D Secure, redirect, popup, return route
□ Authorize, capture, partial capture, void, refund, partial refund
□ Fraud challenge, review, decline, timeout, duplicate protection
□ Currency, locale, device, browser, content blocker, and failure states

Order completion

□ Place-order lock and repeated click
□ Quote to order and cart cleanup
□ Confirmation page, email, analytics, consent, affiliate tracking
□ ERP, OMS, WMS, CRM, marketplace, and fulfillment messages
□ Order appears correctly in account and administration
□ Recovery when external confirmation arrives late or never arrives

Fallback-specific checks

□ Exact fallback routes and theme recorded
□ Luma CSS and JavaScript dependencies identified
□ Header, footer, navigation, messages, and brand styling match
□ Consent, analytics, accessibility, and performance retested
□ Cache, static assets, deployment, monitoring, and rollback tested
□ Long-term owner and replacement plan decided

Check 07 · Acceptance matrix

Write proof before build starts

Use a stable fixture where possible. Store screenshots, logs, reports, and decisions with the build version and test date.

Acceptance evidence for each critical route or dependency.
Evidence family	Protocol to write	Owner and reviewer	Pass, exception, location
Functional	Fixture, steps, expected data and state, integrations, failure, recovery.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Visual and responsive	Pages, states, viewports, browsers, approved reference, tolerance.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Accessibility	Standard, routes, keyboard, focus, screen reader, zoom, contrast, errors.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Performance	Lab pages, device, network, runs, statistic; field source, percentile, window.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Analytics and consent	Events, parameters, consent states, destinations, duplicate control, debugging.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
SEO and content	URLs, canonicals, metadata, structured data, robots, links, redirects, rendering.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Security and privacy	Content security policy, secrets, access, data exposure, logs, third parties.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________
Release and recovery	Build, deploy, cache, index, smoke tests, monitoring, rollback, incident route.	Owner: ______ Reviewer: ______	□ Pass □ Exception Evidence: __________________

Check 08 · Go or no-go record

Do not hide open items inside the estimate

Every test-pending item must become a resolved decision, a priced assumption, an accepted exclusion, or a reason not to proceed.

Ready to estimateCritical routes and modules are inventoried, paths have evidence, owners are named, and unknowns are bounded.

Discovery still requiredImportant package versions, custom code, test access, checkout combinations, or product decisions are missing.

No-go until resolvedA critical payment, account, pricing, integration, legal, accessibility, data, or rollback condition has no credible path.

Open-risk record

Risk: __________________________________________
Customer or operational effect: ___________________
Decision needed: _________________________________
Owner and due date: ______________________________
Estimate assumption: ______________________________
Release condition or rollback: _____________________

Approval record

□ Critical routes have owners and evidence.
□ Checkout combinations and failures are covered.
□ Test-pending work is time-boxed.
□ Estimate assumptions are visible.
□ Accepted exceptions have business owners.
□ Release and rollback conditions are written.
Technical approver: ______________________________
Buyer approver: __________________________________

Check 09 · Carry decisions forward

Keep the same owners and evidence in the contract

The final register should be an SOW attachment or an explicitly versioned input to the SOW. Do not let approved paths become unwritten assumptions.

Named owners

Use the Hyvä developer role map to confirm that every decision, test, release duty, and handoff has an approved person.

Contract controls

Use the Hyvä pod SOW worksheet to include the compatibility version, assumptions, change path, acceptance, release, rollback, documentation, and support duties.

Check 10 · Sources and limits

Official technical references

Package requirements, products, and compatibility support change. Check the exact documentation and vendor package records again for the versions in the proposed build.

This checklist is an editorial procurement tool. It does not establish that an extension works, replace vendor support, or replace engineering review and route testing on the buyer's exact estate.