Yuriy Boyko's blog

Mage-OS Hackathon in the Netherlands: Nov 4, 2026

2026-10-22T00:00:00.000Z

On November 4, 2026 the Mage-OS Hackathon takes place in Amsterdam: a day when developers, agencies and companies work together on the code of Mage-OS and Magento. It is not a commercial event and it changes nothing overnight for your store, but it says a lot about who is behind a platform that many online stores use every day. Here is what to know, in simple terms.

What a community hackathon is

A hackathon is not a competition. It is a day of shared work in which people split into small groups and contribute to the project in practical ways: fixing bugs, reviewing changes proposed by others, improving existing features, writing tests and documentation. The value also lies in face-to-face exchange: questions that would take weeks of online messages get settled in a few hours.

Mage-OS is a distribution of Magento Open Source developed by the community. It is an independent project, not affiliated with Adobe.

The program in Amsterdam

According to the official agenda of Mage-OS Nederland, the Dutch community, three related events take place that week:

Date	What	Where
Wednesday, November 4, 10:00–17:00	Mage-OS Pre-MMNL Hackathon: a day of building Mage-OS and Magento together, the day before Meet Magento Netherlands	Bold Commerce, Amsterdam
Wednesday, November 4, 20:00–00:00	Official Meet Magento Netherlands pre-party, hosted by Mago	Brouwerij Troost Westergas, Amsterdam
Thursday, November 5	Meet Magento Netherlands: the community's annual gathering	LIEF, Amsterdam

Tickets and details are on the official pages: Hackathon and Meet Magento Netherlands. An Italian delegation will be there: at least one agency from the Mage-OS Italia community has announced it will attend.

Why it concerns you if you run an online store

A platform looked after over time. An active community means more frequent fixes and updates. You can see it in Mage-OS's security releases of 2026, from 3.2.0 on July 14 to 3.6.0 on October 14.
Less dependence on a single vendor. The code is open and maintained by those who use it, not by one company.
Italian needs reach the table. E-invoicing, tax data at checkout and other topics of ours often stay out of international discussions: bringing them to a European event helps them get considered. That is the idea behind the Italian Mage-OS distribution.
Better-prepared agencies. Those who contribute to the code know it in depth, and it shows when your store needs work.

Other Dutch community events

Mage-OS Nederland's agenda shows how active the community is:

Date	Event
November 19, 2026	Loki Hackathon (components and checkout), Baarn
December 15, 2026	Nebula Hackathon (new admin theme), Baarn
May 27–28, 2027	Hyvä hackathon and MageTitans conference, Groningen

Frequently asked questions

Do I have to attend to use Mage-OS?

No. The hackathon is for people who want to contribute to the code. For your store what matters are the releases that come out of it, which you receive by updating.

Does anything change for my store after the event?

Not right away. Contributions flow into future versions of Mage-OS and Magento: you will see them in upcoming updates.

How do I know whether my agency is involved?

Ask: a team that follows the community, attends events and contributes to the code is a good sign for the maintenance of your store.

An up-to-date store, with someone who knows the platform

Following Mage-OS and Magento releases, testing them and deploying them without stopping sales is recurring work. With the maintenance and support service I take care of it.

Considering Mage-OS or a new e-commerce? Request a consultation and a free quote. For moving from another platform see replatforming and migrations.

Informative article: dates and times come from the agenda published by Mage-OS Nederland (nl.mage-os.org/en/agenda) and may change. For tickets and details refer to the official event pages.

Critical PHP Security Update, Oct 21: What to Do

2026-10-21T00:00:00.000Z

The PHP team has announced a critical security update for PHP for Wednesday, October 21, 2026, at 14:00 UTC (16:00 in Italy), the language that runs Magento, Adobe Commerce, Mage-OS, WooCommerce and countless other online stores. It fixes two vulnerabilities scoring 9.2 out of 10. Details and fixed versions will be published with the release. The point that matters: the fix is applied on the server, not in your store's code.

What we know so far

What the PHP team has announced on its official site:

two critical vulnerabilities, both scoring 9.2 out of 10 (CVSS v4.0);
release announced for October 21 at 14:00 UTC, which can be brought forward if details become public or attacks in the wild appear;
PHP users are asked to prepare in advance, so they can upgrade as soon as the release is out.

According to information found on the web, still to be confirmed by the official announcement, the details leaked on October 20, the flaws would allow remote code execution on the server, and they would affect all PHP versions from 5.4 onwards. Some security researchers fear mass attacks right after publication.

What it means for your store

If your store runs on PHP, this fix concerns you too. And it is not solved by updating the store: it has to be installed on the server where PHP runs. So the right question is: who manages my server?

Managed hosting: ask your provider right away whether they will apply the update as soon as it is out, and when.
Your own or dedicated server: you need whoever administers it, your sysadmin or me through the maintenance service.
Managed cloud: ask the provider how and when they will apply the update.

What to do, in order

Write to your hosting provider right away and ask them to be ready to apply the PHP update as soon as it is published.
Check the PHP version your store uses (your host or whoever looks after it can tell you).
When it is published, read the announcement on php.net: the fixed versions will be there.
Have the update applied on every environment, including the test one.
Check that the store works: cart, checkout, customer area, admin and background tasks.
After the update, watch for unusual signs, such as unexpected files or access.

If you use an old version of PHP

Again according to information found on the web, PHP officially supports only version 8.2 and later: no official fix is planned for 8.1 and earlier. In that case ask your provider to apply the fix to your version or move to a supported version, after checking that your store is compatible. It is a move to plan, not to improvise: if your store runs an old Magento version, it may be the moment to look at replatforming and migrations.

