Chargeback & Dispute Management System Architecture (2026)

A chargeback is not a support ticket. It is a distributed, deadline-bound state machine whose transitions are dictated by card-network rulebooks, whose inputs arrive as batch files and webhooks from three counterparties at once, and whose failure mode is silent, automatic financial loss. Build chargeback dispute management as an afterthought — a queue, a folder of screenshots, a human who remembers to respond — and you will lose winnable cases to expired timers and misclassified reason codes long before you lose them on the merits. The interesting engineering problem is not “should we fight this dispute.” It is modeling an adversarial, asynchronous, rule-versioned workflow so that every case advances deterministically and no deadline is ever missed by accident.

This is a systems and architecture analysis, not financial, legal, or compliance advice; validate any rule, fee, or deadline against current card-network publications and your acquirer before acting.

What this covers: the end-to-end dispute lifecycle as a state machine, the card-network reason-code taxonomy and how to normalize it, ingestion of network files and processor webhooks, representment evidence assembly under hard SLAs, pre-dispute alert decisioning, the case-management data model, and the failure modes that quietly drain win rates.

Context and Background

The dispute rails predate almost every system that now sits on top of them. Regulation Z and the Fair Credit Billing Act gave U.S. cardholders the right to dispute charges in the 1970s; the card networks operationalized that right into the chargeback, a mechanism for an issuing bank to forcibly reverse a settled transaction and claw the funds back from the acquiring bank, which in turn debits the merchant. Everything a modern dispute management system does is an attempt to automate a merchant’s side of a process the networks designed around banks and paper.

Two rulebooks dominate. Visa restructured its process into Visa Claims Resolution (VCR), which went into effect in April 2018 and collapsed roughly twenty-two legacy reason codes into four dispute categories routed through two workflows — Allocation and Collaboration (Visa). Mastercard runs a parallel model documented in its Chargeback Guide, with four-digit reason codes and an explicit second-presentment, pre-arbitration, and arbitration ladder (Mastercard Chargeback Guide). American Express and Discover, as three-party networks, run their own variants. A dispute system has to speak all of these dialects while presenting one internal model to the business.

The incumbents in this space are chargeback-management vendors and the dispute modules bundled into payment orchestration platforms and processors. Most large merchants historically bolted a third-party service onto their payment orchestration platform and treated disputes as an outsourced back office. What has changed by 2026 is the rise of network-native pre-dispute tooling — Visa’s Verifi and Mastercard’s Ethoca — that lets you intercept a dispute before it becomes a chargeback at all. That shifts the architecture from a purely reactive representment engine to a real-time decisioning system that has to choose, within seconds, whether to refund, deflect, or fight. The rest of this piece treats that decision as a first-class design concern.

Reference Architecture for a Dispute Management System

A dispute management system has one job that everything else serves: take a case from the moment a dispute signal arrives to a terminal, reconciled outcome, without ever losing the case to a missed deadline or a lost document. Concretely, that means an ingestion layer that normalizes heterogeneous inputs into a canonical case, a state machine that governs every legal transition, a decision engine that chooses accept-versus-fight-versus-deflect, an evidence assembler that builds representment packets, and a set of timers that make deadlines a property of the system rather than a human’s memory.

Figure 1: Reference architecture — network files and processor webhooks feed an ingestion and normalization layer, a case state machine backed by a case store, a decision engine informed by the fraud system and reconciliation, and an evidence assembler that emits representment submissions through the acquirer.

In the diagram, dispute signals enter from the left through two fundamentally different transports: bulk network files (Visa’s VROL/Visa Resolve Online exports and Mastercard’s Mastercom) and near-real-time processor webhooks. The ingestion layer deduplicates and time-stamps them, the normalizer maps every network-specific reason code into an internal taxonomy, and the case state machine becomes the single writer to the case store. The decision engine reads from the fraud system and the reconciliation ledger; the SLA timer service and reconciliation feed events back into the state machine. Outbound submissions flow to the acquirer gateway, and pre-dispute alerts are handled on a separate real-time path.

The state machine is the system of record

