Multi-Vendor Marketplace QA: What to Test Before You Open to Sellers

Before you open a multi-vendor marketplace to sellers, test vendor data isolation, split orders and payouts, commission maths, refunds, disputes and vendor onboarding. Each is a pass-or-fail check with evidence behind it: a seller must never see another seller's orders, money must split to the penny, and a refund must claw back the right share. Automate the money paths first.

If you would rather have the suite built and run for you, see how RAITHub would test this below. The rest is the checklist, so your own team can run it before launch.

Why does a marketplace need more QA than a normal store?

A single-brand store has one seller: you. A marketplace adds many sellers who each see a slice of the system, plus money that splits between them and you on every order. That turns two ordinary features into high-risk ones. The first is isolation: one vendor reading or editing another vendor's orders, products or payouts is a data breach, the same class of bug as cross-tenant leaks in SaaS (how one tenant ends up seeing another's data). The second is money: a commission or payout that is a few cents wrong, multiplied across thousands of orders, becomes a reconciliation nightmare you discover when a vendor complains.

So the checklist here is weighted to those two areas. Standard store QA still applies on top, and the pre-launch QA checklist covers the rest: critical journeys, performance, accessibility and a rollback plan.

What does the whole checklist look like on one page?

Six areas, each with a minimum bar. If an item fails, you fix it or write down why you are opening to sellers anyway.

Area	Minimum bar to pass	Automate or manual
Vendor isolation	A vendor gets a 404 for any order, product or payout that is not theirs	Automate (API tests)
Split orders and payouts	A basket from three vendors creates three sub-orders; each vendor sees only their line; totals reconcile	Automate + one manual pass
Commission and fees	Commission, payment fees and tax compute to the penny on every rate	Automate (unit tests)
Refunds and cancellations	A partial refund claws back the right commission share and the right vendor payout	Automate + manual
Disputes and moderation	A buyer can open a dispute; an admin can hold a payout; the audit trail records who did what	Manual + API
Vendor onboarding	A new vendor cannot sell until approved, bank details verified and payouts enabled	Manual

How do you test vendor data isolation?

Treat each vendor as a tenant. For every endpoint that returns or changes a vendor-owned record, sign in as vendor A and request vendor B's record by ID, on reads, updates, deletes and list filters. Expect a 404, not a 403, so the response does not even confirm the record exists. Generate the cases from your list of vendor-scoped resources, so a new resource is covered the day it ships. This is the same API layer that catches the most dangerous bugs in any multi-party system (the test pyramid for a SaaS).

// tests/api/vendor-isolation.spec.ts
import { test, expect } from '@playwright/test'
import { tokenFor } from './helpers'

const vendorScoped = ['orders', 'products', 'payouts', 'messages']

for (const resource of vendorScoped) {
  test('vendor A cannot read vendor B ' + resource, async ({ request }) => {
    const token = await tokenFor('owner@vendor-a.test')
    const res = await request.get('/api/vendor/' + resource + '/belongs_to_vendor_b', {
      headers: { Authorization: 'Bearer ' + token },
    })
    expect(res.status()).toBe(404)
  })
}

Back the application check with the database. If you use PostgreSQL row-level security, add a CI test that fails when a vendor-scoped table has no policy, so a forgotten policy cannot reach production (row-level security for multi-tenant Postgres).

How do you test split orders and payouts?

Place a basket that spans three vendors and walk the whole path: the order splits into three sub-orders, each vendor sees only their own line and address data they are allowed to see, and each sub-order can ship and be marked delivered on its own. Then check the money. If you settle through a provider's connected-accounts model, the platform takes its fee and the rest routes to each seller; test that with the provider's test mode and replayed webhooks, because the payout confirmation arrives asynchronously (marketplace payments with Stripe Connect). The deeper split-payment and escrow options are in split payments and escrow for marketplaces.

The one check teams skip: reconciliation. Sum every vendor payout plus every platform fee plus tax, and assert it equals the amount the buyer paid, with no rounding drift. Run it as a test, not a spreadsheet you remember to open.

How do you test commission and refunds without rounding bugs?

Store money as integers (cents or the smallest unit), never floats, and test the commission function as a table of cases. A 15% commission on a 9.99 line (stored as 999) is where a float quietly loses a cent.

// src/payouts/commission.test.ts
import { describe, it, expect } from 'vitest'
import { splitLine } from './commission'

