Engineering for Marketplaces — More Transactions, Fewer Disputes
Stripe Connect split payments, fraud at signup, and supply-demand matching — engineered for more completed transactions and fewer disputes hitting your platform balance.
The problem
Marketplaces concentrate every hard problem in B2B SaaS into one product. You're running two products at once — one for the supply side, one for the demand side — and they fail in different ways. The buyer side fails as a conversion problem: a checkout that doesn't complete, a search that returns nothing useful, a payment method the customer doesn't trust. The seller side fails as a trust problem: a payout that lands a week late, a dispute that eats the seller's margin, an onboarding flow that asks for a tax ID before the seller has decided whether your platform is worth the effort.
Connect account type locks in dispute liability
In between sits the part most founders underestimate: the money flow. Stripe Connect is the right tool for split payments, but it ships with three account types that each push dispute liability and onboarding control to different parties — for Express and Custom accounts the platform is liable for fraud and dispute liability, not the connected seller. Picking the wrong one costs a rewrite.
Chargeback reversal fails on negative balances
On destination charges and separate-charges-and-transfers, Stripe automatically debits your platform balance when a chargeback lands, and your only recovery path is reversing the transfer to the connected account — which silently fails if their balance is already negative. When a connected account's balance is negative, payouts are paused until it goes positive again, which creates a queue of unhappy sellers nobody on the product team thought to design for.
Two-sided fraud surface
Then there's fraud. Two-sided platforms get attacked from both sides at once — a fraudster creates the buyer account, creates the seller account, transacts with a stolen card, and pulls the platform's money out as a payout before the chargeback hits the original cardholder's statement. The platform eats the loss, and the worst version of this isn't one attacker — it's a small number of repeat attackers who learn your specific weak points faster than your trust and safety hires can.
Match rate flying blind
Meanwhile the metric that actually decides whether the marketplace survives — match rate, the rate at which buyers find sellers and vice versa, which Andreessen Horowitz names as the core measure of marketplace health — usually isn't even instrumented. Founders see GMV growing and assume liquidity is healthy until a cohort report shows that 60% of buyers leave without ever completing a match.
What changes for your business
What senior engineering buys a marketplace startup is fewer money leaks, faster onboarding for both sides, and a matching system the product team can actually tune.
Connect account model picked deliberately
The money flow is the highest-leverage place to start. The right Stripe Connect architecture isn't a single choice — it's a decision made deliberately about who owns the seller relationship, who owns disputes, and how much of the seller dashboard lives inside your product. Most founders pick Express because it looks like the middle option, then discover six months in that they need Custom-level payout control and end up rewriting. A short upfront design session usually prevents that rewrite.
Webhook reconciliation and dispute state machine
Once the account model is right, the work is webhook reconciliation that handles out-of-order events, dispute flows modeled as a proper state machine, and a payout layer that respects both Stripe's compliance holding periods and the platform-controlled trust holds for new sellers. We've built exactly this reconciliation pattern across seven production apps inside BFEAI — Stripe subscription plus dual-pool credit ledger reconciled against webhooks, with the same primitives a marketplace needs.
Layered fraud defense
Fraud is layered, not a single vendor decision. At signup, identity signals (email reputation, device fingerprint, payment-method risk score, IP geography) feed deterministic rules a trust and safety team can read and edit. For new sellers, a graduated payout schedule — funds held a few days longer than normal until trust signals accumulate, then loosened — catches the bulk of payout fraud without insulting legitimate sellers. For transaction-level fraud, vendor scoring (Sift, Persona, Sardine) plugs in at the points it actually earns its fee, not as a black box wrapped around every action. The goal is to give the trust and safety team explainable decisions, not a vendor lock-in.
Match rate as the tuning metric
Matching and search are the third pillar. For most marketplaces under roughly $50M GMV, Postgres full-text search plus a thoughtful ranking layer — recency, seller quality score, distance, fill rate — goes further than founders expect. The ranking weights live as configuration so the product team can run match-rate experiments without a deploy. A dedicated search index (Typesense, Meilisearch, OpenSearch) gets added when the data shape or query volume justifies it, not as a reflex. The metric every change gets measured against is match rate, instrumented per cohort, surfaced where the founder sees it daily.
The outcome is straightforward. More completed transactions per visitor, fewer disputes hitting your platform balance, fraud caught before money has left the system, and a matching system the product team can tune without burning senior engineering capacity on every experiment.
What ships in a typical engagement
Engagements are bounded and concrete. The most common shapes:
- Architecture audit, two to four weeks. A written engineering memo: where the Stripe Connect model will fight you at scale, where the fraud surface is exposed, where matching is leaving money on the table, what we'd ship first, and what we wouldn't touch. The memo is yours whether or not you continue.
- Stripe Connect rework. Move from a single-product Stripe integration or a misfit Connect account type to a flow that handles split payments, refund and chargeback reversal, payout trust holds, and out-of-order webhooks without losing money. Includes a reconciliation report against Stripe so finance can stop spreadsheet-matching.
- Fraud and disputes pipeline. Layered signup checks, graduated payout schedule for new sellers, webhook-driven dispute state machine, and a recovery report that surfaces unrecovered losses to finance weekly. Vendor integrations (Sift, Persona, Sardine) wired in at the points they earn their fee.
- Search and matching engine. Postgres full-text plus a configurable ranking layer, with match rate instrumented per cohort. Optional upgrade path to Typesense, Meilisearch, or OpenSearch when the data shape demands it.
- Migration off a no-code marketplace prototype. Lift a Sharetribe, Arcadier, or Bubble-backed MVP onto a Postgres, queue, and Stripe Connect runtime you own. Preserve the live feature set, port listings and identity, replumb payments, cut over without losing in-flight transactions.
- We won't own KYC, AML, or money-transmitter compliance. Stripe Connect, Adyen for Platforms, and similar processors carry most of that burden by design, and your legal and compliance leads own the rest. If you're considering a custodial wallet model or anything that looks like holding customer funds in your own name, you need a fintech compliance specialist, not just engineering.
- We won't write the trust and safety policy itself. Which seller categories you allow, how you adjudicate disputes between buyers and sellers, how aggressive your payout trust holds should be — those are business decisions your trust and safety lead owns. We'll wire what they specify, with audit logging on every decision branch and explainable rules they can edit.
- We won't build a custom search engine when an off-the-shelf one fits. Typesense, Meilisearch, OpenSearch, and Algolia each have their place. If one of them fits your data and query patterns, that's what we'll wire in. Building a search engine from scratch is rarely the right answer for a marketplace under $100M GMV.
- We won't take a single-engineer dependency you can't recover from. Code is documented, infrastructure is described in version control, and an internal engineer can take the work over without a knowledge-transfer crisis. The goal is to leave your team stronger than we found it, not to make ourselves load-bearing.
Every engagement ships a short engineering memo at the end: what we built, what's left, where the next failure modes are likely to surface. The handoff is the deliverable as much as the code.
What we won't take on
A few hard lines, stated up front so the engagement doesn't surprise anyone:
Outcomes you should expect
What this delivers
- More completed transactions per visitor — fewer drop-offs at signup, search, checkout, or payout setup
- Fewer payment disputes hitting your platform balance, with reversal and recovery flows that finance can actually audit
- Fraud caught at signup and at first transaction, before money has left the system
- Supply-demand matching logic your product team can tune without a senior engineer in the loop for every change
- Stripe Connect onboarding and payout flows that pass a CFO review and an investor diligence check
Industry data
By the numbers
Total third-party GMV of the top 100 online marketplaces is projected to grow 10.1% to $3.2 trillion in 2025, according to Digital Commerce 360's Global Online Marketplaces Database.
Stripe Connect offers three account types — Standard, Express, and Custom — and for Express and Custom accounts the platform is liable for fraud and dispute liability, not the connected seller.
On destination charges and separate-charges-and-transfers, Stripe automatically debits the platform balance for the disputed amount and fee, and the platform can attempt to recover funds by reversing the transfer to the connected account.
When a connected account's Stripe balance is negative, payouts to its bank or debit card are paused until the balance becomes positive, and Stripe first assigns refunds and chargebacks to the account the original charge was made on.
Andreessen Horowitz frames match rate — the rate at which buyers can find sellers and vice versa — as the core measure of marketplace health, alongside time-to-match, GMV, and take rate.
Live in production today
The same engineering, shipped in production at BFEAI.
I'm co-founder & CTO of Be Found Everywhere (BFEAI), a 7-app AI SaaS platform running today. The work I deliver for clients is the work I do every week on my own platform.
7
Production apps
200K+
Keywords generated
1,500+
AI scans run
7,000+
Sites automated
Common questions
What buyers ask before reaching out
Why senior engineering instead of a typical agency for a marketplace build?
Marketplaces concentrate the hardest parts of B2B SaaS — multi-party billing, mixed-trust identity, search relevance, asynchronous payment flows — into one product. A senior engineer who has shipped Stripe webhook reconciliation, multi-tenant Postgres with row-level security, and queue-based out-of-order event handling already knows where the money leaks are. Cheaper teams typically catch those leaks in production, often after the first chargeback wave.
Have you built a marketplace before?
BoostFrame and BFEAI are not marketplace products. What transfers is the architecture: 7 production apps share a multi-tenant Postgres with row-level security, billing handles a Stripe subscription plus a dual-pool credit ledger reconciled against webhooks, and cross-app SSO runs on custom JWT with refresh-token rotation. Those are the same primitives a two-sided marketplace needs for separating buyer and seller data, holding funds before payout, and unifying identity across web, mobile, and admin surfaces.
Which Stripe Connect account type should we use — Standard, Express, or Custom?
It depends on who you want to own dispute liability and how much of the seller experience you want to control. Standard pushes onboarding, the dashboard, and dispute handling to the seller — fastest to ship, but the seller sees Stripe branding and you have less control over payouts. Express keeps the seller experience inside your product but makes your platform liable for fraud and disputes. Custom means the seller never sees Stripe at all, with the most integration effort. In our experience, most marketplace founders pick Express, discover later that they wanted Custom-level payout control, and end up rewriting. A short architecture call usually saves that rewrite.
How do you handle fraud at signup on a two-sided marketplace?
Two-sided marketplaces are uniquely exposed because a fraudster can create both the buyer and seller account, transact with a stolen card, and pull the platform's money out as a payout before the chargeback hits. The defense is a layered identity check at signup (email reputation, device fingerprint, payment-method risk score), a graduated payout schedule for new sellers (funds held until trust signals accumulate), and out-of-band review for transactions that match collusion patterns. We design these as deterministic rules the trust and safety team can read and edit, not as a black-box ML score. Brand-name fraud vendors like Sift, Persona, and Sardine plug in where they earn their fee.
What does a first engagement typically look like?
Usually a two-to-four week architecture audit or a single bounded build — a Stripe Connect rework, a supply-demand matching engine, a fraud and dispute pipeline, or a migration off a no-code marketplace prototype. We write a short engineering memo on what we found, what we'd ship, and what we won't. From there, we either continue into a build phase or hand the memo to your internal team.
Can you help us migrate off Sharetribe, Arcadier, or a Bubble marketplace prototype?
Yes — moving a working no-code or low-code marketplace onto a Postgres, queue, and Stripe Connect runtime you actually own is a common engagement. The work is bounded: preserve the live feature set, port listings and identity, replumb payments through Stripe Connect with proper webhook reconciliation, and cut over without losing in-flight transactions. We'll be honest about whether your current GMV justifies the migration cost yet — sometimes the answer is to stay on the no-code platform another six months and revisit.
How do you handle disputes and refunds across split payments?
On destination charges and separate-charges-and-transfers, Stripe debits your platform balance for the disputed amount automatically. Recovering the seller's portion means reversing the transfer to the connected account — which fails silently if their balance is negative. We design dispute flows as a state machine: the chargeback arrives by webhook, the system reverses the transfer where possible, logs the recovery gap where it isn't, and surfaces unrecovered losses to finance weekly. Without that, marketplaces typically discover six months in that the disputes column on the P&L is materially larger than they thought.
What about search relevance and supply-demand matching?
For most marketplaces under roughly $50M GMV, Postgres full-text search plus a thoughtful ranking layer (recency, seller quality score, distance, fill rate) goes further than founders expect. We add a dedicated search index (Typesense, Meilisearch, or OpenSearch) when the data shape or query volume justifies it, not before. The ranking logic gets exposed as configuration so the product team can tune weights against match-rate cohorts without a deploy. Match rate is the metric a16z names as the core measure of marketplace health, and it's the one we instrument first.
Ready to see if this is a fit?
A 15-minute call. No deck, no slides. We talk about what you're shipping and where engineering is the bottleneck. Either way, you walk away with a senior engineer's read on your situation.