The most important design decision is to model the case as an explicit finite state machine with the network as an adversarial actor, not as a status column you mutate ad hoc. Every card-network transition — inquiry, first chargeback, representment, pre-arbitration, arbitration, ruling — becomes a named state with an enumerated set of legal successors and a guard condition. A transition is only permitted if the current state allows it, the network deadline has not lapsed, and the required artifacts exist. This makes illegal transitions unrepresentable and turns “we responded twice by accident” or “we escalated a case that was already closed” into compile-time or validation-time errors rather than production incidents.

Ingestion must be idempotent and reconciled

The same dispute can appear in a processor webhook and, hours later, in a network file. Ingestion therefore needs a deterministic case key — typically a composite of acquirer reference number, card network, original transaction identifier, and dispute sequence — so that the second arrival updates the existing case rather than forking a duplicate. Duplicate cases are not a cosmetic problem: they cause double responses, which networks reject, and they corrupt the dispute-rate metrics that govern your standing in network monitoring programs. Ingestion is also where you attach the financial context by joining to the original transaction in your reconciliation engine, so the case carries the settled amount, currency, and clearing record from the first moment.

The decision engine sits between rules and economics

Once a case is normalized and its state is known, the decision engine answers the only question that matters commercially: what do we do with this. That decision is a function of the reason code, the strength of available evidence, the dispute amount net of representment cost, the customer’s history, and a fraud-system verdict on whether the underlying transaction was genuinely fraudulent. Crucially, the decision engine is not the state machine — it recommends a transition; the state machine validates and executes it. Keeping recommendation and execution separate lets you A/B test decision logic, replay historical cases against a new policy, and audit why any given case was accepted or fought.

The Dispute Lifecycle as a State Machine

The lifecycle is where abstract architecture meets the rulebook. A dispute begins its life either as a retrieval request (an issuer asking for transaction detail, increasingly rare) or directly as a first chargeback, and it ends in one of a small number of terminal states: accepted loss, dispute won, or a binding network ruling. Between those poles the case can bounce through representment, pre-arbitration, and arbitration, with strict deadlines gating each hop.

Figure 2: The dispute lifecycle state machine — a settled transaction can receive a retrieval request or a first chargeback; a triage decision routes to accepted loss or representment; representment either wins or escalates to pre-arbitration, then arbitration, then a binding network ruling.

Read the state machine as a directed graph with guarded edges. From “first chargeback,” the triage decision is the only outbound branch that a merchant controls: accept and eat the loss, or represent. From “representment submitted,” control passes back to the issuer, which can accept your evidence (you win) or reject it and file pre-arbitration. Pre-arbitration is a genuine negotiation state — you can concede or hold — and only unresolved cases proceed to arbitration, where the network itself rules and the loser pays the arbitration fee. Modeling each of these as a first-class state, rather than as free-text status, is what lets you attach the correct deadline, the correct required evidence, and the correct set of legal next actions to every case.

Direct-answer: how a dispute system models the lifecycle

A dispute management system models the chargeback lifecycle as a deterministic finite state machine: each card-network stage — inquiry, first chargeback, representment, pre-arbitration, arbitration, ruling — is an explicit state with guarded transitions, a hard response deadline, and a required-evidence set, so that no case can advance illegally or silently miss a network deadline.

Visa and Mastercard map to the same abstract states

The internal state machine should be network-agnostic, with network-specific behavior injected as configuration. Under VCR, Visa routes fraud (reason codes beginning 10) and authorization (11) disputes through the Allocation workflow, and processing-error (12) and consumer-dispute (13) categories through Collaboration; Visa also retired the word “representment” in favor of “dispute response.” Mastercard keeps a more classical ladder: first chargeback, second presentment, pre-arbitration, arbitration. Both, however, collapse onto the same abstract states — a dispute, a merchant rebuttal, an escalation, and a ruling. Encoding the abstraction once and mapping each network onto it keeps the core engine small and makes adding a new network a configuration exercise, not a rewrite.

Terminal states must be reconciled, not just closed

