How to test an online marketplace

Direct answer

Shipped untested, an online marketplace lets a seller pass onboarding with a borrowed tax ID and collect payouts for counterfeit goods, and keeps selling a high-volume seller's listings with no seller name, address or report link on the listing page. 7 tests are mandatory here, each tied to a risk in the map below. After the release smoke check, start the risk tests with end-to-end functional tests: seller verification at the volume threshold and the buyer report path carry both the fake-seller fraud and the seller disclosure penalty.

7 mandatory testsfirst: end-to-end functional tests

What counts as an online marketplace

An online marketplace here is a two-sided platform on web, iOS and Android where third-party sellers list goods, buyers pay the platform, and the platform splits each payment into seller payouts and handles disputes. It covers seller onboarding and verification, listings and buyer-seller messages, split payments, payout holds and the trust team's report queue. A single-merchant store that sells only its own stock and a platform where sellers are paid outside the platform are out of scope.

Adjacent product types not covered here

  • ecommerce store: An ecommerce store sells its own stock, so there is no seller onboarding, payout split or seller disclosure duty, and checkout and stock errors lead the map instead.
  • ride-hailing app: A ride-hailing app also pays independent providers, but drivers are matched to trips in real time, so driver document transfers and automated driver deactivation replace counterfeit listings and seller disclosure.
  • event ticketing platform: A ticketing platform sells seats from organisers for a fixed event date, so seat inventory under sale-day load and event cancellation refunds replace seller verification and payout holds.

Risk map

4 risks attached to online marketplace with evidence. Sorted by severity.
RiskGradeNoteEvidence
Fraud or abuse by users
fraud-abuse
moneyprimaryA seller passes onboarding with a borrowed tax ID, lists counterfeit goods, collects payouts, and buyers find no way on the listing to report them.
Fine or enforcement by a regulator
regulatory-penalty
legalprimaryA seller crosses the high-volume threshold and their listings keep selling in the app with no seller name, address or report-this-listing link.
Personal or sensitive data exposed
data-breach
datasecondary
by design analysis
A seller changes the order id in the order API and reads the shipping address and phone number of buyers who ordered from a different seller.
App rejected or removed by a store
store-rejection
distributionsecondary
by design analysis
The reviewer opens buyer-seller messages and listings and finds no way to report a listing or block a seller, which the user-generated content rule requires.

Mandatory tests (7)

  1. Step 1: release smoke tests

    Why:store-rejection

    Done when: On the release build, a buyer finds a listing, reports it, blocks the seller and completes a purchase from another seller.

    Tool class: mobile automation. Who usually runs it: QA engineer.

  2. Step 2: end-to-end functional tests

    Why:fraud-abuseregulatory-penalty

    Done when: A test seller crosses the volume threshold, is asked for verification, and has listings paused until verified; a buyer report on a listing reaches the trust team queue.

    Tool class: browser automation. Who usually runs it: QA engineer.

  3. Step 3: penetration testing

    Why:data-breachfraud-abuse

    Done when: A tester signed in as seller A cannot read seller B's buyers, orders or payout account, or change another seller's bank details, by editing ids, and a seller account set up with a tax ID that does not match the seller's verified name cannot receive a payout.

    Tool class: proxy. Who usually runs it: security specialist.

  4. Step 4: compliance checks

    Why:regulatory-penaltyfraud-abuse

    Done when: A signed checklist shows that sellers above the volume threshold are verified, and that their name, address and a report link show on every listing on web and app.

    Tool class: test management. Who usually runs it: product manager.

  5. Step 5: exploratory testing

    Why:fraud-abuse

    Done when: A session log records attempts at fake-seller onboarding, refund abuse, off-platform payment requests in messages and review manipulation, with the platform's response to each.

    Tool class: test management. Who usually runs it: QA engineer.

  6. Step 6: data integrity and migration testing

    Why:regulatory-penalty

    Done when: A daily ledger report shows, for every order, buyer charge equal to seller payout plus fees plus refunds, and lists every high-volume seller with verified details.

    Tool class: data validation. Who usually runs it: QA engineer.

  7. Step 7: security scanning

    Why:data-breach

    Done when: The scan of the buyer and seller APIs shows no open high-severity finding, and payout bank-detail changes require re-authentication.

    Tool class: DAST scanner. Who usually runs it: security specialist.

