Three Ways to Implement Multi-Brand Commerce on Drupal

Picture a manufacturer with three brands. Each brand needs its own website, with its own look, its own content, and its own product catalog.

But the customers overlap. A buyer who orders from one brand should be able to sign in once, see every order they've placed with the company, and buy on the payment terms they've already negotiated. Ideally, they only need to check out once.

It's a common request from multi-brand B2B companies, and there are several ways to build it. Which one is the right choice? It depends on where you want the complexity to live.

Start with what's actually shared

A typical multi-brand brief includes the following requests:

Distinct branding for each brand
Distinct content for each brand
A distinct product catalog for each brand
One customer record across all brands
Order history and payment terms visible from any brand
A single sign-on across every brand's site
Possibly one cart that spans brands

The first three items are about keeping brands apart. Everything else is about keeping the customer together and reconciling his information and activity. A shared login, shared customer data and a shared cart are naturally features of one application. Keep that fact in mind.

Option 1: Go headless

Drupal powers the backend and each brand has a separate front end.

What it adds: a modern front end and a separate deployment for each brand.
Where it struggles: it doesn't remove the hard problems. A shared login and a shared cart still have to work across separate sites, and now both the front ends and the APIs behind them have to handle it.
The ongoing cost: every feature gets built twice, once as an API and once in the front end. Caching has to be coordinated across two layers. A single page load can trigger many API requests to the server.

Option 2: Use multiple websites with separate databases

Each brand gets its own Drupal site and database, all running from one shared codebase, each using a different theme.

What it adds: clean separation between brands.
Where it struggles: one customer becomes several records that must be kept in sync. Order history and payment terms have to be copied or shared, and a single sign-on becomes its own identity management project.
Data replication: customer data has to be replicated from one site to the others. That introduces lag, and conflicts when the same record changes in two places at once. A shared cart is the worst possible candidate for this kind of delayed syncing.

Option 3: Run every brand from one installation

One Drupal installation serves every brand, using the Domain module suite, with Commerce Store Domain connecting it to Drupal Commerce.

How it works: each brand is a record inside one Drupal installation, and the web address a visitor arrives on decides which brand they see. Each brand also gets its own store in Commerce, and the store decides which prices, promotions and payment methods apply.
What it adds: one codebase, one configuration, one deployment and one database.
Where it struggles: the brands are less isolated. They share a release process and a database.

Where does the complexity live?

None of the options above is wrong. Each can be built, and each solves legitimate requirements. The difference is the starting point:

The first two build separate systems, then add technology to make them share customers, carts, orders and logins.
A single installation never separates those things in the first place.

When shared customers and shared logins are the central requirements, that difference decides a lot.

What one installation gives you for free

Customer records, order history and payment terms. There's only one record of each, so there's nothing to sync. In our proof of concept, orders placed in three different brand stores all appeared in the order history of every brand.
Phone and offline orders. Bring them into the system once, and every brand can see them.
Search. One search index serves every brand. The brand is simply a filter.
Future catalog plans. Offering another catalog, such as a punchout catalog for procurement systems, is straightforward when products already live in one place. Across three databases, it's much harder.
Real brand separation. Content assigned to one brand is refused on the others by access control, not just hidden. Themes and site names differ through configuration, with nothing duplicated.

What is still difficult with one installation?

One installation simplifies many of the hard problems, but it doesn’t erase them.

Logins across separate domains

Browsers won't share a login cookie across different root domains, no matter how the site is built. With one installation, though, every brand already shares the same session storage, so the job is placing a cookie, not federating identities between systems.

A cart that spans brands

In Drupal Commerce, each brand gets its own store entity, and every order is recorded against exactly one store. That store decides which merchant account takes the payment and which promotions apply. So when one cart holds products from three brands, the whole order is treated as if it came from a single brand. That brand's merchant account collects everyone's money, and its promotions can discount the other brands' products.

The fix is to split the order after checkout. The customer still sees one order, but behind the scenes each brand gets its own portion, with its own payment, warehouse instructions and emails. It can work, and work well, but it's the largest piece of custom development in a shared cart, which is why many companies launch with a separate cart for each brand.

Release discipline

A deployment reaches every brand at once, so testing and release planning have to account for all of them. A bug introduced for one brand can surface on another, and brand teams can't release on completely independent schedules.

However, this works in your favor, too. A fix or security update reaches every brand at once, instead of being applied site by site.

Does one installation hold up at scale?

One outdoor lifestyle and gear company runs eight brand sites across North America and Europe from one Drupal Commerce installation, using the Domain suite. Each brand has its own currencies, languages, warehouses, legal entities, payment accounts, and email identities. Our hypothetical example of three brands is a smaller version of a problem already successful in the real world.

Questions to ask before you choose

Do your brands need to share customers, or just a parent company?
Do the brands truly need separate root domains, or could they share a parent domain? That one decision creates most of the single sign-on work.
Does a cross-brand cart need to exist at launch, or can each brand start with its own cart?
How independently do brand teams need to release changes?
If data lives in several places, who owns the cost of keeping it in sync, for as long as the sites exist?

Talk it through with us

If you're weighing architectures for a multi-brand commerce build, we're happy to walk through your requirements and show you where the complexity would land in each option.