A case is not done when you submit evidence; it is done when money has moved to match the outcome and the ledger agrees. A “won” case that was never credited back is an unreconciled receivable, and a “lost” case that was never debited is a liability you have not booked. The state machine therefore treats reconciliation confirmation as the guard on entering a terminal state. This is the tie-in that most naive designs miss: the dispute system and the reconciliation engine are two views of the same money, and closing a case without reconciling it produces books that silently drift from reality.

Reason-Code Taxonomy and Normalization

Reason codes are the dispute system’s type system. They determine which workflow applies, which evidence will be accepted, and how long you have to respond. Getting the normalization layer right is disproportionately valuable because every downstream decision keys off it.

Visa’s post-VCR structure is legible by prefix. Codes beginning 10 are fraud, 11 are authorization, 12 are processing errors, and 13 are consumer disputes — so 10.4 is card-absent fraud, 13.1 is merchandise or services not received, 13.3 is not-as-described, and so on. Mastercard uses four-digit codes beginning 48: 4837 is no-cardholder-authorization fraud, 4853 is a cardholder dispute, 4834 is a point-of-interaction error, and 4808 is authorization-related. American Express and Discover carry their own code sets. The normalization layer’s job is to map all of these onto a small internal enumeration — say, fraud, authorization, processing error, and consumer dispute — while preserving the original code, because representment requirements and deadlines are defined at the original-code granularity.

Map to an internal enum, but never discard the original

A common and costly mistake is to normalize destructively — to store only the internal category and throw away the network’s precise code. The internal category is right for routing and reporting; the original code is right for evidence rules. Visa’s Compelling Evidence 3.0 requirements, for instance, apply specifically to reason code 10.4 and to nothing else. A system that has flattened 10.4 into a generic “fraud” bucket cannot tell whether the CE 3.0 evidence path is even available. Store both: the raw network code as the ground truth, and the internal enum as a derived, indexed projection for workflows and dashboards.

Reason codes drive the evidence contract

Each reason code implies a different burden of proof. A “merchandise not received” consumer dispute is won with proof of delivery to the cardholder’s address; a “not as described” dispute is won with the product description the customer agreed to and evidence the item matched it; a card-absent fraud dispute under CE 3.0 is won with a specific pattern of prior undisputed transactions. Encoding these as declarative evidence requirements — a mapping from reason code to a required set of artifacts — lets the evidence assembler know exactly what to gather before it starts, and lets the decision engine estimate win probability from artifact availability rather than guessing.

Ingesting Dispute Notifications

Disputes arrive through two transports with very different latency and reliability characteristics, and a robust system treats them as complementary rather than choosing one. Network files — Visa Resolve Online exports and Mastercard’s Mastercom — are the authoritative record, delivered on the networks’ cadence and complete with the fields required to respond. Processor and gateway webhooks are faster but are notifications, not the full case; they tell you a dispute exists so you can start the clock, but you often still fetch authoritative detail from the network system.

The ingestion design principle is to make the network file the source of truth and the webhook an early-warning trigger. When a webhook lands, create or update the case, start the SLA timer conservatively from the earliest known dispute date, and mark the case as “awaiting authoritative detail.” When the network file arrives, reconcile it against the webhook-seeded case using the deterministic case key, promote it to “detail complete,” and recompute the deadline from the network-stated date. This two-phase ingestion buys you response time — you begin evidence gathering hours or days earlier — without ever responding on incomplete data.

Idempotency is non-negotiable here. Files get re-sent, webhooks get retried, and the same dispute can surface under slightly different identifiers across processor and network. The composite case key and an idempotency table of already-seen event fingerprints prevent duplicates. Every ingestion event should also be persisted raw, before parsing, so that a mapping bug can be replayed against the original bytes rather than lost — dispute rules and file formats drift, and last quarter’s parser may misread this quarter’s file.

Representment: Evidence Assembly Under a Clock

Representment — Visa’s “dispute response,” Mastercard’s “second presentment” — is where the system earns its keep, and it is fundamentally a race against a deadline. The chargeback representment workflow has to classify the case, resolve the exact evidence contract for its reason code, gather artifacts from systems that may be slow or occasionally down, assemble a compliant packet, and submit it through the acquirer before the network’s response window closes.