The timeline

When	What
October 20	The details leak and PHP announces the critical release
October 21, 14:00 UTC (16:00 in Italy)	Release scheduled, can be brought forward

Security updates without the worry

After Adobe's October 13 patch comes another critical fix. Following the alerts, coordinating the hosting, testing updates and verifying the store is recurring work: with the maintenance and support service I take care of it.

Want to know whether your store and your server are ready? Request a security audit and a free quote.

Informative article, written on October 21, 2026 before the release was published: fixed versions and details are those of the official announcement on php.net, to be consulted first. The situation is evolving and unofficial information may change.

Shopify Checkout Attack: What Happened and What to Do

2026-10-20T00:00:00.000Z

Since October 10, 2026 some Shopify stores have shown customers a fake checkout. On clicking "Pay", the customer landed on a page identical to the real one that copied the card details and then sent them on to the genuine checkout: the order went through and nobody noticed anything. According to the vendors involved, the code was loaded through third-party apps installed in the stores. It is a lesson for anyone selling online, whatever the platform.

What happened

This account is based on information found on the web as of October 19, which cites the developer who found it and the vendors' statements:

October 10: developer Roman Zipp notices the fake page while buying from a Shopify store and reports it.
October 10 to 18: HulkApps, Selleasy and Swym confirm that an unauthorized party changed what their apps loaded on some stores.
October 18: Swym disables its app for all merchants after new unauthorized activity.

Nobody has yet published how the attackers got in, or how many stores and cards are involved.

How it worked

According to the reconstructions, the code acted on the click on "Pay", on the store pages that come before checkout. The malicious code waited for the click, sent the customer to a fake site with a different address, collected the card details and sent them on to the real checkout. Because the customer paid anyway, whoever ran the store saw nothing in the orders. The payment security standard (PCI) calls this technique double-entry skimming.

It is not just one platform's problem

Every app or script running on your store's pages is code that someone outside your company can change. It happens on any platform, Magento included: we covered it with StyleSmuggler and the October patch. The difference lies in who controls what.

Why control matters: Magento, Mage-OS and Adobe Commerce with Hyvä

On an open platform such as Magento, Mage-OS or Adobe Commerce, you, with your developer, decide which scripts may run and check it. In practice:

Script policy (CSP). A CSP tells the browser which scripts it may run and blocks the rest. According to Adobe Commerce documentation, from version 2.4.7 it is active in restrictive mode on payment pages.
Hyvä Checkout. According to the official documentation, from version 1.3 it applies a strict CSP on all checkout pages: every script needs an authorization, and no code can be injected dynamically. Hyvä states that this meets PCI DSS 4.0 requirements.
PCI DSS 4.0. For payment pages it requires keeping an inventory of scripts and detecting changes (requirements 6.4.3 and 11.6.1, in force since March 31, 2025). We cover it in PCI DSS 4.0 for e-commerce.

A word of caution: no platform or theme makes you compliant on its own. Third-party modules, marketing scripts and updates have to be checked over time, and Magento has its own vulnerabilities: maintenance is needed. More control also means more responsibility.

If you have a Shopify store

Run a checkout test in a private window, from the product to payment, and watch whether the address changes.
List the apps that load code on your pages and remove the ones you do not need.
Read the vendors' notices for the named apps (HulkApps, Selleasy, Swym).
Do not rely on orders alone: the customer paid anyway. Watch for reports of strange pages or card fraud after purchase, and tell your payment provider.

A checkout under control

If you want to understand how exposed your checkout is, or evaluate Magento, Mage-OS or Adobe Commerce with Hyvä Checkout, I can help with a risk review and with choosing the platform. See B2C e-commerce development and replatforming and migrations; to keep it under control over time there is the maintenance and support service.

Want to know whether your checkout is protected? Request a security audit and a free quote.

Informative article: the facts come from public reports as of October 19, 2026, and the situation is evolving. It is not PCI compliance advice: how your store is classified should be checked with your payment provider.

Mage-OS 3.6.0: Security Update and What to Do

2026-10-15T00:00:00.000Z

On October 14, 2026 Mage-OS 3.6.0 was released, a security release: the community recommends upgrading every Mage-OS 3.x store. It includes Adobe's October 13 fix (APSB26-153), which resolves a critical vulnerability scoring 10 out of 10 that can be exploited without authentication to run code on the server. The upgrade is direct from 3.5.x, with no dependency or PHP version changes. But there is also a returns change to check.

What it fixes

The security fixes are those of Adobe's bulletin, ported into the Mage-OS version. In plain words:

Running code on the server (CVE-2026-103849): an attack goes through the email template system and can take control of the store. It is the 10-out-of-10 flaw.
Customer data exposure: with particular API searches, password hashes and reset codes could come out.
Access to guest carts and bypassable checks in the admin content editor.
Other fixes to template previews, email address validation and bulk product updates.

For the full list see the Mage-OS 3.6.0 release notes and the Adobe bulletin. The release also fixes seven non-security bugs, such as order PDFs and the customer export.

Watch the returns

The release also updates the returns module. The return period is now calculated from the shipping date, per quantity: expired products appear as not selectable and the labels use right-of-withdrawal terms, translated into Italian too.

There is one point to check before upgrading, though. The law starts the period at delivery, which the system does not know. That is why you should add your expected delivery time to the return days. If you leave the value as it is, you effectively extend every return window by however long shipping takes. For the legal picture read the withdrawal button in e-commerce.

