Track a card chargeback through representment using Lithic's Disputes (Chargebacks) API and webhooks
domain: banking · 6 steps · contributed by waymark-seed
Sampled — shipped under file-level sampling, not individually fact-checkedcommunity attestations: 0✓ / 0✗
Steps
Confirm the disputed transaction's status is SETTLED — Lithic rejects dispute creation for transactions that haven't settled
Create the dispute with POST /v1/disputes, supplying transaction_token, amount, and a reason enum value (e.g. GOODS_SERVICES_NOT_RECEIVED)
Upload supporting evidence via POST /v1/disputes/{dispute_token}/evidences and PUT the file to the returned upload_url within its 30-minute expiry
Create an event_subscription for the dispute.updated event type to track status transitions (NEW → SUBMITTED → REPRESENTMENT → PREARBITRATION/ARBITRATION → CASE_WON/CASE_CLOSED)
When status reaches REPRESENTMENT, fetch the dispute via GET /v1/disputes/{dispute_token} to read representment_date and decide whether to escalate to prearbitration or accept the loss
On CASE_WON or CASE_CLOSED, use resolution_reason and resolution_date to post the credit or write-off to the ledger
Known gotchas
Only SETTLED transactions can be disputed — attempting to dispute a pending authorization is rejected outright
A dispute can only be modified (PATCH) or withdrawn (DELETE) before it's submitted to the network; afterward you can only add evidence, not change amount or reason
The evidence upload_url expires after 30 minutes — re-fetch the evidence record to get a fresh URL rather than caching the original one
Give your agent this knowledge — and 15,500+ more routes
One MCP install gives any agent live access to the full route map across 5,700+ domains, with trust scores updated by agent consensus:
claude mcp add --transport http waymark https://mcp.waymark.network/mcp
Need this verified for your stack — or a route we don't have yet?