Designing breach settlement prepaid card and digital wallet disbursement UI in Figma: CARD-*, WAL-DIS-*, and rail choice without trapping claimants

Quick answer

Prepaid card and digital wallet rails exist because not every claimant can receive ACH or accept a mailed check—but the UI must not feel like a downgrade or a data grab. Design CARD- issuance and load workflows* tied to counsel approval and GATE-PAY-*, WAL-DIS- wallet disbursement* with the same pre-export validation patterns as NACHA rows, and claimant rail choice that compares timing, fees (if any), and tax reporting implications without exposing card numbers. Card UI sits beside wire and check fallback—treasury picks rails per corridor; claimants pick when the settlement plan allows member election. Activation flows reuse email OTP and identity re-verification when load amounts exceed thresholds. Status in the claim status portal reads Issued → Activated → Loaded → Available to spend—never last-four-only teases that imply full PAN storage in the portal. Start from the Figma guides hub and use forms, progress steppers, and Dev Mode handoff.

---

Who this is for

• Product designers adding a third rail after ACH and check without cloning three unrelated wizards.
• Claims administrators explaining why a claimant must activate a card before load—not “we’re slow.”
• Compliance aligning card KYC with sanctions screening and foreign claimant restrictions.

---

CARD-* prepaid card issuance model

PrepaidCardIssuance — CARD-992-301 · pay_id: PAY-992-8812
├── Eligibility (from [award chart](/designing-breach-settlement-plan-of-allocation-and-award-chart-ui-in-figma/)):
│   ├── amount_cents · tier_id · rail_allowed: card | ach | check | wallet
│   ├── member_election_required_bool · default_rail if no response
│   └── Block CARD-* if deceased/heir flow incomplete ([heir designation](/designing-breach-settlement-deceased-claimant-and-heir-designation-ui-in-figma/))
├── Issuance states:
│   ├── pending_vendor → issued → shipped | digital_ready
│   ├── activation_required → activated → load_pending → loaded | load_failed
│   └── terminal: replaced (CARD-REPL-*) · closed · escheated ([UCF](/designing-breach-settlement-unclaimed-funds-and-escheatment-ui-in-figma/))
├── Vendor handoff (admin only):
│   ├── card_proxy_id (never PAN in UI mockups—use tokenized placeholder)
│   ├── ship_tracking_id for physical · expedite flag
│   └── Load file CARD-LOAD-* batch linked to [disbursement tracking](/designing-breach-settlement-payment-disbursement-and-payout-tracking-ui-in-figma/)
├── Controls:
│   ├── [Duplicate claim fraud](/designing-breach-settlement-duplicate-claim-detection-and-fraud-prevention-ui-in-figma/) before second CARD-* on same pay_id
│   ├── [Payee correction](/designing-breach-settlement-payee-correction-and-beneficiary-update-ui-in-figma/) voids in-flight load
│   └── [Idempotency](/designing-breach-settlement-payment-idempotency-and-duplicate-submission-prevention-ui-in-figma/) on load submit
└── Audit:
    ├── LOG-CARD-* state transitions · vendor callback ids
    └── Link [proof of payment](/designing-breach-settlement-proof-of-payment-and-remittance-advice-ui-in-figma/) type = card_load

Rail	Best for	Claimant sees	Treasury sees
ACH	US bank on file	“Direct deposit scheduled”	NACHA export
Check	No bank / mail preference	“Check mailed”	PPAY-* + mail batch
Prepaid card	Unbanked, instant spend need	“Activate your card”	CARD-LOAD-*
Digital wallet	Mobile-first, vendor supports	“Add to wallet”	WAL-DIS-*

Verdict: One pay_id maps to one active disbursement rail unless settlement plan explicitly allows split—show rail switch only before GATE-PAY-* opens, not after load.

---

WAL-DIS-* digital wallet disbursement

WalletDisbursement — WAL-DIS-992-044 · wallet_vendor: VND-WAL-A
├── Capture (claimant-facing, [payment methods patterns](/designing-payment-methods-ui-in-figma/)):
│   ├── wallet_type_enum · masked handle (e.g. ••••@email)
│   ├── consent_to_wallet_terms · link [privacy notice](/designing-privacy-notice-version-management-and-policy-changelog-ui-in-figma/)
│   └── Step-up: OTP + [IDV](/designing-breach-settlement-claimant-identity-reverification-and-step-up-ui-in-figma/) when amount > program threshold
├── Processing:
│   ├── validate → submit → vendor_ack | vendor_nack
│   ├── Same exception queue metaphors as [ACH NACK remediation](/designing-breach-settlement-payment-submission-acknowledgment-and-processor-nack-remediation-ui-in-figma/)
│   └── Retry with backoff—do not double-load ([idempotency keys](/designing-breach-settlement-payment-idempotency-and-duplicate-submission-prevention-ui-in-figma/))
├── Reconciliation:
│   ├── Match vendor settlement file to [fund reconciliation](/designing-breach-settlement-fund-reconciliation-and-bank-matching-ui-in-figma/)
│   └── Fees: FEE-WAL-* separate line—not deducted silently from award in portal copy
└── International:
    ├── Often blocked—surface early with link to [foreign claimant](/designing-breach-settlement-foreign-claimant-and-international-payment-ui-in-figma/)
    └── If allowed, SAN-* must clear before submit