Recommended and optional tests

  • device and browser compatibilityrecommended

    Becomes mandatory when sellers list mainly from phones.

  • integration testsrecommended

    Becomes mandatory when a payout released before a dispute closes is recorded for this product type with verified evidence (see the methodology).

  • contract testsrecommended

    Becomes mandatory when the payment provider or shipping label provider changes its API version.

  • regression suiterecommended

    Becomes mandatory when fee or payout rules change more than once a quarter.

  • accessibility testingrecommended

    Becomes mandatory when the platform sells in a market with a web accessibility law that covers it.

  • performance and load testingrecommended

    Becomes mandatory when the platform runs a sitewide sale or drop above its past peak traffic.

  • resilience and failure testingrecommended

    Becomes mandatory when payouts are triggered automatically from payment events.

  • payment and money-flow testingrecommended

    Becomes mandatory when a payout released before a dispute closes is recorded for this product type with verified evidence (see the methodology).

Not needed and why

  • localization testing

    Not needed: one country and one currency. Becomes recommended when cross-border sellers or a second currency are added.

  • analytics and event tracking tests

    Not needed: no evidenced risk depends on event data. Becomes recommended when seller rankings or fees are computed from tracked events.

Order of work

First release

  1. release smoke tests: On the store build, find a listing, report it, block the seller and complete a purchase from another seller.
  2. end-to-end functional tests: Push a test seller over the volume threshold and confirm listings pause until verification, then file a buyer report on a listing and confirm it reaches the trust team queue.
  3. penetration testing: Have a tester signed in as one seller try to read another seller's buyers, orders and payout account and change their bank details by editing ids, then set up a seller with a tax ID that does not match the verified name and try to receive a payout.
  4. compliance checks: Check every listing of each seller above the volume threshold on web and app for the seller name, address and a report link, and sign the checklist.
  5. exploratory testing: Spend a session trying fake-seller onboarding, refund abuse, off-platform payment requests in messages and review manipulation, and log the platform's response to each.
  6. data integrity and migration testing: Run the ledger report and confirm, for every test order, that the buyer charge equals seller payout plus fees plus refunds, with every high-volume seller listed with verified details.
  7. security scanning: Scan the buyer and seller APIs and confirm that a change of payout bank details asks the seller to sign in again.

Ongoing cadence

Tools

Listed alphabetically inside each test type, filtered to the tests above and to the platforms of online marketplace (web, ios, android). Not recommendations.

38 tools shown

release smoke tests

  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

end-to-end functional tests

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • DetoxGray-box end-to-end testing for React Native apps. iosandroidopen-source
  • EspressoAndroid UI testing framework from Google. androidopen-source
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • MaestroMobile UI flows written in YAML. iosandroidfreemium
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

penetration testing

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium

security scanning

  • Burp SuiteProxy and scanner for web application security testing. webapifreemium
  • mitmproxyInteractive HTTPS proxy. iosandroidwebapiopen-source
  • MobSFStatic and dynamic analysis for mobile binaries. iosandroidopen-source
  • OWASP ZAPDynamic application security scanner. webapiopen-source
  • SemgrepStatic analysis with custom rules. apiwebiosandroidfreemium
  • SnykDependency and code vulnerability scanning. apiwebiosandroidfreemium

device and browser compatibility

  • AppiumCross-platform mobile UI automation over WebDriver. iosandroidopen-source
  • ApplitoolsVisual comparison of screens across builds. webiosandroidcommercial
  • BrowserStackCloud of real devices and browsers. webiosandroidcommercial
  • Firebase Test LabRuns app tests on hosted devices. iosandroidfreemium
  • LambdaTestCloud browser and device grid. webiosandroidcommercial
  • PercyVisual review of UI changes. webcommercial
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • Sauce LabsCloud test infrastructure for web and mobile. webiosandroidcommercial
  • SeleniumWebDriver-based browser automation. webopen-source