What to do, in order

Check your Mage-OS version. With this release, 3.5.0 is no longer supported.
Plan the upgrade and test it in a test environment: from 3.5.x it is direct.
Review the return days as explained above.
After upgrading check cart, payments, orders and emails.
Recheck September. For the StyleSmuggler vulnerability the patch alone was not enough: if you have not yet followed those instructions, reread StyleSmuggler: critical vulnerability and patch. For the October patch Adobe also recommends rotating the encryption keys and related credentials: discuss it with whoever looks after your store.

One update a month

Mage-OS release	Date	Reason
3.2.0	July 14	Adobe's July security patch
3.3.0	August 5	Critical flaw in the template import module
3.4.0	August 11	Adobe security patch APSB26-92
3.5.0	September 8	StyleSmuggler emergency fix
3.6.0	October 14	Adobe security patch APSB26-153

Frequently asked questions

My store is on Magento Open Source, not Mage-OS: does this concern me?

This release is for Mage-OS. For Adobe Commerce and Magento Open Source, Adobe's October patch applies, explained in this article.

How complicated is the upgrade?

From 3.5.x it is a direct upgrade, with no dependency changes. It should still be tested and handled by someone who knows your store, because it also touches returns and emails.

What happens if I stay on 3.5.0?

With this release 3.5.0 reaches end of support: it will receive no further fixes and stays exposed to the October issues.

Security updates without the worry

Following a release a month, testing it and deploying it without stopping sales is recurring work. With the maintenance and support service I take care of it, on Mage-OS, Magento and Adobe Commerce.

Want to know whether your store is up to date? Request a security audit and a free quote.

Considering a move to Mage-OS? See replatforming and migrations and Mage-OS Hackathon Italy: a distribution for companies.

Informative article: the data comes from the Mage-OS 3.6.0 release notes of October 14, 2026 and Adobe's bulletin APSB26-153. For upgrade instructions always refer to the official documentation.

Adobe Commerce APSB26-153: Critical October Patch

2026-10-14T00:00:00.000Z

On October 13, 2026 Adobe published security bulletin APSB26-153 for Adobe Commerce, the B2B module and Magento Open Source. It fixes 11 vulnerabilities: 5 rated critical, 5 high and 1 medium. Adobe says it is not aware of attacks already under way, but asks you to apply the updates as soon as possible: those who do not remain vulnerable, and Adobe will have limited means to help them. The official bulletin has all the details.

What was fixed

Severity	How many	Possible effect
Critical	5	Running code on the server, privilege escalation
High	5	Running code, writing files on the server, bypassing security controls, privilege escalation
Medium	1	Bypassing security controls

The most serious one (CVE-2026-103849) has the maximum score, 10 out of 10, and allows code to run on the server without being authenticated. Three other critical vulnerabilities do not require authentication either.

Which stores are affected

Adobe Commerce from version 2.4.4 to 2.4.9, up to the September 2026 releases, both on cloud and on your own servers.
Magento Open Source from 2.4.6 to 2.4.9. Fixes are distributed for 2.4.7 and later: anyone on an older version has no patch.
B2B module in versions 1.3.3 to 1.5.3.

What to do, in order

Check your version and hosting type. If you are on Adobe Commerce cloud, the fix arrives with Adobe's automatic updates: applying the patch by hand when it is already there can cause installation errors.
Check the base. The monthly patches are tested only on the latest yearly security release of your version and must be applied in order: if you skipped one, apply that first.
Apply the October patch, the right file for your version and for each installed component.
Also apply the hotfix for CVE-2026-75650, September's critical vulnerability (bulletin APSB26-146), if you have not already: Adobe asks for both. We covered it in StyleSmuggler: critical vulnerability and patch.
Rotate your encryption keys and the related credentials. Adobe strongly recommends it as part of the remediation.
Verify the result with Adobe's tool, which shows which patches are missing and which vulnerabilities you are protected from. Test everything in a test environment and release in a low-traffic window.

Why not wait

Four of the critical vulnerabilities require no credentials. Once a bulletin is published, anyone who wants to attack a store knows what to look for. That is why it is not worth putting it off, even though Adobe does not report attacks in progress.

The next date is November 10: an optional release because of the holiday code freeze, as is December 8.

Frequently asked questions

Do I have to apply the patch right away?

Adobe recommends applying the updates as soon as possible. With critical vulnerabilities that need no authentication, putting it off raises the risk with no benefit.

I am on Adobe Commerce cloud: what changes?

The fix is in Adobe's cloud package update. Check the installed version first, because applying the manual patch when the fix is already there can make the installation fail.

My store is on an old version: what now?

For Magento Open Source, below 2.4.7 there are no fixes, and the bulletin does not include Adobe Commerce versions older than 2.4.4. In that case the way forward is to update or change platform.

Security updates without the worry

Reading bulletins, testing patches, rotating keys and verifying the result without stopping sales is recurring work. With the maintenance and support service I take care of it: fixes are read, tested and released at the right time.

Want to know whether your store is up to date? Request a security audit and a free quote.

If your store runs a version that no longer receives fixes, see replatforming and migrations.

Informative article: the data comes from bulletin APSB26-153 and Adobe's support article of October 13, 2026. For installation instructions always refer to the official documentation.

How Much Does an E-commerce Store Cost? What to Check

2026-10-02T00:00:00.000Z

