Founders assumed thin margins. The unit economics model revealed every transaction lost money before overheads.
Success Story · Unit Economics · FinTech · High-Volume Transactions
A US FinTech business operating a high-volume transaction product had no per-transaction profitability model. The founders had built the business on the assumption of thin but positive margins. The reality, once we mapped revenue per transaction against the full direct-cost stack — payment gateway, processing, chargebacks, support cost per ticket — was starker. Revenue per transaction was lower than the payment gateway charge alone. Every transaction was generating a loss before overheads were considered. The product was discontinued. Burn stopped. Capital was redirected into the parts of the business where unit economics actually worked.
The ChallengeAggregate revenue was growing. The per-transaction math had never been done.
From the outside the business looked like a growth story. Volume up, revenue up, board pack clean. Underneath, four problems were stacked — each of them compounded by the absence of a per-transaction unit economics model.
No per-transaction profitability model. The aggregate P&L showed top-line revenue growing against a cost base that was growing in lockstep. The founders had intuition about margins — thin but positive. The intuition was never tested against a per-transaction view. The unit economics simply did not exist as a number anyone in the business had seen.
Direct costs scattered across the chart of accounts. Payment gateway fees sat in one line. Processing costs sat in another. Chargebacks were buried in operating expenses. Support cost was a single line with no per-ticket allocation. There was no view in which all the direct costs of a single transaction were assembled together.
Growth-by-volume strategy with no margin floor. The operating cadence was "grow transaction volume." The implicit assumption was that each new transaction added to the bottom line. Without unit economics, the business was unable to test whether more volume was actually adding value or destroying it. Volume was being optimised in the dark.
Series A approaching with no defensible margin story. An upcoming Series A conversation was going to require a defensible margin story. Smart investors would ask for unit economics in the first thirty minutes of diligence. The founders knew they would not have a credible answer unless the work was done — and unless it was done before the conversations started, not during them.
What We DidWhat we found once the per-transaction math was on a single page.
The build itself took several weeks of data extraction and cost allocation work. The finding was stark, and once seen, it did not depend on any judgment call. Three findings restructured the conversation from a Series A prep into a product-level decision.
Finding 1 · Revenue per transaction. Average revenue per transaction was a small number — expected for a high-volume, low-ticket business. The take rate had been set against competitive market pricing. So far, so consistent with what the founders believed.
Finding 2 · Direct cost stack. When we stacked every direct cost into a single per-transaction view — payment gateway, processing, chargebacks, support cost per ticket — the total cost was higher than the revenue line by a meaningful margin. The largest single cost item was the payment gateway charge alone, which on its own exceeded revenue per transaction. Every other direct cost compounded from there.
Finding 3 · The decision became unambiguous. Once the unit economics were on a single page, the conversation changed shape. The product could be repriced if pricing power existed (it didn't in this competitive market), restructured if gateway costs could be moved (they couldn't at this volume), or discontinued. The founders chose discontinuation, made the call quickly, and redirected the capital and engineering bandwidth into the parts of the business where the unit economics did work.
Across one quarter we built five deliverables: a per-transaction revenue model, the direct cost stack per transaction, net margin per transaction as the central output, a decision pack assessing reprice / restructure / discontinue, and an internal-team handover so the per-transaction model became a permanent decision instrument the controller could maintain.
The OutcomeWhat changed once the math was on the table.
The per-transaction loss was quantified for the first time — revenue per transaction sat below the payment gateway charge alone, meaning every transaction was generating a loss before overheads. The loss-making product was discontinued within the month of the unit economics finding. Burn stopped, runway extended because the largest source of operating burn was removed, and capital and engineering bandwidth were redirected into the segments where unit economics worked.
The unit economics model is now the working document for every pricing change, every product variant, and every gateway renegotiation. The Series A conversation that triggered the engagement now starts with a unit economics number the founders can defend — not with intuition. The internal controller maintains the model monthly; EasePro reviews quarterly.
“We had been growing the volume on this product for over a year. The unit economics model put it in front of us in two pages. We discontinued the product within the month. It was the hardest call we’ve made — and the most obvious, once the math was on the table.”
Figures shown are illustrative — based on a real engagement, anonymised and rounded for client confidentiality.