B2B Marketplaces in 2026: Platforms & Architecture

Building a B2B marketplace in 2026 means solving problems a B2C store never has: company accounts with several buyers, negotiated prices, quotes, credit terms, bulk orders and approval chains. You can launch on marketplace SaaS (Mirakl, Sharetribe, CS-Cart), extend a headless commerce engine (Medusa, Saleor) or build custom. The platform matters less than three things: the workflow depth your buyers expect, how you handle payments and vendor payouts, and how you get the first hundred transactions through the system.

How B2B marketplaces differ from B2C

Most marketplace software was designed around a consumer buying one item with a card. B2B trading breaks almost every assumption in that model.

Accounts, not users. The customer is a company with several buyers, each with a role: requester, approver, finance, admin. Orders and invoices belong to the account, not to the person who clicked "buy". Model organization, member and role from day one; retrofitting this into a single-user schema is painful.

Negotiated pricing. List price is a starting point. Real prices come from contracts, volume tiers, customer groups and time-boxed agreements. One SKU can have a different price for every account, and finance expects an audit trail.

Quotes and RFQs. Large or unusual orders start as a request for quotation: the buyer asks, vendors respond, the buyer accepts, and only then does an order exist. It is an asynchronous flow with messaging and versioned offers, not a cart.

Credit terms and invoicing. Many buyers do not pay at checkout. They order on account, receive an invoice, and pay in 30 or 60 days. You need credit limits, invoice generation, dunning, and a way to reconcile which vendor gets paid what once the buyer settles.

Bulk orders. Spreadsheet upload, reorder from history, quick-order by SKU and quantity, minimum order quantities and unit-of-measure conversions (box of 12, pallet of 48 boxes).

Catalogs per customer. An account may see only the assortment it is allowed to buy, with its own SKU codes and prices. Catalog visibility is a permission problem, and search has to respect it.

Approval workflows. Orders above a threshold wait for a manager. Some accounts require a purchase order number on every order. Punchout (the buyer shops on your marketplace from inside their procurement system) is common in enterprise procurement.

If a platform handles all seven natively, it is a B2B platform. If it handles two or three, budget the rest as custom work.

B2B marketplace platform options compared

Four groups: enterprise marketplace SaaS, general marketplace SaaS, headless engines you extend, and custom builds. Shopify B2B is included because it comes up in every evaluation, although it is a single-seller wholesale channel. Mirakl is a marketplace back office that assumes an existing storefront, PIM and order management; Medusa and Saleor are commerce cores, so the multi-vendor layer is your project.

Platform	Best fit	Customization	Fees / licensing	Time to launch	Multi-vendor	Payments and split payouts
Mirakl	Retailers, distributors and manufacturers adding third-party vendors to an existing channel	Configuration plus APIs; core flows are fixed	Enterprise license, priced by scale	Months, mostly integration	Native: vendor onboarding, quality scoring, offer management	Via PSP partners; supports B2B quotes and multi-currency
CS-Cart Multi-Vendor	Mid-size marketplaces wanting an on-premise PHP platform with a low license cost	Add-ons and source access	One-time or subscription license per edition	Weeks to a few months	Native, with vendor plans and payouts	Built-in gateways; split payouts through supported PSPs
Sharetribe	Startups validating a niche marketplace fast	No-code builder plus a customizable web template and API	Subscription plus a share of transactions on lower tiers	Days to weeks	Native	Stripe Connect built in; no invoicing or credit terms
Medusa / Saleor (headless)	Engineering teams wanting a modern commerce core and full control of front end and logic	Full: modules (Medusa, Node.js) or apps (Saleor, Python/GraphQL)	Open source; paid cloud optional	Months; multi-vendor and B2B are built or assembled by you	Not core; via modules or custom services	Any PSP; split payouts implemented by you on Stripe Connect, Adyen or Mangopay
Shopify B2B	A brand or distributor selling wholesale to its own customers	Theme, apps and Functions	Shopify Plus subscription plus transaction fees	Weeks	No (single seller)	Shopify Payments; net terms, company accounts, price lists included
Custom build	Marketplaces where the workflow (RFQ, contracts, compliance, ERP coupling) is the product	Unlimited	Engineering cost, no license	Six months and up to a real MVP	Whatever you design	Any PSP; you own the ledger and payout logic

For the wider build-versus-buy trade-off, see custom e-commerce platforms vs SaaS.

Architecture of a B2B marketplace platform

Whatever you choose, a B2B marketplace decomposes into the same domains. Treat them as separate services or well-separated modules in a monolith; the boundaries matter more than the deployment style (see microservices vs monolith).