The cost of an e-commerce store has no single price: it depends on the platform, the features, the integrations and how much is customized. The good news is that there are only a few items, and they can be compared. Knowing them before asking for a quote helps you avoid surprises and choose better.

The cost has two parts

Most quotes focus on the first, but the second weighs more over time.

Part	What it includes	When you pay
Upfront cost	Analysis, design, development, loading products, connections to other systems, testing.	Once, before launch.
Ongoing costs	Hosting, platform and module fees, payment fees, maintenance and security.	Every month or every year.

What pushes the price up or down

The platform. Some have a monthly fee (like Shopify), some a license (like Adobe Commerce), and some are free but need more setup work (like Magento Open Source, Mage-OS or WooCommerce).
Design and customization. A ready-made theme costs less than a custom design.
The catalog. A few simple products are easy to load; many variants, sizes or colours take more work.
Integrations. Connecting the store to your back-office system, warehouse or carriers takes development, but saves retyping data by hand.
Special features. B2B selling, several languages or countries, different price lists per customer.
Moving from an existing site. Transferring products, customers and orders without losing search rankings is a job of its own.

The costs people often forget

Maintenance and security. Platforms and modules need updates: neglecting them exposes the store to problems that cost more to fix later.
Payment fees. Every card or other payment carries a percentage paid by the store.
Subscription modules. Many add-on tools are paid monthly or yearly.
Content and promotion. Photos, copy and advertising are not part of development, but you need them to sell.

How to compare two quotes

Two offers with very different prices often do not include the same things. Always ask:

Which platform is planned and what are its ongoing costs?
Which features and connections are included, and which are not?
Who loads the products and how many hours are planned?
What happens after launch: support, updates, fixes?
Is the work fixed-price or hourly, and what happens if the requirements change?

How to keep spending under control

Spending less does not mean spending worse, if you choose your priorities well:

Start with the essential features and postpone the rest: any extra feature can be added when needed.
Set the budget from the goal, for example how many monthly orders the store needs to pay for itself.
Ask for a phased plan, with the cost of each phase, instead of one lump sum.
Prepare the content first: photos and descriptions that are ready reduce working hours.

Frequently asked questions

Is a fixed-price quote better than hourly?

A fixed price gives a defined cost when requirements are clear. Hours are more flexible for work that changes along the way, such as ongoing support or small improvements. Sometimes the two are combined.

How long until it is online?

A simple store can be ready in a few weeks. With many features or connections it takes longer. After the first analysis a concrete estimate is possible.

Can I start small and grow later?

Yes, and it is often the wisest choice: start with the essential features and add the rest when results justify it. Just pick a platform that will not lock you in later.

A clear quote before you decide

Every project is different, so I do not give a price before understanding it. I work hourly starting at €60/hour, with discounts for large projects and long-term collaborations, or with a fixed-price quote. If you are considering a new store, see B2C e-commerce development; to keep it up to date over time there is the maintenance and support service.

Want to know what yours would cost? Request a free, no-obligation quote.

Migrating an E-commerce Store Without Losing Rankings

2026-09-30T00:00:00.000Z

Migrating an e-commerce store to a new platform can cost you visibility on Google if page addresses change without being handled. With proper preparation the risk is greatly reduced, but it does not disappear: a temporary drop in traffic can still happen. The point is that the pages that bring you customers today must stay reachable and recognizable.

Why there is a risk

Google took time to understand your site: which pages matter, what they are about, how they are linked. If after the migration a product changes address and the old one does not point to the new one, then to Google that page disappears and an unknown one appears. Customers clicking from search results hit an error, and sales are lost.

The checklist before the move

A list of the pages that bring traffic. Start from Google Search Console data: the products, categories and articles that bring visits and orders today.
A map of old and new addresses. Every important page needs an exact match.
Permanent redirects. Anyone opening the old address is automatically sent to the new one, using the type of redirect Google recommends for moves.
Titles, descriptions and texts kept. Changing everything together with the platform makes it hard to know what works.
A consistent category structure. Important pages should not end up further from the home page.
Sitemap and structured data. They must be recreated on the new site and submitted to Google.
Speed and mobile performance. The new store should be at least as fast as the old one.

When to migrate

Peak traffic periods, such as sales, Black Friday and Christmas, are the worst time to switch. A quieter period is better, leaving time to fix any problems before the important season.

After go-live

The work does not end at launch. In the following weeks you check errors in Search Console, missing pages, and the trend of traffic and orders, and fix anomalies right away. A short dip after changing platform is normal; one that lasts needs analysis.

What you can lose besides rankings

Visibility is not the only thing at stake. Before the move, also check:

Customers and orders: they must be transferred complete. Passwords usually cannot be carried over from one platform to another, so customers sometimes have to reset them: better to warn them.
Connections to other systems: back-office, shipping and payments must be reconnected and tested.
Analytics and tracking: measurement tools must be switched back on, otherwise you cannot tell whether traffic is falling.
Automatic emails: order confirmations and shipping notices must work from day one.

Frequently asked questions

How long does a migration take?

It depends on the catalog, integrations and customizations: from a few weeks to a few months. After the analysis a concrete estimate is possible.

Does the store stop during the move?

The old store stays live while the new one is built. Downtime is limited to the switch itself, planned for a low-traffic window.

Can I change the design during the migration too?

You can, but consider how much to change at once, because every extra change makes it harder to tell what caused a drop. If traffic drops, it is easier to find the reason when changes were gradual.

Plan the migration before you start

