01
How we turned ClearSale's transaction data into a new SaaS product, helping issuers and merchants reduce chargebacks before they happen.
ClearSale
2023-2025
Product Designer
As part of ClearSale's innovation team, I joined as Product Designer to lead the product Buy Checker from discovery to pilot. The team: 1 PM, 1 tech lead, 3 developers, 1 QA, plus a cross-functional team, working with legal, compliance, account managers, and product marketing.
fewer disputes
issuers onboarded
Every year, customers report purchases they actually made as fraud. This comes at a cost for the entire payment chain: globally, chargebacks are expected to exceed US$1 billion. The dispute journey has three stages: pre-dispute (the customer doesn't recognize the charge), formal dispute (the chargeback is registered), and resolution (someone bears the cost).
ClearSale is a leader in fraud prevention, serving over 100,000 merchants. At the time, its anti-fraud products focused on detecting and blocking fraudulent transactions during purchase, before approval. However, the company was not acting in the pre-dispute window when the purchase is legitimate and the customer simply doesn't recognize it.
Choosing where to start
Before defining anything, we needed to understand who would benefit most. I organized research around three groups.
From merchants: retailers lost money with every dispute. They shipped goods they'd never get back, paid chargeback fees, and risked penalties from acquirers. Like any chargeback management solution, avoiding disputes was desirable. But proving that value would require testing the connection with the cardholder first.
From issuers: banks were more receptive. Resolving disputes before they're formalized meant less support volume and better customer relationships.
From cardholders: 73% called their bank before opening a dispute. Most didn't recognize a charge on their statement, as the merchant names appear as abbreviations or codes that are difficult to recognize. Sometimes they had simply forgotten the purchase, or someone else in the family had used the card.
Key pain points
With issuers as the entry point, we focused on the bank analyst. Unlike the app, reaching the analyst required no integration on the bank's side. They were already in the middle of the conversation when a cardholder reached out with a doubt.
Generic names
Merchant names appear as abbreviations or codes that are difficult to be recognized
Lack of context
No images, no company details, no location
Fragmented dashboard
Analysts jump across multiple screens to piece together information
Limited time
The default is to accept the dispute and move on
Banks move slowly due to legacy systems, third-party dependencies, and long approval chains. We couldn't wait for full integration to prove the product worked, we needed to show the benefit justified the test.
We started with what we had: transaction data from ClearSale's merchant base and relationships with issuers. I mapped which information to surface, when, and how.
The hypothesis: if we surface enriched transaction details to the bank analyst at the moment a customer calls with a doubt, the analyst can help the customer recognize the purchase before it becomes a formal dispute.
01
Proof of concept
We built a fast-search web app based on interviews with the operations team. Analysts could use it without any bank integration, searching transactions directly.
In six months, the POC showed a significant reduction in disputed value and led to the first contract.
02
Scaling
With the POC validated, the next problem was compliance. Merchants needed to explicitly consent to participating.
We ran sessions with legal, product marketing, and account managers to demonstrate value for both sides of the ecosystem.
We refined use cases with the Value Proposition Canvas and ran Product-Market Fit research with cross-functional teams. That work clarified the product positioning and directly shaped how we communicated about Buy Checker externally.
At this stage we also started testing integrations with banks to use Buy Checker within their own systems and operations.
03
Database expansion
Not all merchants had opted in. During sessions with issuers, this became the main friction: they needed broader coverage to integrate Buy Checker into their customer flows. Our search metrics confirmed it: there was a gap between transactions requested and transactions found.
We defined the "hit rate" as our key metric: the difference between what was searched and what we could actually surface. I was involved in sessions with the PM and GPM, bringing research insights about user behavior and market gaps.
Through that work, we approached Mastercard's Ethoca project with a partnership proposal, and I was responsible for understanding their experience, adjusting our flow to receive their data, and testing whether it improved coverage.
Coverage vs. consistency
We assumed querying both databases at once would be better. In practice, it meant slower searches and unnecessary fields upfront. We split it into two steps instead.
The tradeoff: when a match came from Ethoca, the detail screen looked different, their data came back as a hosted page, not something we could pull into our own UI.
For the validation phase, we accepted that inconsistency to test whether the partnership actually improved hit rate before investing in a seamless integration.
What I'd change
If I were to do this again, I would have maintained a more consistent flow of updates and decisions from our team as the product gained traction, so all teams could stay aligned on the same understanding.
What I'd add
More trust in the process and in myself. Everything was new, the space and the responsibility. Looking back, that uncertainty was just part of the experience, and I’m glad I went through it.
What I'd repeat
The Value Proposition Canvas and the alignment work around it. It had a real impact across teams: commercial, marketing, leadership, and product and it directly influenced how we talked about Buy Checker outside the company.