Wallet flows should reuse the same timeline component as hold release notifications so call center agents do not learn a second event vocabulary.

---

Claimant rail selection and comparison UI

RailChoiceWizard — portal · claim_id: CLM-992-120
├── Step 1 — Compare (table from [cards UI patterns](/designing-cards-in-figma-layouts-variants-and-handoff/)):
│   ├── Columns: speed, needs bank account, physical mail, tax form delivery
│   ├── No “recommended” badge unless plan document defines default
│   └── Link [where-is-my-payment](/designing-breach-settlement-payment-inquiry-and-where-is-my-payment-ui-in-figma/) help per rail
├── Step 2 — Capture method-specific fields
│   ├── ACH → [saved addresses / bank](/designing-saved-addresses-and-address-book-ui-in-figma/) pattern
│   ├── Check → mailing address confirmation
│   ├── Card → shipping vs digital delivery choice
│   └── Wallet → vendor picker + consent
├── Step 3 — Confirm award amount and rail (read-only FIN-AWD-* version)
│   └── Ack [award restatement](/designing-breach-settlement-award-restatement-and-fin-awd-version-history-ui-in-figma/) if amount changed since intake
└── Post-submit:
    ├── Lock rail unless [amendment](/designing-breach-settlement-claim-amendment-and-correction-ui-in-figma/) reopens
    └── Emit EVT-RAIL-SELECT-* for timeline

Use segmented controls for rail choice on mobile—dropdown hides fee and timing tradeoffs.

---

Load failure, replacement, and clawback

When CARD-LOAD- fails*, claimants need a path that does not dead-end in “contact support.”

Failure	Admin queue	Claimant action
Vendor NACK	CARD-EX-* row	Retry load or switch rail if plan allows
Activation timeout	Stale CARD-*	Resend activation link (OTP)
Lost/stolen	CARD-REPL-*	Block load; issue replacement
Overpayment	Tie to clawback	Plain-language balance notice

Admin screens use tables with badges for load_failed vs fraud_hold—different playbooks.

---

Handoff checklist (Dev Mode)

• PrepaidCardIssuance — card_id (CARD-*), pay_id, state_enum, vendor_proxy_id, ship_tracking_id, load_batch_id, idempotency_key.
• WalletDisbursement — wal_id (WAL-DIS-*), wallet_type, masked_handle, vendor_ack_id, fee_cents.
• RailChoiceWizard — claim_id, selected_rail_enum, fin_awd_version, election_timestamp.
• CardLoadBatch — batch_id (CARD-LOAD-*), row_count, export_state, reconciliation_match_id.
• ClaimantCardStatus — copy_key_enum only (no PAN, no CVV, no full card art with readable numbers).

---

Common mistakes

Mistake	Why it hurts	Fix
Show last-four in portal	Implies PAN storage	Status labels only
Card as only rail	Excludes banked claimants	Rail choice table
Load before activation	Vendor rejects	Gate load on activated
Separate timeline per rail	Call center confusion	Shared EVT-* model
Skip SAN-* on wallet	Compliance gap	Same holds as ACH
Hide wallet fees	Trust / disputes	FEE-WAL-* line item
Allow rail hop after load	Double pay risk	Lock at GATE-PAY

---

Recommended workflow

1. Map settlement plan allowed rails and member election rules.
2. Design CARD- admin board* + claimant activation funnel in one file with shared components.
3. Reuse pre-export validation layout for CARD-LOAD-* and WAL-DIS-* batches.
4. Align status portal stepper with disbursement tracking pay states.
5. Document replacement and clawback paths before first card wave goes live.

---

FAQ

Same as payment methods ecommerce post?

Ecommerce post covers saved cards for checkout; this post covers outbound disbursement rails—different consent, tax, and reconciliation hooks.

Cards vs wire cut-off scheduling?

Cards use vendor load windows, not Fed wire CUT-—treasury may still batch CARD-LOAD- daily; do not reuse wire countdown components blindly.

Tax 1099 for card loads?

Yes when reportable—capture delivery preference for tax docs in rail wizard, not only in account settings.

Minors and guardian designation?

Card shipping and activation may require guardian flow—block CARD-* until guardian state completes.

Relation to escrow replenishment?

Card loads draw RES-OP- like ACH*—show reserve warning on CARD-LOAD-* batch submit.

---

Next steps

• Design breach settlement wire and check fallback disbursement UI in Figma — primary rails
• Design breach settlement payment disbursement and payout tracking UI in Figma — pay_id states
• Design breach settlement claim status portal and claimant dashboard UI in Figma — claimant timeline
• Design payment methods UI in Figma — capture patterns
• Design breach settlement proof of payment and remittance advice UI in Figma — load confirmation artifacts