A well-prepared migration protects the results you built over years. If you are thinking about changing platform, or your store runs a version that is no longer updated, see the page on replatforming and migrations. If cost is your concern, also read how much an e-commerce store costs.

Want to assess migrating your store? Request a consultation and a free quote.

Mage-OS Italy Hackathon: a Distribution for Businesses

2026-09-28T00:00:00.000Z

On September 25, 2026 the second Italian Mage-OS Hackathon took place in Bologna. Mage-OS is the open source project created to grow the Magento ecosystem. The idea the community voted for most was an Italian distribution of Mage-OS: a single package, ready for one specific national market, meant to cut the cost and time of launching an online store. It is still in development, but it shows a trend that matters for any merchant: ready-made, localized setups for Mage-OS.

Informative article: it reports the results of the event. Timing and final features depend on the work of the open source community.

Why an Italian distribution can save money

Today, opening a Magento store in a specific country often means assembling several separate modules: translations, invoice request at checkout, local tax data handling. Each module must be chosen, installed, tested and kept up to date.

According to the organizers' recap, the distribution should bring together in one package translations, support for Italian invoicing, invoice request at checkout and the basic settings for the local market. The expected benefits for anyone launching or renewing a store:

Lower upfront costs: fewer hours spent putting third-party components together.
Fewer compatibility risks: components designed to work together, maintained by a community.
A common base that developers and agencies can build on, instead of starting from scratch every time.

Note: your store's tax compliance remains your responsibility, to be checked with your accountant or tax advisor, whatever package you use.

What was proposed

The day was used to decide where to invest effort, by voting on priorities:

Area	What it includes	Benefit for sellers
Italian distribution	Single package with translations and invoicing.	Faster launch and fewer modules to manage.
Customer data and checkout	Custom fields compatible with the Hyvä checkout.	Collecting needed data without getting in the way of the purchase.
Login and analytics	Social login and Google Analytics 4 / Tag Manager integration.	Easier sign-up and sales measurement.
Artificial intelligence	Help with product descriptions, SEO and images.	Catalogs that are faster to prepare.

In the afternoon, hands-on work produced solid foundations for social login, analytics and early parts of invoicing and attributes. These are foundations, not finished tools: the organizers gave no release dates.

Frequently asked questions

What is Mage-OS and how does it differ from Magento?

It is an independent open source project based on Magento Open Source and led by a community of developers and companies. It keeps compatibility with the Magento ecosystem.

Can I move my current store to Mage-OS?

In many cases yes: since it is based on Magento, catalog, customers and orders can be kept. Every migration must be assessed and tested first, depending on version and installed modules.

When will the Italian distribution be available?

No date has been announced. Work will continue over the coming months; until it is released and tested, it is not wise to base a production project on it.

A new store or a renewal?

Mage-OS gives anyone who wants to sell online an open base with no license fees. Taking part in the community makes it possible to judge what is mature and what is not, and to set up a store that does not become a burden to maintain.

Thinking about a new e-commerce or renewing your current one? Request a consultation and a free quote.

B2B E-commerce: How It Works and What You Need

2026-09-21T00:00:00.000Z

A B2B e-commerce is an online store reserved for business customers: resellers, installers, companies. Each logs in with their own account and orders at the agreed prices and terms, without phone calls, emails and spreadsheets. It makes sense when customers order often, with different price lists, and your order desk spends its time retyping data.

How it differs from a consumer store

	B2C	B2B
Who buys	The general public	Companies and professionals, often existing customers
Prices	The same for everyone	Different per customer or group
Orders	Small, occasional	Large and repeated
Access	Open	Often restricted, with approved registration
Payment	Immediate	Often on credit terms

The features you really need

You do not need them all from day one. The most requested are:

A customer portal with several users for the same company.
Price lists and discounts per customer, with no separate files prepared by hand.
Quick order by product code or from a file, for those who always buy the same things.
Reordering of products bought in the past.
Quote requests for special orders.
Order approval and spending limits, for companies with several people.
Connection to your back-office system, to keep prices, stock and orders aligned.

What benefits it brings

Less manual work for the order desk, and fewer mistakes in codes and quantities.
More independent customers: they check history, order status and availability on their own.
Orders at any hour, including outside office hours.
More time for key customers, because simple requests go through the site.

Which platform to choose

There is no single answer. Adobe Commerce includes native B2B features, such as company accounts and quote requests, but it has a license cost. Magento Open Source and Mage-OS are free and flexible, and B2B features come from extensions or custom development. Other platforms offer B2B options that depend on the plan and modules you choose. The choice depends on catalog, number of customers, integrations and budget.

When it makes sense, and when it does not

A B2B e-commerce works well if you have many customers who order often, price lists that change from customer to customer and an order desk that spends much of the day entering requests. It is less worthwhile if you have few customers and every order needs a negotiation: in that case simpler tools for quotes and contact management are enough.

How to start

Start from the processes, not from the site: how orders arrive today, who enters them, where time is lost.
Pick a few essential features and put them online with a small group of customers.
Collect feedback from the people who really use it, and improve before opening to everyone.
Extend to new features and more customers, one step at a time.

Frequently asked questions

Can I have B2B and B2C on the same site?

Yes, it is a common choice. The same catalog can serve consumers and business customers, each with their own prices and terms.

Do I have to change my back-office system?

Not necessarily. The store connects to the one you already use to sync prices, stock and orders.

Where should I start?

With the features that save the most time, usually the customer portal, per-customer price lists and quick order. The rest is added later, once customers are comfortable. Starting with a few features also lowers the risk: you see straight away whether customers use it, before investing more.

