What I learned removing hops from a UPI flow

A UPI transaction looks instant to the customer. Behind that, it can pass through half a dozen systems, each adding milliseconds and, more importantly, each adding a way to fail. When I mapped ours end to end, the diagram was longer than anyone expected — including the people who built it.

The hops were not there by mistake. Each one was added for a good reason at some point: a validation, a log, a workaround for a partner who has since changed their API. Nobody removes these, because nobody is sure what breaks. So the map itself was the deliverable — once everyone could see the full chain on one page, the conversation shifted from "is it fine?" to "which of these still earns its place?"

The reasoning that carried the day was failure surface, not speed. A hop that adds 30ms is easy to defend. A hop that owns a timeout, a retry policy and a reconciliation edge case is not. We prioritised by how much operational noise each one produced, not by latency.

The lesson I carry from it: performance work in payments is usually a documentation problem first. You cannot delete what nobody has drawn.