Test your Marketplace Connect integration
Verify the quickstart, failure recovery, and the experience your app or store controls.
Run these cases against the Marketplace Connect quickstart. Copy the tables into your test report and attach redacted evidence. Every case starts Not run.
| 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.
| 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 |
| 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 |
| 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 |
| 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 |
| 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.
