← All product work

Product Strategy / Case study

OTT Wallet/Billing Migration: 50% to 1%

Migrated subscription billing off high-cost rails and rebuilt wallet/DCB flows, payment cost from 50% to 1%.

50% → 1%Payment cost
5M+Paid subscribers
+70%ARPU
$10M+ARR

The operating decision, in context.

Diagnosed unit economics as a payments problem, not a pricing problem. Rebuilt rail mix, retries and dunning around wallet/DCB economics, pulled payment cost from ~50% to ~1% of revenue while scaling to 5M+ paid subscribers.

Evidence overview

What changed, and why it held.

Operator lens

Payment cost is a product variable, not a procurement one.

Payment cost / revenue

~50%→~1%

Paid subscribers

~0→5M+

ARPU

Baseline→+70%

◆ Diagramfig.
Billing rail migration: from one expensive rail to a portfolio.
RAILSUNIFIED PLATFORMCONSUMERSCardsMPGS · MDESWalletsJazzCash · EasypaisaDCBDirect carrier billingIBFT1Link · NIFTBank transfersRTGS · ACHCross-borderDLocal · Thunes · Boku · CodaUnified APIPay-in · PayoutRouting engineCost · success · healthRisk servicePre-auth · post-auth · asyncCanonical ledgerDouble-entry · idempotentSettlement engineMulti-rail · corridor-awareMerchantsConsole · WebhooksFinanceT+0 / T+1 settlementRegulatorReporting pipeline

Subscriber cohorts route across DCB, wallets and cards by cost, success and lifecycle. Retry orchestration and dunning are platform services, not per-rail glue, payment cost fell from ~50% to ~1%.

The job to be done.

An OTT streaming platform's subscription business was being eaten alive by payment cost, operator and aggregator margins consumed up to half of revenue, capping growth and ARPU.

What I built.

  • Re-architected billing to prefer wallet, DCB and direct bank rails
  • Smart retry and dunning flows tuned per rail and per cohort
  • Pricing and packaging changes aligned to rail economics
  • Reconciliation against operator settlements to recover leakage

How it fits together.

  • Rail preference engine per subscriber state and prior failure history
  • Per-rail retry curves instead of a single global retry policy

Where I sat in the work.

Head of Project and Product at an OTT streaming platform. Drove payments product strategy, vendor renegotiation and the cross-functional migration with growth, finance and engineering.

What moved.

  • Reduced payment cost from ~50% to ~1% of revenue
  • Scaled to 5M+ paid subscribers
  • Increased ARPU by 70%

What carries into the next build.

  • Payment cost is a product variable, not a procurement one.
  • Retries and dunning are growth levers when rail economics are understood.

Relevant beyond this one platform.

The transferable core: treating payment cost as a product variable, rebuilding rail mix, retries and dunning around wallet and DCB economics. Every subscription, marketplace and creator platform hits this wall eventually, inside every network, PSP and cross-border platform; only the logo changes.

Bring the context

Building through
real operating pressure?

Start with the decision, constraint or delivery problem in front of you. We can work out whether there is a useful fit.