The Hidden Life of a UPI ID

@ybl to @oksbi: the hidden architecture, ownership, and lifecycle of India’s payment identity.

Open Google Pay.

Tap “Create UPI ID.” Wait two seconds.

Done. You now have rahul@oksbi.

Here’s what nobody tells you: Google didn’t create that. Google Pay doesn’t own it. And if Google Pay shut down tomorrow, what happens to your UPI ID is far more complicated and far more interesting than you’d expect.

I’m a backend engineer who spent the last month inside UPI onboarding and payment routing systems. What I expected was a simple username registration. What I found was a layered ownership structure, a surprisingly fragile namespace, and edge cases that affect millions of people who don’t know these edge cases exist.

The part after the @ is the real story

Most people read rahul@oksbi and think: rahul is the important part.

Flip that. The handle after the @ is where all the interesting decisions live.

These handles aren’t branding decisions. They’re ownership markers. Each one identifies which PSP — Payment Service Provider is the registered custodian of that VPA (Virtual Payment Address) within the NPCI network.

Did you know?

The app you use and the entity that owns your payment identity are not the same thing.

Google Pay → your interface

SBI (@oksbi) → your identity’s actual owner

NPCI → what makes it all resolve

How UPI IDs are actually formatted

NPCI defines one universal rule for what a VPA can look like:

[username]@[psp-handle]

The username: 3–60 characters, letters, numbers, dots, hyphens, underscores. No spaces, no special characters. Total length under 100 characters. Simple.

What varies significantly is how each app decides what goes before the @.

Three different philosophies sit behind these choices:

Google Pay ties your identity to your Gmail name. Your UPI ID becomes yourgmail@oksbi — readable, name-first, and notably does not expose your mobile number.

PhonePe ties your identity to your phone number. 9876543210@ybl means anyone who knows your number can pay you without asking for your UPI ID separately. PhonePe also lets you create up to 3 additional custom-name slots on the same account.

Bank apps default to mobile number too — because the mobile number is already the KYC anchor for the account. No separate identity layer needed.

The handle after the @ you cannot choose. It’s assigned by the PSP. The prefix before the @ is where each app has made a deliberate product decision about what your payment identity should look like.

Why different apps suggest different UPI IDs

Your bank account is the same. So why does Google Pay suggest rahul13@oksbi while PhonePe suggests 7898875643@ybl and Paytm suggests rahul@paytm?

Did You Know?

One HDFC savings account can simultaneously have all three of these — and they all land money in the same place.

7898875643@ybl (PhonePe / Yes Bank)

rahul13@oksbi (Google Pay / SBI)

rahul@paytm (Paytm / Paytm Bank)

The answer is PSP namespace ownership.

Each PSP has a licensed handle within the NPCI network — and each PSP prefers to register users within its own namespace. When you open Google Pay for the first time and link your HDFC account, Google Pay’s PSP partner (SBI) registers you under @oksbi. PhonePe’s PSP partner (Yes Bank) registers you under @ybl.

From your perspective as a user: all three IDs work identically. Money arrives the same way regardless of which handle the sender uses.

From the ecosystem’s perspective: each PSP is quietly building a directory of identities it controls. The more users registered under @ybl, the more payment flows PhonePe can observe and route through its stack.

This is also why the same person can and often does end up with three different UPI IDs pointing to the exact same account. Not because they wanted three identities. Because three PSPs each wanted them in their namespace.

Not all UPI IDs are created equal

This is the section most explainers skip entirely. UPI IDs come in three distinct types with different ownership chains, behaviors, and failure modes.

Type 1 — Personal UPI IDs (Third-Party Apps)

Type 1

Type 2 — Bank-Owned UPI IDs

Type 2

Type 3 — Merchant UPI IDs

Type 3

What actually happens when you create a UPI ID

It looks like creating a username. It’s actually a multi-party registration across a national payment network.

The lifecycle of a UPI ID

Most people assume a UPI ID is created once and exists forever. It isn’t.

Every UPI ID moves through a lifecycle and most users are unaware of what happens at each stage.

Active

Your UPI ID is linked to an active bank account and is ready to send and receive payments.

Dormant

If the UPI ID isn’t used for a long time, the PSP may classify it as dormant based on its own operational policies.

Inactive

If the linked account is closed, the relationship changes, or the UPI ID is no longer maintained, it may eventually become inactive and stop working for payments.

Key Insights

A UPI ID isn’t a permanent username.

It’s a managed payment identity whose status can change over time.

Interesting Edge Cases Most Users Never Think About

The real complexity isn’t in creating a UPI ID. It’s what happens months or even years later.

1. What happens when you delete Google Pay?

Most people think deleting the app deletes the UPI ID. It doesn’t.

