Card Transaction Dispute with Evidence
Design a dispute flow that helps a customer choose the right reason, submit useful evidence, and follow a card claim after filing.
The brief
Understand the problem
Background
Customers may use the word fraud for duplicate charges, canceled subscriptions, goods not received, cash withdrawals, and card theft. Each situation can require different immediate actions, evidence, and investigation timing.
User context
Ethan paid $186 for a desk that never arrived. The merchant stopped responding after confirming a refund, and he has the order receipt, delivery estimate, and message history.
Product problem
Ethan needs to file the correct claim without repeating information, while the bank needs a coherent timeline and evidence it can review.
Objective
Create transaction selection, guided reason choice, evidence assembly, submission, and status tracking for one card dispute.
What to design
Define the experience
Required experience
- Select an eligible posted transaction
- Choose a dispute reason through plain-language questions
- Build a dated evidence package
- Submit the claim and understand status, deadlines, and next steps
Screens and states
- Transaction eligibility
- Dispute reason guidance
- Evidence and timeline builder
- Claim receipt and tracker
Core user flow
Follow the critical path
- 01
Ethan opens the desk purchase from his statement
- 02
He answers questions that distinguish non-delivery from an unrecognized transaction
- 03
He uploads the receipt and messages, then orders events on a timeline
- 04
He submits and receives a claim reference with the bank's next review date
Product rules
Requirements and constraints
Requirements
- Explain why a transaction is eligible, pending, or routed elsewhere
- Reuse known merchant, amount, and date data
- Support files, text notes, and a chronological evidence view
- Show what happens after submission without promising an outcome
- Allow the customer to add requested evidence later
Constraints
- Pending authorizations cannot enter the posted-transaction dispute path
- File limits and accepted formats must be visible before upload
- Regulatory timing and provisional credits vary by claim type and region
Reality check
States worth considering
Ready-to-use content
Mock data
Use this content to test hierarchy and realistic data states. You can expand it when the concept needs more depth.
Evidence timeline
- 3 July: order placed for $186
- 5 July: merchant promised dispatch
- 12 July: delivery date passed
- 16 July: merchant promised refund
- 30 July: no refund received
Finish line
What to deliver
- Four responsive screens and one claim-status component
- Annotations for evidence requests, partial refunds, and ineligible transactions
If you want more
Optional extensions
Optional direction
Visual resources
Use these as a starting constraint if you want one. They are not part of the required solution.