Skip to main content
Documentation
Service VIN developer & AI platformGetting startedAuthenticationPaginationIdempotencyRate limitsErrorsWebhooks & signature verificationConnecting ClaudeRecipesMCP servers & the Claude connectorREST resource referenceCapability indexCustomers capabilitiesVehicles capabilitiesLeads capabilitiesWarranties capabilitiesQuotes capabilitiesInvoices capabilitiesPayments capabilitiesServices capabilitiesJobs capabilitiesCalendar capabilitiesScheduling capabilitiesStaff capabilitiesInventory capabilitiesComms capabilitiesTasks capabilitiesShop capabilitiesDocuments capabilitiesKnowledge capabilitiesReports capabilitiesBooking capabilitiesForms capabilitiesMarketing capabilitiesReviews capabilitiesAutomations capabilitiesIntegrations capabilitiesChangelogSearch

Payments

payments.dispute

Get the chargeback on one payment and its evidence deadline
Read-onlyRead budget

REST

Shipping
POST /api/v1/payments/dispute

MCP tool

Live
payments.dispute

Exposed on: REST API · Shop MCP server · Claude connector · Dash (in-app copilot) · Zapier. Part of the Payments domain.

Operating contract

One chargeback in full, plus the ONE FIELD THAT DECIDES WHETHER ANYTHING CAN STILL BE DONE: evidence_due_by, read live from the processor rather than from a stored copy that could be a week stale.

LEAD WITH THE DEADLINE. 'A $1,400 chargeback, evidence due Thursday' is an instruction; 'a chargeback is open' is a fact somebody will read on Friday.

deadline_available: false means the live read could not be made — the processor is not configured for this shop, or it declined the lookup. The stored row is still true; the deadline simply is not known, and guessing one is worse than saying so.

has_evidence: true means somebody has already uploaded a response. past_due: true means the window has closed, and the honest thing to say then is that the outcome is now the bank's alone.

live_status is the processor's status RIGHT NOW and can be fresher than status, which is whatever the last webhook wrote. When the two disagree, the live one is the true one.

amount_cents is in cents — the processor's own unit, kept exactly as it left the bank.

KEYED ON THE PAYMENT, not on the chargeback's own id, because that is how the question arrives: a payment came back, what happened to it. A chargeback the processor could not match to a recorded payment has no payment to key on — payments.disputes lists those, and their deadline can only be read at the processor.

One dispute, entirely returned, so nothing is truncated. Contesting it is not a capability: the evidence is documents somebody has to choose, submitted once, to a bank.

Who may call it

Permission
invoices.accessThe caller must hold Invoices at the ACT level. A read-only dashboard grant on the same section is refused.
Plan
Every planNo plan gate. Available on every Service VIN plan.
Retries
naturalNaturally idempotent — running it twice leaves the same world as running it once. A retrying integration needs no key.
Rate class
readCounted against the read budget — the widest of the four.

Input

FieldTypeDescription
payment_idrequiredstringuuid

The disputed payment, as returned by payments.list or payments.disputes.

Output

FieldTypeDescription
idstring

—

statusstring

—

openboolean

—

reasonstring | null

—

amount_centsnumber

—

currencystring | null

—

opened_atstring

—

updated_atstring

—

payment_idstring | null

—

payment_amountnumber | null

—

invoice_idstring | null

—

invoice_numbernumber | null

—

customer_idstring | null

—

customer_namestring | null

—

funds_clawed_backboolean

—

clawed_back_centsnumber

—

deadline_availableboolean

—

evidence_due_bystring | null

—

live_statusstring | null

—

has_evidenceboolean | null

—

past_dueboolean | null

—

submission_countnumber | null

—

Examples

Built from this capability's own schema — required fields and the ones carrying a default, and nothing invented. Paste one and it validates.

curl
export SERVICEVIN_API_KEY=svk_live_…

curl -X POST https://www.servicevin.com/api/v1/payments/dispute \
  -H "Authorization: Bearer $SERVICEVIN_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"payment_id":"9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20"}'

TypeScript (fetch)
const res = await fetch("https://www.servicevin.com/api/v1/payments/dispute", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.SERVICEVIN_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    "payment_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20"
  }),
});

// Success and failure are both envelopes. Switch on error.code, never
// on error.message — the codes are stable, the messages are for people.
const payload = await res.json();
if (!res.ok) throw new Error(payload.error.code);
const data = payload.data;

Python (requests)
import os, requests

res = requests.post(
    "https://www.servicevin.com/api/v1/payments/dispute",
    headers={"Authorization": f"Bearer {os.environ['SERVICEVIN_API_KEY']}"},
    json={
    "payment_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20"
},
    timeout=30,
)
payload = res.json()
if not res.ok:
    raise RuntimeError(payload["error"]["code"])
data = payload["data"]

MCP tools/call — https://www.servicevin.com/api/mcp
{
  "jsonrpc": "2.0",
  "id": 1,
  "method": "tools/call",
  "params": {
    "name": "payments.dispute",
    "arguments": {
      "payment_id": "9b2f1c6e-4a77-4d2b-9f31-0f1c9a8e5d20"
    }
  }
}

Refusals

The four gates run in this order on every surface, and the order is not arbitrary — see Authentication.

StatusCodeWhen
404not_foundThe id is unknown, or the feature is not enabled for this account. Deliberately the same answer for both.
403forbiddenThis login does not hold invoices.access.
422validation_errorAn argument was wrong. The message names the field.
429rate_limitedToo many read calls. Back off and retry.
500internal_errorSomething failed on our side. Nothing was changed.