Marketplace QA
Multi-sided platform testing: seller onboarding, listing accuracy, and transaction trust.
// OVERVIEW
Three parties see the same transaction differently. The bugs that matter let money move to the wrong person at the wrong time, let dispute state leak across role boundaries, or let a suspended seller's listings remain visible and purchasable after moderation has acted.
// What makes Marketplace QA different
- Three distinct role perspectives (buyer, seller, admin): the same action has different visibility and different success criteria for each — a payout that looks correct to the seller may be premature from the platform's perspective
- Payouts are time-delayed and commission-dependent: the seller receives payment only after the buyer confirms receipt, minus the platform's commission — both the amount and the timing are independently error-prone
- Disputes are a state machine across three parties (buyer claim → seller response → admin resolution): each party sees a restricted view of the same record, and a visibility leak is a security bug
- Moderation creates seller-vs-buyer asymmetry: a suspended seller's listings may remain visible and purchasable; a buyer can leave a verified review for an order they cancelled
- Listing data integrity: the price and availability shown to the buyer must reflect the seller's current live state, not a stale cache — stale state creates the appearance of a valid purchase that cannot be fulfilled
// Core user journeys
| Journey | What to cover |
|---|---|
| Seller onboarding and listing | Seller completes KYC onboarding, creates a listing with price and inventory, and publishes it; assert listing is immediately discoverable in search |
| Buyer purchase flow | Buyer browses listings, purchases an item, receives order confirmation, and confirms receipt; assert payout is triggered only on buyer receipt confirmation |
| Seller payout and commission | Order reaches buyer-confirmed state; assert the correct commission is deducted and the seller receives the net payout within the defined window |
| Dispute: claim through resolution | Buyer opens a dispute; seller submits a response; admin reviews and resolves; assert each party sees only the information scoped to their role at each state |
| Seller suspension and moderation cascade | Moderator suspends a seller account; assert all active listings are removed from search and become un-purchasable immediately |
// RISKS & TEST AREAS
// Main risk areas
| Risk | Why it matters |
|---|---|
| Premature payout | Seller payout is triggered at 'shipped' status before the buyer confirms receipt; if the buyer then opens a dispute, funds have already been disbursed and the platform has no recourse without a claw-back mechanism |
| Commission rounding error at scale | Floating-point rounding on a percentage commission (e.g. 12% of $0.83 = $0.0996) systematically rounds down to $0.09 instead of $0.10; across thousands of transactions the platform under-collects materially |
| Dispute state visibility leak | The seller-facing GET /disputes/{id} endpoint returns admin_notes and admin_decision fields in the response body before the admin has published the decision |
| Suspended-seller listing still purchasable | Moderator suspends a seller account but the seller's active listings are not removed from the search index; buyers can discover and complete a purchase against a suspended seller |
| Fraudulent verified review | A buyer cancels an order within the return window but the cancellation does not revoke verified-purchaser status; the buyer can post a verified review for an item they never received |
// Functional areas to test
- Seller onboarding and KYC: identity verification, bank account registration, and account state management
- Listing management: create, edit, publish, unpublish, and inventory management with immediate search-index sync
- Buyer purchase flow: browse, add to cart, checkout, payment, and order confirmation
- Payout and commission engine: commission calculation, payout trigger on buyer confirmation, and payout status tracking
- Dispute resolution workflow: claim submission, seller response, admin review, resolution, and per-role visibility enforcement
- Moderation and trust and safety: seller suspension, listing takedown, review gating, and cross-account isolation
// API & integration areas
- Payment split API: assert buyer charge, platform commission hold, and seller payout are three separate ledger events and that each fires in the correct order
- Seller KYC/identity verification: assert onboarding cannot be completed without a verified identity and that API calls from unverified sellers are rejected
- Dispute state machine API: assert the dispute transitions correctly through open → seller-responded → admin-decided → resolved and that invalid transitions are rejected
- Notification webhooks on dispute transitions: assert buyer, seller, and admin each receive the correct notification payload at each state change
- Search index sync: assert a listing published or unpublished by the seller appears or disappears from search results within the defined propagation SLA
// Data testing
- Seed multi-role accounts (buyer, seller, admin) with known states for each test scenario; reset to a clean state between dispute-visibility tests
- Seed a commission matrix: percentage-based, flat-fee, and mixed combinations across a range of order totals including fractional amounts
- Seed a dispute in each workflow state (open, seller-responded, admin-decided) to test per-role visibility in each state without requiring full end-to-end flows
- Never use real banking details or payment credentials — use sandbox payment methods and synthetic seller payout accounts
// CROSS-CUTTING CONCERNS
// Security & privacy
- Seller financial details (bank account, payout history, commission rate) must not be accessible to buyers or other sellers via any API endpoint
- Admin-only dispute fields (admin_notes, admin_decision, internal_flag) must not appear in seller or buyer API responses at any dispute state
- Listing price must be validated server-side: assert the server rejects a purchase request that contains a client-modified price field and recalculates the total from the listing's current price
- Cross-account isolation: seller A must not be able to edit, delete, or view the listings, payouts, or disputes belonging to seller B
// Accessibility
- WCAG AA contrast and keyboard navigation on the seller dashboard and dispute submission form
- Full keyboard navigation through the multi-step listing creation flow: details, pricing, inventory, images, and publish
- Screen reader on order status and dispute status updates: assert state changes are announced via an ARIA live region rather than silently reflected
// Performance
- Search index update latency: assert a listing published or unpublished by the seller is reflected in search results within the defined SLA under concurrent seller activity
- Payout batch processing: assert end-of-period batch payout completes within the defined time window at realistic order volume
- Dispute notification delivery: assert all three parties receive dispute-transition notifications within the defined latency under high-volume dispute events
// Mobile & responsive
- Mobile buyer purchase flow at 375 px: product images, add-to-cart, checkout, and payment confirmation must be fully usable with touch
- Seller mobile dashboard: payout summary, pending disputes, and notification delivery must be readable and actionable on small screens
// BUGS & SCENARIOS
// Common bugs
| Bug | Scenario / repro |
|---|---|
| Premature payout | Seller payout fires when order status transitions to 'shipped' rather than 'buyer confirmed receipt'; buyer opens a dispute two days later but funds are already disbursed; platform must initiate a claw-back instead of withholding the payout |
| Commission rounding error | 12% commission on a $0.83 order total = $0.0996; system applies Math.floor and records $0.09; across 10,000 such transactions the platform under-collects $10.00 — a systematic loss at scale |
| Dispute visibility leak | Seller calls GET /disputes/{id} before admin has published a decision; the API response body includes admin_notes and admin_decision fields, revealing the admin's internal assessment before the seller is notified |
| Suspended-seller listing purchasable | Moderator suspends the seller account; the seller's three active listings are not removed from the search index; a buyer discovers and purchases one of them; the order is in a fulfilled state against a suspended seller |
| Fraudulent verified review | Buyer cancels an order on day 2 within the return window; the cancellation sets order status to 'cancelled' but does not revoke the verified-purchaser flag; buyer posts a one-star verified review for the item they returned |
// Example test scenarios
- 01Complete a purchase and mark the order as shipped; assert that seller payout is NOT triggered at 'shipped' status — assert payout fires only when the buyer confirms receipt
- 02Create 1000 orders each with an $0.83 total and a 12% commission rate; assert the total commission collected equals exactly $100.00, not an amount reduced by systematic rounding
- 03Open a dispute; as the seller, call GET /disputes/{id}; assert the response body does not include admin_notes or admin_decision fields
- 04Create an active listing; suspend the seller account; assert the listing no longer appears in search results and that attempting to purchase it returns a seller-unavailable error
- 05Complete a purchase; cancel within the return window; attempt to POST a review for the cancelled order — assert the endpoint returns HTTP 403 because the order is in a cancelled state
// Edge cases
- Seller account deleted mid-dispute: the dispute must remain resolvable by admin using the evidence already submitted, and the seller's response must be preserved even after account deletion
- Listing price updated while a buyer has it in their cart: assert the buyer is warned of the price change before checkout confirmation, not silently charged the stale price
- Chargeback after completed payout: buyer files a bank chargeback after the seller has been paid; assert the platform claws back from the seller's payout balance, not from the platform's general pool
- Admin resolves dispute in the seller's favour after the buyer has already been refunded by the payment provider: assert both parties receive consistent resolution notifications and the ledger reflects the correct final state
- Listing with zero inventory published: seller sets stock to 0 and publishes; assert the listing is displayed as 'unavailable' and the add-to-cart or purchase action is blocked
// AUTOMATION & TOOLS
// What to automate
- Payout trigger timing: automated test asserting the payout event fires only on the 'buyer confirmed receipt' status transition and that no other status transition (shipped, delivered) triggers it
- Commission precision matrix: parametrised test over a range of order totals and commission rates; assert the collected amount equals the expected value to two decimal places across all combinations
- RBAC API sweep: for each dispute endpoint, assert that the seller-role response and the buyer-role response exclude admin-only fields; run as a role × endpoint × field matrix in CI
- Moderation cascade: automated test asserting that suspending a seller account immediately removes all of that seller's listings from the search index within the defined propagation SLA
// Useful tools
PostmanDispute state machine API, payout trigger endpoint testing, and payment split ledger verificationPlaywrightE2E buyer purchase flows, seller listing creation, and dispute submission across all three rolesPairwise test case generatorCommission rate × order total matrix and role × endpoint × field RBAC sweep coverageBoundary value generatorCommission precision edge cases: exactly at rounding boundaries and minimum-fee thresholdsRole & permission testing checklistThree-role (buyer, seller, admin) RBAC coverage for all listing, order, and dispute endpointsAPI testing checklistPayment split API, dispute state machine, and KYC integration coverage
// SHIP & LEARN
// Release readiness checklist
- Payout timing correct: seller payout fires only on buyer-confirmed-receipt status in all order-completion paths — no payout on shipped, delivered, or any intermediate status
- Commission precision verified: rounding tested at the full range of order totals and rates, no systematic under-collection or over-collection confirmed
- Dispute visibility enforced: seller-role and buyer-role API responses exclude admin-only fields in all dispute states
- Seller suspension cascade: suspension immediately removes all listings from the search index and blocks purchase within the defined propagation SLA
- Cross-account isolation: seller A cannot read, edit, or delete seller B's listings, payouts, or disputes through any API path
- Verified-review gate: cancelled and returned orders cannot trigger a verified-purchase review in any order state
- All dispute-transition notifications tested: buyer, seller, and admin each receive the correct payload at every state change