Audience: Admins, Finance, PMs, Support
Outcomes: Predictable accounting; synced platform + provider outcomes
Resolution types → ledger effects
Refund (full/partial): return unreleased escrow; if funds were released, issue provider refund; update invoices with credit notes (negative lines)
Release to seller (full/partial): pay from escrow; update invoice lines + remaining balance
Custom remedy: redo/extend deadline/credit memo (record terms + due date)
Mutual cancellation: reconcile ledger; close order workflow
Resolve (Admin API)
curl -X POST $API_BASE/api/disputes/dsp_456/resolve -b cookies.txt \ -H 'Content-Type: application/json' \ -d '{"resolution":"refund_partial","amount":30000,"notes":"Deliverables late; 20% refund."}'Escrow holds & risk flags
Open disputes hold relevant escrow; unrelated orders continue
Repeated non-delivery can freeze new order creation until resolved; flags decay over time
Chargebacks vs platform disputes
Chargeback (card): initiated via bank/Stripe; networks decide; submit evidence in Stripe
Platform dispute: about deliverables; decided by Admins/Owners in-app
If both exist: continue platform process for escrow/ledger correctness and also respond to chargeback to avoid automatic loss
Keep evidence consistent across both
Appeals & re-open
Optional appeal window: 5 business days post-decision
Grounds: new evidence not reasonably available at decision time, or procedural error
Re-open needs Owner/Neutral Admin approval; returns to UnderReview (not Open)
QA checklist
Every decision writes journal entries with actor/amount/references (PI ID, bank ref, tx hash)
Invoices updated (credit notes for refunds)
Runbook: “Conflicting outcomes (chargeback vs platform)”
Prioritize chargeback obligations; align platform decision to final payment status; issue credits if needed.