UPI Has an Owner. Your Payment Doesn't.

NPCI owns UPI. It doesn't own your payment.

The first line of NPCI's own published roles-and-responsibilities document is unambiguous: "NPCI owns and operates the Unified Payments Interface."¹ It prescribes the rules, approves who participates, routes the traffic, and runs settlement.

What that sentence doesn't cover is the four things that actually determine whether your specific payment works. NPCI doesn't own the app you tapped. It doesn't hold your money. It doesn't verify your PIN. And it doesn't credit the merchant. Those belong to a third-party app provider, your bank, your bank again, and a fourth institution you have no relationship with at all.

So UPI has an owner. A single transaction across it does not. The switch is owned end to end; the path isn't.

That distinction is the whole reason UPI fails the way it does. Every failure mode in the flow below sits on a line between two organisations that don't report to each other, run on separate infrastructure, and are held to separate obligations.

Eight hops, three organisations

A UPI payment initiated by scanning a merchant QR code, the Intent flow, runs through eight steps between tap and confirmation. The interesting annotation isn't what each step does. It's which ones cross a company boundary.

1. User taps Pay; the merchant app fires a UPI Intent.
2. The intent resolves to a registered UPI app — Google Pay, PhonePe, Paytm, whichever is set as default.
3. The app validates the payee VPA and sends the request to NPCI.
4. NPCI checks the daily transaction limit and routes the debit request to the issuing bank.
5. The issuing bank authenticates the UPI PIN, which is entered into a secure library on the device and travels encrypted, never in the clear, and checks the balance.
6. The debit executes. Money leaves the account here.
7. The payee PSP credits the merchant's account.
8. The merchant is notified and the user sees a success screen.

Steps 1 and 2 happen inside one device, and mostly inside one company's code. Everything from step 3 onward crosses a boundary. The app talks to NPCI, NPCI talks to your bank, your bank talks back, and a separate bank on the payee side completes the credit. Three organisations minimum, four if the app you used is a third-party provider riding on a sponsor bank's UPI licence — which, for Google Pay and PhonePe, it is.¹

Watch it break

Click the highlighted node to advance. Steps marked with a dot have a failure branch; selecting one shows the technical cause, what the user sees, and the engineering response. Six failure modes are mapped in.

Three failure types, not six edge cases

Listed as six, these read like an incident catalogue. Grouped by what kind of distributed-system problem they are, they collapse into three, and the grouping is more useful than the list.

Unknown state after a partition. The network drops after the debit instruction goes out but before confirmation returns. The debit may have succeeded. The app has no way to know. This isn't a payment failure at all, it's a partition, and the only correct response to a partition is to stop guessing and reconcile. The specific error here is showing "Payment Failed" when the truthful answer is "we don't know yet." Reconciliation against NPCI's records plus a proactive notification is the fix; a better error string is not.

An SLA breach on a party you don't control. The PSP doesn't hear back from NPCI inside the mandate window. Your app owns the spinner and owns none of the latency. This category has a legally defined floor: the RBI's TAT framework requires that a UPI merchant payment where the account is debited but the merchant never gets confirmation be auto-reversed within T+5 days, with ₹100 per day of delay payable to the customer, paid out without the customer having to ask.²

Read that carefully, because it's the most underappreciated fact in Indian retail payments. Five days. And the obligation to reverse falls on the beneficiary bank — an institution the user has never interacted with, chosen, or heard of. The person whose money is missing has no contractual relationship with the entity legally required to return it.

Silent failure in a dependency you routed into blind. The issuing bank is down, and you find out after the user has entered their PIN. They did everything right and got a generic failure twenty seconds later. The architectural problem is that the routing decision was made without any signal about the destination's health. You can't fix this after the PIN. You fix it before the bank is selected, or not at all.

The other three modes in the simulator — NPCI limit rejections, incorrect PIN, duplicate transactions — fall into the same three buckets. Once you're classifying rather than enumerating, the response patterns generalise, which is the point of classifying.

Where AI belongs, and where it never does

Three of the responses above are, structurally, prediction problems. Which bank is degrading right now. Which of thousands of pending transactions correspond to which settlement records. Which route is likeliest to complete in the next sixty seconds. Those are legitimate machine learning problems: they operate on high-volume signals, they tolerate error, and being wrong costs a retry.

None of the responses in the authorisation path are. PIN verification, debit execution, and mandate limit checks are places where the system must produce the same answer every time for the same inputs, and must be able to explain that answer to an auditor years later. Swap a probabilistic component into that path and you don't get a better version of the deterministic one. You get a worse system dressed up to look the same.

The formulation I'd resist, though, is "AI should never touch money movement," because it's already false. Fraud and risk scoring on UPI is probabilistic today, and it does block transactions. Any principle that pretends otherwise gets dismissed by anyone who works in payments.

This is the same shape as the argument in the Aegis credit engine, where a fraud gate can override any score but no score can buy past the gate. I didn't set out to write the same position twice. It keeps turning out to be the same position.

What I'd build: a contract, not a state machine

The version of this I'd have written a year ago proposed a client-side transaction state machine with honest states — Initiated, Pending, Confirmed, Failed, Reconciling — instead of the two most apps ship, Success and Failed. That's still right, and it's still not enough, because it solves the problem inside one app's boundary and the problem isn't inside one app's boundary.

The platform version is a shared failure envelope: a status contract every PSP implements identically, where "pending" carries a machine-readable resolution deadline derived from the TAT obligation, and where an unresolved transaction has one canonical status across the app, the PSP, and the bank rather than three views that disagree. The client state machine is the consumer half of that contract. Without the contract, every app invents its own vocabulary for uncertainty, and the user learns that "pending" means nothing in particular.

I'd frame this as a hypothesis rather than a proposal. The technical design is the easy half. The hard half is that the contract has to be specified by the one party with rule-making authority over all the others, and NPCI's incentive to standardise how failure is displayed is much weaker than its incentive to standardise how it's settled. That's a governance argument, not an engineering one, and I don't have a good answer to it.

Where this doesn't reach

This covers the Intent flow only, and Intent is increasingly the only flow there is. NPCI discontinued person-to-person collect requests from October 1, 2025, to cut a well-documented fraud vector,³ and manual-VPA collect for merchant payments was phased out from February 28, 2026, with carve-outs that still matter — IPO and stock market applications, iOS, autopay mandates, and international transactions. So "Collect is dead" is close enough for most consumer contexts and wrong in the four that are left.

AutoPay mandates run a separate flow with their own failure modes, and BBPS is a different rail entirely. I haven't traced either.