Why You Can't Build an App on UPI123PAY - And Why That's a Good Thing

Aman Patel — Sun, 19 Apr 2026 15:30:07 +0000

If you've ever wondered — "Can I build my own app that uses UPI123PAY?" — the short answer is no. But the real answer is much more interesting, and understanding why will teach you how India's payment security architecture actually works under the hood.

Let's break it all down.

🤔 What is UPI123PAY?

Launched by RBI and NPCI in March 2022, UPI123PAY was designed to bring UPI payments to feature phone users — people without smartphones or internet access. It operates over:

IVR (Interactive Voice Response) — Call a number and navigate a voice menu
Missed Call payments — Give a missed call to a pre-registered number
Sound-based payments — Using ultrasonic proximity tones
Feature phone apps — Lightweight apps on non-smart devices The goal was noble: bring 400+ million feature phone users into the digital payments ecosystem.

But here's the question that any curious developer asks next:

"Can I build an app that hooks into UPI123PAY and automates payments?"

❌ Why Building a UPI123PAY App Is Not Possible

The Licensing Wall

To interact with UPI123PAY infrastructure, you need to be a recognized entity in a very strict hierarchy:

NPCI (National Payments Corporation of India)
        │
        ├── Member Banks (SBI, HDFC, Axis...)
        │         │
        │         └── PSPs (Payment Service Providers)
        │                   │
        │                   └── TPAPs (Google Pay, PhonePe, Paytm...)
        │
        └── TSPs (Telecom Service Providers: Jio, Airtel, Vi)
                  │
                  └── UPI123PAY channel

As an independent developer or even a startup, you sit nowhere in this diagram by default.

To get in, you need:

Requirement	Issued By	Reality Check
UPI Membership	NPCI	Banks only
PSP License	NPCI	Large fintechs/banks only, heavy compliance
TSP Agreement	Jio / Airtel / Vi	Requires PSP license first
PA License (Payment Aggregator)	RBI	Minimum ₹25 Cr net worth
IVR Infrastructure Access	TSP partners	Not publicly available

Even if you somehow got a TSP to partner with you, you're still nowhere near being able to freely access the UPI123PAY flow. And there's a very specific reason why — security.

🚨 "But What If NPCI DID Give Access? Can They Steal Money?"

This is the smartest question to ask. Let's say hypothetically, NPCI and a TSP partner with a rogue company and give them full UPI123PAY integration. Could that company silently drain your bank account?

The answer is still NO — and here is the technical reason why.

The UPI PIN Wall — The Unbreakable Barrier

Let's trace a UPI123PAY transaction flow completely:

User's Phone
    │
    ├─ Dials *99*1*1*recipientVPA*amount#   ← Even if an app pre-fills this
    │
Telecom Network (Jio/Airtel/Vi)
    │
    ├─ Routes to NPCI UPI Switch
    │
NPCI Backend
    │
    ├─ Validates VPA, account, amount
    │
Bank Server
    │
    └─ Sends PIN prompt via SIM Toolkit (STK)
              │
              ↓
         ┌─────────────────────────────┐
         │   "Please enter your        │
         │    UPI PIN on keypad"        │  ← THIS CANNOT BE AUTOMATED
         │                             │
         │   User physically types PIN │
         └─────────────────────────────┘
              │
              ↓
         DTMF tones → Encrypted PIN Block
              │
              ↓
         Bank HSM (Hardware Security Module)
              │
              ↓
         Transaction Approved / Rejected

The critical insight here is that the UPI PIN is not part of the USSD menu flow. It is a completely separate secure prompt handled by the SIM Toolkit (STK) — a secure application that lives on your SIM card itself, not on your phone's OS.

No app, no TSP, no middleware can:

Pre-fill the PIN prompt
Inject keystrokes into it
Intercept the encrypted PIN in transit
Bypass the HSM validation This is not just a policy rule. It is cryptographic architecture. The PIN block is end-to-end encrypted between your SIM's secure element and the bank's HSM. There is no point in the chain where a third-party app can read or manipulate it.

🔐 "But Regular UPI Apps Like PhonePe/GPay — How Are They Secure?"

This is where most people get confused. They assume that since you enter your PIN inside the UPI app, the app must be able to see or store it.

This is completely wrong.

Here's what actually happens when you pay via GPay or PhonePe:

The PIN is NEVER entered in the UPI App

GPay / PhonePe App
    │
    ├── Collects: recipient VPA, amount, remarks
    │
    ├── Sends transaction request to PSP backend
    │
    ↓
