Cards, authorization, and disputes

Authorization and capture — the flow

1. 01AuthorizeRequest issuer approval
2. 02CaptureSubmit collection instruction
3. 03ReconcileMatch the settlement record

Authorization is a request to the issuer within the card workflow. Capture advances an authorized payment toward collection. A merchant may authorize before the final amount is known, capture later, or cancel an unused authorization. Exact validity periods and adjustment rules vary. Model them as product configuration, not a universal constant.

Keep partial capture, reversal, refund, and dispute as distinct events. A refund is not a deletion of the original sale. Record the link between events so a payment that changes state several times is still one commercial story. Otherwise, revenue and fraud counts can both double count the same bicycle.

Consider a hotel that authorizes an estimated stay and captures the final bill later. The authorized amount is a temporary permission or reservation within the payment process; the captured amount follows the completed service. A product that treats the first amount as permanent revenue can misstate both customer availability and merchant receivables. The correct implementation depends on the processor and network contract, including how changes and expiry are handled.

Risk controls must therefore identify the operation they govern. An approval for an initial authorization does not automatically cover every later amount change. Store links between the order, authorization attempts, captures, reversals, and refunds. A single purchase may have several messages, while duplicate messages must not become several purchases. Reconciliation must preserve this distinction.

Inside the mechanism. Treat authorization as a reservation-related message and capture as a later financial operation within the applicable processor and network rules. Do not infer capture from an authorization approval. Model partial captures, reversals, expired authorizations, and refunds as linked operations with their own amounts. For a hotel stay, the original estimate and final bill may differ. The invariant is not one payment row with one amount; it is a traceable relationship among permitted operations and their financial effects.

A concrete example. A hotel authorizes an estimated stay and later captures the completed bill. The authorized amount, captured amount, and available merchant funds are separate quantities. The batch begins with $96,500 of instructions and $92,640.00 of captured value. At the observation cutoff, $2,779.20 remains pending. After the stated refunds, fees, and restrictions, $74,297.28 is available for payout. The unresolved instruction count is 2; an unknown external result is handled separately from a known decline.

When the assumption fails. Incremental charges and expired reservations are collapsed into one paid flag. Link each financial operation to the original stay while preserving its own state. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A hotel authorizes an estimated stay and later captures the completed bill. The authorized amount, captured amount, and available merchant funds are separate quantities.

01Reference conditionHotel authorization batch↗02Failure and stressHotel authorization batch↗03Controlled responseHotel authorization batch↗

Authorization and capture — the distinction

Reversal

• Releases an unused authorization

Refund

• Returns value after a captured payment

Bicycle state journal

Fictional educational excerpt / Not for execution

Bicycle state journal

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Authorized600 USD

   Initial approved amount

2. 2

   Captured550 USD

   Final sale amount

3. 3

   Released50 USD

   Unused authorization portion

The final sale differs from the initial hold

Authorization and capture — control and failure modes

Control design

Both events and their linked amounts. The final sale differs from the initial hold.

Failure mode 1avoid

Only a $600 sale. That overstates the captured amount.

Failure mode 2avoid

Two unrelated orders. The events describe one purchase.

Failure mode 3avoid

A deleted authorization. Deletion loses the state history.

Authentication is one layer — the flow

1. 01ChallengeAsk for stronger proof
2. 02ResultStore the exact response
3. 03DecisionCombine with remaining risks

Authentication tests control of a credential or interaction. It does not prove that a merchant will deliver goods, that a customer was not manipulated, or that every later claim is false. A successful challenge can reduce some uncertainty while leaving other risk intact.

Treat authentication outcomes as structured evidence. Store the method, result, time, and applicable provider fields. Do not infer liability shift from a generic authenticated flag. Network rules, transaction type, and the precise result determine any shift. Customer friction is also a cost: repeated challenges can cause abandonment, especially when recovery paths are poor.

Inside the mechanism. Authentication answers a scoped question about an interaction, not every question about the purchase. Keep the authentication result, method, timestamp, transaction binding, and provider response distinct from the fraud score. A compromised session, manipulated customer, or merchant fulfillment failure can still create harm. When evaluating the layer, compare matched populations and mature outcomes. A change in the population that reaches authentication can otherwise look like a change in authentication quality.

A concrete example. The checkout has an authentication result, transaction evidence, and a later outcome label. A successful authentication is useful evidence but does not settle every loss path. The rule flags 643 of 24,000 card attempts. Of those flags, 288 meet the synthetic target, giving 44.79% precision. It misses 72 target events. Under the stated cost assumptions, residual loss and operating friction total $20,984. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. Degraded context signals make the action rule miss more synthetic fraud and flag more legitimate activity. Evaluate the action policy with mature labels and preserve authentication scope. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The checkout has an authentication result, transaction evidence, and a later outcome label. A successful authentication is useful evidence but does not settle every loss path.

