Hyva Checkout replaces Magento's native checkout outright, and that one architectural fact is why every shipping, payment and address extension in your build needs compatibility work of its own. On August 24, 2026, Hyva and Sendcloud announced that Sendcloud's Magento integration is now an official, continuously maintained module for Hyva Checkout. The feature list is not the interesting part. The word maintained is.
What Hyva and Sendcloud announced
Sendcloud's Magento module is now officially supported and continuously maintained against Hyva Checkout, rather than a compatibility effort chasing a moving target. Hyva's partnership announcement says service point selection, address display and order synchronisation behave the way they do on a standard Magento 2 checkout, with no rebuilt integration required on the merchant side.
Sendcloud claims access to more than 170 carriers and roughly 390,000 service points across Europe. For a brand shipping parcels into multiple European markets, the service point picker is not a nice to have. It is the difference between offering pickup delivery and not offering it.
What the announcement does not contain is worth naming too. There is no module version, no package name, no release date and no supported Hyva Checkout version range. It is a partnership post, not release notes. Treat it as a signal about ownership rather than as something you can act on in a composer file this afternoon.
Why Hyva Checkout needs a compatibility module at all
Because Hyva Checkout is not a restyled Luma checkout. It is a separately licensed commercial product built on Magewire, a PHP driven component framework, and it replaces the Knockout and UI component layer that Magento's stock checkout is assembled from. Hyva's own documentation is explicit that developers should understand Magewire before customising it, and that Hyva Checkout can run on a store still using a Luma theme, enabled per store view so a merchant can move one market at a time.
That per store view rollout is the underrated part. It means a checkout migration does not have to be a single cutover across every market on one night. It also means you can end up running two checkout stacks in parallel for a quarter, and every extension in the checkout path has to work in both.
The consequence for extensions is blunt. Anything that hooked into the old checkout through Knockout templates, UI component XML or layout XML has nothing left to attach to. It is not a styling problem that Tailwind classes can solve. The component tree it was written against is gone. So each vendor either ships a Hyva Checkout specific integration, or somebody writes a shim.
Official module vs agency shim
The real difference is not what works on launch day. It is who pays for the next upgrade. Both options can look identical in a demo. They diverge the first time Hyva Checkout ships a release that moves a component boundary.
A shim your agency wrote works until it does not. When it breaks, someone has to diagnose it, rewrite it and retest the full checkout path, and that work lands on your invoice. A vendor maintained module moves that cost onto the vendor, who amortises it across every merchant using the same integration. Over a three year build, that is not a rounding difference. It is the reason to prefer an officially supported integration even when the shim is cheaper to stand up in month one.
There is a second trap, and it is the one that actually damages projects. Compatible is not a yes or no answer. It is answered per feature. ShipperHQ is the clearest published example: its own compatibility documentation states that the standard ShipperHQ Magento 2 module for quoting shipping rates at checkout works with Hyva Checkout, while four of its additional modules do not. Enhanced Checkout, the address type selector, in store pickup and the calendar and date selector are all listed as unsupported.
Read that carefully, because it is the shape of the problem across the whole ecosystem. An extension can appear on a compatibility list, pass a smoke test, and still have dropped the exact capability you bought it for. If your delivery promise depends on a date picker at checkout, or your stores depend on click and collect, a green tick against the vendor name tells you nothing useful.
What we would change this quarter
Audit checkout extensions feature by feature before scoping a Hyva Checkout migration, not after the build has started. Most of the budget overruns we see on Hyva migrations are not theme work. They are checkout integrations discovered late.
Start by listing every extension that renders inside checkout or writes to the quote. Shipping rate engines, service point pickers, address validators, payment methods, gift options, tax logic, loyalty and store credit. For most premium Magento builds that list runs to somewhere between eight and twenty entries, and almost nobody has it written down before the project starts.
Then, for each entry, answer two questions in writing. Does the vendor publish official Hyva Checkout support, or is a shim implied? And which specific features are covered, checked against the vendor's own documentation rather than a third party compatibility table? Vendor docs are where the exclusions live, as the ShipperHQ page shows.
Finally, price the shims as recurring cost rather than one off scope. Every shim is a small maintenance contract you are signing without a renewal date. That belongs in the migration budget as an annual line, next to the Hyva Checkout licence itself. When a vendor upgrades a shimmed extension to an officially maintained one, that line goes down, which is exactly why the Sendcloud news is worth noting even though it ships no code you can read.
None of this argues against Hyva Checkout. The performance case for moving off the stock checkout is settled, and we have measured it under load. The argument is narrower: the checkout layer is where a Hyva programme meets its integration debt, and the honest way to scope it is per feature, from vendor documentation, before anyone commits to a date. Teams planning that work should read the migration guide first and build the extension inventory second.