Case study 05 · Unit economics · Revenue

When does a POS terminal pay for itself?

Revenue per terminal stayed steady while the cost of the device itself climbed after a currency devaluation. The SVP of Distributed Network Sales asked what that meant for payback, so I measured how far it had stretched, where the revenue really came from, and found terminals being kept "active" with the bare minimum.

Role
Analyst, end to end
Context
The agent network of a leading Nigerian fintech: card terminals placed with agents who serve walk-in customers
Methods
Cohort ROI curves, scenario modelling, revenue concentration, transaction-size mix, behavioural pattern detection
Tools
SQL, Python (pandas), spreadsheet scenario model

Situation

After the naira devaluation, the local cost of a new POS terminal jumped, while the fees each terminal earns are in naira and did not move.

Task

The SVP of Distributed Network Sales asked how long a terminal now takes to earn back its cost, and whether anything could be done about it.

Action

Tracked cumulative return by deployment cohort, built a payback model for two device types, split revenue by who earns it and by transaction size, and tested for terminals kept "active" with the bare minimum.

Result

Showed payback had stretched sharply for post-devaluation cohorts, that a minority of terminals earns most of the money, and flagged a gaming pattern costing material revenue, with recommendations to tighten what counts as active and match devices to agents.

The question

A card terminal (POS, point of sale) is bought by the company and handed to an agent, usually a small shop that offers cash withdrawals, deposits and transfers to its neighbourhood. The company earns a small fee on each transaction. So every terminal is an investment: it costs money up front and pays it back slowly, one fee at a time.

Most devices are imported and priced in dollars. When the naira was devalued, the local cost of a new terminal jumped, but the fees it earns are in naira and did not move with it. The SVP of Distributed Network Sales wanted to know what that did to payback, and whether there was anything to do about it.

Charts use illustrative data rebuilt from the shape of the real results: values are indexed and lightly perturbed, and the real figures stay with the company.

Payback calculator: cheaper mobile device vs standard POSIllustrative data
mobile device: time to pay back
standard POS: time to pay back
extra time the currency shock adds to a standard POS
standard POS: net earnings per week

Left: cumulative net earnings as a share of device cost; a line crossing 100% is the payback point. Right: weeks to pay back at every throughput level, with your current setting marked. Payback beyond ten years is cut off. As in the real payback model, revenue grows more slowly than throughput (the fee kept per naira falls as volumes rise), the standard POS earns a little more per naira than the mobile device, and running costs start at zero.

The model is deliberately simple: device cost, scaled by the currency shock, divided by weekly net earnings. Its value is that a commercial team can move the sliders in a meeting and see the trade-off. Two things come out of it straight away. Payback is very sensitive to throughput at the low end, where most terminals sit: the curve is steep there and flattens out, because revenue grows more slowly than throughput. And the cheaper device wins at every throughput level, by roughly a third, even though the standard POS earns a little more per naira; in weeks, that gap is widest exactly where low-volume agents sit.

Revenue held. Cost did not.

I grouped terminals into cohorts by the month they were deployed and tracked each cohort's cumulative revenue against what its devices cost. Average monthly revenue per terminal stayed in a narrow band across cohorts, once a terminal was past its first month. What changed was the denominator: cohorts deployed after the devaluation carry up to about double the device cost, so a similar revenue stream takes far longer to cover it. Cohorts from before the shock crossed 100% within the first year; those after it are on course to take well over a year.

Cumulative ROI by deployment cohortIllustrative data
typical payback, cohorts before the shock
typical payback, cohorts after the shock

Top: cumulative revenue as a share of device cost, by months since deployment (month 1 is the part-month of deployment). Solid lines are observed; dashed lines project forward at the cohort's average monthly ROI gain, because newer cohorts have not been around long enough to reach payback. Bottom: average monthly revenue per terminal over months 2 to 6 (the same ages for every cohort) and average device cost, both indexed to the first cohort.

A minority of terminals carries each cohort