Your UPI ID is registered in the PSP’s server and NPCI’s registry not inside the app. The app is just a window. Closing the window doesn’t remove what’s inside.

What actually happens:

  • Your UPI ID stays active in the registry after you uninstall
  • Money sent to your “deleted” handle can still land in your bank account
  • No notification is sent to you either way

The app is a client. The identity lives in the network. These are two completely separate things.

2. What happens when a PSP exits UPI?

This isn’t hypothetical. It’s a structural risk baked into how UPI namespaces work — and it has no clean solution.

Every UPI handle belongs to a PSP-owned namespace. @ybl belongs to Yes Bank. @paytm belongs to Paytm Payments Bank. @oksbi belongs to SBI operating on behalf of Google Pay. The PSP is the registered custodian of that namespace within NPCI’s system.

If that PSP exits the UPI ecosystem — whether due to regulatory action, business failure, or a strategic pullback — every VPA under that namespace is at risk:

  • Every UPI ID under that namespace can become unresolvable overnight
  • There is no automatic forwarding to a replacement handle
  • There is no grace period communicated to users or merchants
  • Anyone who saved that handle in their contacts, accounting software, or printed invoices has no recourse

The closest documented example is Paytm Payments Bank. In early 2024, RBI directed Paytm Payments Bank to stop onboarding new customers and eventually wind down certain banking operations. Users with @paytm handles scrambled to migrate their UPI IDs to other PSPs — except there is no migration. You cannot port a VPA. You can only create a new one on a different PSP and hope your contacts update their records.

Merchants who had store@paytm printed on QR codes, banners, and invoices had to reprint everything. There was no redirect. No forwarding address. No official transition period for the handle itself.

3. Can someone else claim your abandoned UPI ID?

Nobody has a clear answer. That’s the problem.

You used 7898875643@ybl for three years. You switch apps and never open PhonePe again. The PSP eventually marks your VPA dormant, then inactive, then deregistered.

Could someone else register 7898875643@ybl now?

There is no public policy on VPA recycling. If UPI follows the telecom model where old numbers are reassigned after dormancy your former identity could belong to a stranger. An old contact pays them by mistake. No one is notified.

It goes further. UPI namespaces have no trademark enforcement layer. NPCI checks uniqueness, not legitimacy. That means:

  • Anyone can register tata@paytm before the Tata Group does
  • A scammer can register hdfcbank@upi to collect payments from confused users
  • Protection is reactive only PSPs can remove fraudulent handles after a complaint, not before

The network is robust. The namespace ownership layer has single points of failure that most people haven’t thought about.

The Namespace Challenge

Unlike internet domain names, UPI handles don’t publicly expose a trademark reservation process before registration.

The primary goal of the ecosystem is uniqueness and successful payment routing not brand protection.

That creates interesting questions:

  • How are well-known brand names protected?
  • Can similar-looking VPAs confuse users?
  • How are disputes resolved?

In practice, PSPs perform KYC checks and can suspend fraudulent VPAs after they are reported.

But from a developer’s perspective, it highlights an interesting challenge:

Payment identity and brand identity are not always solved by the same mechanisms.

The Real Innovation Behind UPI IDs

  • The real innovation wasn’t making payments shorter it was making them humanize.
  • People don’t remember account numbers.
  • They remember identities.
  • Just as an email address routes a message to the right inbox, a UPI ID routes money to the right bank account.
  • That’s why UPI scaled so quickly: it hid banking complexity behind a simple, memorable identity.

A UPI ID Is Becoming More Than a Username

A UPI ID started as a way to send and receive money.

Today, it’s becoming the foundation for new financial services.

  • UPI Lite makes small payments faster.
  • Credit on UPI allows payments through approved credit lines.
  • Delegated Payments let trusted users pay on someone else’s behalf.
  • International UPI is expanding to supported countries and merchants.

One thing remains unchanged: rahul@oksbi

As new capabilities are added, your UPI ID stays the same.

It is slowly evolving from a payment address into a broader digital financial identity.

Key Takeaways

Here’s what I learned while working on UPI systems:

  • A UPI ID is not your bank account. It’s a unique payment identity linked to your account.
  • The part after @ tells you which PSP or bank manages that UPI ID.
  • Google Pay, PhonePe, and your bank are different players. The app provides the interface, the PSP manages the handle, and NPCI enables interoperability across the network.
  • One bank account can have multiple UPI IDs, all pointing to the same account.
  • Your UPI ID has its own lifecycle. It can be created, become inactive, or be managed differently depending on the PSP.

The next time you share: rahul@oksbi remember that it isn’t just a username.

It’s a payment identity that works across banks, apps, and one of the world’s largest real-time payment networks.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.