Reversing the UPI Wallet Protocol:
From OTP Login to Transaction History

Platforms: Amazon Pay · MobiKwik · PhonePe · BharatPe · Airtel · FreeCharge · Paytm

1. Overall Architecture

1.1 Transport

All platforms run over HTTPS (TLS), with some enabling HTTP/2 to reduce handshake overhead. Request bodies are predominantly JSON; a few legacy endpoints (e.g. Amazon Pay) still use the older server-rendered HTML + client-side parsing pattern.

1.2 Session Lifecycle

A UPI wallet session follows a strict linear pipeline with hard state dependencies — each step's output is the next step's input:

Device init / registration
        ↓
Fetch encryption public key (some platforms)
        ↓
Request OTP send (phone number entered)
        ↓
Verify OTP → obtain Auth Token / Cookie / Session
        ↓
Query UPI ID (requires logged-in Token)
        ↓
Query transaction list (requires Token, paginated)
        ↓
Query transaction detail (optional)
        ↓
Token refresh / logout

An OTP request that omits the prerequisite Cookie is rejected outright; a Token that did not pass OTP verification cannot reach the UPI ID or history endpoints. This "progressive unlock" is itself a layer of defense-in-depth.

2. The OTP Login Flow

OTP login is split into a send step and a verify step:

• Step 1 — Request OTP send: the client submits a phone number; the server sends a 4–6 digit code to that number.
• Step 2 — Verify OTP: the client submits the code; on success the server returns an auth credential used as the identity for all subsequent calls.

Some platforms (e.g. Paytm) layer a multi-step OAuth2 authorization on top of OTP verification (state token → authorization code → access token), ultimately producing a Bearer Token valid for roughly one month.

2.1 Prerequisite Steps

Before requesting an OTP, most platforms require one or more initialization actions — so a "bare" OTP request is almost impossible to succeed against a modern UPI wallet:

2.2 Request-OTP Endpoint

Method: POST  ·  Auth state: anonymous

Beyond business fields, the Header layer carries extensive device and crypto metadata:

Success-response fields: otpId / nid / sessionId (unique OTP ID, echoed at verify), otpLength (4 or 6), and a platform status flag (success:true / status:"SUCCESS").

Common errors: phone number not found / malformed, rate-limited, device not authorized.

2.3 Verify-OTP Endpoint

Method: POST  ·  Auth state: anonymous

The client submits the 4–6 digit code plus the correlation identifier returned by the send step. On success the server issues an auth credential — and the credential's concrete shape is where platforms diverge most:

Common verify failures: wrong code (attempts decrement), expired (~3–5 min), max attempts exceeded (5 tries → 24h lockout).

3. The Encryption Scheme

UPI wallets generally use a hybrid RSA + AES scheme:

• Asymmetric (RSA): the client fetches the server's RSA public key (~36h validity) and uses it to wrap a one-time AES key.
• Symmetric (AES): the business body (e.g. phone number) is AES-encrypted; the AES key itself is RSA-wrapped and placed in a Header (cske) so the server recovers it with its private key.

This mirrors the "double-layer" idea of running application-layer encryption inside TLS: even if the transport is observed by a MITM (e.g. a debug proxy), the application-layer ciphertext still protects sensitive fields.

4. UPI ID Lookup & Transaction History

Once the auth credential is in hand, two core paths open up:

1. UPI ID (VPA) lookup: Token-gated; returns the registered Virtual Payment Address (e.g. xxxx@bank) and binding status. Some platforms attach this directly in the OTP-verify response.
2. Transaction history: also Token-gated, paginated, with optional single-transaction detail. These endpoints directly expose a user's financial trail and carry additional device checks and rate limits.

5. Security Controls Summary

6. Methodology Notes

1. Establish session context first. Always capture from a cold start and record the full prerequisite chain — device registration → public-key fetch → cookie acquisition — or later requests won't replay.
2. Identify the crypto layer. Locate the client-side RSA public-key cache and AES key-generation logic; they usually concentrate in the network layer or a dedicated crypto class.
3. Track token lifecycles. Distinguish short-lived from long-lived tokens, and note their different injection points across Header / Cookie / Body.
4. Watch for risk signals. Rate limiting, attempt lockout, and device-fingerprint checks are implicit constraints outside the protocol proper — they often define the feasibility boundary of any automation.

This document is for technical demonstration and authorized research only. It provides no tools or methods for unauthorized access to real payment services. © CoderGeek.