B2B Ecommerce Platform Selection: Buy the Workflow, Not the Feature List

Ask a B2B company why its ecommerce project stalled, and you rarely hear “the platform couldn’t render product pages.” You hear about price lists that couldn’t be tied to customer accounts, quotes that had to be re-keyed into an ERP, orders that needed a manager’s approval but arrived in a checkout built for individuals, and net-30 invoices that the store insisted on charging to a credit card. Retail platforms are very good at retail problems. B2B platform selection goes wrong when teams evaluate candidates against a retail checklist and only later discover that the workflows they actually run — negotiated pricing, approval chains, payment on terms, ERP sync — are the hard part.

This article works backwards from those workflows. We look at what a B2B store must do, then at how Shopify, WooCommerce and TYPO3 each answer, because the three platforms answer very differently.

The requirements that actually decide the project

Before comparing vendors, write down how your business sells. Five questions tend to decide everything:

• Who is the buyer? An individual with a cart, or a company with several locations, multiple purchasers and a purchasing officer who approves what others select?
• How is price set? One public price, or negotiated per-account pricing with volume breaks and contract rates?
• How does the order get approved? Straight to fulfillment, or through an internal approval step with a purchase order number attached?
• How do you get paid? Card at checkout, or net payment terms with invoices, partial payments and reminders?
• Where does the order data live? Solely in the web store, or synced to an ERP that treats the store as one input among several?

A store that needs the left-hand answer to every question is basically a retail store with business customers, and almost any platform will do. Each right-hand answer adds structural requirements, and it is the count of right-hand answers that should drive platform selection — not the length of a feature comparison table.

Two more items deserve a place on the list. Tax handling, because most B2B buyers are tax-exempt and the store must record exemptions rather than guess at checkout. And content depth, because B2B purchases usually involve spec sheets, compliance documents and documentation that outrank the product page in the buyer’s research.

Shopify: native B2B, with the platform’s usual boundaries

Shopify now ships a substantial set of native B2B features, documented in Shopify’s B2B manual. The model is company-based: you create a company, add one or more locations to it, and attach contacts to those locations with permissions — an ordering-only contact can place orders and view history, while a location administrator can manage addresses and payment methods. This maps well onto how wholesale buyers are actually organized, and it is a genuinely different data model from “customer with a tag,” which is how the app ecosystem used to fake it.

Pricing runs through B2B catalogs: fixed prices or percentage adjustments per product or variant, quantity rules for minimums, maximums and case-pack increments, and volume price breaks by quantity tier. Orders can carry purchase order numbers, and payment terms support the vocabulary B2B finance teams expect — net terms, due-on-receipt or due-on-fulfillment dates, deposits at checkout, and card vaulting for later collection. Draft orders let a sales rep assemble a quoted order, lock its prices and submit it for review. On the storefront side, features like the quick order list acknowledge that wholesale buyers paste SKU lists rather than browse.

The honest caveats are plan availability and boundary. Shopify has been broadening which plans can use which B2B features, and the feature-to-plan mapping has changed repeatedly, so treat the manual — not a blog post, including this one — as the source of truth for what your plan includes today. More fundamentally, the boundary stays where it always was: the commerce engine is Shopify’s. For standard wholesale workflows that boundary is irrelevant, and letting Shopify own checkout and payment certification is exactly the point. The further your process deviates — multi-step approvals that span systems, deep ERP round-trips, pricing logic derived from contracts in external software — the more you are writing against the platform rather than with it. Clients coming to our Shopify development service for B2B work usually land in the first category: standard wholesale mechanics, hosted operations, no server to harden.

One genuine gap deserves naming. B2B buyers research heavily before they buy, and Shopify’s content tools are modest for a site whose spec documentation and application notes need to be a first-class publishing operation. That is not a criticism of Shopify’s commerce; it is a reminder that commerce is only part of the site.

WooCommerce: B2B as a configuration of WordPress

