A B2C and B2B implementation on one Magento 2 platform
Bring retail and business sales together in one store. We design and build Magento 2 platforms in which a shared core of data and integrations meets separate accounts, prices, catalogues and purchase processes.
We start by checking which processes are worth combining and which should stay separate. Only then do we settle the architecture, the scope of features and the way Magento 2 connects to the company's systems.
- process analysis
- platform architecture
- both purchase paths
- integrations and data
- QA and launch
B2C and B2B use the same data but buy differently
An individual customer expects a short purchase path, an up-to-date offer and convenient payment. A business customer may need their own price list, several users on one account, purchase limits or an order approval step.
The implementation puts both experiences in order without duplicating the whole catalogue and every integration. The shared core serves everything both channels rely on.
The differences are designed at the level of the website, the account, prices and the purchase process. The exact split follows an analysis of the sales model, the systems and how the teams work.
Shared core
The following can be shared
- product data
- stock and availability
- order handling
- integrations
- the admin panel
- data used in analytics
B2C
Retail sales
The scope can cover:
- guest checkout or a standard customer account
- public prices, discounts and promotions
- online payments and retail deliveries
- merchandising, content and product search
- a purchase process optimised for a short decision
B2B
Business sales
The scope can cover:
- company accounts and users with different roles
- individual price lists and trade terms
- catalogues available to selected groups
- limits, approvals and order reordering
- payments and deliveries following the customer's contract
- Planning retail sales only?See the D2C implementation on Magento 2
- Need a standalone B2B platform?See the B2B implementation on Magento 2
Two separate systems start duplicating data, integrations and the team's work
Splitting the channels can make the start easier. The problems appear with growth, once the same products, prices, stock and orders begin to be handled under different rules.
The e‑commerce team manually fixes discrepancies between catalogues. Sales agrees trade terms outside the platform. IT maintains several connections to the same ERP or PIM. Every larger change has to be checked against both environments.
| Area | Current situation | Consequence |
|---|---|---|
| Product data | Descriptions, images and attributes are imported into several places. | Updates land at different times and part of the offer starts to drift apart. |
| Stock and orders | The channels send data to separate queues or integrations. | The team manually reconciles differences in availability and statuses. |
| Prices and terms | Sales rules are maintained in several systems. | It becomes harder to establish which price or rule takes precedence. |
| Development | Similar features are built separately for B2C and B2B. | The cost of each further change covers several environments and several test sets. |
01Product data
Current situation
Descriptions, images and attributes are imported into several places.
Consequence
Updates land at different times and part of the offer starts to drift apart.
02Stock and orders
Current situation
The channels send data to separate queues or integrations.
Consequence
The team manually reconciles differences in availability and statuses.
03Prices and terms
Current situation
Sales rules are maintained in several systems.
Consequence
It becomes harder to establish which price or rule takes precedence.
04Development
Current situation
Similar features are built separately for B2C and B2B.
Consequence
The cost of each further change covers several environments and several test sets.
One architecture can separate the channels without separating the data
The B2C website and the B2B portal can have different interfaces, catalogues, prices, roles and purchase processes. The shared Magento 2 layer handles the data and the integrations both channels use.
The architecture can rest on separate websites, store views and catalogue scopes. Some companies need the channels fully separated. In other cases a shared offer with different prices and features unlocked after login is enough.
The architecture model depends on the Magento edition, the source systems, the current infrastructure and how independent the channels have to be. We settle these decisions before preparing the final estimate.
Sales channels
- B2C websiteIndividual customer
- B2B portalBusiness customer
Magento 2shared data and operations
Integration layer
Source systems
- ERP
- PIM
- WMS
- CRM
What each layer is made of
- 01
Shared layer
- products and attributes
- availability information
- orders and statuses
- connections to the company's systems
- content and configuration management
- monitoring of the most important processes
- 02
B2C layer
- the public offer
- promotions
- retail payments
- a convenient purchase path
- content supporting product choice
- 03
B2B layer
- company accounts
- roles and permissions
- trade terms
- catalogues and prices assigned to a customer
- a purchase process matching the buyer's organisation
If the architecture still has to be defined, the starting point is often a pre-implementation analysis. Scope and schedule are estimated once the decisions on layers and integrations are closed.
B2C and B2B in one store or on separate Magento 2 sites?
This is the first architectural decision of the project and the most expensive one to change later. Below are the three arrangements we use most often, each with what it costs to run.
- 01
One storefront, B2B features behind a login
The business customer sees the same store as a consumer, but once logged in gets their own price list, payment terms, limits and fast ordering. The channels are separated at the level of customer groups and pricing rules, not separate sites.
Fits when
- both channels sell largely the same range
- the differences come down to prices, terms and how orders are placed
- one team serves both channels with the same processes
Running cost
The lowest of the three: one frontend, one set of content and one path for shipping changes.
- 02
Separate B2C and B2B sites in one Magento 2
Each channel has its own site — its own domain, look, catalogue and sales configuration — but both stand in the same installation, on shared code, integrations and admin panel. That is the website level of the Magento architecture.
Fits when
- the range or the messaging of the two channels genuinely differ
- B2B needs its own domain or separate payment and delivery methods
- the retail and wholesale teams work independently of each other
Running cost
One platform to update, but two frontends and two sets of content to run.
- 03
Two independent platforms
Each channel has its own implementation, its own code and its own integrations. Only the company's systems stay shared — the ERP, the PIM or the WMS, as far as both are connected to them.
Fits when
- the channels have separate business models, teams and budgets
- the B2B requirements are unusual enough to rule out a shared architecture
- one of the platforms has to be rebuilt from scratch anyway
Running cost
The highest: integrations, updates, testing and work on product data all doubled with every change.
In most projects the choice is between 01 and 02, and it is settled by whether the channels sell the same range and whether the same team serves them. We close the decision before work starts, together with the split of processes the rest of the scope follows from.
Scope starts with the processes that differ between the channels
The feature list should follow the actual rules of sale. Copying solutions from another platform often carries over processes that already required manual workarounds.
- 01
Customer and company accounts
You need to establish who can create a company account, how it is verified and how many users can operate within one organisation. Roles should reflect the way orders are placed and approved at the customer.
If company accounts are the only channel that matters, a B2B implementation on Magento 2 may make more sense.
- 02
Catalogue and offer availability
The B2C offer can be public while some B2B products stay available only to named customers or segments. The scope also covers selling units, minimum quantities, bulk packaging and availability.
- 03
Prices and trade terms
A price can follow the customer group, a contract, volume, the market or data sent from the ERP. Before the implementation you have to point to the place where the rule is maintained and approved.
- 04
Cart and order
The retail path usually leads to a quick purchase. B2B may add limits, requests for quotation, approvals, customer order numbers, deferred payments and reordering of earlier purchases.
The retail process itself is covered in more depth under the D2C implementation on Magento 2.
- 05
Interface and content
A B2C customer needs an efficient way to choose a product. A business user works more often with SKUs, lists, purchase history and quick order forms. Both interfaces should match how the decision is made.
- 06
Admin panel and reporting
The client's team needs a clear split of orders, customers, prices and content. The scope of the panel should reduce manual work rather than move it from spreadsheets into more admin screens.
Every type of data needs one clearly assigned source
A shared platform requires deciding which system is responsible for the product, the price, stock, the customer and the order status. Without that decision, integrations start duplicating business rules in several places.
A product can come from the PIM, a contract price from the ERP, availability from the WMS and customer data from the CRM. Magento uses that information while selling and passes orders and status changes back.
Before the estimate we check the data format, API availability, synchronisation frequency and error handling. Integration quality affects the team's work long after the platform goes live.
None of the systems listed here is mandatory. Some companies run both channels on a single ERP; others only move product data into a PIM once further markets or brands appear.
Example data matrix
Products and attributes
PIM or ERPB2C and B2B
Decision to makeWhich system is the primary source
Stock and reservations
ERP or WMSAvailability and order fulfilment
Decision to makeHow often the data should be refreshed
Prices and discounts
ERP, CRM or MagentoThe retail offer and B2B terms
Decision to makeWhere the rules are maintained
Customers and companies
CRM, ERP or MagentoAccounts, roles, segments
Decision to makeWhich system creates and updates the record
Orders and statuses
Magento, ERP, WMSSales handling and communication
Decision to makeHow errors and retries are handled
An example matrix. The final split follows the architecture of the client's systems.
First we settle the rules of sale, then we build the platform
A B2C and B2B project carries many dependencies between sales, logistics, finance, e‑commerce and IT. Settling the rules early limits the number of changes made while the platform is being built.
- 01
Diagnosis of the sales model
We map the current processes, the roles of the teams, the problems in both channels and the growth plans. The result is a list of shared areas and of differences that need separate handling.
What the stage leaves behindA list of shared areas and of differences between the channels
- 02
Architecture and scope
We settle the structure of the websites, the data sources, the integration map, the responsibility of each system and the limits of customisation. Those decisions go into the scope and the backlog.
What the stage leaves behindAn architecture description, an integration map, the scope and the backlog
- 03
UX for both channels
We design the B2C and B2B purchase paths, accounts, search, cart, checkout and the features used after login. A prototype lets the process be verified before development.
What the stage leaves behindA prototype of both purchase paths and the interface design
- 04
Development and integrations
Frontend, backend and integrations are built in an order that accounts for the dependencies between systems. Code goes through review and progress is reported within the agreed project process.
What the stage leaves behindReviewed code, integration documentation, progress reports
- 05
Data, testing and acceptance
We check the scenarios of both channels, permissions, prices, orders and data exchange. Migration and imports need trial runs before the production launch.
What the stage leaves behindTest scenarios, trial import results, an acceptance record
- 06
Launch and further growth
The launch covers a rollout plan, control over the most important processes and handling of the issues found after go-live. Further changes go into an ordered development backlog.
What the stage leaves behindA launch plan, a list of monitored processes, a development backlog
After launch
Responsibility does not end on publication day
Stabilisation, monitoring, ticket handling and the required SLA are agreed before the launch. The scope of platform maintenance is described under AURORA CARE, and further feature work under AURORA EVOLUTION.
The project has to stay controllable before launch
An implementation covering two channels has more dependencies than a standard store. Control requires a clear scope, named decision owners, acceptance criteria and a procedure for handling changes.
- 01
Scope and estimates
Assumptions, dependencies and everything excluded from scope should be visible before the work starts. A changed requirement has to come with its impact on budget, deadline and the remaining features.
- 02
Running the project
A dedicated Project Manager keeps decisions, tasks and communication in order. The E‑commerce Manager should not be the person chasing the supplier's work every day.
- 03
Technical quality
Code goes through code review and features are checked by QA. Documentation covers the architecture, the integrations and what is needed for later development.
- 04
Maintenance after launch
Monitoring, ticket handling, development and the required SLA should be agreed before the launch. That avoids a situation where responsibility ends on publication day.
Extracts from real documentation, backlogs and reports are shown at the offer stage, with client data anonymised.
Before launch we check the whole purchase and order-handling flow
A checkout that simply works is not enough. Testing has to cover prices, roles, stock, payments, data exchange and how the order is handled onwards in the company's systems.
Scenarios are prepared separately for B2C and B2B, then combined with integration tests. The length of the list depends on the features, the systems and the implementation model.
B2C
- product and promotion visibility
- variants, cart and checkout
- payment and delivery
- the customer account and post-order communication
B2B
- company registration and verification
- user roles and permissions
- prices, catalogues and limits
- approval, payment and reordering
Integrations
- product and price import
- availability updates
- order hand-off
- status return
- handling a dropped connection and retries
Operations
- administrator permissions
- notifications
- reports
- monitoring
- the release and rollback procedure
A shared Magento makes sense when both channels genuinely share processes
Combining B2C and B2B should simplify the company's operations. Running two channels does not in itself mean they have to sit in one architecture.
A shared platform is a good direction when
- 01both channels use the same catalogue or a large shared part of the offer
- 02stock, orders and product data are handled by the same systems
- 03B2B sales require accounts, prices, permissions and processes beyond a plain retail account
- 04the team wants to reduce the number of separate panels and integrations
- 05the company plans to grow both channels, more brands or more markets
Another option is worth considering first when
- B2B orders are few and are handled smoothly in the current process
- the channels operate in completely separate companies and systems
- full separation of data, teams and infrastructure is required
- the current platform can be extended without a costly rebuild
- there is nobody accountable for decisions about processes and data
If both channels run on separate platforms today, we start by comparing the processes, the data and the costs. Only then do we recommend a shared architecture, extending the current system, or keeping the channels separate.
B2C and B2B on Magento 2 in practice — the Paxit case study
Paxit sells cartons to business and individual customers, online and by phone. The new Magento 2 store had to serve both models at once and connect a made-to-order range to the ERP.
- Starting point
- The conversation began with taking care of the existing store. The analysis showed that technical neglect by the previous vendor was blocking any further growth, so together we decided to build a new Magento 2.
- Both channels in one store
- The design and the processes were prepared for business and individual customers at the same time, with individual terms attached to accounts.
- Catalogue and ERP
- Paxit can make almost any carton pattern and size, so the range had to be connected to the ERP in a way that keeps the process automatic from the order through production to shipping and invoicing.
- Integrations and the purchase process
- Magento 2 connected to the ERP, BaseLinker, Thulium and Trusted, with Doofinder search and an order completed on a single page.
- 1platform for both channels
- 5systems connected to Magento 2
- 2order paths: online and phone
See how the decision to build a new store was made, how both purchase paths were designed and how the range was connected to the ERP.
See the Paxit case studyFrequently asked questions about combining B2C and B2B on Magento 2
The answers cover the scope of the service, the platform edition, integrations and the conditions that drive the cost, the schedule and the way both channels are launched.
Let's discuss combining B2C and B2BYes, provided the shared architecture follows the company's processes and data. Magento can separate websites, catalogues, prices, roles and purchase paths. The implementation model depends on the platform edition, the integrations and how independent the channels have to be.
Yes, and usually that is the point: a product is created once, and who sees it and at what price follows from its site assignment and the customer's group. Part of the range can stay wholesale-only and part retail-only. More important than the catalogue itself is settling which system is the source of products, prices and stock — without that, a shared catalogue quickly drifts apart between the channels.
The scope can cover prices assigned to a group or to a specific customer, individual catalogues, discounts, limits and payment terms. Before the estimate you have to establish where those rules are stored and who manages them.
No. Both channels can have separate interfaces, navigation, content and features. What stays shared is the chosen layer of data, integrations and administration. That is how Pronar Wheels runs: two separate websites inside one Magento 2 instance, on one SAP integration.
The decision should follow the features required, licence cost, the scope of customisation and the growth plans. Some B2B features are available in a given edition, others need modules or separate development. The comparison should be made before the architecture is approved. What the Open Source edition covers on its own is shown by the Magento 2 demo.
Often it can, but it requires an audit of the code, data, checkout and integrations first. Extending makes sense when the current technical base is stable and lets the second channel grow without cementing technical debt. If the store was built incompletely, the starting point is often finishing the Magento 2 store.
Choosing Magento does not automatically mean replacing the other systems. You have to check the available APIs, data quality and the current integrations. Sometimes a new connection is enough; sometimes the data needs cleaning up or a separate PIM.
The estimate follows the architecture and the scope, because those are what drive the cost: the number of sites, the range of B2B features, the pricing rules, the number of integrations, the design work and the level of testing required. The number of products or customers alone is not enough to price it. If the project has to fit a fixed scope at a fixed price, the reference point is AURORA ONE — with the caveat that extended B2B processes fall outside that standard.
We prepare the schedule after analysing the processes and their dependencies. What weighs most is the integrations, the readiness of product and pricing data, the number of B2B features and the time the client's team needs for decisions and sign-offs. With two channels there is one more: agreeing the rules of sale between the retail and the wholesale side can take longer than the development itself.
A shared platform is usually cheaper to run, because it does not duplicate integrations, updates, testing or work on product data. Two separate stores can still be the sensible choice when the channels have separate business models, teams and budgets, or when the B2B requirements rule out a shared architecture. The three arrangements and what each costs to run are compared in the section on the architecture of both channels.
Yes, provided the architecture and the dependencies allow the project to be split safely. The stages have to lead to the target model. Temporary solutions should not create further integrations and processes that will need removing a few months later.
After launch you need stabilisation, monitoring, ticket handling and a development backlog. The scope of maintenance and the required SLA can be agreed under AURORA CARE.
Planning sales in further markets at the same time? The scope of a multi-language, multi-store architecture is described under AURORA CROSS. For a closed, standardised scope it is worth looking at AURORA ONE.
Let's start with the B2C and B2B processes that need connecting today
In the first conversation we go through the sales channels, the current systems, the data sources and the most important constraints. If a shared platform is not justified, we will say so plainly.
You don't need a finished specification. What helps is information about the current technology, how business customers are served today, the systems to integrate and the growth plans for both channels.
What to expect after sending the enquiry
- 1Contact within 1 business day and follow-up questions about both sales channels.
- 2A conversation about processes, data sources and the systems handling orders.
- 3An answer on whether a shared Magento 2 platform is justified and what data is needed to prepare the scope.