integration tests

  • Charles ProxyHTTP proxy for inspecting and throttling traffic. iosandroidwebcommercial
  • JestJavaScript test runner with mocking and snapshots. webapiopen-source
  • JUnitTest framework for the JVM. apiandroidopen-source
  • VitestTest runner for Vite-based JavaScript and TypeScript projects. webapiopen-source
  • XCTestApple's framework for unit and UI tests. iosopen-source

regression suite

  • CypressBrowser-based end-to-end testing with a visual runner. webfreemium
  • PlaywrightBrowser automation for Chromium, Firefox and WebKit. webopen-source
  • PromptfooEvaluation and regression tests for LLM prompts and outputs. apiwebopen-source
  • TestRailTest case and run management. webiosandroidapicommercial
  • XrayTest management inside Jira. webiosandroidapicommercial

accessibility testing

  • Accessibility ScannerGoogle's on-device accessibility checker for Android. androidopen-source
  • axe-coreAccessibility rules engine for automated checks. webopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • Pa11yCommand-line accessibility testing. webopen-source

performance and load testing

  • ArtilleryLoad testing with YAML scenarios. apiwebfreemium
  • GatlingLoad testing with Scala, Java or Kotlin scenarios. apiwebfreemium
  • JMeterLoad testing tool from the Apache Foundation. apiwebopen-source
  • k6Load testing scripted in JavaScript. apiwebopen-source
  • LighthouseAudits for accessibility and performance in Chrome. webopen-source
  • LocustLoad testing scripted in Python. apiwebopen-source

payment and money-flow testing

What to send to the person who will test

Send the checklist and the brief below. The printable checklist for online marketplace has the same 7 items with checkboxes.

Download the checklistMarkdownCSVBrief (Markdown)

Acceptance criteria wording

A release of the online marketplace is accepted when a test seller over the volume threshold has listings paused until verified, and every verified seller's listings show name, address and a report link on web and app. For every test order, the buyer charge equals seller payout plus fees plus refunds in the ledger report.

Brief

# Test brief: online marketplace

Product type: online marketplace. A two-sided platform with third-party sellers, payouts and disputes.
Risk map and evidence: https://howtotestaproduct.com/how-to-test/marketplace/
Printable checklist: https://howtotestaproduct.com/checklists/marketplace/

Run these 7 mandatory tests in this order. A test is done only when its done condition is true on the build you will release.

1. release smoke tests (risks: store-rejection). Tool class: mobile automation. Usually run by: QA engineer.
   Done when: On the release build, a buyer finds a listing, reports it, blocks the seller and completes a purchase from another seller.
2. end-to-end functional tests (risks: fraud-abuse, regulatory-penalty). Tool class: browser automation. Usually run by: QA engineer.
   Done when: A test seller crosses the volume threshold, is asked for verification, and has listings paused until verified; a buyer report on a listing reaches the trust team queue.
3. penetration testing (risks: data-breach, fraud-abuse). Tool class: proxy. Usually run by: security specialist.
   Done when: A tester signed in as seller A cannot read seller B's buyers, orders or payout account, or change another seller's bank details, by editing ids, and a seller account set up with a tax ID that does not match the seller's verified name cannot receive a payout.
4. compliance checks (risks: regulatory-penalty, fraud-abuse). Tool class: test management. Usually run by: product manager.
   Done when: A signed checklist shows that sellers above the volume threshold are verified, and that their name, address and a report link show on every listing on web and app.
5. exploratory testing (risks: fraud-abuse). Tool class: test management. Usually run by: QA engineer.
   Done when: A session log records attempts at fake-seller onboarding, refund abuse, off-platform payment requests in messages and review manipulation, with the platform's response to each.
6. data integrity and migration testing (risks: regulatory-penalty). Tool class: data validation. Usually run by: QA engineer.
   Done when: A daily ledger report shows, for every order, buyer charge equal to seller payout plus fees plus refunds, and lists every high-volume seller with verified details.
7. security scanning (risks: data-breach). Tool class: DAST scanner. Usually run by: security specialist.
   Done when: The scan of the buyer and seller APIs shows no open high-severity finding, and payout bank-detail changes require re-authentication.

Acceptance criteria wording:
A release of the online marketplace is accepted when a test seller over the volume threshold has listings paused until verified, and every verified seller's listings show name, address and a report link on web and app. For every test order, the buyer charge equals seller payout plus fees plus refunds in the ledger report.

