Payment & MDR Analyzer
Upload a payment-gateway export and instantly see what each rupee of revenue actually costs.
01 · The opportunity
What it set out to solve
Payment data is messy and rarely analysed. Gateways settle net of fees across UPI, cards, netbanking and wallets, each at a different rate — so founders can't easily see which methods cost what, or whether the charges even line up.
02 · The approach
How I thought about it
I started from the business question, not the code — mapped how settlements actually work, defined effective MDR per method and network, and turned a messy CSV into a clear picture a founder can read in minutes.
03 · What I built
- CSV import for common gateway exports (or one-click sample data)
- Effective MDR computed per payment method & card network
- Flags fees charged above the expected rate card
- Settlement lag and net-vs-gross revenue breakdown
- Charts: MDR by method, fee trend, method mix
- An 'Ask your data' panel that answers plain-English questions
04 · The result
What changed
A working, interactive tool that turns a raw export into decisions in minutes — an example of the finance tooling I build for clients.
The leak, step by step
Your gateway charges 2.05% on a card payment.
The rate card said 1.80%. A 0.25% difference — who'd even notice?
On ₹2 crore a month of card volume…
that invisible 0.25% is ₹50,000. Every single month.
One year later
₹0
quietly gone from margin.
Illustrative numbers. The tool below flags exactly this pattern from a real gateway export — try it.
Try it with sample data.
Load the sample gateway export (or drop in your own CSV) and watch the effective MDR, fee overcharges and settlement picture build in real time. Nothing leaves your browser.
See what your payments really cost
Load the sample export to compute effective MDR by method, catch fees billed above the rate card, and check settlement timing, or drop in your own gateway CSV (any column names, you can remap them).
Runs entirely in your browser. Nothing is uploaded.
05 · Decisions & trade-offs
The questions I'd get asked about this, and my answers
Why compute everything in the browser instead of a backend?
Payment data is sensitive. Doing the math client-side means nothing is uploaded — someone can try it without trusting me with their numbers. It also means the tool needs zero servers to stay live.
Why a rule-based 'Ask your data' panel and not an LLM?
Trust. For a public tool I'd rather ship deterministic math I can stand behind than a black box that might hallucinate a number. In a client build I'd wire the same interface to an LLM for free-form questions — the analysis underneath stays real.
How does this reflect how you'd build for a client?
Start from the decision the founder needs to make, model the real mechanics, and only then build the interface. The tech serves the business question — never the other way round.