Figure 3: Evidence assembly under an SLA timer — a received chargeback starts a timer and is classified; the reason code resolves an evidence-requirements set; order data, AVS/CVV/3-D Secure records, delivery proof, and prior-transaction history are pulled and assembled into a packet; a deadline-safety gate either submits the response or escalates to auto-accept.

The flow in Figure 3 makes the timer a structural element, not a reminder. The moment a chargeback is received, a countdown starts; classification resolves the evidence requirements; the puller fetches order data, authorization artifacts (AVS and CVV results, 3-D Secure authentication records), delivery proof, and prior-transaction history in parallel; and a deadline-safety gate decides whether there is still enough runway to submit. If the gate finds the deadline unsafe — evidence incomplete with too little time left — it escalates to a deliberate decision rather than letting the case drift into an automatic, unfought loss.

Compelling evidence is a data-assembly problem, not a writing problem

Winning a card-absent fraud dispute in 2026 is largely mechanical if you have the data. Visa’s Compelling Evidence 3.0, effective April 15, 2023, defines a precise, checkable standard for reason code 10.4: you must show two prior transactions by the same cardholder that were undisputed, that occurred between 120 and 365 days before the disputed transaction, that used the same payment credential and the same merchant descriptor, and that share matching identifiers with the disputed order — with at least one match being the device ID or IP address, alongside elements like a login ID or shipping address (Visa CE 3.0 merchant readiness). Notice what this is: a query over your own transaction history joined to identity signals. A dispute system that has indexed transactions by cardholder credential, device fingerprint, and IP can evaluate CE 3.0 eligibility automatically and assemble the qualifying pair without a human reading anything. The evidence assembler is, in effect, a specialized query planner over your order and identity data.

Authorization artifacts decide many cases before evidence is written

For a large share of disputes, the outcome is determined by what happened at authorization time. If a transaction was authenticated through 3-D Secure and the issuer accepted the authentication, liability for fraud generally shifts to the issuer, and a fraud chargeback should not stand. If AVS returned a full match and the transaction was card-present with a chip read, a “no authorization” claim is weak. This is why the evidence assembler pulls authorization records as a distinct artifact class: the 3-D Secure authentication value, the AVS and CVV response codes, and the electronic commerce indicator are frequently dispositive. Systems that capture and retain these at authorization — and can retrieve them months later when the dispute lands — win cases that under-instrumented competitors lose.

The submission itself must be network-compliant and reconciled

Assembling the right evidence is necessary but not sufficient; the packet has to satisfy the network’s format, size, and field requirements, submitted through the acquirer’s channel. A representment that exceeds a document limit, omits a mandatory field, or lands in the wrong workflow is rejected on technicality regardless of merit. After submission, the case moves to “awaiting issuer response,” and only when the outcome returns and reconciliation confirms the funds movement does it reach a terminal, reconciled state.

Trade-offs, Gotchas, and What Goes Wrong

The failure modes of a dispute system are specific, recurring, and mostly silent — which is exactly what makes them dangerous. Nothing pages you when a winnable case slips past its deadline; the money simply never comes back.

Missed deadlines are the dominant loss driver. The single most expensive bug is a case that reaches its response window without a submission. It happens when the timer starts from the wrong date (webhook date versus network date), when a downstream evidence system is slow and no one budgeted slack, or when the queue depth exceeds human capacity and cases silently age out. The mitigation is architectural: make the deadline a monotonic timer owned by the system, escalate at fixed fractions of the window (for example, alert at fifty percent elapsed, force a decision at seventy-five percent), and treat “auto-accept because we ran out of time” as an explicit, logged decision rather than an accident.

Reason-code misclassification poisons everything downstream. Because the reason code drives workflow, deadline, and evidence, a mapping error routes the case into the wrong evidence contract and often the wrong deadline. Network rule drift makes this worse: reason-code definitions, evidence requirements, and workflow assignments change on the networks’ schedules, and a normalization table that was correct last year can quietly misroute this year. Version the mapping table, treat network releases as change events, and keep the raw code so a re-mapping can be replayed.