01Reference conditionCard authentication layer↗02Failure and stressCard authentication layer↗03Controlled responseCard authentication layer↗

Authentication is one layer — the distinction

Credential control

• Evidence about access

Purchase legitimacy

• Evidence about the whole transaction

Authentication evidence

Fictional educational excerpt / Not for execution

Authentication evidence

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Challengecompleted

   One positive signal

2. 2

   Delivery addressrecently changed

   Separate risk signal

3. 3

   Liability shiftnot established

   Needs applicable rule evidence

Authentication does not erase other signals

Authentication is one layer — control and failure modes

Control design

Evaluate the remaining transaction context. Authentication does not erase other signals.

Failure mode 1avoid

Approve every linked payment forever. Evidence has a limited scope.

Failure mode 2avoid

Assume all disputes are impossible. Rights and liability still depend on rules.

Failure mode 3avoid

Delete the address-change event. It remains relevant evidence.

Disputes create delayed labels — the flow

1. 01PurchaseExposure begins
2. 02DisputeAn allegation arrives later
3. 03OutcomeProcess produces a result

A dispute is an allegation in a defined process. Some disputes concern unauthorized use; others concern goods, cancellation, or processing. A dispute outcome is useful feedback, but it is not a perfect label for criminal intent. A merchant may lose because evidence was late or incomplete.

Track event dates separately: purchase, dispute receipt, evidence submission, decision, and recovery. Compare cohorts at the same age. A week-old merchant cohort looks clean partly because disputes have not arrived. Train a model only with labels that had time to develop, and record when each label became available.

Suppose a September dashboard compares one merchant’s August sales with another merchant’s January sales. The older cohort has had more time to develop disputes. A higher observed dispute rate may reflect that extra observation time, a different customer mix, or a real control problem. Compare cohorts at a similar age and keep the original purchase date separate from the dispute date. Operations still needs a current workload view, so the organization may correctly maintain both a purchase-cohort report and a dispute-arrival report. Their totals answer different management needs.

Inside the mechanism. A dispute label needs the purchase date, report date, reason history, amount, and final disposition. Store the observation date as well as the underlying event date. A purchase made in January but disputed in March was not a known dispute in February. A model trained with that future fact has information unavailable to the real decision. Reports should distinguish provisional disputes, confirmed unauthorized activity, service disputes, and final financial loss rather than treating every early allegation as the same target.

A concrete example. The analyst measures disputes by original purchase cohort. Some outcomes arrive well after the merchant has received proceeds. The rule flags 623 of 18,000 captured purchases. Of those flags, 360 meet the synthetic target, giving 57.78% precision. It misses 90 target events. Under the stated cost assumptions, residual loss and operating friction total $15,230. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. Young cohorts are compared with older cohorts as though their observation ages were equal. Keep purchase time, dispute arrival, final reason, and label maturity separate. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

The analyst measures disputes by original purchase cohort. Some outcomes arrive well after the merchant has received proceeds.

01Reference conditionDelayed dispute cohort↗02Failure and stressDelayed dispute cohort↗03Controlled responseDelayed dispute cohort↗

Disputes create delayed labels — the distinction

Dispute reason

• Category of the claim

Fraud ground truth

• Best available evidence of deception

Delayed feedback record

Fictional educational excerpt / Not for execution

Delayed feedback record

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Purchaseday 0

   Observation time

2. 2

   Disputeday 35

   Label arrives later

3. 3

   Training cutoffday 10

   Dispute unavailable then

The feature was not available at decision time

Disputes create delayed labels — control and failure modes

Control design

No; that leaks future information. The feature was not available at decision time.

Failure mode 1avoid

Yes because the purchase already existed. Event existence does not reveal future outcomes.

Failure mode 2avoid

Yes if the dispute was later upheld. Later certainty still comes from the future.

Failure mode 3avoid

Only if the amount is small. Amount does not change temporal leakage.

Build evidence at the event — the flow

1. 01CollectCapture event-time evidence
2. 02AssembleMatch evidence to claim type
3. 03SubmitVerify receipt before deadline

Dispute evidence is stronger when it was collected in the ordinary flow. Record the terms shown, customer acceptance, fulfillment evidence, communication, and refund history with timestamps. Retrofitting records after a claim invites errors and makes the chain harder to defend.

Do not submit everything merely because storage is cheap. Match evidence to the reason for the dispute, protect personal data, and respect submission limits. Measure whether evidence was complete and timely separately from whether the merchant won. A low win rate can reflect weak claims, weak records, weak routing, or a poor decision to contest.

Inside the mechanism. Evidence should be collected at the event where it becomes knowable. A fulfillment record needs a reference to the order and item, a source, a timestamp, and the meaning of its status. A carrier scan is evidence of a reported logistics event; it is not a universal proof that the correct customer accepted the promised product. Preserve corrections and missingness. A later dispute packet should assemble source records rather than invent a single narrative from untraceable screenshots.

