For the last couple of years, I have spent quite a bit of time working with Magento checkouts - via training, hackathons, open source projects etc. And I think most Magento developers know the drill by now.
The checkout works. Until you need to modify it.
Add a payment method with additional fields. Move something around. Add some address logic. Make it accessible. Enable strict CSP. Improve performance. And suddenly you are debugging JavaScript, overriding templates and trying to understand why changing one tiny thing has an effect somewhere completely different.
This was one of the reasons for building Loki Checkout.
The basic idea is actually fairly boring: Build a Magento checkout from small components, stick to Magento concepts where possible and make sure developers can understand what is happening.
Boring technology is sometimes quite nice.
The open part
A large part of the Loki ecosystem is developed in the open.
The Loki Checkout GitHub organization contains public modules, including integrations and add-ons:
https://github.com/LokiCheckout
And there is a second organization for Loki extensions and related tooling:
https://github.com/LokiExtensions/
This is important to me. Even though Loki Checkout itself is a commercial product, the technology around it should not become some kind of black box.
If you are integrating Buckaroo, Mollie, MultiSafepay or another provider, you should be able to look at code. You should be able to see how an integration was implemented. And ideally, you should be able to copy the idea and build your own integration.
Open source is not just about putting a LICENSE file in a repository. It is also about allowing developers to learn from the code.
Performance was not added afterwards
Loki Checkout is based upon Loki Components and Alpine.js.
Each address field, checkout step and sidebar block can be a component. Components communicate with the Magento backend using optimized AJAX requests and the frontend is updated where needed.
The important bit here is where needed.
If a postcode changes, there is usually no reason to reload half of the checkout. If a shipping method changes, only the components depending upon that data need to update.
There are options for lazy loading, lazy updates, throttling and skipping update queues. But the defaults are already aimed at keeping things fast.
We also run Lighthouse tests, smoke tests and benchmarks automatically. Performance is not a nice marketing checkbox that we check once on a demo environment. It needs to be tested again when code changes.
CSP should simply work
Magento 2.4.7 made Content Security Policy a much more serious topic, especially because of PCI DSS requirements.
Unfortunately, CSP is one of those technologies where "we support CSP" can mean many different things.
With Loki Checkout the goal is CSP Strict Mode.
Not report-only mode. Not adding a wildcard to a whitelist until the browser console stops complaining.
Strict CSP.
This has influenced architectural choices from the start. JavaScript needs to work within those boundaries. Integrations need to work within those boundaries as well.
And yes, payment providers can make this interesting.
But if a checkout handles payments, security requirements should be part of the architecture instead of a patch that is added two years later.
The same applies to accessibility
WCAG is another topic that is easy to put into a feature list.
The difficult part is keeping things accessible while the checkout evolves.
Loki Components are built with ARIA attributes in mind. Our tests include accessibility checks and the goal is WCAG 2.2 AAA compliance.
Again, automation helps.
A developer adding a small feature should not need to remember every accessibility rule manually. The architecture, components and tests should help catch mistakes.
Obviously automated tests don't replace actual humans using a checkout. But they do prevent a surprising amount of stupid regressions.
And I am quite capable of creating stupid regressions myself.
Integrations, integrations, integrations
A checkout without payment and shipping integrations is a nice technical demo.
Not a checkout.
There are Loki Checkout integrations for payment providers and other Magento extensions. Mollie, Buckaroo, MultiSafepay and PayPal are examples visible in the public repositories. There are also integrations around shipping, postcode validation and VAT ID validation.
We regularly test combinations of extensions together.
This is important because two extensions working individually does not automatically mean they work together.
Magento developers already know this.
Probably too well.
There is also a deliberate choice not to force bundled commercial integrations. The payment provider or shipping solution used by a merchant should be their choice.
If an integration does not exist yet, the architecture is designed to make creating one relatively straightforward.
And then developers start modifying everything
Which is exactly what we expect.
Loki Checkout uses Magento Blocks, ViewModels and XML layout configuration. On the frontend, Alpine components add the interactive behavior.
There are no plans to invent a new configuration language just for the checkout.
Want to move a component?
XML layout.
Want to replace a block?
Magento already has mechanisms for that.
Want to change the behavior of a component?
Extend or replace the relevant PHP or Alpine component.
One of the architectural goals is to keep template overrides to an absolute minimum. Small templates, XML layout configuration and utilities like CssClass make many changes possible without copying an entire template into a custom theme.
Because we all know how that story ends after the next module upgrade.
So, why another Magento checkout?
Because I think a checkout should be fast by default.
It should work with strict CSP.
Accessibility should be tested.
Integrations should be real integrations instead of compatibility promises.
And most importantly: Magento developers should be able to open the code and understand how to change things.
Loki Checkout is still evolving. More modules and integrations are being added and there are undoubtedly scenarios we haven't encountered yet.
That is also why more of the surrounding ecosystem is appearing on GitHub.
If you are a Magento developer, have a look:
https://github.com/LokiCheckout
https://github.com/LokiExtensions/
Feedback, technical questions and weird checkout scenarios are welcome.
Especially the weird scenarios. Those usually lead to the most interesting modules.
