Choosing an ecommerce platform for your B2B business is not just a website decision. It’s a decision that will determine how orders will work between your customers, your business rules and your ERP.
Most B2B ecommerce projects get scoped as a website build - a customer login, prices, a basket and a checkout – which makes it look like a simple decision: which platform gives us the most B2B features for the best price?
But it’s not that easy. The platform has to sit between three things that will not change to suit it:
Retail assumes one published price, a customer is one person, and payment at the point of order. B2B assumes none of that.
Customers have several buyers across many sites. Prices vary by business, quantity, and unit of sale. Buyers need spending limits and approvals set by their own management. Customers buy on credit. And the website and your ERP have to stay in sync on all of it.
Almost every mainstream platform now says they support B2B. With Shopify it is built-in, with Adobe Commerce (Magento) it's a module on a paid tier, with BigCommerce trade customers get a separate portal, and with WooCommerce, B2B capability is added through plugins. But the same five risks turn up whichever you choose, because they come from the underlying model rather than what the feature list says.
So your first job is not choosing a platform. It is understanding how your customers actually buy.
Two platforms can say they support approvals and mean completely different things.
Shopify has two buyer roles: “ordering only” and “location admin”. Both can place orders, but neither is an approver, and neither carries a spending limit. Shopify can hold orders for review, but it is an on-or-off setting for a whole site, and the held order lands in your admin queue for your staff to release, not your customer.
BigCommerce ends up somewhere similar: what a senior buyer approves is a shopping list, not an order.
Adobe Commerce is the strongest of the four. Its customers can set up their own rules, with several named approvers, triggered by order value or the number of lines. But there’s nothing in their documentation about a running total or a monthly budget. Every rule is checked against one order at a time. So a customer who sets approval at £1000 has not capped anything. Eleven separate £900 orders in a week all go through.
All three can say they support approvals, but the workflow may be very different from the one your customer actually needs.
The same applies to pricing. “Supports customer-specific pricing” tells you nothing until you know where the price comes from, who has to maintain it, what happens when it changes, and which system wins when the website and ERP disagree. Those questions matter more than any others here.
Multi-site customers are where those differences become particularly obvious. A builders’ merchant with six branches wants prices set for each branch and one view at head office of what all six are spending. Facilities management is the same problem: central procurement negotiates the deal, dozens of contract sites do the ordering, and procurement still needs to see the spend.
None of the four big platforms give you the complete picture. Shopify prices per site but has no company-level role, so head office sees nothing across them. Adobe has the head-office view but assigns catalogues per company, so per-site pricing means separate companies. BigCommerce comes closest, through parent and child hierarchies.
What this means for you
A customer asks for orders over £5,000 to go to their finance director for approval. What you can offer instead is that every order from that customer is held in your admin queue for your staff to release. Their internal control has become your daily admin job. That is not self-service. And the multi-site customer, exactly the account worth winning, is told they can have personalised pricing or central visibility, but not both.
Where the platform stops, an add-on starts. One for customer price lists. Another for credit limits. A third for approvals. Each does its own job, but nobody is responsible for making sure they all work together.
In fact, WooCommerce’s own documentation says “third-party products made for WooCommerce are not guaranteed to work with our software”.
So you might have a multi-site customer who wants spend control with approvals on any overage. You get one plugin to handle budgets and another for approvals, but neither of them connect, and WooCommerce won’t guarantee that they will work with their software.
It’s also worth mentioning that all platforms regularly release new versions, but the responsibility for maintaining plugins is on the developer, and in many cases, you have to manually install the updates yourself.
What this means for you
You thought you were just buying a platform, but you’ve taken on a compatibility program without realising it. Every update becomes a decision with a risk attached. That means you need to run a staging site and testing programme that someone needs to own. All of it is necessary, but none of it is on the pricing page. And you now depend on several companies to keep the system working.
There is a huge market for Shopify developers, Magento developers, WooCommerce developers, but developing custom functionality is very different from maintaining it.
We’ve already said that the responsibility for maintaining plugins is on the developer, but when it comes to custom code, that responsibility is on you.
Adobe puts this in writing: “custom code, extensions, and custom integrations belong to the customer, including patching them”.
Shopify gave a recent example. Scripts was the standard way to build custom cart and checkout logic, but in April 2026 they announced it was going, and by 30 June it stopped running altogether. To be fair, it had been on the cards for a few years and Shopify did nothing wrong, but nothing was migrated automatically and rebuilding the logic was the merchant’s job.
The important point is what often gets custom-built. It is the trading logic the standard platform could not handle, such as pricing, cart or checkout behaviour. So the thing most likely to break is your pricing, your cart or your checkout. And the first people to notice are your customers. As one merchant put it on Shopify’s own forum after the deadline: “Scripts that silently stopped on June 30 usually mean full-price checkouts, and customers rarely report it – they just leave”.
What this means for you
A bill you did not budget for, on a deadline you have no control over. You plan capital spend annually, but platform vendors don’t ask you first. And another company now has a say in whether your system keeps working.
This is the risk that undoes the others, and the hardest one to see in a demo.
If information you already maintain in your ERP has to be recreated or kept up to date separately for the website, then ecommerce has added an admin job rather than removed one. That applies to prices, stock, credit status, delivery addresses, account terms, product ranges, and order statuses. Every one of those already has an owner in your business. The question is whether the website gets that information from the ERP, or keeps its own copy.
Add-ons can be the reason it becomes its own copy. An extension can hold customer-specific prices, but what it cannot usually do is keep them in sync with your ERP. B2BKing (a popular B2B plugin) requires prices to be maintained inside WooCommerce or imported, rather than synced continuously from the ERP. Across thousands of products and hundreds of customers, that is somebody’s job.
It matters well beyond pricing too. Stock figures decide whether a customer trusts what the site says is available. Credit status decides whether you should have accepted the order at all. An order status decides whether the portal actually stops the phone calls it meant to stop. A customer who logs in and cannot see where their order is will ring anyway. You have paid for a portal, but it isn’t self-service.
Shopify and Adobe both make it clear that the integration itself sits outside their responsibility. Shopify’s ERP programme is delivered by partners who build connectors, while Adobe provides a starter kit but does not support the integrations built with it.
What this means for you
If your systems do not stay in sync, somebody in your team has to maintain the website data by hand. It’s rarely written into anyone’s job description, it never finishes, and when it doesn’t get done, it can go unnoticed, which is what makes it expensive. A contract price that should’ve been updated on 1 January turns up as lower GP than expected, by which time dozens of orders have gone out at the wrong price.
Bruce Harmer at Armaflo described it before they solved it: “Every pricing matrix is completely bespoke to each customer. This became quite a challenge to replicate on the website”.
It gets worse as you add extensions, because each arrives with its own store of data. A site built from four of them can hold four partial copies of the customer record, none of which reflects what’s in your ERP.
So ask a narrower question than whether the platform integrates with your ERP. For every important piece of data, ask which system owns it, and how does it get there. A platform vendor who thought about this answers item by item. One who has not answers about the platform in general.
So far we’ve discovered that add-ons split the technology across several vendors, custom work split the responsibility for maintaining the software, and middleware split the connection to the ERP.
By the time the website goes live, you’re buying from 5 or 6 different companies: the platform, the hosting provider, two or three add-on vendors, the integration supplier, and the agency that put it together. Each contract covers one part, but it’s rare for any to cover whether an order eventually reaches your warehouse.
You can see how this plays out, because these conversations happen all the time on support forums. In one WooCommerce thread from August 2025, a merchant reported a fatal error when adding products, broken order email and a failing order-received page. Over 5 days they were sent to a plugin author, then to a second plugin’s support forum, then told that “it’s the responsibility of those plugin developers to ensure compatibility with WooCommerce and WordPress”, then referred to the theme developer. Four redirections, four companies.
The worst part is nobody was deliberately unhelpful. Every reply was quick and polite, which goes to show that every supplier can do exactly what its contract says, and you can still be unable to take orders.
What this means for you
How long you are stuck stops depending on how serious the fault is. Instead, it depends on how quickly several companies agree whose fault it is. A fix that should take an hour ends up taking days.
It shows up outside the crisis too. Somebody has to keep track of which vendor is responsible for each part and know who to call first. That work usually has no owner and no budget, but it is an overhead you will pay for.
Avoiding technical risk is not why anyone starts an ecommerce project, so it is worth being clear about what you get when the system fits how your customers actually buy.
Your customer’s site users place their routine orders themselves. Their agreed prices, permissions and approval rules are applied automatically as they order. Nobody in your team has to step in and manage the process manually.
That is where the commercial benefit comes from. Routine orders no longer need your team to key them in, so you can handle more orders and more complex customers without adding admin at the same rate. Individual sites can order for themselves while head office keeps control. And you become easier for a large customer’s procurement team to buy from, which matters when they decide who stays on the supplier list.
But all of this only works when you get customers to use your ecommerce portal, which is the part most people assume will happen. A capable system removes no admin at all while customers keep ordering by phone and email. Adoption depends on the portal showing the right products and prices, the customer’s own users and permissions, and ordering being genuinely easier than picking up the phone.
When you get it right, the shift is substantial. Janitorial Express, a London-based janitorial and hygiene supplier and a Jangro member, now takes nearly 70% of all orders through the website or via EDI. Both count, because both remove the need for someone to read an order and type it in.
Simon Powell, Customer Service Manager at Armaflo, says “It pulls through all the prices for the customers, their account details, and stock levels. We don’t have to do any extra work to set it up.” And David Gourlay, Managing Director at Janitorial Express, says “It was very much Apparatus who took the lead in this integration. If I need to talk to Apparatus and OGL, I just know I’ll get the response from Apparatus within minutes.”
The monthly licence is the easiest number to compare, but it is rarely the whole cost of a B2B ecommerce site.
Add up everything: the licence, the B2B apps and extensions, integration middleware, any agency retainer, custom development and the rebuilds that follow, hosting, testing and release management, maintenance after platform changes, the manual data admin wherever the website keeps its own copy, and your team’s time coordinating suppliers and sorting out faults.
You do not need figures for this to be useful. The proposal with the lower monthly licence does not necessarily cost less to own. And asking a supplier to itemise their quote will tell you a lot about whether they have thought about the whole problem.
It’s clear that the mainstream ecommerce platforms can claim they support B2B, but the feature list only tells you part of the story. So before you speak to a platform vendor or agency, ask your team these questions:
Once you’ve uncovered the answers internally, test every vendor on three things: demonstrate our exact workflow, tell us where each piece of data will come from, and explain how you would troubleshoot an order that does not reach the ERP.