Catalog and PIM. Vendors upload catalogs by CSV, XLSX or API. A product information layer normalizes them into a canonical taxonomy with attribute templates per category, units of measure and packaging hierarchies. Keep the canonical product separate from the vendor offer (price, stock, lead time, MOQ): one product, many offers. Customer-specific catalogs are a visibility rule over offers, not a copy of the catalog per account.

Search. Index denormalized offer documents into OpenSearch, Elasticsearch, Typesense or Meilisearch: facets by attribute, synonyms for industry jargon, tolerant part-number matching, and filtering by what the current account may see at its price. Precompute effective prices per price group when rules are heavy.

Pricing and quotes. A pricing service evaluates list price, price groups, contract prices, volume tiers and promotions in a defined order and returns an explainable result ("contract X, tier 3"). The quote service owns the RFQ lifecycle: draft, sent, responses, revisions, accepted, expired. Accepting a quote creates an order with the quoted lines frozen.

Order orchestration. A cart can contain lines from several vendors. Checkout splits it into one order per vendor with a parent reference, applies the account's approval workflow, and emits events that fulfillment, invoicing and payouts subscribe to. This is a textbook case for event-driven architecture: idempotent consumers, a durable log, compensating actions when a vendor cancels part of an order.

Vendor onboarding. Registration, KYB, bank and tax details, contract acceptance, catalog import, and a staged go-live where you review the first listings. Delegate KYB and bank collection to the PSP's hosted onboarding.

Payments and payouts. The marketplace collects funds (card, SEPA debit, bank transfer, or an invoice paid later), keeps its commission and pays each vendor. Holding third-party money yourself is regulated, so use a platform PSP:

• Stripe Connect: fastest to integrate, hosted vendor onboarding, destination and separate charges with transfers, good card and SEPA coverage. Natural fit for Medusa, Saleor and custom stacks.
• Adyen for Platforms: strong for large volumes, many markets and local payment methods; more integration effort and a commercial contract.
• Mangopay: built around e-wallets per vendor and buyer, common in European marketplaces, good for escrow-like flows and invoice-based settlement.

Whichever you pick, keep your own ledger of orders, commissions, refunds and payouts; the PSP's reports are not your accounting. The security side is covered in payment system development.

Invoicing. Who invoices the buyer? The vendor directly (marketplace as agent), the marketplace on the vendor's behalf (self-billing), or the marketplace as seller of record. The choice drives VAT treatment, so settle it with your tax advisor before writing the invoice service. Support credit notes, partial invoices for partial shipments, and export to accounting.

ERP integration. Buyers want orders in their procurement system; vendors want orders in their ERP and stock flowing back. Offer a documented API, webhooks, and a file-based fallback (SFTP with CSV is still the norm in many industries). Punchout (cXML, OCI) is a separate project for the scale phase.

The liquidity problem and how to launch

A marketplace with vendors and no buyers is a catalog. With buyers and no vendors it is a wish list. Liquidity, the chance that a buyer finds an acceptable offer and a vendor gets orders, is the only thing that matters in year one.

1. Own the supply first. Distributors and manufacturers start from their own catalog. Buyers get a complete assortment on day one; third-party vendors join a channel that already has traffic. This is the Mirakl playbook and the least risky.
2. Anchor vendors. Sign three to ten vendors who cover most demand in one category, with commitments on catalog completeness and response time, in exchange for favorable terms for a fixed period. Depth in one category beats breadth in twenty.
3. Bring existing buyers. Migrate accounts you already serve by phone and email. Their reorders provide baseline volume while you recruit new demand.
4. Constrain scope. One vertical, one country, one language. Expand when repeat purchase rate in the first segment is healthy.
5. Do it by hand first. Onboard vendors manually, answer RFQs yourself when a vendor is slow, enrich catalogs for them. Automate once you know which step is the bottleneck.

Monetization can wait: free or near-free for the first cohort, then commission, then vendor subscription tiers. Fix the model before launch so contracts are clear, but do not optimize it until there is volume.

KPIs for a B2B marketplace

Track a short list and review it weekly. Registered vendors is a vanity metric.

