💸What you are actually building
A normal e-commerce store takes money from a buyer and keeps it. A marketplace takes money from a buyer, holds part of it, gives most of it to a seller who may be in another state or country, keeps a commission, refunds on disputes, and produces tax documents for everyone involved. That is not a checkout feature — it is a regulated money-movement business wrapped around your product, and it is the single hardest subsystem in any marketplace build.
The hard part is not charging a card; Stripe, Adyen and a dozen others have made that a solved problem. The hard part is everything after the charge succeeds: who legally holds the funds, when the seller can withdraw, what happens when the buyer opens a dispute three weeks later, how your commission is calculated when a partial refund lands mid-payout, and what your ledger says about all of it when an accountant or auditor asks.
This guide walks the decisions in the order you will hit them: payment model, processor flow, escrow logic, compliance obligations, payout and take-rate mechanics, fraud, and finally cost. Where specifics depend on a provider, they are described factually as of writing — verify current terms before you commit.
The one-sentence version: never let marketplace funds touch a bank account you control unless you have legal advice confirming you are not acting as a money transmitter. Route funds through a processor that is licensed to hold them.
🧭Choose a payment model first — it decides everything downstream
Every marketplace payment architecture is one of three models, and the choice determines your regulatory exposure, your tax paperwork and your fraud liability before a line of code is written.
In the merchant-of-record model, you are legally the seller. You collect the full amount, you own the chargeback liability, you remit sales tax or VAT, and you pay the actual seller as a supplier. This gives maximum control over the buyer experience and is the model behind most digital-goods and services marketplaces, but it puts the compliance weight squarely on you.
In the platform-with-connected-accounts model — the Stripe Connect pattern, also offered by Adyen for Platforms and others — each seller has an account at the processor, funds are split at charge time, and the processor handles seller onboarding, identity verification and payouts. You stay out of fund custody entirely. This is the default choice for most goods and local-services marketplaces because it keeps you clear of money-transmission questions.
See how we built an e-commerce marketplaceStripe vs Adyen: a factual comparison
| Model | Who holds funds | Chargeback liability | Seller KYC | Tax forms | Typical fit |
|---|---|---|---|---|---|
| Merchant of record | You (via processor) | You | Light — they are suppliers | You remit sales tax/VAT | Digital goods, services, strong brand control |
| Connected accounts (Connect-style) | Processor, in seller accounts | Shared — configurable per charge type | Processor collects it | Processor issues 1099-K (US) where required | Goods, rentals, local services — the default |
| Direct buyer-to-seller | Seller directly | Seller | Minimal or none | You invoice commission; sellers self-report | Classifieds, lead-generation marketplaces |
🔄The Stripe Connect-style flow, described factually
Because the connected-accounts model is what most teams should build, it is worth being precise about how it works. The concepts below use Stripe Connect vocabulary because it is the most common implementation; Adyen for Platforms and Mangopay have equivalent constructs with different names.
First, account types. A Standard account is a full Stripe account the seller owns and manages — you have limited control but also limited liability. An Express account is Stripe-hosted onboarding with a lighter dashboard; you get more control over the flow while Stripe still collects KYC information and handles payouts to the seller bank account. A Custom account gives you full control of the experience via API, but you take on the integration work and a larger share of compliance responsibility. Most marketplaces start with Express: it is the middle point of effort and control.
Second, charge types. A direct charge is created on the connected account itself — the seller is the merchant, and your commission arrives as an application fee. A destination charge is created on your platform account and funds are transferred to the seller automatically, with an application fee retained. Separate charges and transfers means you collect the full amount on your platform account and transfer to sellers later, in whatever shape you choose — this gives the most control over timing (essential for escrow) but puts you closest to fund custody, and Stripe restricts this pattern in some configurations, particularly cross-border.
Third, onboarding. With Express or Custom accounts, the seller completes a hosted or embedded KYC flow — legal name, date of birth, address, tax ID, bank account — and the processor decides when the account is charges-enabled and payouts-enabled. Your system listens to account.updated webhooks and gates listing publication on those flags. Never let a seller transact before the processor confirms the account is enabled; retroactive verification failures on settled funds are miserable to unwind.
| Charge type | Funds land on | Commission mechanics | Control over timing | Notes |
|---|---|---|---|---|
| Direct charge | Seller account | Application fee transferred to you | Low — seller paid on their schedule | Seller owns the dispute; cleanest liability split |
| Destination charge | Your account, then auto-transferred | Application fee retained at transfer | Medium — transfer at charge time | Good default for goods marketplaces |
| Separate charges + transfers | Your account until you transfer | You keep the difference | High — you decide when funds move | Needed for true escrow; check regional restrictions |
Pick Express accounts plus destination charges as your starting architecture. It handles roughly 80 percent of marketplace shapes with the least compliance surface. Deviate only when a concrete requirement — like holding funds until delivery confirmation — forces you to.
🔒Escrow logic and the ledger you must build yourself
Escrow in a marketplace context means: buyer pays, funds are captured but not releasable to the seller until a condition is met — delivery confirmed, service completed, inspection window expired. No processor will run this business logic for you. The processor gives you primitives (capture now, transfer later, refund, reverse transfer); the state machine is yours.
Model it as an explicit state machine on the order, not as flags scattered across tables. A typical flow: CREATED → PAYMENT_AUTHORIZED → FUNDS_HELD → RELEASED, with branches to REFUNDED, PARTIALLY_REFUNDED and DISPUTED. Every transition has a trigger (buyer confirms delivery, N days elapse, dispute opened) and a ledger effect. Time-based auto-release is essential — real buyers do not reliably click "confirm receipt", so a delivery-confirmed state that auto-releases after, say, 7 days keeps sellers from being held hostage by silent buyers.
Underneath the state machine, keep a double-entry ledger. Every money event writes balanced entries: buyer payment credits "funds held", debits "buyer receivable"; release credits "seller payable" and "platform revenue" in the take-rate split. This sounds like accounting pedantry until the first reconciliation incident, when a seller claims a missing $4,000 and you need to prove exactly where every cent went. A ledger makes that a query; a pile of payment records makes it a forensic project.
Handle the ugly cases in the design, not in production. Partial refunds after release require clawing back from the seller balance before payout. Disputes freeze the related entries. A seller whose balance goes negative — refunds exceeding pending payouts — needs a policy: debit their bank via the processor (supported on connected accounts), hold future payouts, or write it off. Decide now, in a document, not during the incident.
| Escrow state | Entered when | Funds position | Exit triggers |
|---|---|---|---|
| PAYMENT_AUTHORIZED | Checkout completes | Card authorized, not captured (or captured, untransferred) | Seller accepts order; authorization expiry (~7 days on cards) |
| FUNDS_HELD | Seller accepts / capture succeeds | Held by processor, not yet transferred | Delivery confirmed; auto-release timer; dispute opened |
| RELEASED | Release condition met | Transferred to seller minus your fee | Terminal — but refunds and disputes can still hit later |
| DISPUTED | Chargeback or platform dispute opened | Frozen; processor may debit on loss | Dispute won → release; lost → refund path |
| REFUNDED / PARTIAL | Refund issued per policy | Returned to buyer, pro-rata fee handling | Terminal |
🪪KYC, AML and where your obligations actually start
The good news in the connected-accounts model: the processor performs seller identity verification — document checks, sanctions and watchlist screening, tax ID collection — as part of account onboarding, because they are the regulated entity moving the money. In the US they also handle 1099-K reporting to sellers above the applicable thresholds; in the EU, DAC7 makes platforms report seller income to tax authorities, and processors have built tooling for this. Thresholds and rules change; verify the current ones at integration time.
The less good news: you are not obligation-free. You are responsible for your own business compliance — sanctions exposure if you knowingly facilitate prohibited transactions, consumer-protection rules on refunds and disclosures, marketplace-specific tax collection duties (most US states now have marketplace facilitator laws that make you the sales-tax collector even in the connected-account model), and accurate records. If you ever touch funds directly — collecting into your own account and paying sellers later — you have entered money-transmitter territory, which in the US is a state-by-state licensing regime you do not want to discover retroactively.
Operationally, build these from day one: webhook-driven KYC status tracking per seller, a block on payouts until verification completes, records retention for transactions and identity events (five years is a common regulatory baseline — confirm for your jurisdictions), and an audit trail of who on your team touched any manual payout or refund. These are boring features that become urgent the first time a bank partner or auditor asks.
📊Payout timing and take-rate mechanics
Payout timing is a product decision disguised as a finance detail. Pay sellers too slowly and they leave for a competitor; pay instantly and you have funded every fraudulent seller who will ever sign up. The industry default is a delay: funds become available some days after the release condition — Stripe Express payouts commonly settle on a rolling 2-day basis in the US for established accounts (longer for new ones), and instant payouts exist for a fee. Your policy layer sits on top: many marketplaces add their own holding period for new sellers or high-risk categories, then relax it as a seller builds track record.
Rolling reserves are the blunter instrument: hold back, for example, 10 percent of each payout for 90 days as a chargeback buffer. Reserves protect you but sellers hate them, so apply them selectively — new sellers, categories with high dispute rates, or sellers whose dispute metrics degrade — rather than universally.
Take rate mechanics deserve equal care, because "we charge 15 percent" is five different implementations. Is your fee calculated on the item price, or item plus shipping? Do you refund your fee on a full refund? (Whether you recover the processor fee on refunds depends on provider policy — Stripe, as of writing, does not return processing fees on refunds; factor that into your margin math.) Do you charge sellers a subscription, a payment processing passthrough, or a withdrawal fee? Application fees in the Connect model are set per charge, which means tiered and promotional take rates are just logic in your codebase — but every variation multiplies your ledger cases and your support tickets.
| Payout policy | Seller experience | Your risk | Typical use |
|---|---|---|---|
| Instant / same-day | Excellent | High — little time to catch fraud | Established sellers, low-risk categories |
| Standard rolling (2–7 days) | Acceptable industry default | Moderate | Most sellers, most categories |
| Delayed (release + N days) | Poor for new sellers | Low | New sellers until track record builds |
| Rolling reserve (e.g. 10% for 90 days) | Actively disliked | Lowest | High-dispute categories, degraded sellers |
🕵️Fraud basics you cannot skip
Marketplaces face fraud from both sides of the transaction, which is what separates them from ordinary e-commerce. From the buyer side: stolen cards, friendly fraud (a real buyer claiming non-delivery), and account takeover. From the seller side: fake sellers collecting for goods they never ship, collusion between buyer and seller accounts to launder stolen cards, and triangulation schemes where a fraudster uses your marketplace as the storefront and a stolen card elsewhere as the funding source.
The processor layer gives you the first line of defense: ML-based card risk scoring (Stripe Radar, and equivalents), 3D Secure authentication which also shifts chargeback liability on authenticated transactions, and card-testing velocity protections. Turn these on and tune the rules — outright blocking on high risk scores, review queues on medium — rather than accepting defaults blindly. Note that 3DS coverage and liability-shift rules vary by region and card network; SCA requirements in Europe already force strong authentication on most transactions there.
The second line is yours, and it is mostly velocity and anomaly logic: a new seller listing expensive items in volume, a seller whose first five orders all ship to the same address as another seller, payout bank accounts changed immediately after a large sale, buyers with many disputes across different sellers. None of these need machine learning to start — SQL and a review queue catch the obvious cases, and the obvious cases are most of the volume early on.
The chargeback number to fear is not the fee — it is the dispute rate. Card networks start monitoring programs around roughly 1 percent of transactions disputed, and processors will hold reserves or terminate accounts before you reach network thresholds. In the connected-account model, configure who owns dispute liability deliberately; it is a setting, not a default you inherit by accident.
💰What this costs to build, and when to hire a team
Honest labelled ranges at US-market rates, assuming the connected-accounts architecture described above: a basic marketplace payments build — seller onboarding via Express, destination charges, a simple hold-and-release flow, standard refunds and payouts — runs roughly $25,000 to $50,000 as part of a broader marketplace build. A full financial subsystem — escrow state machine with auto-release, double-entry ledger, tiered take rates, reserves, dispute tooling and reconciliation reporting — adds roughly $30,000 to $80,000 on top, depending on how many edge cases (partial refunds post-release, multi-item split orders, cross-border sellers) are in scope.
When to hire a team: if you have never built ledger-based systems, the escrow and reconciliation work is where experience pays for itself — the failure modes (double-release, unbalanced entries, orphaned transfers) are silent until they are expensive. A senior team that has shipped marketplace payments before will also know which processor restrictions apply to your region and category before you design around the wrong primitive.
We built the payments and escrow subsystem for an e-commerce marketplace — seller onboarding, hold-and-release, commission splits and dispute handling — and the case study covers the architecture choices in detail. If you are scoping a marketplace now, that page is the fastest way to see what the finished system looks like.
Case study: e-commerce marketplace buildHow we build marketplace apps end to endScope your marketplace with us