PSP Backend (Google's / PhonePe's servers)
    │
    ├── Forwards to NPCI UPI Switch
    │
    ↓
NPCI → Bank Server
    │
    └── Bank sends PIN prompt via
        ──────────────────────────────────────────
           Android / iOS Secure PIN Page
           (Hosted by the BANK, not the UPI app)
        ──────────────────────────────────────────
              │
              ↓
         You see a screen that says:
         "Enter UPI PIN" (this is BANK-controlled UI)
              │
              ↓
         PIN goes directly to bank's server
         over an encrypted channel (TLS + HSM)
              │
              ↓
         GPay / PhonePe NEVER sees your PIN
         GPay / PhonePe NEVER stores your PIN

This is enforced by the NPCI UPI Security Framework and verified during the PSP certification process. UPI apps are technically UI shells — they collect the recipient and amount, but the actual PIN verification happens on a secure page that is:

Rendered by the bank's own SDK (not the UPI app)
Communicates directly with the bank's backend
Isolated from the UPI app's memory and storage ### Why PhonePe / GPay Cannot Steal Your Money

Even if a rogue developer somehow got a PSP license and built a malicious UPI app, they still couldn't steal money because:

PIN never touches the app — The bank SDK handles PIN entry in an isolated process
Transaction requires your explicit confirmation — The app cannot auto-submit without your action
NPCI monitors all transactions in real-time — Anomalous patterns trigger freezes
Device binding — UPI accounts are bound to your SIM + device combination; transactions from a different device require re-registration

5. Velocity checks — Sudden large or repeated transactions trigger holds

🛡️ The Complete Security Architecture Summary

Layer	What it protects	How
NPCI Licensing	Unauthorized apps from entering the system	Strict membership, audits, compliance
TSP Partnership	USSD/IVR channel access	Not available to third parties
SIM Toolkit (STK)	PIN input isolation	Secure element on SIM, OS cannot access
Bank PIN Page	PIN never reaches UPI app	Isolated bank SDK, separate process
HSM (Hardware Security Module)	PIN decryption and validation	Tamper-proof hardware at bank datacenter
Device Binding	Account takeover prevention	SIM + device fingerprint required
NPCI Real-time Monitoring	Fraud detection	ML-based anomaly detection on every transaction

💡 So What CAN You Build?

If you're a developer wanting to integrate UPI into your product, here are your legitimate paths:

1. Payment Gateway Integration (Easiest)

Use licensed payment aggregators — Razorpay, Cashfree, PayU, Instamojo. You get UPI collect and intent flows via their SDKs with no NPCI license needed on your end.

2. Become a TPAP (Third Party App Provider)

Like GPay or PhonePe, but requires a tie-up with a sponsor bank (SBI, Yes Bank, etc.), NPCI approval, and an extensive technical audit.

3. Apply for a Payment Aggregator (PA) License

RBI-issued, requires ₹25 Cr minimum net worth. Full control over payment flows, full regulatory responsibility too.

4. UPI Deeplinks (For Your Own App)

You can trigger UPI payments from your app using the upi:// deeplink scheme:

upi://pay?pa=merchant@upi&pn=MerchantName&am=100&cu=INR&tn=OrderID

This opens the user's UPI app of choice. You never handle the PIN. This is the correct, secure, NPCI-approved way for merchants.

🧠 Key Takeaways

1. UPI123PAY is locked by design — No independent developer can access it without NPCI + TSP partnership, and those partnerships are not available to arbitrary companies.

2. Even a rogue partner cannot steal money — The UPI PIN architecture is cryptographically isolated. No middleware, no app, no TSP can access or inject the PIN.

3. UPI apps (GPay/PhonePe) are secure by design — They never see or touch your PIN. PIN verification happens on a bank-controlled secure page that is completely isolated from the UPI app.

4. The security is not just policy — it's cryptographic — SIM Toolkit, HSM, end-to-end encrypted PIN blocks. Even NPCI itself cannot read your PIN in transit.

5. The right way to build UPI products — Use payment gateway SDKs, upi:// deeplinks, or apply for proper licensing.

🔚 Final Thought

India's UPI architecture is genuinely one of the most secure real-time payment systems in the world. The reason it works at this scale — 10+ billion transactions a month — is precisely because of these layered security boundaries.

The next time someone tells you "UPI apps can steal your money," you can now explain exactly why the architecture makes that impossible — not just by policy, but by cryptographic design.

The walls are not bureaucratic red tape. They are load-bearing walls.

Found this useful? Drop a comment or follow for more deep dives into Indian fintech infrastructure, security architecture, and mobile payments.

Forem: Aman Patel