Skip to content

UPI / Real-time Payments#

Problem statement (interviewer prompt)

Design India's UPI-style real-time payments network: payer scans a QR / enters a VPA, money moves from payer-bank to payee-bank via a central switch in 2-5 seconds, 24×7. Cover idempotency, reversal on partial failure, end-of-day reconciliation, and PSP-level integration.

flowchart LR
  P[Payer App / PSP]
  NPCI[NPCI Switch / UPI]
  PB[Payer Bank]
  RB[Payee Bank]
  R[Payee App / PSP]
  P --> NPCI
  NPCI --> PB
  NPCI --> RB
  R --> NPCI

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class P,NPCI,PB,RB,R service;

flowchart TB
  subgraph Apps[PSP Apps]
    GP([GPay / PhonePe / Paytm / BHIM])
  end

  subgraph PSP[PSP / TPAP]
    SDK([UPI SDK])
    PSPC[PSP core service]
    DEV([Device + MPIN auth])
    SIM([SIM binding / one device])
  end

  subgraph Switch[NPCI UPI Switch]
    SWITCH[Central switch]
    ROUTE[VPA → bank mapping]
    NRR[NPCI reference]
    UDIR[UPI directory]
  end

  subgraph PayerBank[Payer Bank]
    PBANK[Bank CBS]
    ACCT[Account holds]
    DEBIT[Debit on success]
  end

  subgraph PayeeBank[Payee Bank]
    RBANK[Bank CBS]
    CREDIT[Credit]
  end

  subgraph Reconciliation
    RECON[Recon files end-of-day]
    REVERSAL[Reversal / NACK]
    DR[Dispute resolution]
  end

  subgraph Security
    PKI[Public key infra]
    SIGN[Signed messages]
    MPIN[MPIN at bank, never at PSP]
  end

  Apps --> SDK --> PSPC --> SWITCH
  SWITCH --> PayerBank
  SWITCH --> PayeeBank
  PayerBank -. credit confirm .-> SWITCH
  PayeeBank -. credit confirm .-> SWITCH
  Reconciliation --- SWITCH
  Security --- PSPC

    classDef client fill:#dbeafe,stroke:#1e40af,stroke-width:1px,color:#0f172a;
    classDef edge fill:#cffafe,stroke:#0e7490,stroke-width:1px,color:#0f172a;
    classDef service fill:#fef3c7,stroke:#92400e,stroke-width:1px,color:#0f172a;
    classDef datastore fill:#fee2e2,stroke:#991b1b,stroke-width:1px,color:#0f172a;
    classDef cache fill:#fed7aa,stroke:#9a3412,stroke-width:1px,color:#0f172a;
    classDef queue fill:#ede9fe,stroke:#5b21b6,stroke-width:1px,color:#0f172a;
    classDef compute fill:#d1fae5,stroke:#065f46,stroke-width:1px,color:#0f172a;
    classDef storage fill:#e5e7eb,stroke:#374151,stroke-width:1px,color:#0f172a;
    classDef external fill:#fce7f3,stroke:#9d174d,stroke-width:1px,color:#0f172a;
    classDef obs fill:#f3e8ff,stroke:#6b21a8,stroke-width:1px,color:#0f172a;
    class GP,SDK,DEV,SIM client;
    class PSPC,SWITCH,ROUTE,NRR,UDIR,PBANK,ACCT,DEBIT,RBANK,CREDIT,RECON,REVERSAL,DR,PKI,SIGN,MPIN service;

Flow (push, person-to-person)#

  1. Payer enters VPA + amount; signs request with MPIN on phone (verified at bank).
  2. PSP forwards to NPCI switch.
  3. Switch routes debit to payer bank.
  4. On success, switch sends credit to payee bank.
  5. Both banks acknowledge; switch returns NRR.
  6. Both PSPs notify users.

Latency budget#

  • End-to-end 2-5 s typical; SLA defined by NPCI.

Idempotency & retries#

  • Each leg has unique txn_id; retries must be idempotent.
  • Reversals on partial failure (debit success, credit fail) are critical and must be auditable.

Glossary & fundamentals#

Concepts referenced in this design. Each row links to its canonical page; the tag column shows whether it is a high-level (HLD) or low-level (LLD) concept.

Tag Concept What it is Page
HLD Idempotency & retries safe re-execution, backoff + jitter idempotency-retries

Quick reference#

Functional#

  • VPA-based addressing (name@bank).
  • Push payment & collect request.
  • QR codes, intent links, deep links.
  • 24×7 instant settlement.

Non-functional#

  • Sub-5s end-to-end.
  • Strong audit (NPCI mandates).
  • 99.99%+ per PSP.

Capacity (India, 2024)#

  • 10B+ transactions/month.
  • Switch peaks of thousands/s.

Schema (PSP side)#

  • users(id, primary_vpa, devices[])
  • bank_links(user_id, account, ifsc)
  • transactions(id, switch_ref, payer_vpa, payee_vpa, amount, status, leg_states[])
  • disputes(id, txn_id, reason, status)

Trade-offs#

  • Switch-mediated = centralized scaling pressure; NPCI invests heavily.
  • MPIN at bank only = strong security but extra hop.
  • No card networks = lower fees; different settlement model.

Refs#

  • NPCI UPI specs (public).
  • "UPI: A Real-Time Payment System" academic papers.
  • PhonePe / GPay engineering posts on scale.
  • ByteByteGo "Design a real-time payment system".

FAQ#

How does UPI work end to end?#

A payer app sends a payment instruction with the payee VPA to its PSP. The NPCI switch routes the debit to the payer bank and credit to the payee bank, settling in seconds.

What is a VPA in UPI?#

A Virtual Payment Address like name@bank is a human-friendly handle that resolves to an underlying bank account, hiding the actual account number from senders.

How does UPI handle failed transactions?#

If a debit succeeds but credit fails, the switch issues a reversal to make the payer whole. End-of-day reconciliation catches lingering inconsistencies between bank ledgers.

Why is UPI so fast compared to traditional bank transfers?#

UPI uses a central real-time switch with always-on connectivity to member banks and lightweight ISO 8583-like messages, completing transfers in 2 to 5 seconds 24x7.

What is a PSP in the UPI ecosystem?#

A Payment Service Provider is a bank or third party that hosts the user-facing app and submits transactions to the NPCI switch on behalf of users.

How does UPI prevent fraud?#

UPI relies on device binding, MPIN authentication, transaction limits, velocity checks, and real-time risk scoring by both PSPs and the central switch.