This pack has not completed a verification run yet, so nothing is published here. When the harness runs it, this space becomes the measured record: pass rate as M of N clean-scaffold runs on a pinned model, per-run token cost and wall time, per-check results, locked dependency versions, and whether the scaffold was left pristine. No pass rate, token cost, or deploy is claimed until then.
Marketplace Payouts & Connected Accounts
complex-universaldraftTwo-sided marketplace money on Stripe Connect Accounts V2 — charge-type architecture, hosted onboarding/KYC, fulfillment holds and payout timing, refunds and disputes against connected accounts, negative balances, and the US 1099 reporting surface — as a receipt-backed build pack for your own coding agent.
How install works
- Accounts
- Tools
About 20–30 minutes, almost all of it account signups and installs — none of it billed to your Claude plan, and none of it requiring a Stripe account with Connect enabled (that comes later, at live cutover).
Full setup walkthrough ships in the zip after purchase.
Marketplace money on Stripe Connect is four irreversible decisions wearing a trench coat: which charge model you use, who is merchant of record, who eats a chargeback, and whether you can hold funds at all. Get one wrong and the fix is not a refactor — it is re-onboarding every seller under a different agreement. This pack is a receipt-verified Next.js + Prisma + Stripe **Connect Accounts V2** spine — charge-model architecture, hosted KYC onboarding, fulfillment holds, proportional refunds, dispute and negative-balance handling, a five-bucket money ledger that provably conserves, and a US 1099 reconciliation surface — that your own coding agent builds in a few sessions instead of you learning each of those four decisions from a support ticket. Verification is fully hermetic: 18 acceptance checks against a dummy Stripe key, locally-signed webhook payloads and a real Postgres 17 in Docker, with no Stripe account involved.
Example use cases
- **A services marketplace paying tradespeople after the job is signed off** — needs a fulfillment window between the buyer's card being charged and the plumber being paid, which rules out destination charges entirely and is the single decision most agent-built marketplaces get backwards.
- **A vertical B2B marketplace whose suppliers are small companies that cannot pass full card-payments onboarding** — recipient-only accounts can receive transfers but *cannot* take direct charges, a constraint that surfaces halfway through onboarding if nobody checked it first.
- **A rentals or equipment platform that already shipped destination charges** and has now discovered it needs a damage-claim window before the owner is paid — this pack is the architecture it should have started from, and the decision table explains exactly what the migration costs.
- **A US creator marketplace crossing 200 payouts a year to one seller**, suddenly inside 1099-K territory with no idea whether the reportable amount is gross or net (it is gross, before your commission, before Stripe's fees, before refunds).
- **A solo founder whose agent confidently wrote `stripe.accounts.create({type: 'express'})`** — the shape Stripe deprecated in December 2025 — and who wants the current Accounts V2 shape as a tested contract rather than as a second opinion.
Why this pack
| Bare agent, no pack | This pack ($199 one-time) | Sharetribe (marketplace SaaS) | Hand-rolling it yourself | |
|---|---|---|---|---|
| **Correctness risk** | High, and specifically these four: writing the pre-December-2025 Accounts shape (`type: 'express'`, `capabilities.transfers`, `charges_enabled`) with total confidence, because that is what the training data contains; picking destination charges and only later discovering a hold is impossible under them; hand-rolling a KYC form; and forgetting that `reverse_transfer` and `refund_application_fee` default to **false**, so a refund pays the buyer while the seller keeps the money | Pre-solved — each is a numbered, tested architecture decision (D1/D3, D2, D4, D10), and the money ledger's conservation law fails the build if any path invents or loses a cent | Low on marketplace mechanics — Connect is already wired and battle-tested. The risk moves rather than disappearing: it becomes "does their model match my business," and you cannot inspect or test their money paths | High until you personally get burned by each one, which is the usual way this gets learned — and disputes and negative balances are learned expensively |
| **Cost** | Token spend plus rework, and the rework here is re-onboarding sellers | $199 once | Recurring subscription (their published entry tier is around $99/mo, with higher tiers above that), forever, on top of Stripe's own fees | Your own time at your hourly rate, most of it spent reading Stripe docs before writing a line |
| **Time to correct marketplace money** | Unknown and stochastic — and the failure mode is *silent*: a marketplace with the wrong charge model works perfectly until the first refund or the first chargeback | ~3–4 agent sessions on a $20/mo plan (see the build budget in `PRD.md`) | Fastest of all four if their product fits you — it is a finished product, not a library | Engineering estimate: 3–6 weeks for one developer to reach equivalent correctness, based on this pack encoding 22 numbered architecture decisions, most of which are normally learned one incident at a time |
| **Lock-in** | None, but no guarantee it built the right thing | None — plain Next.js/Prisma/Stripe code you own outright; Stripe is the only vendor dependency and you would need it regardless | Real, and the deepest kind: your marketplace *is* their product. Your listings, users, transactions and money flows live in their schema | None, same as this pack, minus the tests and minus the weeks |
**The honest version of the comparison above:** if what you want is a **marketplace product** — listings, search, seller profiles, messaging, reviews, a storefront — **Sharetribe already has Connect wired and is the better choice, and you should buy that instead of this.** It is a finished marketplace; this is not. This pack is for the buyer who is building marketplace *mechanics inside a product they already own* — a payouts layer in an existing SaaS, a two-sided flow inside a vertical tool, a payments spine that has to live in your codebase and your database because the rest of your product already does. If a hosted marketplace would do the job, the hosted marketplace wins on every axis except lock-in, and it is not close.
This pack is currently **`status: draft`** — it has not been through the OneShot harness yet. When it has, its receipt will report the pass rate honestly as **M of N** verification runs on the pinned model matrix, along with measured token and dollar figures. Agent builds are stochastic; no claim here is "always one-shots," and nothing on this page is a measured number unless it says so.
Scale envelope
The shipped architecture is one Railway-hosted Postgres 17 plus one Next.js instance, with Stripe as the system of record and the database holding four small tables (`Seller`, `Order`, `LedgerEntry`, `ConnectEvent`).
- **What it comfortably handles:** engineering estimate from the write shape, not a load-tested benchmark — on the order of **10,000–50,000 orders per month across a few thousand sellers**. The reasoning: an order writes about seven ledger rows across its whole life (three at capture, two for the Stripe fee, two at release) and generates three to four webhook events. At 50,000 orders a month that is roughly 350,000 short single-row inserts and ~175,000 webhook transactions — an average of one every fifteen seconds, with bursts. Each webhook is one short interactive transaction, not a job. A single small Postgres instance is not the constraint at this volume.
- **First ceiling — and it is financial, not technical: platform float.** Under this pack's charge model, buyer funds sit on *your* Stripe balance for the whole hold window. With the default 7-day hold, you are permanently carrying roughly **seven days of gross merchandise value** on your Stripe balance — at $10,000/day GMV that is about $70,000 of float you cannot spend. This is a deliberate consequence of the architecture (it is also what makes a fulfillment hold possible at all), and it is the number to model before you launch, not after.
**Upgrade path:** shorten `HOLD_DAYS` in `src/config/marketplace.ts`, or move to destination charges and give up holds entirely — the decision table in `ARCHITECTURE.md` D2 spells out exactly what that trade costs.
- **Second ceiling — release batching against Stripe's write rate limits.** One release is one `POST /v1/transfers`. If you release in a nightly batch you will saturate Stripe's write throughput long before Postgres notices, and the failure looks like rate-limit errors on a job that worked fine at half the volume.
**Upgrade path:** spread releases across the day (each order already carries its own `holdUntil`, so a per-minute sweep is a smaller change than a nightly batch) rather than raising concurrency against Stripe.
- **Third ceiling — Postgres connections**, and it shows up from customer-facing page and API traffic rather than from webhooks, once you scale the Next.js app past a couple of instances. Postgres's own default is `max_connections = 100`.
**Upgrade path:** a connection pooler (PgBouncer, or Railway's own pooling) in front of Postgres, then a vertical Postgres upgrade. No application changes: the ledger is append-only and nothing assumes a connection count.
- **What it does not scale into without new work:** multiple sellers per order, multi-currency, and cross-border payouts. All three are explicit non-goals in `PRD.md` because each changes the money model enough to need its own verification, and an unverified money path is worse than an absent one.
**What it costs to skip the pack:** not modelled here, deliberately. This pack has no receipt yet, so there is no measured build volume to reprice, and inventing one would break the same honest-economics rule everything else on this page follows. The sibling `saas-billing-tax` pack — same shape, smaller surface — measured about $6.55 of tokens per verification run and models out at roughly $100–390 for an unguided top-tier-model build. This pack is larger. That is as far as the evidence goes today; the receipt will say the rest.
The reason to buy is not token arithmetic. It is that the four bugs named in the table above are *money* bugs in a system holding other people's money, and money bugs are found by sellers, buyers, and eventually your bank.
Target models
- claude-opus-5
- claude-sonnet-5
- claude-haiku-4-5
Supported stacks
- nextjs-prisma-postgres
node 24.18.1 next 16.2.12 react 19.2.8 react-dom 19.2.8 stripe 22.4.0 stripe-api-version 2026-07-29.dahlia prisma 7.9.1 @prisma/client 7.9.1 @prisma/adapter-pg 7.9.1 typescript 5.9.3 vitest 4.1.10 tailwindcss 4.3.3 @tailwindcss/postcss 4.3.3 shadcn 4.16.1 tailwind-merge 3.6.0 clsx 2.1.1 class-variance-authority 0.7.1 @types/node 24.3.0 @types/react 19.2.2 @types/react-dom 19.2.2 postgres 17.10
Estimated buyer token cost
850,000 tokens for one build pass (estimate, not a guarantee).
FAQ
What if the build fails?
Run `bash verify.sh` first — it prints `CHECK: <name> PASS|FAIL` per acceptance check plus the failing log tail, and `GETTING-STARTED.md` has a full failure→cause map keyed to those exact check names. If it still will not reach `VERIFY: PASS` after working through that map, that is an environment-reproducibility gap, not something to argue about in a support ticket. Full refund within 14 days of purchase if `verify.sh` fails on a supported configuration (the pinned stack and a model from the pack's matrix) — reply to your Stripe receipt email with the verify output or `FAILURE-REPORT.md` attached.
Do I need a Stripe account to build this?
No. The entire acceptance suite is hermetic: a dummy secret key, webhook payloads signed locally with stripe-node's own crypto, an injected fake Stripe client, and a real Postgres 17 in Docker. You need a Stripe account only at live cutover, and Connect specifically has to be enabled on it then — which requires a real business profile and Stripe's own review.
Which models and plan do I need?
Targeted at `claude-opus-5`, `claude-sonnet-5`, and `claude-haiku-4-5`, with tasks routed across all three by difficulty. A **$20/mo plan** (Claude Pro or Cursor's equivalent model access) is the budget the task graph is designed around; `PRD.md` estimates 3–4 agent sessions. Pro's binding constraint is prompt volume against its rolling window and weekly cap, not raw tokens, and Anthropic does not publish an exact figure, so treat that as an expectation rather than a guarantee. Because this pack is still `draft`, the model matrix is *targeted*, not yet verified — the harness confirms or trims it.
Why is this the pack where Accounts V2 matters so much?
Because Stripe changed the shape in December 2025 and every model's training data is dominated by what came before. An agent will write `stripe.accounts.create({type: 'express'})` and read `account.charges_enabled` with complete confidence; both are the superseded API, and Stripe now labels the Standard/Express/Custom account *types* deprecated in favour of controller-style properties and, in V2, `configuration` plus `defaults.responsibilities`. The pack's onboarding tests assert the current shape and assert the absence of the old one, so the mistake fails the build rather than failing in production.
Can I switch charge models later?
Not cheaply, and that is the point of the pack's central decision. The charge model determines who is merchant of record, who pays Stripe's processing fees, who is liable for chargebacks, which capability your sellers must pass onboarding for, and whether holding funds is possible at all. Changing it after launch means re-onboarding sellers under a different service agreement and rewriting every refund and dispute path. `ARCHITECTURE.md` D2 is a full decision table precisely so you make this choice deliberately, up front, with the consequences visible — including the case where the pack's own choice is wrong for you.
Does this make me compliant with 1099 rules?
No, and no code can. Stripe files the forms if you enroll in its Connect tax-reporting product (published pricing: $2.99 per form e-filed with the IRS, $1.49 per form e-filed with states, e-delivery free); you still owe W-9 collection, TIN-mismatch remediation, and any state filing outside the Combined Federal/State Filing program. What this pack builds is a *reconciliation surface*: gross volume per seller per calendar year, computed in your reporting timezone, with the federal $20,000/200 threshold and the sub-federal state thresholds flagged — so you can check Stripe's numbers before the forms go out. The filing obligations themselves are fenced in the manual checklist (M6, M8) and belong to you and your accountant.
Can I customize it after the build?
Yes. It is your code, not a hosted product. The PRD lists deliberate non-goals — multi-seller orders, multi-currency, cross-border payouts, Instant Payouts — as things this pack does not build so it stays a verifiable spine; add them afterward. Auth is a documented one-line stub (`src/lib/actor.ts`) meant to be replaced by a real auth system (see the companion `multitenant-auth-rbac` pack) without touching money logic.
Do I have to deploy on Railway?
No — you can deploy anywhere that runs Next.js and Postgres 17. Railway is prescribed because it is the stack this pack is verified and receipt-tested on (and its referral link, disclosed in `PRD.md`, is how OneShot partly funds verification); deploying elsewhere means the receipt no longer warrants your exact environment.
Why are the versions pinned so exactly (stripe 22.4.0, API `2026-07-29.dahlia`, not "latest")?
Because the receipt's warranty and the acceptance suite are both keyed to an exact, reproducible stack, and on this pack the Stripe API version is not incidental — it is the thing that decides whether the account shape in your code exists. A floating version is something the receipt cannot honestly verify against. `MIGRATION.md` is how you move off the pins when you choose to.
Prescribed services
- Railway — Railway referral credits
Disclosure: some links on this page are affiliate links. We may earn a commission if you sign up through them, at no extra cost to you. We only link to services the pack actually verified against.