WooCommerce has no B2B module in the core plugin. What it has is something arguably more useful for B2B: WordPress’s native user-role system and an extension ecosystem built on it. The wholesale pattern that most stores converge on is documented in WooCommerce’s own Wholesale for WooCommerce documentation: a wholesale user role with its own pricing, tiered and quantity-based pricing per product, registration forms with admin approval before a buyer sees wholesale prices, tax exemption per role, and visibility controls that hide products or prices from non-wholesale visitors. Requisition lists give repeat buyers a saved order template, and a private-store mode locks the whole catalog behind login.

None of this arrives pre-assembled, and that is the tradeoff in one sentence. On Shopify, company accounts and payment terms are platform features that update themselves; on WooCommerce, they are a configuration of roles, extensions and sometimes custom code that you own, maintain and secure like the rest of a WordPress site. If you have read our comparison of WooCommerce and Shopify as operating models, you already know the shape of this decision: WooCommerce moves work from a vendor to your team, and in exchange removes the platform’s ceiling on what the store can do.

For B2B specifically, that ceiling removal matters in specific places. Unusual ordering flows — quote requests that turn into orders after negotiation, approval steps, customer-specific contract pricing pulled from elsewhere — are straightforward to build when the checkout is a template you control. And because the buyer account is a WordPress user, the store, the gated documentation area and the support system can share one identity, which is exactly the seam that hurts when commerce and content live in separate systems. The earlier discussion of how to choose a CMS for a business site covers the general case; in B2B the content-commerce merge is often the deciding factor rather than a nice-to-have.

The costs do not disappear; they relocate. A WooCommerce wholesale store inherits PCI scope, update discipline and performance tuning, and B2B traffic patterns — few sessions, heavy carts — stress caching and sessions differently than retail traffic. Budget for operations, not just for the build.

TYPO3: when the site is bigger than the shop

Some B2B businesses are manufacturers or industrial suppliers whose website is primarily a publication: product documentation, certifications, technical articles, localized microsites. Commerce is one channel of that site, not its reason for existing. For those organizations, choosing an ecommerce platform first and bolting content on afterwards is backwards, and a CMS with strong governance is the natural center of gravity. TYPO3, with enterprise features like workspaces and granular editorial permissions, is built for exactly this profile — a large site, many editors, review workflows, and commerce that must behave like a well-behaved citizen of the content system.

Commerce capability comes from extensions rather than core. The Aimeos extension, listed in the TYPO3 Extension Repository, is an established option explicitly positioned for complex B2B applications, with multi-vendor support and a performance-oriented architecture. The realistic assessment: this is the highest-effort path of the three, chosen when the organization already runs TYPO3, when editorial governance is non-negotiable, or when the shop must integrate tightly with internal systems on the organization’s own terms. Our TYPO3 development service spends far more time on the surrounding site than on the shop itself, which is the correct order of priorities for this profile.

The ERP question cuts across all three

Whatever the platform, decide the integration seam early: does the ERP own product data, pricing and stock, with the store as a presentation and ordering layer? Or does the store own commerce data and push completed orders downstream? Every platform can do either, but the effort differs enormously, and it is the single most common source of unplanned B2B project cost. A store that must wait for a nightly price sync from the ERP has different performance and caching requirements than one where merchandisers edit prices in the admin. Answer this before signing anything.

A short decision heuristic

• If you sell standard catalog products to business buyers, want hosted operations, and your content needs are modest: Shopify with native B2B, verifying current plan limits against the manual.
• If the store must be one product with a content-heavy site, or your ordering flow deviates from standard wholesale: WooCommerce, budgeting for the operational burden you are accepting.
• If the website is an enterprise publication first and a shop second, or TYPO3 is already your system of record: TYPO3 with a commerce extension.

All three decisions are really about where work lands: on a vendor, on your own team, or on an integration. Price the work honestly — the license fees are rarely the expensive part. The full picture also belongs in a total-cost-of-ownership analysis, because in B2B the multi-year cost of operating the workflow you just bought is where platforms actually differ.