PRODUCT DESIGN · FINTECH
Chargebacks, self-served: from a three-team chat relay to a flow users finish on their own
I designed Telda’s chargeback self-service: one flow that lets users dispute a card payment straight from the transaction, and hands the finance team a complete case instead of a chat log.
COMPANY
Telda
ROLE
Product Designer
TIMELINE
Dec 2025 – May 2026
STATUS
Live
WORKED WITH
Product, FinOps, Support, Engineering
02
What’s a chargeback?
A chargeback is how a cardholder asks their bank to reverse a card payment: a purchase charged twice, an order that never arrived, a refund that never landed. The bank raises the case with the card network, Mastercard for Telda’s cards, which has strict deadlines and evidence rules.
At Telda, the only way to start one was the in-app chat. A support agent collected the details and passed the case to Finance Operations (FinOps), who validated it, raised the dispute and followed it up until it was resolved.
03
The problem
Every step was manual, and the process couldn’t keep up as Telda’s users and transaction volume grew. Each group felt it differently.
FOR USERS
Long waits, wrong promises
Users had to explain their case in a chat, and sometimes got the wrong timeline: told Mastercard takes 5 days when it can take up to 45.
FOR SUPPORT
Not knowing what to ask
Chargeback chats piled up and slowed support for everyone, and agents often missed the details a Mastercard purchase dispute needs.
FOR FINOPS
Incomplete cases
A three-person team read through long chat logs to piece each case together, then chased the fields that were missing.
BEFORE
1 path
The in-app chat was the only way to dispute a payment
BEFORE
3 people
In FinOps, handling every case by hand
BEFORE
5 vs 45
Days quoted to users vs. Mastercard’s real maximum
04
Research
I mapped the old flow end to end and sat down with the people who lived with it: the product manager, the support lead and the FinOps team. Together we defined what success meant for each of them, then checked every case against Mastercard’s dispute rules.
Stakeholder interviews
Old-flow mapping
Mastercard dispute rules
Case-by-case flow chart
INSIGHT 01
Purchases are the problem
ATM disputes need no proof and FinOps resolves them quickly. Almost every headache came from card purchases.
INSIGHT 02
Merchant first
Many purchase issues are fixed faster by the merchant, and the acquirer rejects a chargeback if the user never contacted them. Support rarely asked.
INSIGHT 03
Not every issue is a dispute yet
A purchase on hold hasn’t been claimed by the merchant. Often, waiting is the fix: the money is released on its own within about 30 days.
05 — THE CHALLENGE
How might we let users raise a chargeback on their own, while giving FinOps a complete, valid case every time?
Constraints: Mastercard’s evidence rules and 45-day timeline · the merchant-first rule · payments on hold vs. cleared · payments that can’t be charged back at all · a FinOps team of three.
06
Mapping every case
Before designing a single screen, I mapped every path in one flow chart: the transaction type, its status, whether it was paid online or at a POS machine, and what went wrong. Every branch ends in a different outcome: a dispute, a wait, a request for proof, or a clear and kind “not possible”.
I also wrote a short handoff doc for each transaction state, so product, FinOps, support and engineering read the same rules.
The full decision tree. Click to zoom.
STATE 01
Cash withdrawal
ATM issues need no proof. Missing or partial cash becomes a dispute; damaged or extra notes get clear guidance instead.
STATE 02
Authorized (hold)
Money is on hold, not taken. Waiting usually resolves it; failed POS payments go to a 5-day manual release with proof.
STATE 03
Completed (cleared)
The merchant has the money. This is where chargebacks go to Mastercard, with a response within up to 45 days.
STATE 04
Older than 90 days
Outside the network’s window. We explain why and point users to the merchant or support, never a dead end.
07
The solution
One flow that starts from the transaction itself and adapts to its status and the user’s issue. These are the moments that make it work.
STEP 1
Start from the payment
Users report an issue right from the transaction and pick what went wrong in plain words. Each answer branches into the right path, and double charges are split into the cases Mastercard treats differently.
STEP 2
Merchant first
For wrong amounts, missing orders and missing refunds, we suggest contacting the merchant before submitting. It’s usually the fastest fix, and the acquirer requires it before accepting a chargeback.
STEP 3
Overcharged? Just the difference
Instead of disputing the whole payment, users enter the amount they should have paid. FinOps disputes only the difference, and the field catches impossible amounts on the spot.
STEP 4
The proof gate
The most important screen in the flow. Users see examples of good proof and can add a comment. They can still continue without proof, but we’re honest that requests with proof have up to 90% higher acceptance rates, and FinOps gets that signal at intake.
STEP 5
Track every step
After submitting, users see how to find their case and follow it from the transaction itself: waiting for clearance, verifying, sent to Mastercard, refunded.
08
Edge cases
The cases that decide whether a flow like this holds up in real life.
01
Charged twice, three ways
Paying twice with the Telda card, a failed Telda payment followed by another card, or followed by cash all count as a double charge, which Mastercard accepts more often. So we ask whether the user paid another way, and don’t require proof.
02
“I didn’t make this payment”
We secure the account first, then the user can still raise a dispute as an online payment. Payments confirmed with 3-D Secure or made with the physical card can’t be charged back, so we say so clearly.
03
Still on hold
We don’t raise a dispute until the status is clear. Users learn they may need to wait up to 30 days for the payment to clear, and why that wait often fixes it.
04
Outside the window
Disputes can only be raised within 90 days. Instead of an error, users see why and where to go next.
Left: the 90-day window has closed. Right: an ATM dispute, which needs no proof and comes with a clear timeline.
09
Launch: from dry run to live
We launched as a dry run first. Four days of real behaviour taught us more than any review could, and those lessons shaped the version that’s live today.
01
Volume jumped
Cases went from about 20 a week to about 20 a day.
02
The hidden quality gate
The support chat had been quietly filtering bad requests. Without it, users submitted blank screenshots, unrelated images and no context.
03
People tested the system
Some users tried their luck with false claims, so the flow has to be defensive by design.
04
ATM was fine
Cash withdrawal disputes worked smoothly. The whole problem was purchases.
09
What we changed after launch
The root cause: the first version was designed to reduce support volume, but not around FinOps’ validation needs. So we added the right friction in the right places, and all four changes are now live.
01
Required action
Instead of a yes-or-no decision, FinOps can ask the user for a specific missing document after submission, a new case state.
02
Rejection reasons in the app
Users see exactly why a claim was declined, instead of a note only support could read.
03
Guided submission
The merchant-first rule and the right evidence for each dispute type, before users can submit.
04
Rethinking “Report an issue”
It used to route straight to support and bypass self-service entirely. We reworked it so users land in the self-service flow.
Verified
Escalated
Invalid
Refunded
Required action · new
Outcomes on the transaction itself: approved, or declined with the reason.
10
Impact so far
Self-service is live. It cut the time customer support spends on chargeback cases and gave FinOps a better validation process. Our north star is shared by product, support and FinOps.
TARGET
85%
of chargeback requests through self-service: the north star
LIVE
↓ CS
customer support spends less time on chargeback cases
LIVE
↑ FinOps
a better validation process: complete cases instead of chat logs
11
What I learned
Friction isn’t the enemy. Removing the support chat removed the only quality check. The right friction, in the right place, protects both users and the team.
Operations teams are users too. Designing around FinOps’ validation needs from day one would have saved a round of fixes.
Write it down. A handoff doc per transaction state kept four teams reading the same rules.