Evidence gaps are usually instrumentation debt. The reason a dispute is unwinnable is rarely that the evidence never existed; it is that it was never captured or retained. Delivery confirmations expire from carrier APIs, 3-D Secure results are not persisted with the transaction, device fingerprints are not linked to orders. These gaps surface only at dispute time, weeks or months later, when they can no longer be filled. The fix belongs upstream, at authorization and fulfillment, not in the dispute system — but the dispute system’s win-rate metrics are what make the gap visible.

Deflection can cannibalize winnable cases. Auto-refunding through a pre-dispute rule is only rational when the expected cost of fighting exceeds the dispute amount plus the fee. Set the rule too aggressively and you refund transactions you would have won, and you may still accrue the dispute-count signal you were trying to avoid. Set it too conservatively and you pay representment costs on cases you will lose anyway. The decision belongs to an explicit, tunable policy, not to a default.

Pre-Dispute Alerts and Refund-versus-Fight Decisioning

The most consequential architectural shift of the last few years is that you no longer have to wait for a chargeback to act. Network-native pre-dispute programs let a merchant intercept a dispute at the inquiry stage. Visa’s Verifi offers Order Insight, which pushes rich transaction detail to the issuer so a confused cardholder never disputes, and Rapid Dispute Resolution (RDR), which applies merchant-defined rules to refund eligible disputes automatically and in real time. Mastercard’s Ethoca network delivers alerts of impending disputes and, through Consumer Clarity, surfaces purchase detail at the issuer (Verifi RDR).

Figure 4: Pre-dispute decisioning — an issuer inquiry is routed by network; Visa RDR evaluates merchant rules and either auto-refunds or routes to representment; an Ethoca alert is queued and passed through a value-versus-fee check that either refunds or lets the case flow to a full dispute; deflected cases close early.

The decisioning path in Figure 4 is where refund-versus-fight becomes a real-time computation. For a Visa RDR case, your rules — dispute amount thresholds, product categories, customer history — are evaluated in the moment; a match triggers an automatic refund that clears the amount before a chargeback can form, and a non-match routes the case into the normal representment path. Ethoca alerts, being notifications rather than auto-refund instruments, land in a queue where a value-versus-fee check decides whether to refund proactively or let the case proceed to a defensible dispute. The pre-dispute alerts layer is thus a fast, rule-driven front end sitting in front of the slower, evidence-driven representment engine.

The decision matrix: accept, represent, or alert-refund

The core commercial decision reduces to a matrix over two axes: how strong is the evidence, and how large is the amount relative to the cost of acting. The following captures the logic a decision engine should encode.

Scenario	Evidence strength	Recommended action	Rationale
Genuine fraud confirmed by fraud system	N/A — you would lose	Accept (or alert-refund pre-dispute)	Fighting spends money to lose; deflect early to avoid the dispute signal
Friendly fraud, CE 3.0 pair available	Strong	Represent	Mechanical win; the qualifying transaction history exists
Consumer dispute, delivery proof on hand	Strong	Represent	Proof of delivery to cardholder address typically prevails
Low-value dispute, weak or missing evidence	Weak	Accept or alert-refund	Representment cost approaches or exceeds recovery
High-value dispute, partial evidence	Moderate	Represent with best packet	Expected value positive despite uncertainty
Recurring customer, low value, pre-dispute inquiry	Any	Alert-refund via rule	Preserve the relationship and avoid dispute-rate impact cheaply

The matrix is illustrative and must be tuned to your own win rates and costs; the point is that the choice is computable, not a matter of case-by-case intuition. Feed the decision engine the reason code, the evidence-availability signal from the assembler, the amount, the fraud verdict, and the customer history, and it can produce a defensible recommendation that the state machine then executes.

A worked SLA and timer reasoning passage

Consider the timer arithmetic that governs a single case, using illustrative windows — always confirm the real numbers against current network rules and your acquirer. Suppose a Mastercard first chargeback lands with a second-presentment window of, illustratively, 45 days, and your evidence systems have a worst-case retrieval latency of two days for carrier delivery confirmation. If your policy is to never submit in the final safety buffer, you might reserve the last five days for acquirer transit and manual review. That leaves an effective working window of 45 minus 5 minus 2, or 38 days, from the network-stated dispute date — not from the webhook date, which may be a day or two earlier and would make the timer wrong in the dangerous direction if used naively.

