Designing breach settlement payment reversal, chargeback, and unauthorized debit dispute UI in Figma: REV-*, CB-*, and post-TRACE recovery

Quick answer

Reversal and chargeback UI handles money that left the escrow account but cannot stay with the beneficiary—after TRACE- said “paid.”* Design REV- ledger events* that never silently delete history, CB- chargeback cases* with representment deadlines, and unauthorized debit dispute (UDD-*) flows when claimants report “I did not authorize this deposit.” The status portal must not show “paid” as immutable: use paid → reversed → reissue_pending with plain copy and links to where-is-my-payment when appropriate. Treasury connects REV-* to fund reconciliation, clawback (overpayment) vs bank-initiated CB-* (dispute), and returned payment when ACH return codes overlap. Prevent double recovery with idempotency on REISSUE-* after REV-*. Start from the Figma guides hub and use tables, toasts for admin-only alerts, and Dev Mode handoff.

---

Who this is for

• Product designers on claimant dashboards that treat “paid” as terminal—then chargebacks arrive weeks later.
• Treasury and claims ops distinguishing program clawback from bank/card network disputes.
• Counsel and auditors proving REV-* and CB-* handling in post-disbursement QA and final accounting.

---

REV-* reversal event model

PaymentReversal — REV-992-301 · pay_id: PAY-992-4412 · prior TRACE-992-881
├── Preconditions:
│   ├── Settlement leg existed (TRACE-* or [proof of payment](/designing-breach-settlement-proof-of-payment-and-remittance-advice-ui-in-figma/) issued)
│   ├── Reversal source: bank_return | chargeback | admin_error | court_order | fraud_confirmed
│   └── Never hard-delete PAY-* row—append REV-* event
├── States:
│   ├── detected → investigating → reversed | representment_won | reissued | written_off
│   ├── CB-* spawns when source=chargeback
│   └── UDD-* when claimant-initiated unauthorized claim
├── Financial links:
│   ├── REC-* reconciliation period ([bank matching](/designing-breach-settlement-bank-confirmation-and-trace-matching-ui-in-figma/))
│   ├── CLAW-* if program recovery ([clawback UI](/designing-breach-settlement-clawback-and-overpayment-recovery-ui-in-figma/))
│   └── REISSUE-* new leg with fresh IDMP-* ([idempotency](/designing-breach-settlement-payment-idempotency-and-duplicate-submission-prevention-ui-in-figma/))
└── Portal timeline:
    ├── TIMELINE-EVT-REV-* with non-technical copy
    └── Hide network reason codes (R05, etc.) from claimants

Source	Typical operator owner	Differs from clawback?
bank_return	Treasury	Often overlaps RET-*
chargeback	Treasury + counsel	Network dispute timeline
admin_error	Ops + counsel	Internal QA FIND-*
court_order	Counsel	Links to appeal stay
fraud_confirmed	Fraud + counsel	FRD-*

Verdict: One pay_id timeline shows all legs—SUB-* → TRACE-* → REV-* → REISSUE-*—without collapsing to a single status chip.

---

CB-* chargeback case workspace

ChargebackCase — CB-992-017 · rev_id: REV-992-301 · network_ref: redacted
├── Summary header:
│   ├── Dollar · received_date · response_due_date ([date picker patterns](/designing-date-pickers-and-calendar-ui-in-figma/) for internal scheduling)
│   ├── Link pay_id · claim_id · [tax 1099](/designing-breach-settlement-tax-reporting-and-1099-ui-in-figma/) impact flag
│   └── Status: open | representment_filed | won | lost | accepted
├── Evidence checklist ([forms + upload](/designing-file-upload-and-drag-drop-ui-in-figma/)):
│   ├── Claimant authorization · settlement plan excerpt · proof of eligibility
│   ├── [Remittance advice](/designing-breach-settlement-proof-of-payment-and-remittance-advice-ui-in-figma/) · TRACE-* artifact
│   └── Call log from [payment inquiry](/designing-breach-settlement-payment-inquiry-and-where-is-my-payment-ui-in-figma/)
├── Representment workflow:
│   ├── Draft narrative · counsel review flag
│   ├── Submit to processor · LOG-CB-* timestamps
│   └── Outcome updates REV-* state (won → reverse reversal)
└── Claimant comms:
    ├── No access to CB-* workspace
    └── Optional letter template via [individual notification](/designing-affected-individual-breach-notification-and-communication-ui-in-figma/) patterns

Chargebacks differ from CLR-EXC-*: clearing exceptions usually pre-settlement; CB- assumes beneficiary received funds* then disputed.

---

UDD-* unauthorized debit dispute (claimant-initiated)

