FinOps Field Notes: Chargebacks Are a Refund Problem in Disguise

Short Field Note — FinOps Ops Console

---

I spent two years thinking chargebacks were a fraud problem. Then I looked at the data.

In the merchant datasets we analyzed, 68% of chargebacks were preceded by a refund request that was either delayed or ignored. The customer asked for a refund, didn't get it in time, and disputed the charge. The merchant then paid a $15 chargeback fee on top of the refund they should have processed days earlier.

Three lessons:

1. Time is the risk variable.

Refund risk is not binary. It accumulates. A refund request at T+0 hours is SAFE. At T+48 hours it's DUE_SOON. At T+72 hours it's AT_RISK. At T+168 hours it's OVERDUE. This continuous model changed how we built the console. Every screen shows time remaining. Every alert is time-based. The user's job is to beat the clock, not to classify the refund.

2. Demo data from real APIs is worth the complexity.

We could have seeded the demo with static JSON. It would have been done in an afternoon. Instead, we built a pipeline that calls Stripe's test API, generates real payment shapes, and time-shifts them. This took a week. But when a prospect sees a refund with a real Stripe ID, a real amount, and a real risk state, they believe the product works. Fake data feels fake, even when you can't articulate why.

3. Universal search is the killer feature.

Support teams don't think in transaction IDs. They think in customer names, order numbers, email addresses, support ticket references. A search that only works on transaction ID is useless. We built universal search across six fields — customer, transaction, refund, order, ticket, note — and it became the most-used feature in the console. Users find what they're looking for in seconds, not minutes.

---

FinOps Ops Console is open source at [github.com/Gwerdonatus/FinOps](https://github.com/Gwerdonatus/FinOps)