# Examples — Payment Dispute & Chargeback Agent

## Duplicate charge → refund within policy

A clear merchant error: the cardholder was charged twice. Within the auto-refund cap and a valid reason code.

**Input**

```
Dispute: $42.00 at 'BREWHAUS COFFEE' on 2026-06-10. Cardholder: 'I was charged twice for one order.' Card ending 4417.
```

**Output**

```
{
  "reason_code": "12.6 Duplicate Processing (Visa) — same transaction charged more than once",
  "hypothesis": "merchant_error",
  "confidence": 0.92,
  "evidence": ["transaction_lookup: two identical $42.00 auths to MID BREWHAUS 2026-06-10 14:02 and 14:03", "customer_history: no prior disputes, 3y tenure, regular at this merchant"],
  "decision": "REFUND",
  "amount_usd": 42.00,
  "actions": [ { "tool": "issue_refund", "args": { "amount_usd": 42.00, "reason": "duplicate_processing" }, "requires_approval": false } ],
  "customer_note": "We reviewed your dispute and confirmed a duplicate $42.00 charge from June 10. We've refunded the duplicate; it should post to your account within a few business days.",
  "analyst_note": "Clear duplicate (two identical auths one minute apart). Reason 12.6. $42 within cap; auto-refunded. No fraud signals.",
  "escalation": { "needed": false, "reason": "" }
}
```

**Note:** The clean case the kit is meant to clear instantly: two identical auths a minute apart is unambiguous merchant error, within cap and a valid reason, so it refunds and documents. Note the customer note is factual and contains no accusation.

## Friendly fraud → assemble representment evidence

The cardholder disputes a charge as 'never received,' but the evidence shows they got it. The agent challenges with proof rather than refunding.

**Input**

```
Dispute: $310.00 at 'PEAK GEAR' on 2026-05-28, reason 'merchandise not received.' Card ending 4417.
```

**Output**

```
{
  "reason_code": "13.1 Merchandise/Services Not Received (Visa)",
  "hypothesis": "friendly_fraud",
  "confidence": 0.81,
  "evidence": ["transaction_lookup: AVS+CVV match, in-person device fingerprint matches cardholder's usual", "evidence: carrier delivery confirmation to the cardholder's verified billing address, signed 2026-05-30", "customer_history: 4 prior orders from PEAK GEAR delivered to same address, none disputed"],
  "decision": "REPRESENT",
  "amount_usd": null,
  "actions": [
    { "tool": "evidence_assemble", "args": { "reason_code": "13.1", "items": ["delivery_confirmation", "avs_cvv_match", "prior_usage"] }, "requires_approval": false },
    { "tool": "escalate_to_analyst", "args": { "queue": "representment_review", "recommendation": "file" }, "requires_approval": true }
  ],
  "customer_note": "",
  "analyst_note": "Likely friendly fraud: signed delivery to the verified billing address, AVS/CVV match, and 4 prior undisputed orders to the same address. Assembled 13.1 representment package; recommend filing. Network deadline 2026-06-25.",
  "escalation": { "needed": false, "reason": "" }
}
```

**Note:** This is where the kit earns its keep: rather than reflexively refunding a 'not received' claim, it cites delivery confirmation to the verified address plus prior usage and assembles a network-compliant representment package — but leaves the actual filing for human approval, and tracks the deadline.

## Account-takeover pattern → escalate and protect, don't refund

A dispute that looks routine but sits inside a fraud pattern. The agent refuses to treat it as a simple refund.

**Input**

```
Dispute: $1,890.00 at an electronics merchant, reason 'I didn't make this charge.' Card ending 4417.
```

**Output**

```
{
  "reason_code": "10.4 Other Fraud — Card Absent Environment (Visa)",
  "hypothesis": "true_fraud",
  "confidence": 0.7,
  "evidence": ["fraud_signals: login from a new device + new geo 40 min before the charge; password changed 2h prior", "transaction_lookup: ships to an address never used by this account; CVV mismatch", "customer_history: 3 other card-not-present charges to unfamiliar merchants in the last hour"],
  "decision": "ESCALATE",
  "amount_usd": null,
  "actions": [
    { "tool": "escalate_to_analyst", "args": { "queue": "fraud_atо", "priority": "high", "recommend": ["freeze_card", "reverse_session", "verify_cardholder"] }, "requires_approval": false }
  ],
  "customer_note": "Thanks for flagging this — we're treating it as potential fraud on your account and a specialist will contact you shortly to secure it.",
  "analyst_note": "Likely account takeover: new-device/new-geo login + password change preceding a burst of CNP charges to unfamiliar merchants and addresses; CVV mismatch on the disputed item. Recommend freezing the card and verifying the cardholder BEFORE processing refunds. Over cap and fraud-pattern — do not auto-refund.",
  "escalation": { "needed": true, "reason": "Account-takeover pattern + amount over cap" }
}
```

**Note:** The defining example: a 'didn't make this charge' dispute is over the cap and embedded in an account-takeover pattern, so the agent escalates and recommends freezing the card and verifying the cardholder rather than quietly refunding one transaction while the account is still compromised. Fraud is handled as a security event, not a refund.