Let's talk about your B2B channel

Every company sells differently, so a B2B project always starts by listening to your processes. For details see the page on B2B e-commerce; for the connection with your back-office system, system integrations.

Want to take your B2B orders online? Request a consultation and a free quote.

StyleSmuggler Magento: Critical Vulnerability and Patch

2026-09-11T00:00:00.000Z

StyleSmuggler (CVE-2026-75650) is a critical vulnerability in Magento Open Source and Adobe Commerce: it lets an attacker run code on your online store without needing a password. It has the maximum severity score (10 out of 10) and, according to security researchers, it is already being used against real stores. If you run a Magento store, you need to deal with it now.

Informative article, not a security assessment: the right actions depend on your store's setup.

What your store is risking

Whoever exploits the flaw takes control of the site. From there they can install hidden programs to copy your customers' card data, create secret accesses or stop sales. For a business this means:

Direct costs: penalties for the data breach, fraudulent transactions, emergency clean-up expenses.
Reputation damage: customers lose trust and you may run into problems with your payment provider.
Lost sales: the site can stay offline during recovery.

The problem is in Magento's core code, not in an add-on module. That is why ordinary firewalls, which filter traffic from the outside, are not a reliable protection: you need the official fix.

Which stores are affected

Practically every recent Magento store, whatever it looks like:

stores with a traditional theme (Luma or custom);
headless or PWA stores, where the visual part is separate;
stores with the Hyvä theme.

The theme or frontend technology does not change the risk. To find out whether your version is included, check Adobe's security bulletin or ask whoever manages your store.

How to secure it: checklist

Adobe has published an emergency fix (hotfix VULN-39341). These are the steps, in order:

Step	Action	Why it matters
1. Backup	Full copy of files and database.	You can roll back if something goes wrong.
2. Install the fix	Apply it in a test environment first.	Closes the flaw without breaking your customizations.
3. Check	Review files, database and admin users.	Finds any access or code left by an attacker before the update.
4. Keys and passwords	Change the encryption keys and service passwords, as Adobe indicates.	If data was read, the old credentials must no longer be used.
5. Go live	Deploy during low-traffic hours.	Sales are not interrupted.

Installing the fix is not enough if the store has already been attacked: that is why step 3 matters as much as step 2.

Frequently asked questions

Does our hosting firewall protect us?

Not reliably. The attack exploits how Magento works internally and can get past traditional controls. The only definitive solution is the official fix.

Are we safe with Hyvä or a headless architecture?

No. The flaw is in the core of Magento, so these stores are affected too.

What if we suspect we have already been attacked?

Typical signs: slowdowns, strange orders or admin users, unknown files. Put the site in maintenance mode, keep the system logs for analysis, restore a clean backup, apply the fix and do a full clean-up before reopening.

Secure your e-commerce

Applying an emergency fix and cleaning up a compromised site without in-depth Magento knowledge can cause unexpected downtime or leave hidden accesses behind. With the maintenance and support service, security fixes are installed as soon as they are available, without compromising your customizations or your sales.

Want to know if your store is exposed? Request a security audit and a free quote.

Is your store no longer receiving updates? See replatforming and migrations.

Magento APSB26-92: Security Update and Risks

2026-08-12T00:00:00.000Z

On August 11, 2026 Adobe published security bulletin APSB26-92, which fixes seven vulnerabilities in Magento Open Source and Adobe Commerce, five of them rated critical. The most serious lets an attacker take over a customer's account without knowing the password. At release Adobe reported no attacks in progress, but the window to update calmly is short: if you run a Magento store, plan the update now.

Informative article, not a security assessment: the right actions depend on your store's setup.

What your store is risking

The fixed flaws can allow security controls to be bypassed, unauthorized code to run, or permissions to be obtained that should not be available. For an online store this means:

Compromised customer accounts: an attacker can see other people's personal data and orders, with possible data-protection consequences.
Unauthorized system access: settings changed or malicious code inserted into the site.
Sales and reputation: an incident can lead to your payment system being blocked and to customers losing trust.

Why not wait

When Adobe publishes a bulletin, the flaws become public knowledge and attackers study the fixes to target stores that have not updated. Adobe gives this update priority 2 (no known attacks at release time), but security researchers report exploitation attempts against the main flaw. The sooner you update, the less time attackers have.

Which stores are affected

According to Adobe's bulletin, installations not updated to the August 2026 version are affected:

Magento Open Source from 2.4.6 to 2.4.9;
Adobe Commerce (including Cloud) from 2.4.4 to 2.4.9;
Adobe Commerce B2B, with the corresponding versions.

To check your exact version, consult the official bulletin or ask whoever manages your store.

Action plan

A rushed update can clash with your design and payment modules. These are the recommended steps:

Step	Action	Why it matters
1. Prerequisites	Check that earlier updates (such as July 2026) are installed.	The fix needs an up-to-date base, otherwise it fails.
2. Test	Apply the update to a copy of the site.	You find incompatibilities before a customer does.
3. Check	Verify cart, payment, sign-up and email sending.	Sales continue without surprises.
4. Go live	Deploy during low-traffic hours.	Minimal disruption for customers.
5. Review	Look for unusual accounts and admin access.	You spot any abuse that happened before the update.

Frequently asked questions

Do we need to update even if there are no known attacks?

Yes. Once published, the flaws are known to everyone and exploited quickly. Updating in the days after release is the prudent choice.

