Skip to main content

Classification

Triple classifies disputes for you. You don't need to decide whether a case is fraud, service-not-received, processing-duplicate, or cancelled before calling the API. The classifier reads the evidence and picks the category itself.

Why automatic​

Classifying a dispute correctly is hard:

  • Cardholders describe the same situation many ways.
  • The category drives what evidence a scheme expects — get it wrong and your case is weak.
  • Hints from front-line staff or menus cardholders pick from are often inaccurate.

Putting the classifier behind the API means:

  • Callers don't need scheme expertise to integrate.
  • Incorrect hints don't silently weaken the evaluation — we flag when we reclassify.
  • We can improve the classifier without every integrator redeploying.

Categories​

The categories currently supported are:

CategoryWhen it applies
fraudThe cardholder did not authorize the transaction
service_not_receivedGoods or services paid for but not delivered
processing_duplicateThe same transaction was charged more than once
cancelledThe cardholder cancelled and the merchant didn't refund, retained fees, or mismatched their own policy

More categories will come online over time — no integration changes needed on your side.

How we pick one​

Classification runs on whatever case data we have, regardless of entry point:

  • From intake: the cardholder's answers and uploads inside the hosted form or chatbot. The flow itself narrows the case as it goes.
  • From a direct evaluation call: the transaction, card, dispute, and evidences you sent to POST /evaluations/.

The final category appears on the evaluation result as category.

Category hints​

You may send a category along with your request. Triple treats it as a hint, not a directive:

  • If the evidence supports it, we use it and proceed.
  • If the evidence points elsewhere, we reclassify and flag it on the result.
  • We surface the original hint and the final classification so you can reconcile the two (useful if your internal system needs to update the case).

In the transitional period described in Getting Started and How Evaluations Work, sending a category is still required by the API Reference. That requirement goes away once the backend schema update lands; the classifier logic above already runs today.

What's on the result​

{
  "id": "eval_7d9e1f",
  "category": "fraud",
  "confidence": "high",
  "reason_code": "4837",
  "failed_checks": []
}
  • category — the final classification Triple settled on
  • reason_code — the scheme-facing reason code we propose, when the evidence is precise enough to map to one; null otherwise
  • failed_checks — any missing or weak evidence, including cases where the classifier wanted specific evidence that was not provided

Reclassification signals​

When Triple overrides a category hint, the response makes that explicit. (Final field shapes are still settling — refer to the API Reference when relying on these for automation.)

  • classified_from_hint: false — the category on the result doesn't match the hint you sent
  • original_hint: "service_not_received" — the category you sent, preserved for your records

See also​