B2B Wholesale Portal Features: What Trade Buyers Expect

A B2B wholesale portal needs ten features trade buyers now expect: customer-specific price lists, credit limits and terms, quick order with CSV reorder, minimum order quantities and case packs, order approvals, quotes, invoices and statements, multi-user buyer accounts, stock by warehouse, and FEFO allocation for dated goods. Price, credit and stock rules belong on the server; the storefront is the easy part.

If you would rather have it built for you, see how RAITHub would build this below.

This post is the feature checklist. The engineering of the three hardest rules (trade pricing, credit and buyer isolation in the database) is covered in B2B ecommerce platform development, and the wider architecture for stores and marketplaces is in the custom ecommerce and marketplace guide.

What features does a B2B wholesale portal need?

Trade buyers are not browsing. They know what they want, they order the same things every week, and they are often ordering for a business with its own rules about who may spend what. Every feature below exists to make a repeat order faster or a mistake less likely.

Feature	What the buyer expects	Where the rule must live
Customer-specific price lists and tiers	To see only their own price, every time	Server, resolved from the buyer's account
Credit limits and payment terms	To order on account up to an agreed limit	Database, checked in the order transaction
Quick order and CSV reorder	To type or paste SKUs and quantities, not browse	Server validation of every line
MOQ and case packs	To be told the valid quantity before checkout fails	Server, with the same rule shown in the interface
Order approvals	Junior staff place orders; a manager releases them	Server workflow with a recorded decision
Quotes	To negotiate a large or unusual order before committing	Server, with an expiry and a locked price
Invoices and statements	To download invoices and see what is owed and overdue	Generated from the ledger, never edited by hand
Multi-user buyer accounts	Several logins per business, each with limits	Database scoping per company and per user
Stock by warehouse	To know what can ship, and from where	Inventory service or ERP, one source of truth
FEFO allocation	Fresh stock, not the batch about to expire	Database, inside the allocation step

How do customer-specific price lists and tiers work in a wholesale portal?

Each buyer account points at a price tier, and individual products can carry a negotiated override for that buyer. The server resolves the price in one place, in a fixed order: override, then tier, then list price. The cart, the invoice and staff ordering on a buyer's behalf all call the same resolver, so they cannot disagree.

Two rules matter more than the screens. First, the browser never sends a price; it sends a SKU and a quantity, and the server prices the line. Second, prices are private data. A buyer on one tier must not be able to read another tier's price by editing a request, which is a data isolation problem as much as a pricing one. Sundor Skin, the wholesale platform RAITHub built for a skincare importer, uses tier pricing with database-enforced isolation under PostgreSQL row-level security across its 146 tables.

Volume breaks are a related feature. Shopify's B2B catalogs, for example, support up to 10 price breaks per product, applied per variant. If your trade customers expect breaks that combine across variants (any mix of a range counts towards the break), check that your platform supports it before you commit. If you are on Shopify and want tiers without moving to Plus, see Shopify B2B tiered pricing without Plus.

How should credit limits and payment terms work for trade buyers?

Terms say when an invoice is due; a credit limit says how much the buyer may owe at once. A portal needs both. Terms are the easy half: Shopify's B2B documentation lists net 7, 15, 30, 45, 60 and 90 day terms, payment due on fulfilment, and a fixed date for draft orders. Its payment terms page does not describe a credit limit, so on that platform exposure control usually sits in your accounting system or a separate app. Adobe Commerce's B2B module, by contrast, lets merchants allocate credit for a company account.

The rule that protects you: check the order against the limit and the buyer's outstanding exposure (what they owe plus what is ordered but not yet paid) at submission, inside the same database transaction that creates the order. Checked only in the interface, two people ordering at once can both squeeze under the limit. Sundor Skin enforces credit in the database this way.

Payment terms and invoice contents can have tax and legal consequences in your country. This is general information; confirm with your adviser.

How do quick order and CSV reorder work?

Quick order is a page where the buyer types SKUs and quantities into rows, or pastes a list, and adds the lot to the cart in one action. CSV reorder is the same thing for a buyer whose purchasing system exports a file. A third variant, reorder from history, rebuilds a past order at today's prices. Adobe Commerce calls the saved version requisition lists, for "frequently ordered products".

The engineering detail that separates a good quick order from a frustrating one is per-line feedback. A 200-line file will contain an unknown SKU, a discontinued product and a quantity that is not a whole case. Reject the bad lines with a reason each, accept the good ones, and never fail the whole file for one error. The sketch below validates one line against a minimum order quantity and a case pack:

type Product = { sku: string; active: boolean; moq: number; casePack: number }

type LineResult =
  | { ok: true; sku: string; qty: number }
  | { ok: false; sku: string; reason: string }

export function validateLine(
  sku: string,
  rawQty: string,
  catalog: Map<string, Product>,
): LineResult {
  const product = catalog.get(sku.trim().toUpperCase())
  const qty = Number(rawQty)
  if (!product || !product.active) return { ok: false, sku, reason: 'Unknown or discontinued SKU' }
  if (!Number.isInteger(qty) || qty <= 0) return { ok: false, sku, reason: 'Quantity must be a whole number' }
  if (qty < product.moq) return { ok: false, sku, reason: 'Minimum order is ' + product.moq }
  if (qty % product.casePack !== 0) {
    const up = Math.ceil(qty / product.casePack) * product.casePack
    return { ok: false, sku, reason: 'Sold in cases of ' + product.casePack + '; try ' + up }
  }
  return { ok: true, sku: product.sku, qty }
}

Run this on the server even if the interface runs it too. The interface copy is for speed; the server copy is the rule.

What is the difference between MOQ, case packs and quantity increments?

A minimum order quantity (MOQ) is the fewest units of a product a buyer may order. A case pack is the number of units in the outer carton, so orders must be a multiple of it. A quantity increment is the general rule behind case packs. Shopify's B2B catalogs support minimum, maximum and increment rules, applied per variant. Some wholesalers also set an order-level minimum, such as a minimum order value before free delivery. Decide which of these you need before choosing a platform, because order-level and mixed-case rules are where off-the-shelf settings run out.

Do wholesale buyers need approvals and multi-user accounts?

Larger buyers do. A pharmacy chain or a distributor has several people ordering: a buyer who builds the cart, a manager who approves spend over a threshold, and an accounts person who only needs invoices and statements. The portal models this as one company with many users, each with a role and optional spending limit, and orders above the limit wait as a pending approval.

Adobe Commerce documents this pattern as company accounts that join multiple buyers into one, with purchase order approvals. In a custom build, the same scoping that isolates one company from another should also limit each user inside the company, enforced in the database, not only hidden in the interface. Permission design for this is covered in SaaS authorization and RBAC design.

Staff need roles too. Sundor Skin's back office runs on 12 staff roles built from 88 permission codes, so a picker, a credit controller and an owner see and do different things.

Should a wholesale portal support quotes?

Yes, if your buyers negotiate large, seasonal or mixed orders. A quote is a draft order with a negotiated price, an expiry date and a status: requested, offered, accepted, expired. When the buyer accepts, it converts into an order at the quoted price, and the price is locked so that a tier change in the meantime does not alter it. Shopify supports draft orders for B2B, and Adobe Commerce has negotiable quotes. If most of your orders are standard reorders, quotes can wait for a later release.

What should invoices and statements show in a B2B portal?

Invoices show what was shipped and what is due; statements show the running position of the account: invoices, payments, credit notes, the current balance and what is overdue, by age. Buyers on terms want to download both without emailing your accounts team. Generate both from the same ledger that the credit check reads, and never let anyone edit an issued invoice. Corrections go through a credit note, so the trail stays intact. An audit log of who changed a price, a limit or an invoice is part of the same feature; the design is in SaaS audit log design.

How should a wholesale portal handle stock by warehouse and FEFO?

Show buyers what can ship and from where, and allocate from one source of truth. If you hold stock in more than one warehouse, the portal needs stock per location, a rule for which location fills an order, and a way to split or hold a partial order. If products expire, such as skincare, food or pharmaceuticals, allocate by batch, earliest expiry first. That is FEFO: first-expiring, first-out.

The allocation must lock the rows it reads, or two orders can take the same units. A minimal PostgreSQL version:

-- Batches for one SKU in one warehouse, earliest expiry first,
-- skipping anything inside the minimum shelf life the buyer accepts.
SELECT id, expires_on, qty_available
FROM stock_batch
WHERE sku = $1
  AND warehouse_id = $2
  AND qty_available > 0
  AND expires_on >= current_date + $3::int
ORDER BY expires_on, id
FOR UPDATE;

Take units from each row in order until the line is filled, inside the same transaction as the order. Sundor Skin allocates stock by batch with FEFO in the database. The full set of oversell traps is in inventory stock oversell prevention.

Buy, build or hire: which wholesale portal option fits?