UnauthorizedDebitDispute — UDD-992-009 · pay_id: PAY-992-4412 · opened_by: claimant
├── Intake ([forms](/designing-forms-in-figma-inputs-states-and-handoff/)):
│   ├── “I don’t recognize this deposit” · “Someone else took the money” · “Wrong amount”
│   ├── Required: contact method · optional bank letter upload
│   └── [IDV step-up](/designing-breach-settlement-claimant-identity-reverification-and-step-up-ui-in-figma/) before detail reveal
├── Admin triage queue ([privacy case style](/designing-privacy-request-queue-and-case-management-ui-in-figma/)):
│   ├── Link to TRACE-* · BENE-* · [eligibility](/designing-breach-victim-eligibility-verification-portal-ui-in-figma/)
│   ├── Fraud score FRD-* cross-check—not auto-dismiss
│   └── Route: educate (joint account) | open REV-* | open CB-* | [call center](/designing-breach-call-center-and-agent-script-ui-in-figma/)
├── Outcomes:
│   ├── No reversal (misunderstanding) · LOG-UDD-* resolution note
│   ├── REV-* + reissue to corrected BENE ([payee correction](/designing-breach-settlement-payee-correction-and-beneficiary-update-ui-in-figma/))
│   └── Escalate to [disputes/appeals](/designing-breach-settlement-claims-dispute-and-appeals-ui-in-figma/) when entitlement challenged
└── Portal:
    ├── Case status “We’re reviewing your payment concern”
    └── Never expose other claimants’ data in shared household scenarios

---

Status portal: paid → reversed UX

ClaimantPaymentStatus — state machine (simplified)
├── paid_confirmed
│   └── Shows [proof download](/designing-breach-settlement-proof-of-payment-and-remittance-advice-ui-in-figma/) if policy allows
├── reversal_pending
│   └── “We’re verifying a payment adjustment” · no blame language
├── reversed
│   └── Explain reissue path or contact support · link WIMP inquiry
├── reissue_in_progress
│   └── Links [timeline notifications](/designing-breach-settlement-hold-release-notifications-and-claimant-payment-timeline-ui-in-figma/)
└── paid_confirmed (new leg)
    └── New TRACE-* reference internally · same claim_id

Use inline alerts sparingly on portal—prefer timeline events so mobile claimants are not scared by red banners for routine reissues.

---

Comparison: REV-* vs clawback vs returned payment

Mechanism	When	Claimant sees	Primary id
RET- return*	ACH return before/as settle	Delay / fix bank info	Returned payment
REV- reversal*	Post-settlement undo	Adjustment / reissue	REV-*
CLAW- recovery*	Overpayment entitlement	Program-specific notice	Clawback
CB- chargeback*	Network dispute	Often none until reissue	CB-*

Best for: Support training—one inquiry ticket should surface all four linked ids without agents guessing.

---

Handoff checklist (Dev Mode)

• PaymentReversal — rev_id (REV-*), pay_id, source_enum, amount, prior_trace_id, state_enum, opened_at, closed_at optional.
• ChargebackCase — cb_id (CB-*), rev_id, response_due_at, representment_status_enum, evidence_checklist_json.
• UnauthorizedDebitDispute — udd_id (UDD-*), pay_id, claimant_user_id, intake_category_enum, resolution_enum.
• ReversalAuditLog — log_rev_id (LOG-REV-*), event_enum, actor, linked_cb_id optional.
• PortalTimelineEvent — evt_id (TIMELINE-EVT-*), public_copy_key, severity_enum, show_to_claimant_bool.

---

Common mistakes

Mistake	Why it hurts	Fix
Delete “paid” from UI history	Support distrust	Append REV-* events
Same flow as RET-*	Wrong deadlines	Separate CB-* workspace
Auto-open REV-* on every call	Noise	UDD-* triage first
Reissue without IDMP-*	Double pay	New IDMP-* per leg
Show chargeback codes to claimants	Confusion	public_copy_key only
Ignore 1099 impact	Tax chaos	Flag on CB-* header
Representment missed deadline	Lost dollars	due_date banners for admins
REV-* hidden from QA sampling	Audit gap	FIND-* includes REV-* sample

---

Recommended workflow

1. Extend pay_id timeline with REV-* and CB-* lanes in treasury and portal specs.
2. Design CB- workspace* with evidence checklist + counsel review—not email threads.
3. Add UDD- intake* to status portal with IDV gate.
4. Wire REISSUE- to idempotency* and GATE-PAY-* after reversal.
5. Document admin vs claimant field visibility for all dispute screens.

---

FAQ

Card payouts vs ACH only?

CB- UI applies to card/disbursement card programs*—ACH may use RET-* instead; spec payment_rail_enum on REV-*.

REV-* and final accounting?

Reversal adjusts paid counts—FIN-ACCT-* must include REV-* period, not only SUB-* totals.

Claimant says unauthorized but BENE is their ex-spouse?

UDD- + entitlement question*—may route to disputes, not instant REV-*.

Won representment after portal showed reversed?

Timeline event “Payment restored” · internal state representment_won · reconcile REC-*.

Sanctions hold after paid?

Rare recall path—link REV-* source=court_order or compliance_recall · do not reuse CB-* UI.

---

Next steps

• Design breach settlement proof of payment and remittance advice UI in Figma — artifacts for CB-* evidence
• Design breach settlement clawback and overpayment recovery UI in Figma — program recovery vs bank dispute
• Design breach settlement returned payment and reissue UI in Figma — ACH return overlap
• Design breach settlement payment inquiry and where-is-my-payment UI in Figma — post-REV claimant questions
• Design breach settlement post-disbursement QA and audit sampling UI in Figma — sample REV-* cases