How UPI Works: The ₹0 Magic Behind Every Scan-and-Pay (System Design)

UPI is a bank-to-bank payment system, not a wallet. The app on your phone is only a messenger. NPCI runs the central switch that connects banks, while the sender's bank is the only institution allowed to remove money from the account.

When you scan Bablu's faded QR code, your app reads his UPI ID and sends a payment request. The app reaches NPCI through its partner, or PSP, bank. NPCI identifies Bablu's bank, asks your bank to debit ₹20, and then asks Bablu's bank to credit him.

The process can finish in about two seconds, without cash, a card, or a fee. Your PIN is encrypted inside NPCI's common library and never travels to the app or NPCI. If a response is lost, NPCI marks the payment pending and checks whether the credit arrived.

UPI operates at an enormous scale. In August 2026 alone, it handled a record 24.51 billion transactions. That averages about 791 million transactions every day, showing that the two-second chai-stall payment is part of a vast national system.

The article places UPI at roughly 85% of India's digital payments. It also says UPI accounts for nearly half of all real-time payments on Earth. Each transaction still follows the same basic path: an app sends a request, NPCI routes it, and banks handle the money.

This scale makes reliability important. NPCI tracks responses, uses timeouts, marks slow banks pending, and checks payments when replies disappear. It also keeps a tally of what banks owe one another throughout the day. The article does not provide a separate settlement figure or schedule.

Each participant has a narrow job. The payment app collects your instruction and sends it onward. Your bank holds your money and is the only one allowed to debit it. NPCI runs the central switch, directory, tracker, and interbank tally.

For a ₹20 payment, the app sends the request through its PSP bank, the regulated bank connected to NPCI. NPCI asks the sender's bank to debit first. It then asks the receiver's bank to credit Bablu. The receiver's bank is where the money lands, but it does not take money from the sender.

This separation is central to UPI's design. Apps and NPCI are messengers, while banks touch money. The arrangement also assigns responsibility: PSP banks hold certificates and answer for app requests, while NPCI tracks timeouts, pending payments, and reversals.

UPI asks the sender's bank to debit before asking the receiver's bank to credit. This creates a safer order of operations. If a message gets stuck after the debit, the system can reverse that debit. If credit happened first without a successful debit, recovering the money would be harder.

Imagine your bank approves and removes ₹20, but the message to Bablu's bank disappears. NPCI does not assume success. It marks the payment pending and runs a check-status call. If Bablu's bank never received the credit, a reversal goes to your bank and the ₹20 comes back.

The article describes this as deliberate protection against money being stuck in transit. Its promise is simple: the money is with you, with the receiver, or in a reversible pending state. NPCI also applies strict timeouts and records each bank's obligations.

When money leaves your account but the receiver sees nothing, UPI treats the result as uncertain rather than guessing. The sender's bank has reported success, but a message may have been lost between NPCI and the receiver's bank. The payment becomes pending.

NPCI then runs a check-status call to learn whether the receiver's bank actually credited the money. If the credit landed, the payment can complete. If it never landed, a reversal goes back to the sender's bank, returning the debited amount. In the article's example, that means your ₹20 comes back.

The article says reversals usually happen within hours. This tracking process supports UPI's key promise: money is never in two places and never nowhere. NPCI also uses strict timeouts and marks slow banks pending instead of treating silence as success.

UPI apps need PSP banks because NPCI talks only to regulated banks. A PSP bank owns the connection, security certificates, audits, and legal responsibility for requests sent by the app. Using several PSP banks gives an app alternate routes when one partner is unavailable or slow.

The risk became clear in March 2020. PhonePe then ran only on Yes Bank. When the RBI placed Yes Bank under a moratorium, NPCI blocked its handles, and PhonePe went down with them. PhonePe added ICICI handles within months and later added Axis handles.

The lesson is architectural, not just commercial. One PSP can become a single point of failure for an app's UPI access. With multiple partners, the app can quietly route through another bank when one partner has trouble. The article presents this redundancy as today's practical design.

UPI is a switch, not a wallet. It moves money bank to bank through instructions, while NPCI coordinates the banks and keeps no funds itself. The article says NPCI records what every bank owes every other bank throughout the day, creating a tally alongside the individual payment flow.

For your ₹20, NPCI first gets your bank to debit and then asks Bablu's bank to credit. The banks' systems confirm these actions, while NPCI tracks replies, timeouts, and failures. This lets the customer see a near-instant result without money being stored in an app or central wallet.

The design also explains why UPI can avoid top-ups and hidden wallet spreads. The article does not describe the later interbank settlement process or say when physical funds move between banks. It does establish that NPCI maintains the obligations tally and that banks, not NPCI, handle the money.