# Test your Marketplace Connect integration > Verify the quickstart, failure recovery, and the experience your app or store controls. Source: https://help.boltapp.com/products/connect-test-plan Run these cases against the [Marketplace Connect quickstart](/products/connect). Copy the tables into your test report and attach redacted evidence. Every case starts **Not run**. ## Scope and setup [#scope-and-setup] | Scope | What is covered | | ---------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Quickstart | SDK onboarding/status, single-seller order payload, signed callbacks, card-payment verification, and buyer status display. | | Merchant integration | Seller/session ownership, immutable catalog-to-seller assignment, order persistence, monotonic payment updates, and concurrency controls. | | Additional launch work | Seller eligibility enforcement, real commission/tax/shipping, refunds, fulfillment, payout setup and settlement reconciliation. | | Inputs | Enabled marketplace sandbox; seller A with Bolt-provided onboarding details; unconfigured seller B; buyer A/B; one $10.00 USD item assigned to A, free shipping/tax, zero commission. | | Evidence | Record build/date, tester, sandbox division, device/browser, case result, order/transaction/seller or link IDs as applicable, and redacted logs/screenshots. Never attach tokens, credentials, or personal banking data. | Use real sandbox execution for Q cases. Label controlled response substitutions, outages, and replay tests separately; mocks do not establish live payment acceptance. Use a fresh order for each payment test and reset store/fixture changes afterward. Do not retry an uncertain payment until it is reconciled. ## 1. Quickstart checkpoints [#1-quickstart-checkpoints] | Test | Input | Steps | Expected output | Result | | ------------------- | ---------------------------------- | -------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------- | | Q1 · Set up | Marketplace credentials; SDK 1.0.2 | 1. Confirm division enablement, payments, and Trusted Domains. | Marketplace key and signing secret configured; SDK installed; seller splits enabled. | Not run | | Q2 · Onboard seller | Seller A sandbox details | 1. Complete onboarding. 2. Check status through backend. 3. Inspect seller record. | Same stable seller ID saved with server-retrieved completed status; no approval inferred from browser callback alone. | Not run | | Q3 · Connect orders | A’s item; B not onboarded | 1. Request order for A. 2. Inspect item/split seller IDs and amounts. 3. Repeat for B. | A gets token; both seller IDs match A; gross 1000 and commission 0. B receives 409 before Bolt order creation. | Not run | | Q4 · Add checkout | Buyer page; registered signed URLs | 1. Open checkout. 2. Observe shipping/tax/order callbacks. | Correct item and $10.00 USD total; callbacks authenticate; no secrets in browser. | Not run | | Q5 · Verify payment | 4111 1111 1111 1111; 03/30; 737 | 1. Pay once. 2. Match app/Bolt records. 3. Reload and inspect saved seller. | Verified completed payment remains attached to the original seller/order. No claim of bank settlement. | Not run | ## 2. Functional integrity [#2-functional-integrity] | Test | Input | Steps | Expected output | Result | | ------------------------- | --------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | ------- | | F1 · Seller isolation | Seller A session; guessed seller B ID | 1. Request onboarding/config as A with B’s ID appended. | Server resolves A from session; never returns or changes B’s record. | Not run | | F2 · Review gate | under\_review or unconfigured status fixture | 1. Request a new buyer order. | 409; no checkout token generated for a seller who has not completed onboarding. | Not run | | F3 · Seller tampering | Browser cart assigns different seller | 1. Tamper with seller ID. 2. Inspect saved/outgoing cart. | Server-owned catalog assignment wins; mixed/mismatched seller carts rejected. | Not run | | F4 · Signed callbacks | Invalid signature; rotation headers; altered order amount | 1. Send invalid raw signature. 2. Send signed order.create with wrong total. 3. Send a shipping callback with a valid pending signature and invalid primary signature, then reverse them. | Either matching signature accepts the callback; 401 when neither matches; failure for changed order; no payment or order mutation. | Not run | | F5 · Verified transaction | Controlled wrong reference/order/amount/currency; credit/refund | 1. Replay a signed transaction notification against each response. | Mismatch never marks order paid; non-card-purchase transactions ignored by this sample. | Not run | | F6 · Replay/restart | Same signed payment notification twice | 1. Deliver twice. 2. Restart backend. 3. Read order. | One persisted payment reference and original seller assignment; no duplicate business effects. | Not run | | F7 · Buyer isolation | Buyer B; invalid CSRF | 1. Read A’s order as B. 2. Request token without valid CSRF/session. | 404 or authorization rejection; no unauthorized token or order disclosure. | Not run | ## 3. Merchant-owned experience [#3-merchant-owned-experience] | Test | Input | Steps | Expected output | Result | | ---------------------- | ---------------------------------------- | -------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | ------- | | E1 · Seller progress | Onboarding success/review/failure | 1. Exercise each state. 2. Check status and retry controls. | Plain-language state and safe next action; under review is not presented as ready. | Not run | | E2 · Buyer clarity | Single-seller cart | 1. Review product, merchant identity, totals, and confirmation. | Correct seller/product throughout; payment status is server-backed. | Not run | | E3 · Navigation | Delayed seller/status/script response | 1. Leave during onboarding/setup. 2. Return. | No late UI updates or duplicate active checkout; seller form cleans up and can reopen safely. | Not run | | E4 · Access/mobile | Keyboard, screen reader, narrow viewport | 1. Open/close seller form and buyer checkout. 2. Verify merchant controls. | Usable focus, status announcements, and recovery controls; record Bolt-owned UI issues separately. | Not run | | E5 · Uncertain payment | Fail buyer status endpoint after payment | 1. Observe error. 2. Recover the existing order. | No false success, raw exception, or invitation to blindly pay again. | Not run | ## 4. Additional launch requirements [#4-additional-launch-requirements] | Test | Input | Steps | Expected output | Result | | -------------------------- | -------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- | ------- | | L1 · Fees/allocations | Real commissions, shipping, discounts, multi-seller if offered | 1. Run offered combinations. 2. Reconcile allocations. | Seller and marketplace amounts match the approved fee policy; fixture-only sample is not launch evidence. | Not run | | L2 · Payout settlement | Approved bank setup and agreed payout schedule | 1. Confirm seller eligibility and payout configuration with Bolt. 2. Reconcile actual settlement evidence. | Expected seller receives the expected net amount; payment completion alone does not pass this test. | Not run | | L3 · Lifecycle/concurrency | Two simultaneous checkouts; refund/void; fulfillment | 1. Exercise each supported operation. 2. Reconcile buyer, seller, and marketplace records. | No duplicate charges/fulfillment; refunds and fees settle to the correct parties; merchant recovery works. | Not run | ## Completion gates [#completion-gates] | Gate | Required evidence | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------ | | Quickstart verified | All Q cases pass in the real sandbox, including merchant-owned integration work. | | Ready for launch review | All Q, F, E and applicable L cases pass; no required Blocked or Not run cases. Record exclusions with a reason and obtain technical/experience-owner review. | | Failed or blocked case | Record actual output, issue/owner, and retest evidence. A successful payment does not excuse a broken shopper or seller experience. | Use **Pass**, **Fail**, **Blocked**, **Not run**, or **Not applicable** with a reason. A build or mocked test result does not verify production processing, delivery, or settlement.