Now layer the escalation ladder onto that window. The system alerts an analyst at 50 percent elapsed (day 19), forces a decision at 75 percent (day 28), and treats any case still lacking a complete packet at 85 percent as a candidate for deliberate auto-accept rather than a passive timeout. The critical property is that the deadline is computed from an authoritative date, decremented by known system latencies, and enforced by the state machine — so the worst outcome is a logged, intentional accept, never a silent, accidental loss. This is the difference between a dispute system that degrades gracefully under load and one that hemorrhages winnable cases the moment volume spikes.

The Case-Management Data Model

Underneath the workflow sits a data model that has to represent an adversarial, multi-round, multi-party process without losing history. At its center is the case entity, keyed by the composite case key and carrying the current state, the network, the raw and normalized reason codes, the disputed amount and currency, and pointers to the original transaction. Around it hang three important satellite structures.

First, an append-only event log — every state transition, every ingestion event, every submission, every network response — because disputes are audited and because you will need to replay a case’s history to debug a lost one. Second, an evidence collection: typed artifacts (delivery proof, authorization records, prior-transaction references, customer communications) with provenance and retrieval timestamps, so the assembler knows what it has and the auditor knows where it came from. Third, a timers table binding each active case to its computed deadline and escalation checkpoints, driven by the SLA timer service.

Two design rules keep this model honest. The state machine is the only writer to the case’s state field, which prevents concurrent updates from corrupting the workflow. And the event log is the source of truth from which the current state is a materialized projection, so that a bug in state handling can be corrected by replaying events rather than by guessing at a mutated status column. This is the same discipline that makes a real-time fraud detection system auditable, and for the same reason: when money and rules are both in play, you must be able to reconstruct exactly why the system did what it did.

Metrics, Monitoring Programs, and Feedback

A dispute system that does not measure itself cannot improve, and the metrics are also externally consequential because the networks watch them. The two headline numbers are the dispute rate — disputes as a share of transactions, the metric that governs standing in network monitoring programs — and the win rate — the share of represented cases resolved in the merchant’s favor. Crossing a network’s dispute-rate threshold moves a merchant into a monitoring program with escalating scrutiny and fees, so the dispute rate is not just a KPI; it is a compliance boundary. The specific thresholds are set by each network and change over time; treat published figures as illustrative and confirm the current values.

Under those headline numbers sit the operational metrics that actually let you act: response rate (are we submitting on every winnable case), deadline-miss rate (are timers holding), win rate segmented by reason code (where is our evidence strong or weak), and deflection efficiency (are pre-dispute refunds net positive). Segmenting win rate by reason code closes the loop back to instrumentation: a chronically low win rate on “merchandise not received” points at a delivery-proof capture gap upstream, not at the dispute system itself. The metrics are the sensor that tells you where the real defect lives.

Practical Recommendations

Treat the dispute lifecycle as an explicit state machine from day one. Retrofitting one onto a status-column design is far more painful than building it in, and the state machine is what makes every other guarantee — no illegal transitions, no missed deadlines, reconciled terminal states — possible.

Make deadlines a system property. Own the timer in a dedicated service, compute it from the authoritative network date minus known latencies, escalate at fixed fractions of the window, and log every auto-accept as a decision. A missed deadline should be structurally impossible without an audit trail explaining it.

Capture evidence upstream, at authorization and fulfillment, not at dispute time. The cases you lose are usually cases whose evidence expired before the dispute arrived. Persist 3-D Secure results, AVS/CVV codes, device fingerprints, and delivery confirmations with the transaction, and index transactions so CE 3.0 eligibility is a query, not a hunt.

A short checklist for evaluating or building a dispute system:

