Marketplace AI app rescue — Stripe Connect, payouts, trust

The escrow layer is the piece AI tools always skip, and it is the piece that decides whether the marketplace can survive a dispute. A real escrow flow is a state machine with five distinct states — pending, held, released, refunded, and disputed — plus an immutable ledger that records every transition. The buyer's payment lands in held, a timer or a delivery-confirmation event moves it to released, and only then does a Transfer fire to the connected seller account. Disputes reverse the state without losing the audit trail.

The piece AI tools miss is the ledger. Every state change gets a row in a payments_ledger table with the transaction ID, the Stripe event ID, the prior state, the new state, the actor, and an immutable timestamp. The ledger is append-only — there is no update path and no delete path. Reconciliation runs against the ledger, not the transactions table, so a month-end close can be reproduced from the event stream if the application database is ever rebuilt. For a marketplace supabase developer rescue this means a new table with RLS, a Postgres trigger to enforce append-only, and a reconciliation job that runs nightly.

The payout pipeline is the second state machine. Transfers fire from the held-and-released balance to the connected account on a schedule — daily, weekly, or manual depending on the marketplace rules. Every Transfer carries an idempotency key so a cron retry cannot create duplicates. Every Transfer emits a payout.paid webhook that records the ledger entry. Every failed Transfer triggers a review task in the ops queue rather than silently stalling. A database optimization expert usually owns the ledger schema on a rescue this size.

A marketplace loses money on disputes when the refund path and the payout path are not linked. The classic failure: the buyer disputes, the platform refunds, but the seller has already been paid out — and the platform has no reserve held against the connected account to claw back. The result is a direct PnL hit plus the $15 Stripe chargeback fee. We fix this by wiring the dispute flow into the escrow state machine from day one.

For a dispute before payout, the fix is clean. The held balance reverses, the Transfer never fires, and the ledger records the full path. For a dispute after payout, we wire Stripe's transfer_reversal API against the connected account. If the connected account has enough balance, the reversal clears immediately. If it does not, the reversal queues and the platform balance takes the hit — with a manual ledger entry that tracks the seller's outstanding debt for future payouts. This is the spot where AI-generated code goes silent and the platform eats every chargeback. A Stripe integration expert rebuilds this surface first on every marketplace rescue.

Refunds have to trigger inventory restocks, listing reactivations, and review-window resets. The refund API call is one line; the side effects are the hard part. We ship this as a refund_events table with handlers for inventory, listing state, and reviews, each idempotent on the Stripe event ID. A single refund webhook replayed ten times produces exactly the same end state as one run. This is the same pattern from the ecommerce rescue, applied to the marketplace-specific surface.

Every marketplace founder with a broken AI-built platform asks whether they should have picked Sharetribe or Bubble instead. The honest answer depends on three inputs — the transaction complexity, the listing model, and whether the marketplace is the product or a feature of a larger product. The decision is rarely close once the inputs are written down.

A custom build wins when the transaction flow is non-standard: auctions with timed bids, subscription-based marketplaces where listings renew on a cadence, or platforms with negotiated pricing between buyer and seller. It also wins when the listing model is rich — rentals with availability calendars, services with duration and location matching, or goods with complex variant axes. For those, Sharetribe fights you every step of the way. An airbnb-style app developer build is almost always custom for this reason.

Sharetribe or the newer alternatives (Tradly, Marketplacer, Nautical) win when the marketplace is a rental or goods platform with a standard booking or cart checkout, when the team is one person, and when the admin UI needs to be fully operable by a non-technical founder. The total cost of running on Sharetribe across year one lands lower than a custom build if you fit the shape. The moment you need a custom dispute flow, a custom payout schedule, or a white-label buyer app, you will migrate off — which is a six-month project.

Bubble is almost never the right answer for a marketplace past the first 100 transactions per month. The Connect integrations are shallow, the escrow support is effectively zero, and the performance curve breaks down on complex queries. We have migrated two marketplaces off Bubble in the last year; both were pre-Series A and both hit the same ceiling at roughly $40k MRR. The middle path — keep the AI-built custom codebase, rescue the payments spine — is what we recommend for roughly four in five of the marketplace founders who send us a repo.

We have rescued a dozen marketplace platforms in the last year. Two recent write-ups cover the Connect and escrow failure modes in detail: the B2B SaaS escape from Bolt to Next.js write-up, which is a B2B wholesale marketplace with a complex payout schedule, and the Fintech MVP rescued from Lovable study, which includes the audit-log and RLS patterns that show up on every marketplace rescue.

A marketplace rescue engagement is the longest of our vertical rescues. The scope is larger, the testing surface is broader, and the production cutover is more sensitive because real seller payouts are already on the schedule. We quote 2 to 6 weeks, fixed price, depending on which phases are in scope.