Marketplace acquisitions are attractive because network effects make them defensible. They're complex because the technical infrastructure serves three distinct parties — buyers, sellers, and the platform — with often conflicting needs. Evaluating a marketplace requires a different framework than evaluating a traditional SaaS product.
This guide covers the specific technical evaluation challenges of two-sided marketplace platforms — service marketplaces, product marketplaces, rental platforms, and B2B exchanges.
The marketplace-specific risk landscape
Marketplaces have technical complexity that doesn't exist in simpler software:
- Payment splits and escrow — money flows through the platform, not just past it
- Trust and safety — fraud from both supply and demand sides
- Supply data integrity — availability, pricing, and inventory accuracy
- GMV authenticity — the transaction volume may not represent real economic activity
- Network effect fragility — the platform's value depends on maintaining critical mass on both sides
Payment infrastructure evaluation
The payment split architecture
In a marketplace, when a buyer pays, the money must be:
- Collected from the buyer
- Held briefly (or in escrow until service delivery)
- Split between the seller and the platform (take rate)
- Disbursed to the seller
- Reconciled
Every step is a potential failure point. Evaluate:
- Escrow timing: When does money release to the seller? On order placement, on delivery confirmation, on no-dispute period expiry?
- Split calculation: Is the platform's take rate calculated correctly? Are there edge cases (refunds, discounts, credits) where the split is wrong?
- Payout reliability: How often do payouts fail? What's the retry logic? How are sellers notified?
- Reconciliation: Does the platform know its cash position at any point in time? Can it reconcile platform revenue against total GMV?
Red flag: Payouts that the seller initiates manually (the platform doesn't automatically disburse). This is a sign of immature payout infrastructure that will not scale.
Refund and dispute handling
In marketplaces, refunds are complex because money has already split:
- Who pays for a refund — buyer, seller, or platform?
- Is the seller's payout clawed back if a refund is issued after disbursement?
- How are partial refunds handled?
- What happens to the platform's take rate on a refunded transaction?
Test this manually if possible. Refund logic in marketplaces is consistently the most bug-prone payment code.
Payment provider risk
- Is the platform using a marketplace-capable payment provider? (Not all payment providers support marketplace splits — Stripe Connect and Razorpay Route are built for this; generic gateways are not)
- Is the payment provider account in good standing?
- What is the current chargeback rate? (Above 0.5% is a merchant risk signal; above 1% the payment processor may terminate the account)
- Are there any holds on the payment provider account?
GMV verification
GMV is the headline metric for marketplace valuations. It's also the most frequently manipulated.
How GMV can be inflated
- Wash trading: A seller buys their own listings to inflate volume
- Related party transactions: Colluding buyers and sellers transact to inflate metrics
- Reversed transactions: Orders that are later cancelled or refunded counted in gross GMV
- Undelivered services: Transactions recorded but services never rendered
How to verify
- Payment processor reconciliation: Pull total payout to sellers. If platform GMV is ₹10Cr but total payouts are ₹3Cr (at a 30% take rate), something doesn't reconcile
- Seller concentration analysis: Do the top 5 sellers account for 60%+ of GMV? High concentration warrants deeper investigation
- Refund rate by seller: Sellers with high GMV and abnormally low refund rates deserve scrutiny
- Cohort retention: Are buyers returning? A high-GMV platform where buyers only transact once is either a one-time purchase product or has a satisfaction problem
Trust and safety infrastructure
Trust and safety is the area most acquirers underinvest in — until they own the platform and the fraud scales.
Supply-side trust (seller verification)
- Identity verification: How are sellers onboarded? Is there KYC or just email verification?
- Listing quality: How are fake, misleading, or prohibited listings detected and removed?
- Seller performance tracking: Are seller metrics (response rate, completion rate, dispute rate) tracked and enforced?
- Suspension and appeals: Is there a documented process for suspending bad sellers? An appeals process?
Demand-side trust (buyer fraud)
- Friendly fraud: Buyers who claim non-delivery on completed transactions
- Account takeover: Compromised buyer accounts used for fraudulent purchases
- Card fraud: Stolen payment methods used on the platform
- Chargeback abuse: Systematic use of chargebacks to get free services
Review integrity
Reviews are a core trust mechanism in most marketplaces. Verify:
- Can sellers review their own products or incentivize reviews?
- Are there anomalous review patterns? (A seller with 500 reviews and a perfect score may have gamed the system)
- Is review fraud actively monitored and removed?
- Are reviews verified-purchase only, or can anyone leave one?
Supply data integrity
For product marketplaces, inventory accuracy is critical:
- Overselling: Can a product be sold when inventory is zero?
- Price accuracy: Are prices consistent between listing, cart, and checkout?
- Availability sync: For rental or booking marketplaces, is availability updated in real time?
- Duplicate listings: Is there deduplication? Duplicate listings fragment supply signals and degrade buyer experience.
For service marketplaces:
- Availability accuracy: Does the seller's calendar reflect their actual availability?
- Completion rate: What percentage of booked services are actually completed?
- No-show handling: What happens when a seller doesn't show up?
Technical scalability for marketplace dynamics
Marketplaces have non-linear scaling challenges:
- Search and discovery: As the catalogue grows, search performance degrades. Is there a search infrastructure that scales? (Elasticsearch, Algolia, or equivalent)
- Matching algorithms: For two-sided platforms with matching (gig economy, B2B exchanges), how does the matching logic scale with supply and demand volume?
- Notification volume: When an order is placed, notifications go to buyer, seller, potentially admins. Notification infrastructure breaks at scale. Check the queuing and delivery architecture.
- Real-time inventory: For booking/rental marketplaces, concurrent booking creates race conditions. How is this handled?
Valuation adjustments
| Finding |
Adjustment |
| GMV reconciliation gap > 10% |
Re-base revenue figures before applying multiple |
| No escrow, manual payouts |
₹10L–₹25L infrastructure rebuild |
| Chargeback rate > 0.75% |
Payment processor risk; may affect ability to operate |
| No seller verification |
Trust and safety investment required |
| Review fraud detected |
Reputational risk; quantify and factor into brand value |
| No real-time inventory sync |
Overselling risk; quantify refund/dispute cost |
Evaluating a marketplace platform for acquisition and need a technical assessment that covers payment integrity, GMV verification, and trust systems? Contact us — we conduct marketplace-specific technical due diligence with particular focus on the financial infrastructure and trust architecture.