Marketplace App QA Checklist: Transactions, Roles and Failure Recovery

The buyer can place an order, the provider can accept it and the admin can issue a refund. That three-minute demonstration proves almost nothing about the marketplace. The same order may be accepted twice, the refund may not reverse the payout, or a suspended provider may keep receiving jobs through a stale connection.

Marketplace QA must test agreements between roles and systems. Correctness lives in transitions, authority, financial reconciliation and recovery under retries—not in isolated screens.

This checklist organizes validation around risk so a team can prove the commercial loop rather than merely click through it.

Model the complete journey

List buyer, provider, operator and financial states from discovery to settlement.

The failure mode is concrete: testing follows screens and misses cross-role obligations. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, create a state-and-actor coverage map. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include state, actor, command, prerequisite, side effect, notification, evidence and recovery. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with one success and every consequential rejection. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: QA lead
• Release evidence: Model the complete journey acceptance record
• Stop condition: model the complete journey cannot be explained or recovered

Test role boundaries

Each party needs different data and actions.

The failure mode is concrete: UI hiding is mistaken for authorization. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, call routes directly under every role and tenant. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include identity, membership, capability, resource ownership, field exposure and denial result. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with cross-tenant ID and stale role. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: security tester
• Release evidence: Test role boundaries acceptance record
• Stop condition: test role boundaries cannot be explained or recovered

Test transition invariants

Orders and bookings should reject impossible jumps.

The failure mode is concrete: clients can submit arbitrary next states. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, verify transitions and prerequisites server-side. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include current version, requested state, actor, evidence, idempotency and conflict result. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with deliver before accept and cancel after settlement. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: domain tester
• Release evidence: Test transition invariants acceptance record
• Stop condition: test transition invariants cannot be explained or recovered

Test concurrency

The last seat, item or provider can attract simultaneous actions.

The failure mode is concrete: sequential tests miss overselling and double assignment. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, execute competing commands against shared resources. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include resource version, reservation, transaction boundary, winner, loser response and cleanup. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with two checkouts and two dispatchers. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: performance tester
• Release evidence: Test concurrency acceptance record
• Stop condition: test concurrency cannot be explained or recovered

Checkpoint 4: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Test retries and idempotency

Clients and webhooks retry after timeouts.

The failure mode is concrete: duplicates create extra orders, refunds or notifications. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, repeat every consequential command with stable keys. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include key scope, request hash, stored result, expiry and conflict behavior. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with same payload and changed payload. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: integration tester
• Release evidence: Test retries and idempotency acceptance record
• Stop condition: test retries and idempotency cannot be explained or recovered

Test payment states

Checkout, authorization, capture, failure and dispute are distinct.

The failure mode is concrete: success redirect is treated as verified payment. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, drive provider test events and reconcile product state. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include attempt, provider reference, amount, currency, state, event and entitlement. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with delayed callback and failed capture. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: payments QA
• Release evidence: Test payment states acceptance record
• Stop condition: test payment states cannot be explained or recovered

Test refunds and payouts together

Customer reversals affect platform and provider obligations.

The failure mode is concrete: refund tests ignore released payouts. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, verify ledger and recovery across timing cases. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include charge, fee, refund, reserve, provider balance, transfer and adjustment. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with partial refund and post-payout dispute. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: finance QA
• Release evidence: Test refunds and payouts together acceptance record
• Stop condition: test refunds and payouts together cannot be explained or recovered

Test notification truth

Messages should describe verified state once.

The failure mode is concrete: client actions send duplicates or premature updates. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, assert event-triggered communication with deduplication. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include event ID, recipient, template, locale, preference, send state and link. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with retry and state reversal. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: communications QA
• Release evidence: Test notification truth acceptance record
• Stop condition: test notification truth cannot be explained or recovered

Checkpoint 8: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Test search and discovery permissions

Indexes can retain private or suspended listings.

The failure mode is concrete: API data is safe while search leaks it. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, test eligibility and ACL before retrieval. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include listing state, tenant, audience, moderation status, index time and cache. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with unpublish and membership removal. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: search QA
• Release evidence: Test search and discovery permissions acceptance record
• Stop condition: test search and discovery permissions cannot be explained or recovered

Test uploads and media

Marketplace files cross trust boundaries.

The failure mode is concrete: filename and declared MIME type are trusted. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, exercise validation, scanning and safe delivery. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include detected type, size, dimensions, storage key, scan result, access and deletion. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with polyglot and oversized file. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: application security QA
• Release evidence: Test uploads and media acceptance record
• Stop condition: test uploads and media cannot be explained or recovered

