B2B ecommerce development is not the process of taking a consumer store and adding a wholesale price. A serious B2B platform has to model how companies actually buy: multiple users under one account, contract pricing, restricted catalogues, approvals, quotes, purchase orders, payment terms, repeat orders and data that is often owned by an ERP or another back-office system.
That changes the architecture of the project. The storefront is still important, but it is only the visible layer. Underneath it sit commercial rules, identity, permissions, pricing logic, operational data and integration workflows that need to remain correct even when orders are large, buyers have different rights and a sales team is involved.
This guide explains the features and architecture decisions that matter when B2B ecommerce is operationally important to the business. It is written for established companies planning a new platform, a major rebuild or a transition from manual ordering toward self-service digital commerce.
B2B ecommerce starts with the operating model
The first question should not be “Which B2B platform has the longest feature list?” It should be “How does this business sell today, and which parts of that process should the digital platform own?”
Before selecting software, map the commercial rules that already exist across sales, finance, operations and customer service. That usually includes:
- how customer companies and locations are structured;
- which people inside each company can browse, order or approve;
- how prices, discounts and contract terms are assigned;
- whether product visibility differs by account, market or contract;
- how quotes become orders;
- which orders require internal approval;
- which payment terms and credit rules apply;
- how repeat orders are placed today;
- which systems own customers, products, stock, pricing, orders and invoices;
- where sales representatives still need to intervene.
The output is not yet a page design. It is a model of the business rules the ecommerce system must preserve. If those rules are unclear, development will eventually rediscover them as exceptions, plugins and manual workarounds.
1. Company accounts are the foundation
Consumer ecommerce usually assumes one customer account represents one buyer. B2B commerce often needs a company model instead: one organisation with multiple locations, buyers, approvers, administrators and sometimes sales representatives acting on its behalf.
That account hierarchy affects almost every other feature. Pricing may belong to the company or location. Catalogues may differ by branch. A buyer may be allowed to create an order but not approve it. A finance user may need invoices without access to purchasing settings.
Modern B2B platforms expose this company model explicitly. For example, Shopify’s current B2B documentation supports companies, company locations, assigned catalogues, payment terms and order-review rules at company level. The specific implementation differs by platform, but the architectural principle is broader: identity and commercial entitlement must be attached to the correct business entity, not improvised from ordinary customer accounts.
For a custom or WooCommerce-based implementation, define the company entity and role model before building checkout. Otherwise pricing, catalogues and approvals become separate exceptions that are difficult to keep consistent.
2. Catalogues and product visibility can be customer-specific
A B2B catalogue is not always the public product catalogue with different prices. Some customers are allowed to purchase only specific brands, ranges, contract items or regional assortments. Others need products that should never be visible to general visitors.
The platform therefore needs a deliberate entitlement model:
- which products and categories are globally visible;
- which are visible only to authenticated companies;
- which are restricted to particular accounts, locations or segments;
- whether hidden products may still be ordered by SKU or through saved lists;
- how catalogue rules interact with search, navigation and recommendations;
- what happens when an account changes contract or market.
Shopify’s official B2B catalogue documentation, for example, describes assigning products and prices through catalogues and company locations. That is one implementation of a common B2B requirement: product availability and commercial terms are part of the customer context.
3. Pricing is usually a rules engine, not a single field
B2B pricing can depend on company, location, contract, quantity, currency, product group, customer tier, date range or a negotiated exception. The technical mistake is treating that logic as a collection of discounts added after the catalogue is built.
Decide where the authoritative price comes from. In some businesses the ecommerce platform owns price lists. In others the ERP is the source of truth and the storefront only consumes approved prices. Hybrid models are also common, but they need explicit precedence rules.
A useful pricing specification should define:
| Question | Why it matters |
|---|---|
| What is the base price source? | Prevents conflicting values between ecommerce, ERP and sales. |
| Can a company override a segment price? | Defines contract-price precedence. |
| How are volume tiers calculated? | Affects cart logic, display and order validation. |
| Are prices gross or net of tax? | Changes display, exports and downstream calculations. |
| Can sales create one-off negotiated prices? | Determines whether quote logic must override normal pricing. |
| When does a price change become effective? | Matters for scheduled contracts and ERP synchronisation. |
Pricing should be deterministic. The same buyer, account and order context should produce the same commercial result across product pages, cart, checkout, quote, order confirmation and back-office systems.
4. Approval workflows need to match purchasing authority
In many organisations, the person assembling an order is not the person authorised to submit it. Purchasing rules may depend on order value, department, cost centre, product type or budget.
A B2B platform may therefore need requestor/approver workflows, spending limits, delegated authority and notifications. Some companies need only a simple review step; others need multi-level approval or external procurement integration.
Do not bolt approvals onto checkout at the end. Approval status affects when stock is reserved, when a price should be frozen, whether payment is captured, when an order is sent to the ERP and what the buyer sees in their account.
5. Quotes should be a controlled route to an order
Not every B2B purchase belongs in a fixed-price checkout. Configured products, unusually large quantities, project pricing, freight exceptions or strategic accounts may require a quote.
The quote workflow should have a defined lifecycle: request, review, negotiation, approval, expiry and conversion into an order. It should preserve the agreed products, quantities, pricing and terms so that the final order does not have to be reconstructed manually.
A mature implementation also decides who may edit a quote, whether sales can act on behalf of the customer, how price changes are frozen, and whether the ERP or CRM needs to participate before the quote becomes an order.
When quotes live only in email while ecommerce owns the final order, teams often re-enter the same data twice. That creates pricing errors and weakens the value of self-service commerce.
6. Payment terms, purchase orders and credit change checkout
B2B checkout often supports commercial arrangements that do not exist in a typical retail flow. Buyers may use purchase-order numbers, invoices, deposits, account credit or net payment terms instead of paying the full amount by card at checkout.
These are not just additional payment methods. They can affect validation, approval, order status and finance integration. The system may need to confirm whether the company is permitted to use net terms, whether a credit limit is sufficient and whether a PO number is mandatory.
Current Shopify B2B documentation, for example, supports company-level payment terms and options such as net periods, deposits and draft-order workflows. That illustrates the broader requirement: payment logic belongs to the commercial account context.
For custom platforms, define which system owns credit limits and payment status. If the ERP or accounting system owns them, ecommerce should not invent a second independent truth.
7. Repeat ordering is often more important than browsing
Many B2B buyers already know what they need. They may order the same SKUs every week, replenish a standard list, upload a spreadsheet or search directly by product code.
That means B2B UX should not simply copy a consumer discovery journey. Useful capabilities can include:
- quick order by SKU or product code;
- saved lists and order templates;
- reorder from previous purchases;
- bulk quantity entry;
- CSV or spreadsheet upload where the workflow justifies it;
- account-specific recent products;
- visibility of previous quantities, prices and order status.
The objective is not to make B2B look less polished. It is to optimise for the job the buyer is actually trying to complete. For recurring procurement, speed and confidence can matter more than merchandising.
8. ERP integration is usually the operational backbone
For established B2B businesses, ecommerce rarely owns every important record. Customer accounts may live in CRM, prices and stock in ERP, product enrichment in PIM, fulfilment in WMS and invoices in accounting.
If product enrichment and multi-channel catalogue governance are a major part of that architecture, see our PIM integration guide.
For the integration layer itself, our ecommerce ERP integration framework explains source-of-truth ownership, sync direction, retries, reconciliation and failure recovery.
That is why systems integration is often part of the core ecommerce architecture rather than a secondary project.
Before development, create a source-of-truth matrix:
| Data domain | Typical owner to decide | Questions to resolve |
|---|---|---|
| Companies & contacts | CRM, ERP or ecommerce | Who creates and approves accounts? How are IDs matched? |
| Products | ERP or PIM | Which system owns identifiers, attributes and lifecycle? |
| Inventory | ERP or WMS | Real-time, near-real-time or scheduled? By warehouse? |
| Pricing | ERP, pricing engine or ecommerce | Which rules and exceptions are authoritative? |
| Orders | Ecommerce at capture; ERP after acceptance | When is an order considered committed? |
| Invoices & credit | ERP/accounting | What must buyers see back in the portal? |
The exact owner varies by organisation. What matters is that each domain has one deliberate authority and a defined direction of synchronisation.
WooCommerce provides REST APIs for orders and other commerce resources, and its webhook system can emit product, customer and order events to external services. Those primitives are useful, but production integration still needs business logic around retries, duplicate protection, reconciliation and failure handling.
9. Integration failure must be designed, not discovered
An integration is not complete when a successful API request works. It is complete when the system also knows what to do when the ERP is unavailable, a webhook is delivered twice, a price update arrives out of order or an order fails halfway through downstream processing.
For important B2B flows, plan for:
- stable external identifiers across systems;
- idempotent order submission where possible;
- queues rather than fragile synchronous chains for non-instant work;
- retry rules with sensible limits;
- dead-letter or exception handling for records that cannot be processed;
- reconciliation jobs that compare systems after the fact;
- logging that allows support teams to trace a transaction end to end;
- alerting for failures that require human action.
A lost €50 consumer order and a lost B2B replenishment order can have very different operational consequences. Reliability should reflect that difference.
10. B2B UX needs to reduce operational friction
B2B buyers still expect clear, fast interfaces, but the design problem is different from consumer ecommerce. The platform may need to show account context, contract pricing, availability, approval status, purchase history and fulfilment information without overwhelming the buyer.
The broader ecommerce conversion optimization framework is useful for diagnosing friction across discovery, product information, mobile and checkout while keeping B2B-specific conversion events separate from retail purchase funnels.
Good B2B UX makes the commercial rules visible at the moment they matter. A buyer should understand which price applies, why a product is unavailable to their account, whether an order requires approval and what will happen after submission.
This is where UX/UI design and platform architecture should be developed together. Interface decisions depend on permissions, data availability and workflow state; they cannot be solved reliably as a visual layer added after backend development.
11. Hybrid B2B and B2C stores need explicit separation rules
Some businesses serve consumers and trade customers through the same commerce platform. That can be efficient, but only if the system knows which rules belong to which audience.
Define how B2B context changes:
- navigation and catalogue visibility;
- price display and tax treatment;
- minimum quantities and pack sizes;
- promotions and discount eligibility;
- payment and shipping methods;
- checkout fields and order approval;
- customer support and sales-rep access.
The goal is not necessarily two separate storefronts. It is one architecture with predictable segmentation. If the same session can accidentally mix consumer promotions with contract pricing, the commercial model is not sufficiently isolated.
12. Decide where configuration ends and custom development begins
Many modern platforms support some B2B capabilities natively or through extensions. That does not mean every B2B project needs a fully custom stack. It also does not mean every requirement should be solved by installing another plugin.
| Approach | Good fit | Main risk |
|---|---|---|
| Native platform features | Standard company accounts, catalogues, payment terms and common workflows | Forcing unusual business rules into a rigid model |
| Extensions/plugins | Well-bounded features with mature compatibility and support | Overlapping ownership, upgrade conflicts and fragmented logic |
| Custom module | Specific business logic that belongs inside the commerce platform | Creating unnecessary custom code for solved problems |
| Integration/middleware | Cross-system orchestration, transformations and reliable sync | Putting too much business logic into an opaque connector |
| Custom application/service | Unique workflow that needs its own lifecycle or scale boundary | Operational complexity without enough business value |
The right architecture is usually mixed. Use standard capabilities where the business is standard, and reserve custom engineering for the rules that genuinely differentiate how the company sells or operates.
That is also the principle behind choosing custom WooCommerce development instead of stacking more plugins: ownership boundaries matter more than the number of installed features.
13. Migration is a data and workflow problem, not only a storefront rebuild
If B2B ecommerce already exists in another platform, migration must preserve more than products and customers. Company relationships, contract prices, account permissions, saved lists, open quotes, payment terms, order history and external identifiers may all be commercially important.
Before cutover, classify every data set as migrate, recreate, archive or intentionally retire. Then test the workflows that depend on that data rather than checking only row counts.
A company record that migrated successfully but lost its price-list mapping is not a successful migration. Neither is an order history that exists in the database but cannot be used for reordering.
For a broader cutover framework, see our ecommerce platform migration checklist.
14. Build the first release around complete buying journeys
B2B projects become risky when teams try to launch every edge case at once. A better approach is to identify a small number of complete journeys that represent real commercial value.
A first release might support:
- approved company login and account context;
- correct customer-specific catalogue and pricing;
- fast product lookup and repeat ordering;
- one reliable checkout path with the required PO or payment terms;
- order submission into the ERP with status feedback;
- a clear exception path for anything that cannot yet be self-service.
Then add quote workflows, deeper approvals, additional integrations or advanced account administration as the operating model proves what buyers actually use.
This is not an argument for a minimal product that ignores B2B complexity. It is an argument for delivering complete, dependable workflows before expanding the surface area.
15. Define acceptance criteria in business terms
Technical acceptance tests are necessary, but B2B projects also need business-level scenarios. Stakeholders should be able to answer whether the platform behaves correctly for specific account types and exceptions.
Examples include:
- Buyer A at Company X sees its contracted price and only its permitted products.
- A €15,000 order from Buyer B cannot be submitted without approval from Manager C.
- A PO number is required for one account but not another.
- A stock update from ERP reaches the storefront within the agreed window.
- Submitting the same integration message twice does not create two orders.
- If the ERP is unavailable, the order is queued and support can see its state.
- An expired quote cannot be converted using stale commercial terms.
- A branch user cannot access another branch’s orders or invoices.
Those scenarios turn abstract requirements into testable system behaviour.
What serious B2B ecommerce development should produce
The final deliverable should not be described only as “a new ecommerce website.” For an established B2B business, the project should create a dependable digital operating layer between buyers and the systems that run the company.
That normally means documented account and permission models, catalogue and pricing ownership, end-to-end buying workflows, integration contracts, failure-handling rules, UX patterns for repeat purchasing, migration logic and a roadmap for controlled expansion.
When those decisions are made early, the platform can reduce manual order entry without losing the negotiated rules that make B2B commerce work. When they are deferred, the storefront may look complete while sales, finance and operations continue doing the real work in email and spreadsheets.
NAIPEXO designs and builds custom WooCommerce and ecommerce platforms together with ERP, PIM, CRM and API integrations when B2B requirements cross the boundary between storefront, product experience and back-office operations.