Card dispute & chargeback handling automation

A cardholder disputes a payment; the scheme rules give the merchant (or the issuer) a few days to respond with exactly the right evidence. Most merchants either ignore small disputes or burn analyst hours on manual evidence collection. An agent reads the reason code, pulls evidence from commerce, shipping and support systems, decides whether to fight or refund, and drafts the response before the deadline. Issuers use the same pattern to triage claims and auto-resolve the clear ones.

Problem & value

• Today (merchant/PSP): a chargeback arrives via the acquirer or PSP dashboard/API with a reason code and a response window of days. Staff look up the order, find proof of delivery, screenshots, IP and login logs, past undisputed orders, and write a rebuttal in the format the scheme expects. Low-value disputes are often simply accepted because fighting costs more than the amount.
• Today (issuer): the bank's dispute team gathers the cardholder's story, checks authorisation and 3-D Secure data, picks the right reason code and files with the scheme. Volume is high and mostly repetitive.
• AI value: consistent classification, automatic evidence assembly from many systems, tailored narratives, strict deadline tracking, and a decision on which disputes are economic to fight. It also separates friendly fraud (the cardholder recognises the purchase later) from genuine fraud and from service problems that need a refund or a process fix.
• Evidence of impact: vendors publish win-rate claims (treat as marketing, not independent). Stripe states that Smart Disputes builds evidence packets automatically but does not guarantee outcomes, because the issuer decides [2]. Measure your own baseline.

Variants

• Merchant / e-commerce (card-not-present): fraud (Visa 10.4-type), "product not received", "not as described", subscription cancellation and recurring-billing disputes.
• PSP / acquirer / marketplace: multi-merchant dispute operations, scheme programme monitoring (excess-dispute thresholds), payout and reserve handling.
• Issuer / card processor: cardholder claim intake via app or chat, automatic provisional credit rules, filing to the scheme.
• Pre-dispute deflection: early-warning alerts (Mastercard Ethoca alerts, Visa order-information sharing) let the merchant refund before a chargeback is raised [3].
• Private use: a personal agent could draft a dispute to a card issuer, but there is no meaningful catalogue overlap; see AGENT-019.

How it works

dispute event (PSP webhook / acquirer API / scheme alert)
  -> normalise: scheme, reason code, amount, deadline, payment method
  -> classify: genuine fraud | friendly fraud | service/delivery | duplicate/processing error
  -> economics: win probability x amount vs. fee and effort (tabular model)
  -> decide: auto-refund | accept | fight | escalate to analyst
  -> evidence collection (orders, 3-D Secure, shipping tracking, usage logs, chat history,
     prior undisputed transactions)
  -> draft representment (reason-code-specific template + LLM narrative, fields filled by tools)
  -> human review (above amount threshold or low confidence) -> submit via API before deadline
  -> outcome feedback -> win-rate analytics, root-cause tickets (fulfilment, descriptor, policy)

• Classification: reason codes already give structure; a small classifier or LLM handles the free-text cardholder claim and mismatches between code and facts.
• Evidence agent: tool-calling over order system, carrier APIs, helpdesk and product logs. Each evidence item is cited by source so the reviewer can verify it.
• Compelling-evidence logic: Visa Compelling Evidence 3.0 lets a merchant show prior undisputed transactions with matching identifiers (reported as two or more in a 120-365-day window) to shift liability on card-absent fraud claims; exact rules and recent extensions must be verified in current Visa rules [1].
• Human-in-the-loop: high-value cases, novel patterns, and every issuer-side final denial are reviewed; the agent never invents evidence and flags missing items.

Data preparation

Merchant side: orders, delivery and tracking proofs, customer communication, refund history, terms accepted at checkout, logs (IP, device) from the shop, ERP and PSP. Issuer side: transaction data, card-holder contact history and dispute case files. In an SMB this data is scattered across shop system, ERP, shipping portal, mailbox and PDFs; typical gaps are missing delivery proofs, evidence that is not linked to the order number, unlabelled past disputes and tight deadlines.

Preparation steps: - Connect shop, ERP, PSP and shipping data by order and transaction ID, see PREP-005. - Export past disputes with reason code and outcome as labels, see PREP-020 and PREP-019. - Collect winning evidence packages as templates, see PREP-016. - Digitise paper proofs such as signed delivery notes, see PREP-006 and DOC-014. - Pseudonymise exports used for testing, see PREP-022.