Can the update change the design or features of the site?

Normally not: it only fixes the flaws. If you have customizations in the affected areas, a test beforehand is needed.

What if we skipped earlier updates?

The latest fixes require the previous ones. With a backlog, an ordered sequence is needed to avoid errors.

Security updates without worry

Updating Magento or Adobe Commerce on your own can cause outages and incompatibilities. With the maintenance and support service, security bulletins are applied promptly, after testing, without compromising customizations, speed or sales.

Want to know if your store is up to date? Request a security audit and a free quote.

Is your store no longer receiving updates? See replatforming and migrations.

E-commerce Withdrawal Button: What Changes in 2026

2026-05-14T00:00:00.000Z

From June 19, 2026, if you sell online to consumers in the EU, your store must let customers exercise their right of withdrawal with a clearly visible button, directly on the site. This is the so-called withdrawal button, and it applies to any online store, whatever platform it uses.

Here you will find what the rule requires, the difference between withdrawal and return, how to handle returns without wasting time, and what to check in your store.

Informative article, not legal advice: for your store's compliance, consult a lawyer or your advisor, as national implementation details can vary.

What changes in practice

The change comes from Directive (EU) 2023/2673, which requires EU member states to apply these rules from June 19, 2026. If you sell to consumers in the EU, your site must offer:

A clearly visible, easy-to-find withdrawal function, available for the whole period in which the customer can withdraw.
Clear wording, such as "withdraw from the contract here" or an equivalent phrase.
Two steps: the customer enters their details and the order, then confirms the choice.
A receipt sent immediately, for example by email, with the content of the request and the date and time it was sent.

Before, in many cases a page with instructions or an email address was enough. Now the process must be simple and tracked directly on the site.

Who must comply

Anyone who sells to consumers in the EU with contracts concluded online. If you only sell to other businesses the rule does not apply to you; if you sell to both, it applies to the consumer-facing part. The platform does not matter: Magento, Mage-OS, Shopify, WooCommerce or a custom site.

Withdrawal and return are not the same thing

	Withdrawal	Return
What it is	The declaration by which the customer cancels the purchase	The operational process: authorize, receive and inspect the goods, refund or replace
Where it comes from	A legal obligation	An organizational choice of the store
What you need	Button, confirmation and receipt with date and time	Requests, statuses, customer communication and refunds

The button makes the customer's wish to withdraw valid and tracked; a returns system helps you manage in an orderly way what happens next. You need both.

How to handle returns without wasting time

Without a dedicated tool, returns turn into a flood of emails, phone calls and spreadsheets. With a suitable system you get orderly requests, an always-clear status for you and the customer, attached photos and documents, a single channel for dialogue (with private internal notes) and automatic emails at every step.

If your store runs on Magento 2 or Mage-OS, there is a free, open source module, MageOS RMA, published in the official mage-os organization on GitHub. In the admin panel you find the list of returns, customers get a "My returns" section, and even those who bought without registering can request a return from their order.

Three points to check, with any system

A returns tool is not enough on its own to be compliant. The MageOS RMA documentation raises three points that work as a reminder for any system:

The withdrawal button must be built anyway. The module handles returns after the request, but it does not describe the two-step function and the receipt with date and time.
When the days start counting. The module's return period (30 days by default) starts from the order date, while the 14-day withdrawal period for products generally starts from delivery. With slow shipping you risk closing the window too early.
Which orders can be returned. By default only "completed" ones, but the customer can withdraw even before receiving the goods.

Also remember that the module is disabled by default and must be configured (period, allowed statuses, email texts).

What to do now

Check whether you sell to consumers online.
Look at the site as a customer would: is there a "withdraw from the contract here" button? Does it work in two steps? Does a receipt with date and time arrive?
Define the returns policy: days, conditions, who pays shipping, refund times.
Choose and configure the tool to manage returns, then test everything with a test order.
Have texts and terms reviewed by a lawyer or your advisor.

Frequently asked questions

Is the withdrawal button mandatory for Shopify and WooCommerce too?

Yes. The obligation applies to anyone selling to consumers with contracts concluded online, not to a particular platform.

Does MageOS RMA make me compliant with the new rule?

No, not by itself: it helps you manage returns in an orderly way, but the withdrawal function required by law must be provided and verified separately.

How much does the module cost?

It is open source under the MIT license, so there are no license fees. Installation, configuration and customization costs on your store remain.

Want to bring your e-commerce into line?

If you have a store on Magento 2 or Mage-OS and want to enable returns management, add the withdrawal button or connect returns to your management software, I can take care of it: from analysis to configuration to customizations. The quote is free and non-binding: write to me to talk about it.

Magento Updates Without Stopping Your Sales

2026-04-20T00:00:00.000Z

Updating a Magento or Adobe Commerce store does not have to stop your sales. With a zero-downtime deployment, the new files are prepared on the side and swapped in for the live ones in an instant, so in most cases customers notice nothing. The traditional method, instead, puts the site in "maintenance mode" exactly when you are trying to improve it.

The hidden cost of maintenance mode

Taking the store offline to install a fix or a new design is an economic cost, not just a technical nuisance:

Abandoned carts: anyone on the site at that moment sees an error page and buys elsewhere.
Wasted ad campaigns: if you have active ads, every click that lands on a maintenance page is lost budget.
Risk of prolonged outages: overwriting files directly on the live site means that an unexpected problem during installation leaves the store down until it is fixed.

How deployment without interruptions works

