Marketplace architecture for two-sided platforms
Marketplace architecture has three hard parts that ordinary SaaS doesn’t: money that belongs to someone else passing through your system, strangers who need a reason to trust each other, and search that decides which side of the market gets seen. Get those three right and most of the rest is a normal web application.
I led the architecture of Indiemaker, a platform for buying and selling side-projects and micro-SaaS with escrow built in, and architected the backend and payment integrations for BLU Loyalty, an enterprise loyalty platform with 9M users. I work hands-on with marketplace teams, starting with a two-week sprint.
Marketplace payments: whose money is it?
The moment you collect money from a buyer and pay some of it to a seller, you’re handling funds that aren’t yours. That changes the design:
- Use a platform payments product such as Stripe Connect or an equivalent from your provider. They handle seller onboarding, identity checks and payouts, and in many setups keep you out of holding customer funds yourself. Which account type and charge model fits depends on how much of the seller experience you want to own – check the provider’s documentation and, where money is held, take legal advice.
- Model the funds flow before writing code. Who is charged, when the platform fee is taken, when the seller is paid, who absorbs the processing fee, and what happens on refund or chargeback after the seller has already been paid.
- Escrow is a state machine. Funds captured, held, released on confirmation or timeout, refunded on dispute. Each transition logged, each one triggered by a specific event, none of them editable by hand without an audit trail.
- Keep an internal ledger of what each seller is owed, and reconcile it daily against the provider’s balance and payout reports.
There’s a longer technical walkthrough in marketplace payments, and the general principles are in payment system architecture.
Trust and safety from day one
Fraud finds a marketplace as soon as there’s money to extract. The basics I put in place before launch:
- Verification proportional to risk. Email and phone for buyers; identity and bank verification for sellers before their first payout, not their first listing.
- Payout delays for new sellers, released as they build a track record.
- A moderation queue with reasons, reviewer and outcome recorded, so decisions are consistent and appealable.
- Signals stored as data – account age, dispute rate, refund rate, velocity of new listings – so rules can be added without a deploy.
- Messaging that stays on-platform where possible, because off-platform deals are where both fraud and fee leakage happen.
Search and matching
Search is your marketplace’s storefront, and ranking is a product decision as much as a technical one. Start with PostgreSQL full-text search plus filters on structured attributes; it goes further than most teams expect. Move to a dedicated search engine when you need typo tolerance, faceting at scale or relevance tuning that’s painful in SQL.
Whatever you use, keep the listing data model clean: structured attributes buyers actually filter on, not everything stuffed into a description field. And decide early how new sellers get visibility, or your ranking will only ever show the sellers who were there first.
Two-sided marketplace development: what to build first
Most marketplaces launch with too much software. The liquidity problem – enough supply that buyers find something, enough buyers that sellers stay – is solved by operations and marketing, not features. Early on I’d build listing creation, search, checkout with split payments and a basic dispute flow, and do everything else manually: onboarding calls, curated homepages, refunds from the provider dashboard.
Off-the-shelf marketplace platforms are a reasonable way to test demand. Move to custom code when your transaction model, trust rules or fee structure stops fitting the template.
Consultant or marketplace development company?
If you have a validated model and a clear spec, a marketplace development company can supply the team to build it. If you need someone to design the payments flow, the trust model and the data architecture – or to check what an agency has proposed – that’s where I fit. I often work alongside an in-house team or agency as the technical lead who owns those decisions. For payments-heavy work outside marketplaces, see fintech consulting.
Questions
What is marketplace architecture?
Marketplace architecture is the technical design of a platform connecting buyers and sellers. Beyond a normal web app, it covers split payments and payouts, escrow and disputes, seller verification and fraud controls, listing data models, and search and ranking that balances both sides of the market.
How do marketplace payments work?
Usually the buyer pays the platform through a payment provider’s marketplace product, the platform keeps its fee, and the rest is paid out to the seller, sometimes after a holding period. The provider handles seller verification and payouts; the platform tracks what each party is owed and reconciles it.
Should we build escrow ourselves?
Build the escrow logic, not the money holding. Your code manages the state – held, released, refunded, disputed – while a regulated payment provider or escrow partner actually holds the funds. Holding customer money yourself usually brings licensing obligations; take legal advice before going that way.
When should a marketplace move off a no-code or template platform?
When the template starts dictating your business model: you can’t express your fee structure, trust rules or transaction flow, or fees and limits are eating margin. Validate demand first, then rebuild custom with a clean data model rather than migrating piece by piece.
Designing or fixing a marketplace?
Tell me how money and trust flow between your buyers and sellers. In a two-week sprint we’ll map it, fix the riskiest part and plan the rest.
GMT+2 · Full EU overlap · US East mornings