Building a two-sided marketplace? Payments are not "add Stripe and ship it."
The moment you have sellers who need to get paid, not just a store taking one payment from one buyer, you're making five architectural decisions whether you realize it or not:
- How sellers get verified and onboarded (connected accounts)
- How money comes in (pay-ins)
- What you charge (take rate)
- How it splits between parties (split payments)
- How money goes back out (payouts)
Get any one of these wrong and you're either shipping a bad seller experience or writing a lot of infrastructure code you didn't budget for.
Here's what each decision actually involves at the API/architecture level, and where a payments platform can take the work off your plate.
1. Connected accounts: verify now or verify later?
Every seller needs KYC/KYB before they can hold or move money. The question is when.
Front-load it at signup and you're protected from day one, but you add friction before a seller has listed anything. 74% of users already find marketplace onboarding unnecessarily complicated — that's before you've asked them for a tax ID.
Defer it to first payout and signup is frictionless, but you're carrying unverified sellers on your platform until they cash out.
There's also an account-tier decision hiding underneath this:
- Full connected accounts — seller gets their own balance, multi-currency holding, control over withdrawal timing. Right model for high-earning, repeat sellers (Etsy, Fiverr-style).
- Ledger-style accounts — lighter KYC, cheaper and faster onboarding, no seller autonomy over funds. Right model for high-volume, low-earning sellers (Uber, DoorDash-style gig payouts), where full account infrastructure per seller would cost more than the seller earns.
Building this yourself means maintaining KYC/KYB integration, sanctions screening, two separate account infrastructures, and the migration logic to move a seller from one tier to the other as they grow. That's before you've moved a single dollar.
2. Pay-ins: getting money in the door
Once a seller exists, you need to decide how the buyer's money actually lands.
Capture timing is a cash-flow-vs-refund-risk tradeoff. Capture instantly and you lock in revenue immediately, but a cancelled order means a refund, not a released hold — and refund processing averages $15–25 per transaction once you count interchange and processor fees. Delay capture until fulfillment and you dodge that, but debit holds can release in 1–2 business days, well inside a typical shipping window. Ship late, and the hold's already gone.
Fund custody matters more than most teams think about up front. Some providers hold funds in their own regulated account until the split happens — your bank account never touches the buyer's money. Others route the full pay-in through your account first, which puts you in legal possession of buyer and seller funds simultaneously. In the US, holding customer funds even briefly can trigger money transmitter licensing requirements state by state (New York alone wants a $500K surety bond).
Currency conversion is a build-vs-bolt-on call. Native conversion inside your payment provider runs in the background at ~1%. Bolt on a separate FX provider and you've added a second system with its own handoff — mismatched transaction IDs, delayed conversion, markup stacking to 3-5%.
Method coverage is table stakes for anything cross-border: iDEAL in the Netherlands, BLIK in Poland, Pix in Brazil. Build this yourself and you're managing individual FX relationships and integrating local rails one at a time.
3. Take rate: fixed, variable, or compound
Three shapes, and most marketplaces get this wrong on the first attempt:
- Fixed — flat fee per transaction. Predictable, but disproportionately punishes low-value orders.
- Variable — a percentage that scales with order size. Most common, flexible by category/tier, can double as a growth lever (lower rate for new sellers).
- Compound — fixed + variable. Guarantees a revenue floor while still capturing upside on larger orders. This is where Etsy and eBay both landed — neither started there.
The engineering cost isn't in picking one — it's in what happens when you need to change it. If your take rate is hardcoded percentages scattered through your checkout logic, every pricing change (new tier, new category, switching variable → compound) is an engineer picking up a ticket and shipping to prod. If your payment platform exposes splits and commissions as configurable API objects instead, that same change is a config update, not a deploy.
4. Split payments: the part that actually breaks
Single-seller checkout is trivial: buyer pays $100, you take $10, seller gets $90. No infrastructure required.
Multi-seller orders are where it gets real. Amazon-style carts — one checkout, products from three different sellers — need that $100 split three ways ($60/$30/$10) from a single transaction. Now add a partial refund on that order: you need to reverse one seller's cut without touching the others, while keeping your own commission math correct on what's left.
This is the actual engineering cost center. Split-payment logic alone can eat 20-30% of a marketplace's total engineering effort if you're building it in-house — refund edge cases, rounding, partial reversals, reconciliation. If your platform handles splits, commissions, and refunds natively through the API, all of that collapses into a single call instead of a subsystem you maintain.
5. Payouts: getting money back out
Three models, each with a different tradeoff:
- Scheduled (daily/weekly/monthly) — predictable, easy to reconcile, but funds sit in limbo for the seller. 44% of gig workers say they'd quit a platform that added fees or friction to fast payouts — payout speed is a retention lever, not a back-office detail.
- Instant — money moves in minutes. Sellers want this, but instant rails charge a percentage + flat fee versus a low flat ACH rate. Someone eats that cost — you, or the seller as an opt-in paid upgrade.
- Manual — triggered on demand by either party. Most control, least automation.
There's also a UX decision underneath all three: is payout management (balance, withdrawal, status) embedded in your product, or does it hand the seller off to some other hosted page mid-flow? A jarring redirect after they've spent the whole session in your app is its own churn risk.
Building this yourself means maintaining multiple payout rails, the fee-absorption logic for who pays for speed, and your own embedded UI for balance/withdrawal — on top of everything above.
Build vs. buy
A few marketplaces run the full build — Amazon and Airbnb operate their own licensed payment subsidiaries — but that's years of infrastructure and compliance work, not a decision most teams get to make. Most marketplaces build on top of a payments platform instead of becoming a licensed financial institution themselves.
When you're evaluating one, the questions that actually matter:
- Coverage — buyer-side coverage and seller-side coverage are not the same number. Check both against where your users actually are.
- Compliance — KYC/KYB gets you onboarding. Ongoing sanctions screening and tax reporting (1099-K in the US, DAC7 in the EU) don't stop there. Some platforms handle this for you; others hand you a checklist. (Temu paid a $2M DOJ/FTC penalty in 2025 for exactly this gap.)
- Take rate flexibility — can you change fee structure by tier/category/volume without a full re-integration?
- Merchant of record — who's the name on the buyer's bank statement, and who eats the chargeback? US chargeback volume is projected to hit 146 million disputes worth $15.3B in 2026 — this isn't a hypothetical line item.
Where this leaves you
None of these five decisions are optional — every marketplace payment runs through all of them, whether you've deliberately chosen an answer or defaulted into one. The API-level question is really: do you want to own connected accounts, split logic, take-rate config, and payout rails as code you maintain, or as calls into a platform that maintains them for you?