KPI	What it tells you	Watch for
GMV and orders per vendor	Whether supply is active or just listed	A long tail of vendors with zero orders
Repeat purchase rate per account	Whether you replaced the old ordering channel	Accounts that order once and go back to email
Search-to-offer rate	Catalog coverage	Zero-result searches by category
RFQ response time and acceptance rate	Vendor engagement and price competitiveness	RFQs that expire unanswered
Time to onboard a vendor	Friction in KYB, import and review	Vendors stuck at catalog import
Fill rate and on-time delivery	Vendor reliability	Cancellations after acceptance
Take rate and contribution margin	Whether the model holds	Margin eaten by payment fees and incentives
Days sales outstanding	Credit risk on invoiced orders	Overdue invoices concentrated in a few accounts
Dispute rate	Quality of catalog data and fulfillment	Disputes caused by unit-of-measure errors

Compliance: VAT, invoicing and GDPR

Compliance shapes the data model, so it belongs in design, not in a pre-launch checklist.

VAT. Determine the seller of record for each transaction and where the buyer is established. Intra-EU B2B sales are normally reverse-charged, which means validating the buyer's VAT number (VIES) at registration and storing the result. Build the tax logic as a pluggable rule set or integrate a tax service; never hardcode rates.

Invoicing. Several EU countries are rolling out mandatory B2B e-invoicing and real-time reporting on national timelines, and the EU's VAT in the Digital Age package pushes structured e-invoicing for cross-border transactions. Design invoices as structured data with a UBL or CII export path and Peppol delivery in mind, not as PDFs rendered from HTML.

Payment regulation. Using Stripe Connect, Adyen or Mangopay places the license with the provider, but KYB obligations flow to you: vendors must be verified before payouts, and you need a process for rejected or incomplete verifications.

GDPR. Buyers and vendor contacts are people. You need a lawful basis per processing purpose, processing agreements with the PSP, search provider and hosting vendor, retention rules that separate invoices (which you must keep) from behavioral data (which you must not keep forever), and deletion flows that stop where tax law requires retention. See GDPR and software development.

Decision checklist: SaaS, headless or custom

Choose marketplace SaaS (Sharetribe, CS-Cart, Mirakl) when:

• You need to validate demand or launch a channel in weeks.
• Your workflows are close to standard: list, search, order, pay, ship.
• You have a license budget and a small engineering team, or (Mirakl) an existing commerce stack to plug into.

Choose a headless engine (Medusa, Saleor) when:

• Engineers will own the platform long term.
• You want full control of buyer experience and integrations without rewriting catalog, cart and orders.
• Multi-vendor and B2B logic matter but are not exotic.

Choose Shopify B2B when:

• There is one seller: you, selling wholesale to company accounts.
• Net terms, price lists and company accounts are the B2B features you need.

Choose a custom build when:

• The RFQ, contract or compliance workflow is why buyers would switch to you.
• ERP coupling on both sides is deep and industry-specific.
• Data residency or auditability rules out multi-tenant SaaS.

Phased delivery checklist: MVP to scale

Phase 1 — MVP

• Company accounts with members and two roles (buyer, admin)
• Vendor onboarding with hosted KYB via the PSP; manual review of first listings
• CSV catalog import with attribute templates for the launch categories
• Search with facets and account-level visibility
• Price lists per customer group; contract prices for anchor accounts, even if loaded by hand
• Cart split into per-vendor orders; card and SEPA payment through the platform PSP
• Basic quotes: request, one vendor response, accept to order
• Invoices with correct VAT treatment for the launch country
• Vendor dashboard: orders, payouts, catalog status
• KPI instrumentation

Phase 2 — Traction

• Approval workflows and PO-number enforcement per account
• Credit terms with limits, invoice payment, dunning
• Multi-round RFQs with several vendors
• Quick order, spreadsheet upload, reorder from history
• Second country: currency, VAT rules, language

Phase 3 — Scale

• Punchout (cXML/OCI) for enterprise buyers
• E-invoicing formats and Peppol delivery where mandated
• Promoted listings, vendor subscription tiers, analytics products
• Multi-region hosting, read replicas, search isolation for large accounts

If repeat purchase rate is flat after Phase 1, the fix is liquidity and catalog coverage, not Phase 2 features.

Recommendation

If you are a distributor or manufacturer with an existing catalog and want third-party vendors on it, weigh Mirakl against a headless build; the deciding factor is whether the license costs less than the engineering you would spend on vendor operations. If you are starting a new two-sided market, validate on Sharetribe or similar, and plan the move to headless or custom for the moment accounts ask for credit terms and per-customer catalogs. If the RFQ or contract workflow is your product, build custom on a headless core, use a platform PSP for payouts from day one, and keep your own ledger. At Arvucore we usually recommend settling the invoicing model and seller-of-record question before the first line of code, because it is the one decision that reshapes everything downstream.