QA for a B2B E-Commerce and Wholesale Portal

A B2B wholesale portal needs more QA than a consumer store because its core features are the risky ones: each buyer sees negotiated prices, spends against a credit limit, orders in bulk, and may need an approver. Test that a buyer sees only their own prices and orders, cannot exceed their credit, cannot read another account's data, and that approvals hold. Automate the pricing, credit and isolation checks.

If you would rather have the suite built and run for you, see how RAITHub would test this below. First, the QA plan.

How is a B2B portal different from a consumer store to test?

A consumer store shows one price to everyone and takes payment at checkout. A B2B portal shows a different price to each buyer, lets them buy on credit, and often routes large orders through an approver. That turns pricing, credit and account isolation into features with real failure modes, and adds roles within a single buyer company (a purchaser, an approver, an admin). The build side is covered in B2B e-commerce platform development and B2B wholesale portal features; this post is the test plan.

What does the QA plan cover?

Area	Minimum bar to pass	Automate or manual
Buyer isolation	A buyer gets a 404 for any order, price list or document that is not theirs	Automate (API tests)
Trade pricing	Each buyer sees only their tier or negotiated price; no consumer price leaks	Automate (unit + API)
Credit limit	An order that would exceed the limit is blocked at the server, not just hidden in the UI	Automate (API)
Approval workflow	An order over the threshold cannot ship until approved; the approver sees it	Automate + manual
Bulk and reorder	A large basket, a CSV upload and a reorder all price and reserve stock correctly	Automate + manual
Roles within a buyer	A purchaser cannot approve their own order or change the credit limit	Automate (role matrix)

How do you test buyer-account isolation?

Treat each buyer company as a tenant. For every endpoint returning a buyer-owned record, sign in as buyer A and request buyer B's record by ID; expect a 404, not a 403. Generate the cases from your list of buyer-scoped resources, and back the application check with the database (row-level security for multi-tenant Postgres). This is the same high-risk layer that catches cross-tenant leaks in any multi-party system (how one account ends up seeing another's data).

How do you test trade pricing and credit without leaks?

Pricing is the B2B bug that embarrasses you publicly: a buyer sees a price meant for a different tier, or the consumer price leaks into a trade account. Test the pricing function as a table of cases per tier, and assert at the API that the price returned matches the requesting buyer's agreement, never a cached or default price. Store money as integers and test rounding.

// tests/api/trade-pricing.spec.ts
import { test, expect } from '@playwright/test'
import { tokenFor, agreedPrice } from './helpers'

test('a buyer is quoted only their agreed price', async ({ request }) => {
  const token = await tokenFor('buyer@acme.test')
  const res = await request.get('/api/catalogue/SKU-1/price', {
    headers: { Authorization: 'Bearer ' + token },
  })
  const { unitPrice } = await res.json()
  expect(unitPrice).toBe(await agreedPrice('acme', 'SKU-1')) // their tier, not the default
})

Credit must be enforced on the server, inside the order transaction, not just greyed out in the UI. Test that an order which would push the buyer over their limit is rejected at the API even when the client submits it directly, and that a returned or cancelled order restores available credit. Sundor Skin enforces credit limits in the database for exactly this reason (Sundor Skin).

How do you test approvals and roles within a buyer?

A single buyer company has its own roles, so run a role matrix: every role against every sensitive action. The checks that matter most are separation-of-duty ones. Assert that a purchaser cannot approve their own order, cannot raise their own credit limit, and cannot see colleagues' orders they are not entitled to. Then test the approval workflow end to end: an order over the threshold stays blocked until the approver acts, and the approver actually sees it in their queue. The role-design method is in designing RBAC for a SaaS, and the overall layering in the test pyramid for a SaaS.

Buy, build or hire?

Option	What you get	Choose this when
A B2B store platform	Trade pricing, accounts and approvals handled by the platform	Your pricing and credit rules fit the platform's model
A consumer platform with B2B add-ons	Logins and basic tiers bolted on	Your B2B needs are light and you accept shallow credit and approvals
A custom portal you test yourself	Full control of pricing, credit and isolation	Negotiated pricing, credit or approvals are the business, and you have engineers to test them
A managed QA team on your build	Pricing, credit, isolation and role suites gated in CI	You have the portal but no one owns the tests that protect pricing and credit

How long does it take to run this yourself?

For a portal that already works, expect about one to two weeks of one engineer's time to automate the isolation suite, the per-tier pricing and credit tests, and the role matrix, then a manual pass on approvals and bulk ordering. The main risk of doing it yourself is testing the UI and trusting it: the dangerous bugs are server-side, where a direct API call bypasses a greyed-out button and spends past a credit limit or reads another buyer's prices.

Why RAITHub for this

RAITHub built and runs Sundor Skin, a gated B2B wholesale platform with 146 PostgreSQL tables, row-level security on buyer-scoped tables, 88 permission codes across 12 staff roles, tier pricing, credit and FEFO, and 530+ tests including a security suite that tries to read other buyers' data. The same discipline applies to a portal you already have, through the QA as a Service offer. See the eCommerce industry page for the wider context.

When you don't need us

• You run on a B2B platform whose pricing and credit you have not customised. The vendor tests that logic; focus on your theme and integrations.
• You have a handful of accounts and manual pricing. A manual QA pass may be enough until volume grows.
• You need a CREST- or PCI-certified penetration test. RAITHub's security testing is application-level and issues no attestation.

How RAITHub would test this

• Scope: automate buyer isolation, per-tier pricing and server-enforced credit, and the role matrix including separation of duties; run a manual pass on approvals, bulk and CSV ordering; gate the suites in CI.
• Ways to buy it: a fixed-price pre-launch QA audit with a written report, a monthly QA plan, or a dedicated QA team RAITHub manages and bills monthly. RAITHub does not place testers under your management.
• Timeline: fixed in the written quote after the audit, based on how many pricing tiers, roles and approval rules you run.
• What you receive: tests and CI in your repository, a ranked bug report, a short handover document, IP assigned to you and an NDA as standard.
• Next step: a free 15-minute technical audit, then a fixed written quote.

See the SaaS development service, or book the free 15-minute audit.

Guidance reviewed on 10 October 2026.

Frequently asked questions

What should I test first in a B2B portal?

Buyer-account isolation, trade pricing and credit limits. A buyer seeing another account's data is a breach, a leaked price is an embarrassment, and a credit limit enforced only in the UI is a debt you cannot collect. Automate all three before launch.

How do I test credit limits?

Submit an order directly to the API that would push the buyer over their limit and assert the server rejects it, not just that the button is disabled. Then confirm a returned or cancelled order restores available credit. Enforce the limit inside the order transaction.

How is B2B pricing tested without leaks?

Test the pricing function as a table of cases per tier, then assert at the API that each buyer is quoted only their agreed price, never a cached or default consumer price. Store money as integers and test rounding on every tier.

What roles exist inside a single B2B buyer?

Commonly a purchaser, an approver and an admin. Run a role matrix and check separation of duties: a purchaser cannot approve their own order or change the credit limit, and cannot see colleagues' orders they are not entitled to.

Can RAITHub test a B2B portal it did not build?

Yes. RAITHub starts with the isolation, pricing and credit paths, writes characterisation tests that pin down current behaviour, and gates them in CI before widening coverage, through its QA as a Service.