Instead of changing the site while customers are browsing, the new version is built in a separate folder on the server. Tools like Deployer automate these steps:

Step	What happens	Effect on your store
1. Preparation	The server creates a temporary folder.	The public site keeps running.
2. Build and test	The new files are uploaded and prepared there.	Heavy operations happen away from the live cart.
3. Switch	An internal link points to the new version.	The change takes a fraction of a second.
4. Rollback	If something goes wrong, the previous version is restored with one command.	A mistake is fixed in moments, not hours.

The limits to know about

"Zero downtime" does not mean "zero attention". Some updates also touch the database (for example a new Magento version or a module that changes the data structure) and in those cases a tailored plan is needed, sometimes with a short dedicated window. That is why every change should be tested first in a staging environment and published during low-traffic hours.

Frequently asked questions

What happens to customers who are ordering during the update?

With a well-prepared deployment, browsing and checkout continue normally. In more delicate cases, such as database changes, the moment with the least disruption is chosen.

Does it also work for third-party modules (payments, shipping, design)?

Yes. All code changes are installed and verified in the separate folder before going live.

Do I need a special server?

Usually not: a Linux server with secure access, correctly configured by the developer, is enough. Check case by case with your hosting provider.

Fast updates, sales always on

Publishing new features and fixes without stopping the business requires a proven process. With the maintenance and support service, updates to your Magento store are prepared, tested and published without interrupting sales.

Want to update your store without taking it offline? Request a consultation and a free quote.

Is your store on a very old version? See replatforming and migrations.

Informative article: the right procedure depends on your store's infrastructure and customizations and must be verified beforehand.

PCI DSS 4.0 e-commerce: risks and how to comply

2025-03-17T00:00:00.000Z

If your online store accepts card payments, there is a deadline that concerns you, even if you are a small store: from March 31, 2025 the new PCI DSS 4.0 rules on the payment page become mandatory. In short: you must know what runs on the page where customers enter their card and notice right away if someone tampers with it.

Informative article, not a security assessment: for your specific case, check with your bank or payment provider.

What PCI DSS is (and why it is not a law)

It is the security standard of the card networks (Visa, Mastercard and the others). It is not a law, but a contractual obligation: it is required by the bank or payment provider you have an agreement with to accept cards.

The risk: "invisible attacks" on the checkout

Criminals no longer attack only databases: they attack the page where the customer types the card. Malicious code slips in unnoticed, often through an outdated external tool (a chat, an advertising pixel, a third-party module), and copies the data while the customer types it. It is called e-skimming or Magecart. The sale goes through and nobody sees anything: you find out months later, when banks and customers report fraud.

The consequences depend on the contract with your bank or payment provider: from additional costs to liability for the stolen data and, in the most serious cases, suspension of the ability to accept cards. On top of that comes reputation damage.

The two rules that apply from March 31, 2025

Know and authorize every script. You must have a list of all the scripts on the payment page, with the reason each one is there, and allow only authorized ones.
Notice changes. You need a control that detects and reports unauthorized changes to the page, with periodic checks (normally at least once a week).

Does it really concern you? It depends on how you take payments

How you take payments	What it means for you
The customer pays on a provider's page (leaves your site)	Fewer requirements, but you must ensure your site is not exposed to malicious scripts. Ask your provider to confirm.
The provider's card fields are inside your page	Your page's code can affect security: controls matter more.
Card data passes through your site	The highest level of responsibility, with more controls.

For the first case the standard provides lighter rules, provided you declare that the site is not exposed to these attacks (details from the PCI Security Standards Council). Ask your bank or provider which self-assessment questionnaire you must complete: it is the fastest way to understand your level.

Where to start

Find out how you take payments (external page, embedded fields or data on your site).
List the external tools on the payment page (chat, analytics, pixels, widgets) and remove the unnecessary ones.
Ask your provider for written confirmation of what they cover and what remains your responsibility.
Set up change monitoring with automatic alerts.
Keep everything updated and have the result checked by an expert.

The Magento case: why the checkout matters

If you use Magento 2 or Adobe Commerce, everything revolves around the checkout. The traditional one (the Luma theme) relies on dated technologies and many third-party modules: checking every script can become long and costly.

That is why many merchants choose Hyvä, a more modern and lightweight checkout. According to the official documentation, from version 1.3 the browser runs only explicitly authorized code and blocks the rest, in line with the spirit of the new rules. The advantage is also practical: less code to check, usually a faster checkout and easier maintenance.

Be careful though: no theme makes you compliant by itself. Third-party modules must be compatible, and the list of scripts and change monitoring still have to be put in place. And security is not a one-off job: every new module or marketing tool changes what runs on the payment page, which is why periodic updates and checks are needed, that is, ongoing maintenance.

Frequently asked questions

Is PCI DSS a law?

No. It is a card network standard that banks and payment providers impose by contract on anyone who accepts cards.

If I use PayPal, Stripe or another provider, am I exempt?

You are greatly relieved, but not exempt: you must complete the relevant questionnaire and ensure your site is not exposed to script-based attacks. Ask your provider what they cover and what remains your responsibility.

Do I have to switch to Hyvä?

No. It is one of the most straightforward paths for a Magento store, but the goal is to control scripts and detect changes, with any technology.

Want to know if your store is in order?

If you have an e-commerce on Magento 2 or Adobe Commerce, I can do a free technical audit: we look at how you take payments, which tools are on the payment page and what the quickest path is to secure it, including with a modern checkout and periodic maintenance. Write to me to talk about it: the quote is free and non-binding.