• Explicit finite state machine, network-agnostic core, network behavior as configuration.
• Idempotent, two-phase ingestion (webhook trigger, network file as source of truth) with a composite case key.
• Non-destructive reason-code normalization: raw code preserved, internal enum derived.
• Declarative reason-code-to-evidence mapping, versioned against network releases.
• SLA timer service with staged escalation and logged auto-accept.
• Pre-dispute alert front end with a tunable refund-versus-fight policy.
• Append-only event log as source of truth; state machine as sole writer.
• Reconciliation confirmation as the guard on terminal states.
• Win rate segmented by reason code, feeding upstream instrumentation fixes.

Frequently Asked Questions

What is the difference between a chargeback and a dispute?

A dispute is the broad process by which a cardholder challenges a transaction; a chargeback is the specific mechanism the card networks use to reverse funds during that process. A dispute can begin as an inquiry or a pre-dispute alert and may be resolved by a refund before any chargeback exists. A chargeback is the formal, funds-moving event initiated by the issuing bank. In system terms, “dispute” names the whole lifecycle and “first chargeback” names one particular state within it.

How does a system decide whether to fight or accept a chargeback?

A decision engine computes it from the reason code, the strength of available evidence, the disputed amount net of representment cost, a fraud-system verdict, and customer history. When the evidence is strong and the amount justifies the effort, it represents; when the transaction was genuine fraud or the evidence is missing and the amount is small, it accepts or deflects with a pre-dispute refund. The logic is an explicit, tunable policy — a decision matrix — rather than case-by-case human intuition, so it can be tested and audited.

What are card-network reason codes and why do they matter?

Card-network reason codes are standardized identifiers that state why a transaction was disputed, and they drive everything downstream. Visa uses prefixes — 10 for fraud, 11 for authorization, 12 for processing errors, 13 for consumer disputes — while Mastercard uses four-digit codes beginning 48. The code determines which workflow applies, what evidence the network will accept, and how long the merchant has to respond, so a misclassified reason code routes a case into the wrong evidence contract and often the wrong deadline.

What is Compelling Evidence 3.0 and how does a system use it?

Compelling Evidence 3.0 is a Visa standard, effective April 2023, that lets a merchant reverse a card-absent fraud dispute under reason code 10.4 by showing a specific pattern of prior undisputed transactions by the same cardholder — two transactions 120 to 365 days before the disputed one, with the same credential and descriptor and matching identifiers including a device ID or IP address. A dispute system uses it by indexing transactions on cardholder credential, device fingerprint, and IP so it can automatically find the qualifying pair and assemble the evidence without manual review.

How do pre-dispute alerts differ from representment?

Pre-dispute alerts intercept a dispute before it becomes a chargeback; representment fights a chargeback after it has formed. Alerts, delivered through Visa’s Verifi and Mastercard’s Ethoca, let a merchant refund or share transaction detail at the inquiry stage, deflecting the dispute cheaply and avoiding the dispute-rate impact. Representment is the slower, evidence-driven process of submitting compelling evidence to reverse a chargeback already in flight. A mature architecture runs the alert layer as a fast rule-driven front end ahead of the representment engine.

What is the most common reason dispute systems lose winnable cases?

Missed deadlines and evidence gaps, both of which are silent. A case that reaches its response window without a submission loses automatically, with nothing to signal the failure; this happens when the timer starts from the wrong date or when queue volume exceeds capacity. Evidence gaps are usually instrumentation debt — 3-D Secure results, AVS codes, or delivery confirmations that were never captured or retained at transaction time and can no longer be recovered when the dispute lands weeks later. Both failures are architectural, not clerical.

Further Reading

• Reconciliation engine architecture for payments and FinTech — how terminal dispute outcomes tie back to the ledger and why closing a case without reconciling it drifts your books.
• Payment orchestration platform architecture — where the dispute module sits relative to routing, processors, and acquirers.
• Real-time fraud detection architecture — the system that supplies the fraud verdict feeding accept-versus-fight decisioning.
• Mastercard Chargeback Guide (Merchant Edition) — primary source for the second-presentment, pre-arbitration, and arbitration ladder and the 48xx reason codes.
• Visa Compelling Evidence 3.0 merchant readiness — primary source for the CE 3.0 evidence standard on reason code 10.4.

By Riju — about