Skip to main content
Here is the argument in full, because if you don’t buy the thesis the rest of the system looks like over-engineering.

​
Subscriptions are a leaky bucket and nobody looks at the holes

A subscription business has two kinds of churn:
  • Voluntary churn — the customer decided to leave. They cancelled. You can fight it with product and price, and everybody does.
  • Involuntary churn — the customer wanted to stay, but the payment failed and the subscription lapsed. Nobody decided anything. The money just didn’t move.
Involuntary churn is 20–40% of total churn for most subscription businesses, and it’s the cheapest to fix because the customer isn’t even unhappy — they just need to be charged again, at the right time, on a rail that works. Yet on most platforms, recovery is a checkbox: “retry failed cards 4 times over 2 weeks.” Fixed schedule. One rail. No idea why the charge failed. That’s leaving money on the floor. Duro treats the floor as the product.

​
Nigeria makes the leak worse — and the fix more valuable

The standard retry playbook was designed for American credit cards with revolving limits. It does not survive contact with the Nigerian market:

Debit, not credit

Most cards are debit cards drawing on a current account. If the account is empty, a retry fails — and retrying an empty account three more times that week just burns your attempts. You have to wait for money to arrive.

Salary lands once a month

Salaries cluster around payday — the 28th, or the 1st–3rd. A charge that fails on the 15th has a near-100% chance of failing again on the 16th, and a much better chance on the 28th. When you retry matters more than how often.

Cards are the weakest rail

Card success rates are volatile. But the same customer can almost always pay by USSD, bank transfer, or a virtual account. If the card is the problem, stop using the card.

The phone is the identity

Everyone has WhatsApp. Phone numbers are the real primary key for a person. That’s the natural anchor for a payment identity — far more than an email a customer barely checks.
So the recovery engine that would be a nice optimisation in San Francisco is a core differentiator in Lagos. Duro encodes all four facts directly: This is not a flowchart we drew for the docs. It is, almost line for line, the DunningStrategy.decide() function. See the code-level walkthrough →

​
The second bet: unbundle the wallet from the merchant

The great lock-in of conventional billing is that the saved card belongs to the merchant. The customer re-enters their card at every new store. That’s friction the customer eats and the merchant pays for in abandoned checkouts. Duro moves the saved payment method to a customer-owned identity keyed by phone number and verified over WhatsApp: The more merchants on Duro, the more valuable each customer’s saved identity becomes, and the lower every merchant’s checkout friction gets. That’s a network effect a single-merchant tokenizer structurally cannot produce. See the identity chapter →

​
What this buys the people who matter

Revenue that would have silently churned comes back. They see “₦X at risk → ₦Y recovered, Z% recovery rate” as the first number on their dashboard, not buried revenue analytics. They configure their own retry rails, payday-awareness, and dunning emails.
One WhatsApp login shows every subscription across every Duro business. Update a card once, fix every past-due charge. Pay at a new store without re-entering anything.
A clean, OOP, fully-typed monorepo where the marquee features are real: a state machine, a payday-aware retry scheduler, rail-switching, SSRF-guarded signed webhooks, multi-schema tenant isolation, and an integration suite that runs the whole money loop against Postgres on every push.
Now go look at how it’s built. Start with the architecture overview.