describe('splitLine (amounts in cents)', () => {
  it.each([
    { gross: 999, rate: 0.15, platform: 150, vendor: 849 },
    { gross: 10000, rate: 0.2, platform: 2000, vendor: 8000 },
    { gross: 333, rate: 0.1, platform: 33, vendor: 300 },
  ])('gross $gross at $rate', ({ gross, rate, platform, vendor }) => {
    const split = splitLine(gross, rate)
    expect(split.platform + split.vendor).toBe(gross)
    expect(split.platform).toBe(platform)
    expect(split.vendor).toBe(vendor)
  })
})

Refunds are the mirror image and the most common gap. A partial refund must claw back the commission share on the refunded amount and reduce the vendor's payout by the rest, even if the payout already left. Test full refund, partial refund, refund after payout and refund on a mixed-vendor order. The general rule of testing money paths with replayed webhooks is in testing payments and webhooks.

Buy, build or hire?

Option	What you get	Choose this when
Off-the-shelf marketplace SaaS	Vendors, payouts and commission handled by the platform	Your rules fit theirs and you accept their payout model and fees
A no-code or template marketplace	A quick storefront with basic multi-vendor add-ons	You are validating demand and can live with shallow isolation and reporting
A custom build you test yourself	Full control of isolation, payouts and disputes	Your commission, credit or local payment rules are the business, and you have engineers to test the money paths
A managed QA team on your build	The isolation, payout and refund suites written and gated in CI	You have the marketplace but no one owns the test suite that protects the money

How long does it take to run this yourself?

For a marketplace that already works, expect about one to two weeks of one engineer's time to automate the isolation suite, the commission and refund unit tests, and a split-order end-to-end journey, then a manual pass on onboarding and disputes. The main risk of doing it yourself is testing the happy path only: the bugs that cost money hide in partial refunds, mixed-vendor baskets and payouts that already left. Start from the API layer, where the isolation and money bugs live.

Why RAITHub for this

RAITHub built and tested TheSkinProof, a multi-vendor marketplace and the founder's own venture, with 217 API endpoints, 5 role-based portals and 750+ tests, including per-variant stock decremented inside the order transaction. On Sundor Skin, a security suite deliberately tries to read other buyers' data and CI fails if a buyer-scoped table lacks a row-level-security policy. The same discipline applies to a marketplace you already have: see how RAITHub builds marketplaces and the eCommerce industry page.

When you don't need us

• You are on an off-the-shelf marketplace platform. Its own payout and isolation logic is tested by the vendor; focus your QA on your custom theme and integrations.
• You are pre-launch with one or two friendly sellers. A manual pass on the money paths may be enough until volume grows.
• You need a CREST- or PCI-certified penetration test. RAITHub's security testing is application-level against OWASP guidance and issues no attestation.

How RAITHub would test this

• Scope: map the vendor-scoped resources and money paths; automate the isolation suite, commission and refund unit tests, a split-order end-to-end journey and a reconciliation assertion; add the row-level-security CI check; run a manual pass on onboarding and disputes.
• Ways to buy it: a fixed-price pre-launch QA audit with a written report, a monthly QA plan, or a dedicated QA team that 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 vendor roles and payout 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 QA as a Service page or the AI-built app testing page, read about a full SaaS build, or book the free 15-minute audit.

Guidance reviewed on 10 October 2026.

Frequently asked questions

What should I test first in a multi-vendor marketplace?

Vendor data isolation and the money paths. A seller seeing another seller's orders is a breach, and a commission or payout that is a few cents wrong compounds across every order. Automate both before you open to sellers.

How do I test marketplace payouts safely?

Use your payment provider's test mode and replay signed webhooks, because payout confirmations arrive asynchronously. Test full and partial refunds, refunds after a payout has left, and mixed-vendor baskets, then assert that every payout, fee and tax reconciles to what the buyer paid.

Do I need penetration testing before launch?

Application-level security testing against OWASP guidance catches the common issues: broken access control, exposed keys and open endpoints. A CREST- or PCI-certified penetration test is a separate, certified engagement; use a certified vendor if your buyers or acquirer require an attestation.

How is marketplace QA different from normal store QA?

It adds two high-risk areas: isolation between many sellers, and money that splits between sellers and the platform on every order. Standard store QA for journeys, performance and accessibility still applies on top of those.

Can RAITHub test a marketplace it did not build?

Yes. RAITHub starts with the vendor-scoped endpoints and the money paths, writes characterisation tests that pin down current behaviour, and gates them in CI before widening coverage, through its QA as a Service.