Tools: PSP and shop APIs, an OCR/document parser, a simple database. Rough share of effort: about 30 percent, mainly joining evidence sources and labelling history. Use GUIDE-003 for a readiness check.

Implementation paths

Which path for whom

• SMB (A): Payment providers and chargeback services offer built-in dispute tooling with scheme rules and deadlines maintained for you, which fits standard merchant needs.
• Enterprise (B): Issuers, large merchants and PSPs need integration with core systems, own risk rules and evidence sources, so a build on cloud APIs in an EU region fits.
• Developer (B): Cloud LLMs plus a classifier and evidence connectors are the quickest route to a working representment pipeline.

Path A - Buy (recommended)

• PSP-native: Stripe Smart Disputes (rules engine builds and can auto-submit packets; API field intended_submission_method controls who submits) [2]; Adyen, Checkout.com and Worldpay offer dispute-management tooling and APIs.
• Specialist dispute platforms: Chargeflow, Justt, Quavo (issuer and merchant dispute automation), Chargebacks911, Verifi (Visa) and Ethoca (Mastercard) alert networks [3]. Mostly US/UK vendors; check EU data residency and DPA. EU-based PSPs: Adyen (NL), Mollie (NL), Nexi, Worldline (FR) with their own dispute workflows.
• Issuer platforms: Mastercard's dispute-resolution integration with Salesforce, and core-banking dispute modules [4].
• Choose A when: you use a mainstream PSP and need results in weeks; most SMBs.

Path B - Build on cloud APIs

• PSP dispute webhooks and APIs (Stripe, Adyen, Checkout.com) plus a frontier LLM with structured outputs (Claude, Gemini, GPT, or Mistral as EU provider; EU regions via Azure OpenAI, Vertex AI, Bedrock).
• Orchestration with n8n or a custom service; evidence connectors to shop (Shopify, Shopware, Magento), carriers and helpdesk.
• Choose B for custom policy logic, multiple PSPs or industry-specific evidence (digital goods, travel, SaaS).

Path C - Self-host (open source)

• Open-weight LLMs (e.g. Mistral, Qwen, Llama families) on vLLM or Ollama for narrative drafting; scikit-learn/XGBoost for win-probability; Docling or PaddleOCR for proof-of-delivery documents; n8n or Camunda for the workflow.
• Hardware HW2 is enough for case volumes of thousands per month. Needed only if dispute data (cardholder details) must stay on-prem, e.g. issuers and banks.

Path D - Custom training

Fine-tune a classifier or win-probability model on your own history of fought disputes and outcomes (a few thousand labelled cases). LLM fine-tuning is rarely needed.

State of the art (2026)

• Productised automation: PSPs auto-generate and auto-submit evidence; specialists claim fully autonomous representment for eligible reason codes [2].
• Scheme-side data sharing: order-level data shared with issuers (Visa and Mastercard programmes) lets issuers decline invalid claims earlier or lets merchants refund proactively [3].
• Agents add value in evidence collection across messy systems and in writing reason-code-specific narratives; the decision on whether to fight is better handled by a calibrated model.
• Limits: the issuer decides; win rates vary strongly by reason code, vertical and evidence quality. Agents fail when source data is missing (no tracking, no signed delivery), and hallucinated evidence in a representment is a compliance and credibility risk. Scheme rules change frequently, so rule tables must be maintained and versioned. Fighting every dispute can be uneconomic.

Shared resources & combinations

• Fraud signals: ANOM-001 (authorisation-time fraud scores feed the fight/refund decision), ANOM-022 (scam patterns).
• Document/evidence extraction: DOC-001 stack (ocr-docparse, workflow-automation); ANOM-017 for tampered proof documents.
• Customer conversation: CONV-013 (banking assistant takes the cardholder claim at the issuer).
• Related processes: AGENT-014 (claims handling pattern), AGENT-023 (deductions and collections), AGENT-011 (customer data hygiene for identifiers used as evidence).

Effort, cost & KPIs