Test degraded dependencies

Maps, messaging, payments and identity providers fail.

The failure mode is concrete: tests assume every external call succeeds quickly. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, inject timeouts, errors and reordered callbacks. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include timeout budget, retry, circuit state, queued work, user message and reconciliation. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with provider outage and recovery. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: resilience tester
• Release evidence: Test degraded dependencies acceptance record
• Stop condition: test degraded dependencies cannot be explained or recovered

Test offline and stale clients

Mobile clients act on old state and reconnect later.

The failure mode is concrete: the newest arrival overwrites authoritative state. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, verify version conflicts and safe command replay. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include client version, entity version, occurrence time, sync time, conflict and resolution. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with offline acceptance after cancellation. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: mobile QA
• Release evidence: Test offline and stale clients acceptance record
• Stop condition: test offline and stale clients cannot be explained or recovered

Checkpoint 12: reconcile the product promise with the recorded state. Support, finance, security, and delivery teams should be able to reach the same conclusion from the same identifiers without reconstructing events from chat messages or screenshots.

Test accessibility journeys

Purchase and provider operations must work with assistive technology.

The failure mode is concrete: only static pages receive accessibility checks. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, run task-based keyboard and screen-reader tests. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include labels, focus, errors, status announcements, contrast, zoom and timeout handling. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with checkout error and modal workflow. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: accessibility QA
• Release evidence: Test accessibility journeys acceptance record
• Stop condition: test accessibility journeys cannot be explained or recovered

Test operator recovery

Support actions are part of the product.

The failure mode is concrete: defects are repaired directly in the database. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, validate bounded recovery and audit. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include case, capability, reason, preview, action, result, compensation and log. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with wrong refund and partial bulk action. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: operations QA
• Release evidence: Test operator recovery acceptance record
• Stop condition: test operator recovery cannot be explained or recovered

Build release regression evidence

Critical marketplace contracts should remain stable across changes.

The failure mode is concrete: regression selection depends on memory. This is not solved by adding another screen or background job. The product has to define ownership, permitted transitions, and the evidence retained when the transition occurs.

For the first release, maintain risk-tagged suites and production-like fixtures. Write that decision as an enforceable server-side rule, not guidance that depends on a client, operator, or AI model remembering the intended boundary.

Implementation should include journey, risk, owner, automation level, fixture, last result and failure triage. Keep the public response smaller than the internal record: users need a clear outcome and recovery path, while authorized operators need correlation IDs, policy versions, timestamps, and the before-and-after state.

Validate it with schema change and provider upgrade. Test the ordinary path, then repeat under timeout, duplicate delivery, stale state, partial failure, revoked authority, and concurrent requests. A feature is not ready when only the demonstration succeeds.

• Owner: release QA
• Release evidence: Build release regression evidence acceptance record
• Stop condition: build release regression evidence cannot be explained or recovered

Implementation references

Use OWASP API Security Top 10 and record the version applied to this release.

Validate implementation against OWASP Authorization Cheat Sheet and record the version applied to this release.

Review OWASP Web Security Testing Guide and record the version applied to this release.

Compare with W3C Web Content Accessibility Guidelines 2.2 and record the version applied to this release.

Continue with Marketplace Development when translating this guide into delivery scope.

Frequently asked questions

What should be tested first in a marketplace app?

The smallest complete transaction across every role, including settlement and recovery.

Why are screen-by-screen tests insufficient?

Marketplace failures occur across actors, transitions, integrations and financial obligations.

What concurrency cases matter?

Final inventory or capacity, provider assignment, coupon limits, refunds and competing admin actions.

How should payment testing work?

Use provider test events and verify internal payment, entitlement, ledger and notification state.

What is idempotency testing?

Repeating the same consequential request and proving it creates only one effect.

Should admin tools be tested?

Yes. Support recovery, refunds, restrictions, bulk actions and audit trails are production-critical.

How do you test third-party outages?

Inject timeouts and failures, verify truthful user states, queued recovery and later reconciliation.

What belongs in the release regression suite?

High-risk commercial journeys, permission negatives, money invariants, concurrency, recovery and accessibility.

Turn the plan into release evidence

A credible release connects the public promise to durable state, scoped authority and recoverable operations. Ordinary journeys and important exceptions should be explainable from the same evidence.

Keep the initial scope narrow enough to rehearse end to end. Expand only after permissions, financial consequences, data integrity and support outcomes remain consistent under retries, failures and human mistakes.