Stripe Connect for Marketplaces: Architecture Patterns That Actually Scale

Stripe Connect is a great product. It is also a great way to ship a marketplace that breaks the first time a refund happens at the same instant as a payout, or the first time a webhook is processed twice, or the first time the platform decides to take a flat-rate fee on a discount-priced item.

I have built marketplaces on Connect for service platforms, two-sided rental businesses, and licensing systems. The architecture decisions made in the first two weeks determine whether the marketplace scales or burns 20% of engineering time on payment-related bugs for the next two years. This guide is the pattern set.

For the foundational Stripe build, see our Next.js Stripe integration guide. For the deeper service offering, see our Stripe integration service.

Three flows. Pick one and commit; mixing them creates support nightmares.

• Direct charges: Buyer charges the connected account directly. Marketplace takes an application_fee_amount. Best for marketplaces where the seller is the merchant of record (think Etsy).
• Destination charges: Buyer charges the platform account. Funds get transferred to the connected account. Marketplace is the merchant of record. Best for service marketplaces where the platform handles support and refunds.
• Separate charges and transfers: Charge first, transfer later. Best for marketplaces with delayed delivery, escrow, or complex multi-party splits.

The trap: switching from destination charges to direct charges later means a Stripe Connect migration. Pick once.

Webhooks are where marketplaces go wrong. The pattern that works at scale:

1. Webhook handler validates the signature, stores the raw event payload to a `stripe_events` table, returns 200. Done. That is the whole handler.
2. A background worker pulls from `stripe_events`, processes one event at a time, and updates application state.
3. Each event is processed at most once. Dedupe by `event.id`. Use a UNIQUE constraint or a Redis lock — application-layer checks alone will race.
4. Failed processing throws back to the queue with exponential backoff. After N retries, alerts page on-call.
5. `stripe_events` rows live for 90 days minimum. Long enough to replay if you find a bug.

The handler returning 200 in under 100ms is non-negotiable. Stripe retries on slow responses, and slow responses are how the same event gets processed three times in production.

The single most important job in a Connect marketplace is the nightly reconciliation. It compares Stripe's view of the world (charges, refunds, payouts, application fees) against the marketplace's view of the world (orders, items, payouts owed). Drift surfaces here before it surfaces in a seller support ticket.

The reconciliation job does three things:

1. Pull every charge from Stripe for the last 7 days. Match against orders. Flag mismatches.
2. Pull every payout. Match against expected payouts. Flag amount drift over $0.01.
3. Pull every refund and dispute. Verify the marketplace has recorded a corresponding adjustment.

We have caught webhook drops, double-charge bugs, and incorrect application_fee calculations in this job for every marketplace we have shipped.

Stripe defaults to a 2-day rolling payout for US accounts. Marketplace operators usually want longer holds because they want time to detect fraud, process refunds against settled balances, or batch payouts weekly. Connect lets you set a custom payout schedule per connected account.

• Daily: Default. Best seller experience. Highest refund-against-paid-out risk.
• Weekly: Common for service marketplaces. Predictable for sellers, gives the platform a 7-day window to handle disputes.
• Monthly: Best for marketplaces with high chargeback risk or seasonal seller churn.
• Manual: Best for marketplaces with explicit escrow or milestone-based payouts.

Document the payout cadence in the seller agreement. Changing it later is a top-three support load.

1. Synchronous webhook processing. Long-running handlers cause duplicate events.
2. No reconciliation job. Drift accumulates silently until support tickets pile up.
3. Storing Stripe IDs as the primary key. Use UUIDs internally; Stripe ID is a foreign reference.
4. Hard-coded application_fee logic. Fee rules will change. Move them to a config table.
5. No idempotency keys on charge creation. Retry storms produce duplicate charges.
6. Mixing destination charges and direct charges in the same product. Pick one model.
7. Letting sellers self-serve payout schedule changes. Audit and approval queue.
8. No dispute UI in the seller dashboard. Sellers cannot respond, marketplace eats the loss.

Take rate is the lever that determines whether the marketplace is a business. The 2026 benchmarks:

• Service marketplaces (Uber, Fiverr-like): 20 to 35% take
• Two-sided product marketplaces (Etsy-like): 5 to 15% take
• B2B SaaS marketplaces (app stores, integration directories): 15 to 30% take
• Specialty financial marketplaces (lending, securities): 1 to 5% take
• Subscription-driven marketplaces (membership-based): subscription plus 0 to 10% take

Estimate your unit economics with the Stripe cost calculator. The right take rate is the one that funds platform engineering plus seller acquisition without pricing the marketplace out of the seller's willingness to pay.

A representative engagement: a two-sided service marketplace connecting independent contractors to small business buyers. Express accounts, destination charges with application_fee, weekly payouts, dispute UI in the seller dashboard, and Stripe Tax integration. 14 weeks end-to-end on Next.js plus Postgres plus Stripe Connect. Engineering cost: $145K including dispute workflows and reconciliation job.

For analogous engagements, see the J5 Sales OS case study and the Hobbspeak case study. For broader marketplace context, see our e-commerce industry page and SaaS industry page.