Unit 01 · Chapter 2 · 10 min read

Cards, authorization, and disputes

Understand card states, authentication, liability, and delayed feedback.

The lamp is now a bicycle. Maya sees a pending $600 card entry and calls it a charge. Support calls it an authorization. Finance calls it neither revenue nor settled cash. All three teams need the same state diagram before the bicycle leaves the warehouse.

Authorization and capture

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.

Authorization and capture Authorization and capture — the flow Follow the sequence. Match the settlement record. Authorize Request issuer approval Capture Submit collection instruction Reconcile Match the settlement record — Follow the sequence. Match the settlement record. Chapter sources · Open image

Authorization and capture Authorization and capture — the distinction These concepts answer different questions. Read each definition in the context of the section. Reversal Releases an unused authorization Refund Returns value after a captured payment — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Authorization and capture Bicycle state journal Fictional teaching record. Unused authorization portion. Bicycle state journal Illustrative data; not a real customer record or a prescribed policy. Authorized 600 USD Initial approved amount Captured 550 USD Final sale amount Released 50 USD Unused authorization portion The final sale differs from the initial hold — Fictional teaching record. Unused authorization portion. Chapter sources · Open image

Authorization and capture Authorization and capture — control and failure modes The final sale differs from the initial hold. The branches show why alternative designs fail. Control design Both events and their linked amounts. The final sale differs from the initial hold. Failure mode 1 Only a $600 sale. That overstates the captured amount. avoid Failure mode 2 Two unrelated orders. The events describe one purchase. avoid Failure mode 3 A deleted authorization. Deletion loses the state history. avoid — The final sale differs from the initial hold. The branches show why alternative designs fail. Chapter sources · Open image

Authentication is one layer

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.

Authentication is one layer Authentication is one layer — the flow Follow the sequence. Combine with remaining risks. Challenge Ask for stronger proof Result Store the exact response Decision Combine with remaining risks — Follow the sequence. Combine with remaining risks. Chapter sources · Open image

Authentication is one layer Authentication is one layer — the distinction These concepts answer different questions. Read each definition in the context of the section. Credential control Evidence about access Purchase legitimacy Evidence about the whole transaction — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Authentication is one layer Authentication evidence Fictional teaching record. Needs applicable rule evidence. Authentication evidence Illustrative data; not a real customer record or a prescribed policy. Challenge completed One positive signal Delivery address recently changed Separate risk signal Liability shift not established Needs applicable rule evidence Authentication does not erase other signals — Fictional teaching record. Needs applicable rule evidence. Chapter sources · Open image

Authentication is one layer Authentication is one layer — control and failure modes Authentication does not erase other signals. The branches show why alternative designs fail. Control design Evaluate the remaining transaction context. Authentication does not erase other signals. Failure mode 1 Approve every linked payment forever. Evidence has a limited scope. avoid Failure mode 2 Assume all disputes are impossible. Rights and liability still depend on rules. avoid Failure mode 3 Delete the address-change event. It remains relevant evidence. avoid — Authentication does not erase other signals. The branches show why alternative designs fail. Chapter sources · Open image

Disputes create delayed labels

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.

Disputes create delayed labels Disputes create delayed labels — the flow Follow the sequence. Process produces a result. Purchase Exposure begins Dispute An allegation arrives later Outcome Process produces a result — Follow the sequence. Process produces a result. Chapter sources · Open image

Disputes create delayed labels Disputes create delayed labels — the distinction These concepts answer different questions. Read each definition in the context of the section. Dispute reason Category of the claim Fraud ground truth Best available evidence of deception — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Disputes create delayed labels Delayed feedback record Fictional teaching record. Dispute unavailable then. Delayed feedback record Illustrative data; not a real customer record or a prescribed policy. Purchase day 0 Observation time Dispute day 35 Label arrives later Training cutoff day 10 Dispute unavailable then The feature was not available at decision time — Fictional teaching record. Dispute unavailable then. Chapter sources · Open image

Disputes create delayed labels Disputes create delayed labels — control and failure modes The feature was not available at decision time. The branches show why alternative designs fail. Control design No; that leaks future information. The feature was not available at decision time. Failure mode 1 Yes because the purchase already existed. Event existence does not reveal future outcomes. avoid Failure mode 2 Yes if the dispute was later upheld. Later certainty still comes from the future. avoid Failure mode 3 Only if the amount is small. Amount does not change temporal leakage. avoid — The feature was not available at decision time. The branches show why alternative designs fail. Chapter sources · Open image

Build evidence at the event

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.

Build evidence at the event Build evidence at the event — the flow Follow the sequence. Verify receipt before deadline. Collect Capture event-time evidence Assemble Match evidence to claim type Submit Verify receipt before deadline — Follow the sequence. Verify receipt before deadline. Chapter sources · Open image

Build evidence at the event Build evidence at the event — the distinction These concepts answer different questions. Read each definition in the context of the section. Relevant evidence Answers the disputed fact Large attachment May add volume without proof — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Build evidence at the event Fulfillment packet Fictional teaching record. Checks duplicate reimbursement. Fulfillment packet Illustrative data; not a real customer record or a prescribed policy. Receipt order-219 Links to the disputed purchase Delivery proof dated carrier event Supports delivery only Refund log none Checks duplicate reimbursement It speaks to the disputed fact — Fictional teaching record. Checks duplicate reimbursement. Chapter sources · Open image

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.

It speaks to the disputed fact. The branches show why alternative designs fail. Chapter sources · Open image

Keep denominators honest

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.

Keep denominators honest Keep denominators honest — the flow Follow the sequence. Keep the metric definition visible. Count 20 divided by 10000 Value 8000 divided by 400000 Interpret Keep the metric definition visible — Follow the sequence. Keep the metric definition visible. Chapter sources · Open image

Keep denominators honest Keep denominators honest — the distinction These concepts answer different questions. Read each definition in the context of the section. Count ratio 0.2 percent of sales disputed Value ratio 2 percent of sale value disputed — These concepts answer different questions. Read each definition in the context of the section. Chapter sources · Open image

Keep denominators honest Illustrative cohort report Fictional teaching record. Not necessarily final loss. Illustrative cohort report Illustrative data; not a real customer record or a prescribed policy. Sales 10000 Eligible count Disputes 20 Same cohort definition Disputed value 8000 USD Not necessarily final loss The numerators and denominators measure different quantities — Fictional teaching record. Not necessarily final loss. Chapter sources · Open image

Keep denominators honest Keep denominators honest — control and failure modes The numerators and denominators measure different quantities. The branches show why alternative designs fail. Control design Disputed transactions can have different sizes. The numerators and denominators measure different quantities. Failure mode 1 One must be a calculation error. Both can be correct. avoid Failure mode 2 Networks always use value. Program definitions vary. avoid Failure mode 3 Recovery always equals disputed value. Recovery is a separate outcome. avoid — The numerators and denominators measure different quantities. The branches show why alternative designs fail. Chapter sources · Open image

Chapter connections

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.

Sources

Reviewed 2026-09-17