A concrete example. A dispute packet needs evidence from the purchase and fulfillment process. A late investigation cannot recreate facts the product never recorded. The case identifies 612 eligible records from a source population of 720. The required workflow completes for 594, but 9 completed records miss the illustrative internal target. Another 18 remain incomplete. Communication evidence covers 588 generated notices. Scope, completion, timeliness, and delivery are four separate properties of the customer outcome.

When the assumption fails. Delivery references and customer consent records are absent from the case. Capture purpose-limited evidence at the event and retain provenance through the dispute. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A dispute packet needs evidence from the purchase and fulfillment process. A late investigation cannot recreate facts the product never recorded.

01Reference conditionFulfillment evidence chain↗02Failure and stressFulfillment evidence chain↗03Controlled responseFulfillment evidence chain↗

Build evidence at the event — the distinction

Relevant evidence

• Answers the disputed fact

Large attachment

• May add volume without proof

Fulfillment packet

Fictional educational excerpt / Not for execution

Fulfillment packet

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Receiptorder-219

   Links to the disputed purchase

2. 2

   Delivery proofdated carrier event

   Supports delivery only

3. 3

   Refund lognone

   Checks duplicate reimbursement

It speaks to the disputed fact

Build evidence at the event — control and failure modes

Control design

Dated delivery evidence linked to the order. It speaks to the disputed fact.

Failure mode 1avoid

The merchant company logo. Branding does not prove delivery.

Failure mode 2avoid

A unrelated login screenshot. It may not concern fulfillment.

Failure mode 3avoid

The current homepage. It does not establish the past delivery.

Keep denominators honest — the flow

1. 01Count20 divided by 10000
2. 02Value8000 divided by 400000
3. 03InterpretKeep the metric definition visible

A dispute count divided by transaction count is not the same as disputed value divided by payment value. The period and eligible population also matter. Network monitoring programs define their own metrics, exclusions, and dates. Do not reuse an internal ratio as a claim of network compliance.

In an illustrative cohort, 20 disputes from 10,000 sales is 0.2 percent by count. If those disputes total $8,000 on $400,000 of sales, the value ratio is 2 percent. Both are correct. Neither describes net loss until recoveries and other costs are considered. Write the denominator beside every chart.

Inside the mechanism. A rate is a numerator, a denominator, and an observation rule. Dispute count divided by captured transaction count differs from disputed value divided by captured value. One large dispute can move the value rate while barely changing the count rate. Use the same currency treatment, purchase cohort, exclusions, and maturity window in both periods. If a dashboard mixes filing-month disputes with purchase-month sales, a seasonal sales decline can raise the ratio without any change in purchase-cohort behavior.

A concrete example. A card dashboard mixes attempts, approved payments, and value-weighted loss. The resulting percentage appears precise while its population changes between reports. The rule flags 781 of 32,000 card attempts. Of those flags, 307 meet the synthetic target, giving 39.31% precision. It misses 77 target events. Under the stated cost assumptions, residual loss and operating friction total $11,950. The important result is the connection between the population, action, capacity, and outcome—not one isolated score.

When the assumption fails. Declined attempts disappear from the denominator without being disclosed. Publish numerator, denominator, cohort, time basis, and label definition together. The following worked sequence shows the reference condition, a stress condition, and a response condition with explicit synthetic data. These are comparative assumptions, not measured causal effects.

Follow a worked case3 conditions · 36 figures

A card dashboard mixes attempts, approved payments, and value-weighted loss. The resulting percentage appears precise while its population changes between reports.

01Reference conditionApproval-rate denominator↗02Failure and stressApproval-rate denominator↗03Controlled responseApproval-rate denominator↗

Keep denominators honest — the distinction

Count ratio

• 0.2 percent of sales disputed

Value ratio

• 2 percent of sale value disputed

Illustrative cohort report

Fictional educational excerpt / Not for execution

Illustrative cohort report

Illustrative data; not a real customer record or a prescribed policy.

1. 1

   Sales10000

   Eligible count

2. 2

   Disputes20

   Same cohort definition

3. 3

   Disputed value8000 USD

   Not necessarily final loss

The numerators and denominators measure different quantities

Keep denominators honest — control and failure modes

Control design

Disputed transactions can have different sizes. The numerators and denominators measure different quantities.

Failure mode 1avoid

One must be a calculation error. Both can be correct.

Failure mode 2avoid

Networks always use value. Program definitions vary.

Failure mode 3avoid

Recovery always equals disputed value. Recovery is a separate outcome.

This chapter builds on Money movement and the risk map. Continue with ACH, bank debits, and returns to follow the next part of the system. Use the glossary for terminology and risk mathematics for formulas and worked calculations.