• Path A: days to weeks; typically a share of recovered amounts or a per-dispute fee (check vendor terms).
• Path B: 1-3 months incl. connectors and rule tables; ongoing scheme-rule maintenance.
• Path C: 2-4 months, one GPU server plus operations.
• KPIs: win/recovery rate by reason code, chargeback ratio (disputes / transactions), response-on-time rate, cost per dispute, share handled without analyst, refund-before-dispute rate, friendly-fraud share, root-cause fixes shipped.

People & change

Involve management (win-rate and refund policy), the department lead of payments or customer service, end users who handle disputes, IT and IT security (payment data, PCI DSS scope) and the data owners of shop, ERP and PSP data. The data protection officer should confirm legal basis and sign AVVs with providers; a DPIA is usually not needed for plain merchant evidence handling but check it for scoring or large-scale issuer use (GUIDE-005).

Works council: depends. The case-handling tool typically logs which employee processed which case, which can make §87(1) no. 6 BetrVG apply; §90(1) no. 3 requires early information when work processes change. If in doubt, agree briefly on no individual performance evaluation (GUIDE-004).

Support AI literacy (Art. 4 AI Act) through a short training on reason codes, review of AI drafts and escalation (GUIDE-006). Start with a pilot on one reason code and a small team (GUIDE-009). Typical concern: wrongly contested or wrongly accepted disputes. Address it with human approval of every submission at first, a measured win rate and a clear fallback to manual handling (GUIDE-011). On the issuer side, customers must always be able to reach a human.

Risks, regulation & compliance

• EU AI Act: minimal risk; no Annex III category (creditworthiness scoring is not involved). Staff AI literacy (Art. 4) applies. If an issuer used the agent to profile customers for credit decisions or account closure, reassess [5].
• GDPR: disputes contain cardholder identity, purchase history, IP and communications. Lawful basis is typically contract/legitimate interest; limit evidence to what the scheme requires, set retention, sign DPAs with PSP and AI vendors, check transfers outside the EU [6].
• Payments law: PSD2 (Directive 2015/2366) governs unauthorised transactions, refund rights and strong customer authentication; 3-D Secure data is key evidence. Scheme rules are contractual and change often [7].
• Automated decisions: an issuer's auto-denial of a cardholder's claim may be a decision with significant effect (GDPR Art. 22): keep human review and a route to contest.
• Risks: fabricated or unsupported evidence, wrong deadlines, refunds issued to fraudsters, bias against specific customer groups in friendly-fraud flags. Mitigations: cite-only-verified evidence, deadline monitoring, audit log, sampling QA, threshold-based human approval.

Getting started

1. Export 6-12 months of disputes: reason code, amount, outcome, evidence submitted; compute win rate and cost per dispute.
2. Turn on your PSP's native tools (e.g. Smart Disputes or equivalent) and compare against manual outcomes on one reason-code group.
3. Add early-warning alerts and refund rules for low-value, high-probability-loss cases.
4. Build or buy evidence connectors for order, delivery and support data; fix missing-data gaps first.
5. Add root-cause reporting (descriptor confusion, delivery failures, cancellation flow) to cut inbound disputes.

Sources

1. Chargeflow - Visa Compelling Evidence 3.0 explained (vendor; verify against Visa rules) - https://www.chargeflow.io/blog/visa-compelling-evidence-3-0-explained
2. Stripe - Smart Disputes docs - https://docs.stripe.com/disputes/smart-disputes
3. Chargebacks911 - Mastercom Collaboration / Ethoca alerts overview - https://chargebacks911.com/mastercom-collaboration/
4. Mastercard - Mastercard and Salesforce transaction-dispute integration (2024) - https://newsroom.mastercard.com/news/press/2024/may/mastercard-and-salesforce-announce-new-integration-to-transform-transaction-disputes
5. Regulation (EU) 2024/1689 (AI Act) - https://eur-lex.europa.eu/eli/reg/2024/1689/oj
6. Regulation (EU) 2016/679 (GDPR) - https://eur-lex.europa.eu/eli/reg/2016/679/oj
7. Directive (EU) 2015/2366 (PSD2) - https://eur-lex.europa.eu/eli/dir/2015/2366/oj
8. Stripe - Set up Smart Disputes - https://docs.stripe.com/disputes/set-up-smart-disputes