The systems that never made a demo

Most of the write-ups here come with receipts: a public SDK, an open-source CLI, a commit history you can check. This one comes with none. Every system below is internal: no repo to open, nothing to star, not so much as a screenshot. You will have to take my word for it.

What follows is a handful of the smaller things I owned at PhonePe, the plumbing that never makes a demo, but without which a payments platform quietly stops being correct, or defended, or able to grow. One turned an all-or-nothing lever into a scalpel; two turned manual, one-at-a-time work into something automatic and safe to run; one taught the books about a business that hadn't existed the week before. All four were load-bearing.

Month-end close, without the fire drill

Accounting runs on events. Every transaction that completes raises one, and the accounting system turns it into a ledger entry. At month-end the books have to close, which means every event that should have landed actually did.

Most of the time they do, and reconciliations catch the gaps. But a payments platform has a long tail of ways an event goes missing: a provider never fires its callback, a transaction sits in pending, a reconciliation quietly misses one for a reason you only find later. And the events aren't uniform: a subscription, a penny-drop auth, and a handful of other flows each raise their own events with their own payloads. Hand-replaying the right one for every stuck transaction is exactly the month-end scramble you don't want.

So I built the escape hatch: one API that, given a transaction, reconstructs the correct accounting event (right type, right payload) and republishes it. The accounting side was idempotent, so replaying an event that had already landed did no harm; that is what made "replay everything that might be missing" a safe operation rather than a risky one. One endpoint became the one-stop fix for any accounting gap, and closing the month stopped being a scramble.

A kill switch with a scalpel

We already had a kill switch: one lever that stopped all transactions. That is the right tool for a genuine emergency and the wrong one for almost everything else, because "stop everything" is a blast radius you rarely actually want.

So I made it granular. You could now cut traffic to a single merchant, a single API path, or a specific merchant-and-path pair. That precision changed what the switch was for:

• Shed load at peak. Turn off the status checks and other read paths while leaving the actual payment flows untouched: protect the money path by silencing the noise around it, not by stopping everything.
• Defend your own service. When a bad actor hammered one endpoint, we could block them at our service, at the exact path, instead of filing a ticket and waiting on another team to act at the edge. The team that owned the service could defend it.

A blunt kill switch protects you from disaster. A precise one lets you keep running through the things that aren't disasters. Most days, the more useful of the two.

Teaching the books about a new entity

PhonePe had just built a partner service: a way to onboard partners who extend the ecosystem's reach, each bringing their own merchants with them. The catch: a partner was a brand-new kind of entity, and the accounting-and-settlement system had never heard of one. It understood merchants; it knew nothing about partners, and partner-referred money settles by a different set of rules.

My job was the integration that closed that gap: teach accounting what a partner is, and the rules that come with it, so a payment flowing through a partner-referred merchant is recognised correctly and settled to the merchant the right way. Until accounting could see the partner and apply its rules, the new channel couldn't move money to anyone.

The judgment: a new business entity isn't real to a payments platform until the money system knows how to account for it. Reach is a slide deck until settlement works.

Dynamic pricing, self-serve

Partners don't just bring reach; they bring merchants on their own commercial terms. Each merchant can be onboarded at a custom rate (the cut PhonePe takes) and the only real constraint is that the economics still work. Setting those rates used to be manual: every custom-rate onboarding hand-worked, one at a time. That does not scale when volume is the whole point of the channel.

Template management (the heart of what we called dynamic pricing v2) turned pricing into configuration. A partner could onboard a merchant on a custom-rate template, self-serve, with no manual pricing exercise each time. More than twenty partners came on this way, referring over a hundred merchants between them.

The judgment: turning a per-merchant negotiation into a templated, self-serve flow is the difference between a channel that scales and one bottlenecked on a human doing pricing by hand.

None of it shipped a feature anyone saw. Each one kept the platform correct, or defended, or able to grow, the kind of work that is invisible right up until it isn't there. No repo, no screenshot; just my word that the money kept moving the way it was supposed to.