A dispute in a one-merchant world is simple. The cardholder complains, the issuer files, the acquirer debits the merchant, the merchant either fights it or eats it. In a platform or marketplace, the same dispute fans out across three parties at once: the buyer, the seller who fulfilled the order, and the platform that processed the money. The card networks do not see your three parties. They see one entity in the merchant slot, and they bill that entity. The whole job of multiparty dispute design is closing the gap between who the network bills and who actually caused the loss.
This module assumes you already settled how money moves (aggregated vs split, module 2) and who sits in the merchant-of-record seat (module 3). Disputes are where those earlier choices get stress-tested, because liability follows the seat, not the seller.
The two layers of liability
There are always two separate questions, and conflating them is the most common mistake we see.
The first is network liability: who does Visa or Mastercard hold responsible. The network deals with the entity whose merchant ID processed the charge. If your platform is the merchant of record, that entity is you. The network debits your acquirer, your acquirer debits you, and your dispute rate, monitoring exposure, and fines are all yours.
The second is contractual liability: who ultimately absorbs the cost once the dust settles. This is governed by your seller agreement and your processor integration, not by card rules. The standard pattern is that the platform pushes the loss down to the seller who fulfilled the order, by clawing the disputed amount and the dispute fee from money owed to that seller.
The network never enforces your second layer. If the seller has no balance to claw from, the platform is still on the hook to the network. The loss does not disappear; it lands on whoever is closest to the network once recovery fails.
How the seat decides who pays first
The mechanics differ depending on how your processor routes the charge. On Stripe Connect this maps cleanly to charge type.
For destination charges and separate charges with transfers (the typical marketplace setup), the platform is ultimately liable. Stripe debits the disputed amount, the refund, and the fees from the platform balance, and leaves it to the platform to recover from the seller by reversing the transfer.
For direct charges, the connected account is the merchant of record, and Stripe first tries to debit the dispute from that account's balance. The platform only inherits the loss if it has accepted negative-balance responsibility for its sellers, which most onboarding-heavy platforms do.
Either way, the recovery path is the same idea: reverse the transfer, claw the funds, and hope the seller is solvent. The reserve you set during onboarding (module 4) is what stands between you and a seller who has already paid out and walked.
A worked example
A buyer pays $400 for furniture through your marketplace. You take a $40 commission and transfer $360 to the seller. Two months later the buyer files a "merchandise not received" dispute.
The network does not care that you only kept $40. Through your acquirer it debits the full $400, plus a dispute fee. If you are the merchant of record, that $400 plus fee comes out of your balance immediately. Your contract lets you claw the $360 back from the seller, but the seller withdrew that money six weeks ago and the account balance is $12.
You are now out $400 plus the fee, with $12 recovered. The remaining roughly $390 is the loss your reserve policy was supposed to cover. If you held no reserve and ran no payout delay on that seller, you funded a stranger's furniture. Multiply that by a bad cohort of sellers and you understand why payout timing and reserves are a fraud control, not just a cash-flow lever.
The clock, and why it is brutal across parties
Cardholders generally have 120 days from the transaction or expected delivery date to file most disputes, with longer windows for specific fraud cases. That window is the reason a seller who is solvent today may be gone tomorrow. A seller can fulfill, get paid out, close their account, and still generate a chargeback four months later.
Once a dispute lands, the response clock is short and it is the platform's clock if the platform holds the seat. Under Visa's revised process, acquirer-side response windows compressed sharply; some processors, such as Adyen, now set merchant response timeframes around 9 days for the US and Canada as of 2025. Mastercard typically gives US merchants 45 days to respond. Visa also removed the old default "no response" option, so silence is now an explicit acceptance of liability rather than a passive stall.
This matters for multiparty design because the evidence to fight the dispute lives with the seller (tracking numbers, delivery confirmation, chat logs), but the deadline belongs to the platform. If your representment flow cannot pull seller evidence inside a 9-day window, you will lose winnable disputes by default. Build the evidence handoff into onboarding and the order record, not into a panic email after the dispute hits.
Fraud rolls up to the seat too
Network monitoring programs do not score your sellers individually. They score the merchant entity, which on most platforms is you or your acquirer.
Visa consolidated its legacy dispute and fraud monitoring into the Visa Acquirer Monitoring Program (VAMP), effective in 2025 with enforcement phasing in from October 2025. VAMP scores a single ratio: the count of fraud (TC40) plus non-fraud disputes (TC15) divided by settled transactions (TC05). An acquirer portfolio at or above 50 basis points is flagged "above standard"; at or above 70 basis points it is "excessive," carrying per-transaction enforcement fees that have run to several dollars per disputed transaction.
The trap for platforms is pooling. If you aggregate many sellers under one merchant ID, one fraudulent or sloppy seller raises the ratio for the entire pool, and the fines and scrutiny hit the pool, not the bad actor. A clean seller can get throttled because a neighbor in the same MID is generating disputes. That is the hidden cost of aggregation, and it is why per-seller dispute monitoring is something you instrument yourself, well below the threshold where the network notices.
What to build
Three controls do most of the work. First, a reserve and payout-delay policy keyed to seller risk, so there is balance to claw when a late dispute lands. Second, an evidence pipeline that captures fulfillment proof at the order level and can produce a representment packet inside the tightest network window. Third, per-seller fraud and dispute dashboards that flag a bad cohort long before it moves your pooled ratio toward a VAMP threshold.
The takeaway: in a multiparty sale, the network bills the seat, not the seller. Your contracts decide who should pay, but your reserves, your payout timing, and your evidence flow decide who actually does. Design those three before your first late chargeback, because by the time it arrives the seller's balance is already gone.