figma guide

Designing breach settlement payment disbursement and payout tracking UI in Figma: pro-rata distribution, payment methods, and tax reporting

Design breach settlement payment disbursement and payout tracking UI in Figma with pro-rata calculations, check/ACH/PayPal delivery, tax forms, and administrator batch export handoff.

Published
Updated
Aug 23, 2026
Read time
7 min
Level
Intermediate

Quick answer

Breach settlement payment disbursement UI closes the loop after claims are approved—victims need to know when money is coming, how it arrives, and what tax paperwork to expect. Design a payment method capture step (check, ACH, digital wallet per court order), payout status tracker with pro-rata transparency, failed payment retry flows, and an administrator batch disbursement console that exports to payment processors. Connect to claim status, saved addresses, account dashboard, and compliance exports. Start from the Figma guides hub and pair with forms, progress steppers, and Dev Mode handoff.


Who this is for

  • Product designers building post-approval payment experiences—not generic ecommerce checkout.
  • Settlement administrators and finance teams coordinating pro-rata math, payment processor batches, and undeliverable check handling.
  • Support and call center leads who need PAY-* lookup parity with agent scripts.

Payment method capture (post-approval)

PaymentMethodCapture — Claim CLM-992-88421 · Approved · Settlement SET-992 · Select how to receive payment
├── Header: Your claim was approved · Final amount: $47.82 (pro-rata applied)
├── Pro-rata summary (plain language):
│   ├── Total settlement fund: $12.4M · Approved claims: 892,441
│   ├── Your selected remedy: Cash payment (standard tier)
│   └── Amount is final · No further action needed unless payment fails
├── Payment method options (court-approved only):
│   ├── [ Physical check ] — Mailed to address on file · 2–4 weeks
│   ├── [ ACH direct deposit ] — Bank routing + account · 5–7 business days
│   ├── [ PayPal / digital wallet ] — Email on file · Instant to 3 days
│   └── [ Donate to charity ] — Optional if settlement allows · Receipt provided
├── Address confirmation:
│   ├── Pre-fill from [address book](/designing-saved-addresses-and-address-book-ui-in-figma/)
│   ├── "Check will be mailed to this address" · Edit before cutoff date
│   └── Undeliverable warning: Update by 2027-03-01 or payment may be escheated
├── ACH fields (if selected):
│   ├── Routing number · Account number · Account type · Name on account
│   └── Micro-deposit verification optional per processor rules
├── Attestation: "Payment information is accurate" · Submit
└── Confirmation: Payment preference PAY-992-88421 saved · Status: Pending disbursement batch
ElementPurpose
Final amount displayOnly show after pro-rata lock—never during claims review
Pro-rata explainerReduces “why so little?” support tickets
Method cutoff dateHard stop before batch export to processor
Charity optionSome settlements offer in lieu of cash—legal must approve

Verdict: Capture payment method after approval, not during claims filing—users who never get approved should not submit bank details.


Payout status tracker

PayoutStatusTracker — PAY-992-88421 · CLM-992-88421 · Amount: $47.82 · Status: In transit
├── Status stepper: Approved → Batch queued → Sent to processor → Issued → Delivered / Failed
├── Current detail:
│   ├── "Your ACH transfer was initiated on 2027-04-12"
│   ├── Expected arrival: 2027-04-17 · Reference: ACH-992-44102
│   └── No action required unless status shows Failed
├── Payment history (if reissued):
│   ├── Attempt 1: Check returned undeliverable · 2027-03-28
│   └── Attempt 2: ACH pending · Current
├── User actions:
│   ├── Update payment method (before next batch only)
│   ├── Update mailing address · [Address book](/designing-saved-addresses-and-address-book-ui-in-figma/)
│   ├── Download payment confirmation PDF
│   └── Contact administrator · Pre-fill PAY-* and CLM-* references
├── Failed payment state:
│   ├── Reason: Invalid routing number · Check returned · Account closed
│   ├── Retry window: 30 days · Guided re-entry form
│   └── Escheatment warning if unclaimed after statutory period
├── Tax reporting block (if applicable):
│   ├── "Payments over $600 may require Form 1099"
│   ├── W-9 collection prompt if threshold met
│   └── Link tax document download when available
└── Call center parity: Agent lookup by PAY-* shows same status enum as victim portal

Design status copy for long waits—settlement disbursements often batch monthly, not real-time.


Administrator disbursement console (internal)

