For card issuers

Dispute intake that already knows the reason code

A cardholder describes what went wrong in their own words. One API call later you have the Visa or Mastercard reason code, a filing deadline calculated from the network rules, and a decision about which queue the case belongs in.

What it does

ChargebackCheck reads a dispute the way a cardholder tells it and returns what a dispute system needs in order to act: the matching reason code, whether the case is still inside its filing window, what evidence is missing, and whether it is a merchant dispute at all. It is a server-to-server API. There is no database behind it and nothing is kept after a request finishes.

Fraud and friendly fraud are not the same claim

A cardholder saying "I never made this payment" has a fraud claim, not a merchant dispute. The response comes back with fast_path: true, no eligibility result, and a line of routing guidance, so the case goes to your unauthorised-use process without an analyst having to read it first.

The harder call is the one that goes the other way. "They charged me without my authorisation" is how most people describe a subscription that kept billing after they cancelled it, and that is an ordinary dispute under Visa 13.2 with a real chance of recovery from the merchant. Booked as fraud, the same case is simply written off. The classifier is given both directions in as many words, and both are pinned by worked cases that run against the live model rather than by prose in a prompt that nobody checks.

This is the part of the product worth testing hardest, and it is the first thing we show on a call.

Dates are calculated, not generated

Every deadline in a response comes out of ordinary code working from the network's own time limits. The language model classifies the story; it is never asked for a date and has no opportunity to invent one. That is the difference between a deadline an analyst can act on and a number that looks plausible.

Where the rules come from

28 reason codes, each one checked against the published Visa and Mastercard dispute documents and carrying the page reference it was taken from. They are re-checked on a six-month cycle, since Visa republishes in April and October. Time limits, waiting periods and prerequisites are read from that library at runtime, not recalled by a model.

Scope worth knowing up front: the library holds the general-region time limits, so Mainland China, intra-Europe Maestro and US-domestic variants are not in it. Visa and Mastercard are the networks covered.

What comes back

A real response to a goods-not-received case, trimmed. The rest of it, and the analyst report that follows, are what we walk through together.

{
  "partner_case_ref": "DEMOBANK-2026-0042",
  "triage": {
    "rule_id": "visa-13.1",
    "reason_code": "13.1",
    "dispute_name": "Merchandise/Services Not Received",
    "category": "consumer_dispute",
    "is_fraud": false,
    "confidence": "high"
  },
  "eligibility": {
    "status": "eligible",
    "checks": [
      {
        "name": "Filing deadline: 120 days from the expected delivery/service date",
        "status": "pass",
        "deadline_date": "2026-10-13",
        "days_remaining": 71
      }
      // two further checks omitted
    ]
  },
  "fast_path": false
}

Integrating it

Two endpoints. /check runs at intake in about five seconds and fits inside an intake screen. /report takes around twenty-five seconds and returns a full case assessment written for a dispute analyst, in the third person, with no cardholder letter attached, because in your flow the bank files.

Authentication is a bearer key. Your own case reference travels with the request and comes back on the response, so nothing has to be correlated by hand. Errors arrive as a code and a message rather than prose, so your integration can branch on them. Usage is metered per key, and that metering is what invoicing is based on.

Data handling

No part of this product asks for a card number, including the consumer side, and generated documents use placeholders for the last four digits. Nothing is stored: a case exists for the length of the request. The usage log records a sha256 fingerprint of the case together with your reference, the timing and the status, and never the cardholder's text. Sub-processors are listed in full on the privacy page and are covered by the agreement a pilot runs under.

Pricing

Per call, agreed per institution. We quote once we know your volume and which of the two endpoints you would actually use. A pilot starts with a key issued to you and metered from the first request, so the first invoice reflects what you ran and nothing else.

Seeing it on your own cases

The useful first call is a short one where we put your dispute descriptions through it live and you judge the classifications yourself. Tell us roughly what you handle and we will come with cases that look like yours.