Most wholesalers should start by checking whether a hosted platform's B2B features cover their rules. Shopify's pricing page lists Basic from $19 a month (billed yearly), Grow from $49 and Advanced from $299, each with up to 3 B2B catalogs, and Plus from $2,300 a month with unlimited catalogs. Adobe Commerce's B2B module covers company accounts, credit, requisition lists, quick order, quotes and approvals; its documentation presents these as Adobe Commerce features.

Option	Examples	Choose this when	It stops fitting when
Off-the-shelf B2B platform	Shopify Plus, Adobe Commerce B2B	Your price lists, terms and approvals follow common patterns and you want vendor-run hosting	Credit must block orders at submission, or stock, payment or role rules are specific to you
Template or standard plan plus apps	Shopify Basic to Advanced with up to 3 B2B catalogs, plus apps	You have three or fewer price groups and a modest catalogue	You need more tiers, per-buyer overrides at scale, or apps start to overlap and conflict
Custom build	A portal on your own database and cloud	Pricing, credit, batch stock, local payment methods or staff roles are how your business makes money	Your rules are standard; then you are paying for software you could rent

A hybrid is common: keep a hosted storefront and build only the credit, pricing or fulfilment backend behind it. The longer comparison is in Shopify vs custom ecommerce.

Why RAITHub for a wholesale portal

• A live wholesale platform to point at. RAITHub built Sundor Skin, a gated B2B wholesale portal: 146 PostgreSQL tables with row-level security, 530+ automated tests, 88 permission codes across 12 staff roles, tier pricing, database-enforced credit and FEFO allocation. See our work.
• Rules in the database, tested by attack. Pricing, credit and stock are enforced where a bug in a screen cannot bypass them, and tests try to read other buyers' data and must fail.
• Founder-led, fixed scope. A written fixed quote for the first release, then a dedicated team month to month if you want one. No staff augmentation.

When you don't need us

• You have a few price groups, card or net-terms payment and one warehouse: configure a hosted platform's B2B features and launch sooner.
• Your ERP already offers a buyer portal that your customers accept: extend it rather than replace it.
• You need a native mobile app: RAITHub builds web apps and PWAs (installable web apps), not native apps.
• You need a SOC 2 or ISO 27001 certified vendor: RAITHub is not certified. We sign NDAs and DPAs and work inside your controls.

How RAITHub would build this

• Scope: buyer approval and multi-user company accounts; server-side price resolution with tiers and per-buyer overrides; quick order and CSV upload with per-line validation for MOQ and case packs.
• Scope: credit limits and terms checked in the order transaction, with invoices, credit notes and statements from one ledger.
• Scope: stock per warehouse with FEFO allocation, staff roles from permission codes, and an audit log; quotes and approvals added where your buyers need them.
• Timeline: a first release with accounts, pricing, quick order and orders as a fixed-scope 4–6 week build; credit, fulfilment and back-office work behind an existing storefront typically 6–12 weeks, as described on our API and backend development page.
• You receive: automated tests and CI, handover docs and runbooks, and full IP under NDA. Production data stays in your own cloud account; development uses synthetic data.

Next step: book the free 15-minute audit with how your buyers are priced, given credit and supplied, and you get a written fixed quote. The ecommerce industry page sets out what a build includes.

Frequently asked questions

What is a B2B wholesale portal?

A private ordering site where approved trade customers see their own prices, order in bulk, buy on credit terms and download invoices and statements, while staff manage approvals, stock and fulfilment behind it.

What is the most important feature in a wholesale portal?

Customer-specific pricing resolved on the server, followed closely by credit limits checked at order submission. Errors in either cost real money, while a weak interface only costs time.

Can Shopify run a B2B wholesale portal?

Often, yes. Shopify B2B offers catalogs, net terms from 7 to 90 days, quantity rules and up to 10 volume price breaks per product, with up to 3 catalogs below Plus. Its payment terms documentation does not describe a credit limit, so exposure control usually sits elsewhere.

What is FEFO and does my portal need it?

First-expiring, first-out: each order takes stock from the batch that expires first. You need it if your products have expiry dates, such as skincare, food or pharmaceuticals.

How do I let buyers reorder from a CSV file?

Accept a file of SKU and quantity, validate every line on the server for an active SKU, minimum order and case pack, add the valid lines to the cart, and return a reason for each rejected line rather than failing the whole file.

How long does it take to build a wholesale portal?

A scoped first release is typically a fixed 4–6 week build; credit, fulfilment and back-office backends usually take 6–12 weeks. A platform the size of Sundor Skin is larger than either.