DisbursementConsole — Settlement SET-992 · Batch BATCH-992-04 · 12,441 payments · $594,882 total
├── Batch lifecycle: Draft → Legal sign-off → Exported → Processor confirmed → Reconciliation
├── Pre-export checklist:
│   ├── All CLM-* in batch have status Approved
│   ├── Payment method captured for each row
│   ├── Pro-rata amount locked · SN-992-v1 fund allocation verified
│   └── Duplicate PAY-* check · Fraud flags cleared
├── Export formats: NACHA · Check print file · PayPal mass pay CSV
├── Row detail: CLM-* · PAY-* · Amount · Method · Address hash · Export status
├── Exception queue:
│   ├── Missing payment method · Invalid ACH · Address undeliverable flag
│   ├── Manual hold · Legal hold from [compliance exports](/designing-compliance-exports-and-legal-hold-ui-in-figma/)
│   └── Reissue workflow · Links to failed payout tracker
├── Reconciliation panel:
│   ├── Processor confirmation file upload · Match PAY-* to settled transactions
│   ├── Unmatched rows · Retry or void with audit comment
│   └── Batch close · Archive to compliance exports
└── Audit log: batch_id · exporter_id · row_count · total_amount · processor_ref

Internal UI shares PAY- and CLM- IDs** with victim-facing tracker—never invent parallel identifiers.


Monitoring and non-cash remedy handoff

Not every approved claim pays cash. When remedy is extended monitoring or identity restoration credit:

RemedyHandoffPanel — CLM-992-90102 · Approved · Remedy: Extended monitoring (24 months)
├── No PAY-* record for cash · Handoff to MON-* enrollment instead
├── CTA: [ Activate monitoring ] → Pre-fill from claim · Skip duplicate identity steps
├── Link [remediation enrollment hub](/designing-breach-remediation-offers-and-credit-monitoring-enrollment-ui-in-figma/)
├── Restoration credit lump sum: Treat as PAY-* with restricted vendor redemption list
└── Status: Monitoring active · Expires 2029-04-12 · [Alert inbox](/designing-breach-identity-restoration-and-fraud-alert-ui-in-figma/)

Use badges to distinguish cash vs service remedies on account dashboard widgets.


Comparison: disbursement vs adjacent surfaces

SurfaceFocusThis UI adds
Settlement claimsFiling and approvalMoney movement and delivery
Claim status trackerReview pipelinePost-approval PAY-* lifecycle
Remediation offersCompany-funded servicesCourt-ordered cash and batched payouts
Saved addressesGeneric profileCheck delivery with escheatment rules
Payment methods (ecommerce)Checkout cardsSettlement ACH/check with legal constraints

Handoff checklist (Dev Mode)

  • PaymentMethodCapture — pay_pref_id (PAY-), claim_id (CLM-), settlement_id (SET-*), method_enum, address_id, ach_token_ref, cutoff_date.
  • PayoutStatus — pay_id (PAY-*), claim_id, amount_final, currency, status_enum, status_history[], processor_ref, issued_date, delivered_date.
  • ProRataSummary — settlement_id, fund_total, approved_claim_count, user_amount, calculation_version, locked_at.
  • FailedPaymentRetry — pay_id, failure_reason_code, retry_deadline, attempt_count, escheatment_date.
  • TaxReporting — pay_id, threshold_met, w9_status, form_1099_id, download_url.
  • DisbursementBatch — batch_id (BATCH-*), settlement_id, row_count, total_amount, export_format, processor_ref, reconciliation_status.
  • RemedyHandoff — claim_id, remedy_enum, monitoring_offer_id (MON-*), enrollment_prefill_token.

Common mistakes

MistakeWhy it hurtsFix
Collect bank details during claims filingPII exposure for denied claimsPayment method step post-approval only
Show pro-rata math before fund lockNumbers change; erodes trust”Estimated” until batch legal sign-off
Real-time payment expectationsSettlements batch weekly/monthlyClear “batch processing” copy and dates
Different PAY-* status on phone vs portalSupport chaosShared enum in call center UI
No undeliverable check workflowEscheatment and reissue backlogFailed state with address update CTA
Mix PAY-* with ecommerce order IDsFinance reconciliation breaksSettlement-specific ID namespace
Skip W-9 for sub-threshold then issue 1099Tax compliance gapThreshold rules from legal at design time
Export batch without duplicate checkDouble payment liabilityCLM-* uniqueness gate before export

  1. Legal defines approved payment methods and pro-rata disclosure language before wireframes.
  2. Reuse CLM- approved state* from claims UI—do not create separate approval flows.
  3. Design victim tracker and admin console as component variants sharing PAY-* schema.
  4. Build failed payment retry before first batch export—not as a post-launch patch.
  5. Sync PAY- lookup* with call center scripts before disbursement mail date.
  6. Archive batch metadata to compliance exports per settlement administrator requirements.

FAQ

When is the final payment amount shown?

After pro-rata calculation is locked and claim status moves to Approved—typically weeks after the claim deadline, not at submission.

Can users change payment method after batch export?

No—show cutoff date prominently. After export, changes require administrator exception queue.

What if someone never selects a payment method?

Move to exception queue with email and portal banners; after retry window, follow escheatment rules per jurisdiction.

How do monitoring-only remedies appear?

No PAY-* row—show MON- handoff card* on account dashboard instead of empty payout tracker.

Mobile layout priority?

Mobile-first for status checks—users open “where is my check?” emails on phones. Use cards and full-width CTAs.


Next steps

Share on X

§ Keep reading

Related guides.