Averages hide how uneven the network is. Ranking terminals within each cohort by revenue and tracking the share earned by the top 30% showed two trends. Within a cohort, the top group's share grows as the cohort ages: busy agents stay busy while the rest fade. And each newer cohort starts more concentrated than the last, so recent cohorts reach in months a level of concentration that older cohorts took years to reach. Put the other way, the majority of terminals were earning a shrinking slice. That matters for payback: an average that looks healthy can be propped up by a few busy agents while most devices never cover their cost.

How much of a cohort's revenue the top terminals earnIllustrative data
of revenue from the top terminals, earliest cohort at month 6
of revenue from the top terminals, most recent cohort at month 6
Gini coefficient, earlier → recent (0 = perfectly even)

Top: terminals ranked from highest to lowest earner, for the earliest and the most recent of the four cohorts below, both at month 6. The further a curve bows above the dashed line of perfect equality, the more concentrated the revenue; the vertical marker follows the slider. The curves are fitted so their top-30% share matches the traced values. Bottom: share of each cohort's revenue earned by its top 30% of terminals, by months since deployment, for four cohorts a year apart; the grey marker is month 6. The last few months of each cohort are left out because they fall in the same calendar months for every cohort and dip together, a network-wide effect rather than an ageing one.

Small tickets pay the bills

I then split revenue by transaction size, using the same size threshold the business already used to define a "qualifying" transaction. The majority of revenue came from transactions below that threshold: everyday cash-outs and transfers, not large ones.

Over time, though, customers were doing fewer, larger transactions. The terminals where most transactions sat above the threshold multiplied. One reading in the room was that customers trusted the service more and so moved bigger sums. I didn't think the data supported that. Trust has no metric in the data, and the shift started before the devaluation and sped up after it, while wages were largely flat. Customers moving the same money in fewer, larger transactions, to save on fees and trips, fits inflation better than trust. That distinction matters because the remedy differs: a trust story says "do nothing", an inflation story says the high-margin small-ticket base is under pressure.

Active on paper

The business counted a terminal as "active" if it met a weekly qualifying bar. Many terminals missed it. Looking at those that only just met it, a pattern stood out: weeks with exactly one transaction, sized just over the qualifying amount, and nothing else. That is the cheapest possible way to keep a terminal in custody without using it.

One such week can be chance. So I counted how often each terminal did it. About two thirds did it only once, and most of the rest twice. A thin tail did it again and again across the review period, which is hard to explain as anything but deliberate. Valuing those weeks at what an ordinarily active terminal earns put the lost revenue at a material sum.

Gaming detector: single qualifying transaction weeksIllustrative data
terminals with at least one such week
terminals flagged as repeat offenders (share of those with any suspect week)
flagged terminal-weeks
revenue gap in those weeks vs a typical active terminal

Twelve example terminals, 26 weeks

2,000 simulated terminals over 26 weeks; how often a terminal repeats the pattern is drawn from the shape of the real repeat-frequency chart (most once, a long thin tail many times). A "suspect week" has exactly one transaction, sized between the qualifying amount and the margin above it; most such tickets sit close to the bar, so narrowing the margin thins the counts. Bars: share of terminals with any suspect week, by how many they have; red bars are flagged; the line is the running total. In the grid, darker cells are busier weeks.

What I recommended

  1. Tighten what counts as active. Require qualifying activity on several days of the week, or a minimum weekly throughput, so one well-sized transaction can't keep a device in custody.
  2. Work the repeat-offender list. Terminals with many suspect weeks go to the field team for retrieval or a conversation; one-off cases are left alone.
  3. Match the device to the agent. Use the payback model to place cheaper mobile devices with low-throughput agents, and keep standard terminals for agents whose volume can carry them.
  4. Track the top share. Report revenue concentration by cohort alongside averages, so a few busy agents can't mask a weak cohort.

Caveats and what I'd do differently

Skills shown

Unit economicsCohort ROIScenario modellingRevenue concentrationFraud and gaming patternsCommercial recommendations