Report back for each test: pass or fail against its done condition, the build or version tested, and the proof (screenshot, log line or report file).

Licence: CC BY 4.0.

For founders: what to forward and what to ask back. For product managers: turning this page into tickets.

Questions about testing an online marketplace

What testing does an online marketplace need?

7 tests are mandatory, starting with a release smoke test on every store build and end-to-end tests of seller verification and buyer reports. Each is tied to one of the 4 risks in the map, such as fake sellers collecting payouts. Integration, payment sandbox, contract, regression, resilience, compatibility, accessibility and performance tests are recommended, each with the event that makes it mandatory.

What gets an online marketplace rejected by an app store?

The map marks store rejection as a by design analysis risk: the reviewer opens buyer-seller messages and listings and finds no way to report a listing or block a seller, which the user-generated content rule requires. The release smoke test reports a listing and blocks a seller on every store build before submission.

Does an online marketplace need PCI DSS testing?

The risk map does not cite PCI DSS for this product type. The mandatory tests that touch payment data are the security scan of the buyer and seller APIs and the penetration test of seller access to other sellers' buyers and payout accounts.

What does GDPR mean for testing an online marketplace?

The map cites the General Data Protection Regulation for the data breach risk. The data breach case is a seller who edits an order id and reads the shipping address and phone number of another seller's buyers, so penetration testing checks that seller A cannot read seller B's buyers or orders.

Which tests in a vendor test plan for an online marketplace are not needed?

Localization is not needed while the platform runs in one country and one currency, until cross-border sellers or a second currency are added. Analytics tracking is not needed while no risk on the map depends on event data, until seller rankings or fees are computed from tracked events.

How should checkout be tested in an online marketplace?

The recommended payment sandbox test runs a multi-seller cart, a partial refund and a won buyer dispute through the payment provider sandbox and checks buyer charge, seller payout and platform fee for each. The recommended integration test confirms that a payout for a disputed order stays held until the dispute closes, and the mandatory ledger report checks that charges equal payouts plus fees plus refunds.

Evidence

  1. ev-0107regulatorprimary

    Online Marketplace Temu to Pay [amount] Penalty for Alleged INFORM Act Violations, U.S. Federal Trade Commission

    First INFORM Act enforcement: an online marketplace was penalised for missing or hard-to-find seller disclosures and suspicious-activity reporting on third-party listings, including listings inside its app.

    published 2025-09-05 · verified 2026-10-07

  2. ev-0108regulatorprimary

    Informing Businesses about the INFORM Consumers Act, U.S. Federal Trade Commission

    Online marketplaces must verify the information they get from high-volume third party sellers.

    FTC guidance sets the duty for a marketplace to collect, verify and disclose high-volume third-party seller details to deter stolen, counterfeit or unsafe goods, which is the fake-seller risk of this product type.

    published undated · verified 2026-10-07

  3. ev-0012standardprimary

    OWASP API Security Top 10 2023, OWASP Foundation

    The API Security Top 10 names API-specific failures such as broken object level authorization and unrestricted resource consumption.

    published undated · verified 2026-10-07

  4. ev-0025regulatorprimary

    Regulation (EU) 2016/679 (General Data Protection Regulation), EUR-Lex, European Union

    The GDPR sets lawful basis, consent, data subject rights, security of processing (Article 32) and breach notification duties for anyone processing personal data of people in the EU.

    published undated · verified 2026-10-07

  5. ev-0001store-guidelineprimary

    App Review Guidelines, Apple

    Apple reviews every iOS, iPadOS and macOS App Store submission against these guidelines, including crashes and bugs at review, privacy disclosures, in-app purchase rules and extra rules for medical, financial and kids apps, and apps with user-generated content must let users report offensive content and block abusive users (guideline 1.2), and apps offering loot boxes or similar mechanisms must disclose the odds of each item type before purchase (guideline 3.1.1).

    published undated · verified 2026-10-07

Disclaimer

This page lists tests and risks for a product category, not for your product. Risks are attached only with the evidence shown in the Evidence section. Tools are listed alphabetically and are not recommendations. Nothing here is legal, regulatory or security advice; where a regulator or a store sets a requirement, their page is linked and takes precedence.