How UPI payments work, and the engineers behind every layer

The parties

Five roles exist in any UPI transaction, and a given company may play several of them.

The payer PSP is the app the user touches. It handles the user's registration, device binding and UPI PIN capture, and it initiates the request. A third-party app operates here through a sponsor bank rather than directly.

The sponsor bank or PSP bank holds the relationship with NPCI on behalf of a non-bank app. This is why a fintech cannot simply connect to UPI: it needs a bank willing to sponsor it, and that relationship is commercial, regulatory and technical at once.

NPCI operates the central switch. It routes requests, maintains the mapping between virtual payment addresses and accounts, enforces scheme rules, and runs the settlement process between member banks.

The remitter bank holds the payer's account and performs the debit. The beneficiary bank holds the payee's account and performs the credit.

A payment is therefore not one transaction. It is a debit at one institution, a credit at another, and a later settlement obligation between them, coordinated by a switch.

The path of a payment

A simplified collect-free, intent-style flow:

1. The user selects a payee and amount in the PSP app, which resolves the virtual payment address with NPCI.
2. The app captures the UPI PIN. The PIN is encrypted on the device within the NPCI common library and is never visible to the app itself.
3. The PSP submits the request to its sponsor bank, which forwards it to NPCI.
4. NPCI validates the request and sends a debit instruction to the remitter bank.
5. The remitter bank checks balance and risk, debits the account, and responds.
6. NPCI sends a credit instruction to the beneficiary bank, which credits the payee.
7. NPCI returns the outcome to the originating PSP, which shows the user success or failure.
8. Separately, on a later cycle, NPCI computes net positions between banks and settlement occurs.

Steps one to seven complete in seconds. Step eight is a different system entirely, and it is where most engineering disputes end up.

Where it actually breaks

The successful path is straightforward. Production UPI engineering is dominated by the states that are neither clean success nor clean failure.

Timeouts with unknown outcome. The remitter bank debits the account but the response to NPCI times out. The user sees failure. The money has left. This is the single most common serious failure mode, and resolving it correctly is the difference between a trusted product and a support queue.

Deemed approval. Scheme rules define what happens when a participant does not respond in time. A transaction may be treated as approved even though the originating system recorded no confirmation, which means the system's own state and the scheme's state disagree.

Credit pending. The debit succeeds and the credit is delayed at the beneficiary bank. The payer has paid, the payee has not received, and both are looking at your app.

Reversal and refund asymmetry. A failed credit must be reversed to the payer. That reversal is itself a transaction that can fail, and the window for it is defined by scheme rules rather than by your product.

Duplicate submission. A user retries. Without strict idempotency keyed on the transaction reference, a retry becomes a second payment, which is unrecoverable from the user's perspective and expensive from yours.

Peak load asymmetry. UPI volumes in India are extremely high and arrive with sharp peaks around salary dates, festivals and sale events. Systems that behave at average load degrade in ways that only appear at peak, and the degradation usually shows up first in the ambiguous states above rather than in outright failure.

The consequence for hiring is direct: an engineer who has integrated a payment gateway has seen the happy path. An engineer who has owned a UPI stack has spent most of their time on this list.

The variants that generate most current work

The core flow above is stable. Recent engineering demand concentrates in the layers built on top of it, and a candidate's exposure to these is a useful proxy for how recently they have worked on live UPI systems.

Mandates and autopay. Recurring payments under UPI use a mandate: a standing authorisation with a defined amount, frequency and validity, executed later without the user present. The engineering is materially harder than a one-off payment because the execution happens asynchronously, failures are silent from the user's perspective, and retry policy is constrained by scheme rules. Subscription businesses live or die on this working.

UPI Lite and on-device balance. Small-value payments settled against an on-device balance rather than a full round trip to the bank. This exists to reduce load on the core system and improve success rates for low-value transactions, and it introduces a second place where balance state lives, which has obvious reconciliation consequences.

Credit line on UPI. A pre-sanctioned credit line, rather than a bank balance, as the funding source. This connects the payments stack directly to a lending book, which means the payment decision now depends on credit logic, limits and utilisation. It is where lending infrastructure and payments stop being separate systems.

The market share cap. NPCI has maintained a policy position limiting any single third-party app's share of UPI volume. Whether and how it is enforced has been repeatedly deferred, but it shapes product and infrastructure planning at the largest players and is a live consideration in any senior conversation at those companies.

Cross-border. UPI acceptance is expanding in a number of corridors. The engineering adds currency conversion, different settlement timing and a second regulatory regime, and the talent for it is genuinely scarce because very few people have built it.

A candidate who has worked only on the core collect-and-pay flow and a candidate who has shipped mandates or credit line on UPI are at different levels, and the difference does not show up in a job title.

The economics, and why they shape the engineering

Person-to-merchant UPI in India operates with zero merchant discount rate. There is no per-transaction revenue to fund the infrastructure that carries the transaction.

This has a direct engineering consequence that surprises people arriving from card-based markets. The payments stack is a cost centre justified by what it enables: user acquisition, data, cross-sell into lending and wealth, float, and distribution. Investment in payments engineering is therefore defended in terms of reliability and scale rather than margin, and the teams are smaller relative to volume than the equivalent card businesses elsewhere.

It also explains why the commercial leadership role at a UPI business is a genuinely different job, covered in Head of UPI Business.

Talent implications

Each layer of this stack maps to a role, and the pools do not overlap as much as job titles suggest.

Three observations from running these searches.

The scarce profile is settlement, not integration. Engineers who can integrate a payments API are plentiful. Engineers who have personally owned settlement files, dispute windows and reversal logic are not, because the work is unglamorous and few people choose it deliberately. This is consistently where UPI-adjacent searches stall.

Ask about the ambiguous states at interview. The question that separates candidates quickly is some version of: a debit succeeded and the response timed out, what does your system do next, and what does the user see? A candidate who has owned this answers immediately and in detail. A candidate who has not will describe a retry.

Bank-side and fintech-side experience are different. An engineer from a remitter bank understands core banking constraints, batch windows and the internal approval environment. An engineer from a PSP understands scale, user experience and latency. Both are valuable and they are not interchangeable; a brief that says "UPI experience" will surface both and the panel will struggle to compare them.

For a broader view of how the role layers fit together, see FinTech roles in India. For the systems that sit directly adjacent to this one, see ledger architecture and reconciliation and breaks.