UPI payment flow end to end

The app creates a transaction ID and asks the payer PSP to validate the VPA. NPCI routes that to the payee's PSP, which returns the verified name. I enter my PIN on NPCI's Common Library pad, which encrypts it so the app never sees it. The PSP sends ReqPay to NPCI. NPCI asks my bank to verify the PIN and debit my account, then asks my friend's bank to credit theirs. When both legs succeed, NPCI returns a final response to both PSPs and we both get notified. Settlement between the banks happens later, in NPCI settlement cycles, and every party reconciles against NPCI's files.

I never mark it failed, because the payee bank may already have credited the account. NPCI treats it as deemed or pending, and the app shows 'pending, do not pay again'. The PSP queues a status check and calls ReqChkTxn with backoff, staying within NPCI's limits on frequency. If the status comes back as success, we notify both sides. If the credit is confirmed as failed, the debit is reversed. If it is still unknown, reconciliation against the NPCI settlement file decides. RBI's turnaround framework requires auto-reversal for failed credits by T+1, with compensation for delays, so I would alert on anything close to that deadline.

There are five actors. The payer app captures intent and creates the transaction ID. The payer PSP bank owns the customer's VPA, device binding and the ReqPay call. NPCI's UPI switch routes by VPA handle and bank, runs timers and orchestrates the legs. The remitter (issuer) bank verifies the PIN in its secure environment and debits in core banking. The beneficiary bank credits the payee. The payee PSP resolves the payee VPA and notifies the payee or merchant. On the side sit settlement and reconciliation, which run on NPCI settlement files per cycle, and UDIR for disputes. The key point is that NPCI orchestrates while the banks hold the money and the ledgers. The PSP never moves funds itself; it only requests and tracks.

I start with INITIATED when the intent is persisted with its transaction ID. Then SUBMITTED once ReqPay has gone to NPCI. From there it moves to SUCCESS or FAILED on a final RespPay, or to DEEMED or PENDING when the outcome is unknown. DEEMED can only move to SUCCESS, or to FAILED with a reversal reference, after ReqChkTxn or reconciliation confirms it. A REVERSED state records an auto-reversal of a debit. Transitions are forward-only and guarded with a version column or conditional update, so a late or duplicate response cannot move SUCCESS back to PENDING. Every transition is written as an event, which gives an audit trail and feeds notifications through an outbox.

Idempotency is anchored on the transaction ID. The app generates it once per payment intent and persists it before any network call. A retry from the user or the client reuses the same ID, and the PSP checks a unique constraint in the ledger plus a Redis key, so a duplicate returns the existing state instead of starting a new ReqPay. Downstream, NPCI and the banks also deduplicate on the transaction reference. The most important rule is that uncertainty is resolved by asking for status, never by resending the payment. State transitions are one-directional and stored with versions, so a late response cannot overwrite a final state.

The main table is keyed by transaction ID, which is unique per intent. It holds payer and payee VPA, the resolved payee name, amount, currency, initiation mode such as QR, intent or manual, current state, NPCI's reference number once known, the response code, created and updated timestamps, and a version for optimistic locking. A separate append-only transaction-events table records each request and response, with the raw message reference. A reconciliation table maps each transaction to its settlement cycle and match status. Refunds and disputes are separate tables linked by the original transaction ID, never in-place edits. I keep PII minimal, mask account numbers and store data in India to meet RBI's data localisation rule.

I state the assumptions clearly rather than quote real figures. Say the PSP handles 100 million transactions a day with a peak-to-average ratio of five. The average is about 1,160 per second, so the peak is about 6,000. Each payment writes one row and roughly five event rows, plus several status polls. If a row with events is around 2 KB, that is about 200 GB a day before replication, and several terabytes a month. So I need horizontal sharding by transaction ID, hot data kept for the dispute window, and cold storage for audit. Status polling and notifications usually add more load than writes, so read replicas and caching of final states matter. I would add headroom for festival and salary-day spikes.

Because a real-time message is not a ledger. Responses can be lost, timeouts create deemed entries, a bank can debit and then crash before replying, and a PSP can miss an update while it is down. Settlement is what actually moves money between banks, so each participant matches its own records against NPCI's settlement files for every cycle. That catches debited-but-not-credited cases, deemed entries that later succeeded, duplicates and amount mismatches. Reconciliation is the safety net that makes sure nothing stays unresolved even if every online mechanism fails. It is also what regulators and auditors rely on. Real-time status is for user experience; reconciliation is the source of financial truth.

In the deemed state the money may already be in the payee's account; NPCI just did not get the credit response in time. If the app says 'failed', the payer will usually pay again and may be debited twice for one real purchase, which is exactly what the system must prevent. The merchant may also release or cancel goods wrongly. Showing 'pending', with a clear message that it will resolve and a reversal will follow if the credit did not happen, sets the right expectation. The PSP then confirms the outcome through ReqChkTxn and reconciliation. Honest uncertainty is safer than a false failure, and it cuts down on duplicate payments and complaints.

If the credit leg fails after a successful debit, the remitter bank must return the money. When NPCI gets a clear credit failure it triggers a reversal to the remitter bank in the same flow. For deemed cases that later turn out not to be credited, the reversal happens after reconciliation. RBI's harmonised turnaround-time framework sets the limit for UPI at T+1, meaning the debit must be reversed by the day after the transaction. If a bank misses this, it must pay the customer compensation without the customer having to file a claim. Engineering-wise, reversals must be idempotent and keyed to the original transaction, and TAT breaches should be tracked as an alert, not left to a report.

At registration the app sends an outbound SMS from the phone's SIM, so the PSP can confirm that the mobile number registered with the bank is physically in that device. The PSP then binds the customer profile to that device and SIM, using device identifiers and keys. Later payment requests carry this binding, and a SIM swap, a new device or reinstalling the app forces rebinding. This stops an attacker who only knows someone's VPA, phone number or even PIN from paying from another phone. It works with the PIN as a second factor: something you have, the bound device, plus something you know. Rebinding events should also be inputs to fraud scoring.

Three reasons. First, it shows the payer the verified name or merchant details from the payee PSP, so they can spot a wrong or fake recipient before committing; that is a major anti-fraud control. Second, it fails fast on a VPA that does not exist or is inactive, so you don't waste a PIN entry and a debit attempt that would only fail or need reversing. Third, it gives merchant attributes such as category and verified status, which affect limits and risk checks. The cost is one extra round trip through NPCI, but it happens before the user types the PIN, so it barely affects perceived latency. Skipping it would push errors into the money-moving part of the flow.

Reads and validations, such as VPA lookup, can be retried freely. A payment request can only be retried with the same transaction ID, so NPCI and the banks can deduplicate it; a new ID would be a new payment. If the outcome is unknown, I don't resend the payment at all; I switch to ReqChkTxn. Status checks use exponential backoff with jitter and must stay within the frequency limits NPCI sets, because NPCI now restricts how often participants can poll. After those checks I stop and leave the case to reconciliation. Merchant webhooks are retried with backoff from an outbox. The rule is that retries are about learning the outcome, not about trying the debit again.

The transaction was persisted as INITIATED, and as SUBMITTED before the call, so after restart a recovery job finds rows stuck in SUBMITTED longer than the expected response window. For each, it does not resend the payment; it calls ReqChkTxn with the original transaction ID to learn the real outcome and applies it through the normal guarded state transition. If NPCI also reports it as unknown or deemed, the row moves to PENDING and joins the usual backoff and reconciliation path. The user sees 'pending' meanwhile. Writing the state before the external call, write-ahead style, is what makes this possible; if you only write after the response, a crash leaves no trace of the payment.

Strong consistency is needed at the money points: the issuer bank's debit and the beneficiary bank's credit in their core banking systems, and the PSP's state transition for a transaction ID, which must be atomic and forward-only. Idempotency checks also need strong consistency, or two retries could both pass. Eventual consistency is fine for notifications, transaction history views, analytics, merchant dashboards and reconciliation outputs. The system as a whole is eventually consistent across banks: legs complete at different moments and deemed cases resolve later. Reconciliation and reversals provide the guarantee that it converges. I would say this in an interview: per-account and per-transaction strong, cross-bank eventual with guaranteed resolution.

First, detect it: track failure and timeout rates per bank from response codes and latency. When a bank crosses a threshold, a circuit breaker can warn users before they enter the PIN, telling them that bank is facing issues and suggesting another linked account. I would not silently drop requests that NPCI would route anyway, because NPCI and the bank own the final answer. Payments already in flight follow the normal path, and timeouts become pending, not failed. I would also cut down status polling toward that bank and rely on backoff and reconciliation. Publishing a bank health view internally helps support teams, and alerting should key off success-rate drops per bank, not just global errors.

A reversal undoes a payment that never completed properly, for example a debit with no credit. A refund happens after a successful payment, often days later, for business reasons such as a returned order or a partial cancellation. The original transaction is final and already settled, so you cannot rewrite it. A refund is a new credit from the merchant's account to the customer, with its own transaction ID and a link to the original. That keeps ledgers append-only, lets partial and multiple refunds work, and makes reconciliation clean. The merchant system must make refund requests idempotent with its own refund ID, so a retried refund call does not pay the customer twice.

A static QR encodes the merchant's VPA and name, and sometimes a fixed amount. The payer types the amount, so the merchant must match the incoming payment to an order using time and amount, which is hard to reconcile. A dynamic QR is generated per order and carries the amount and a merchant transaction reference. That gives exact order matching and also helps with idempotency on the merchant side. Signed QR codes carry a signature the app can verify, which reduces tampering. In design terms, dynamic QR moves the merchant toward a clean order-to-payment mapping, while static QR needs a fuzzy matching layer and stronger notification handling.

I use the transactional outbox pattern. When the state changes to a final value, the same database transaction inserts an outbox event. A separate relay publishes these events to a queue, and consumers send push notifications, SMS and merchant webhooks. This avoids the dual-write problem where the state updates but the notification is lost, or the reverse. Delivery is at-least-once, so every event has an ID and merchants must deduplicate on it. Webhooks retry with backoff, and merchants can also call a status API to pull the final state. For the merchant, the webhook is a hint; the authoritative check is the status API or settlement report before releasing high-value goods.

I shard by a hash of the transaction ID, which spreads writes evenly and keeps every lookup for one payment on one shard. Queries by user or merchant go through secondary indexes or a separate read store built from events. A large merchant during a sale can generate a huge share of traffic, so I avoid any per-merchant counter or row that is updated on every payment. Things like running totals are computed asynchronously from events or with sharded counters. Merchant-facing reads such as reports come from replicas or an analytics store, not the primary. Per-merchant rate limits and separate queues for webhooks stop one merchant's backlog from slowing others.

UDIR is NPCI's Unified Dispute and Issue Resolution framework. It lets the payer's app raise a complaint about a specific transaction, such as a debit without credit or a merchant not delivering, directly through standard APIs, instead of the customer calling the bank. The complaint is routed to the right participant, tracked with a status, and many cases, especially failed or deemed transactions, can be resolved automatically using transaction status and reconciliation data. On the PSP side, I link the complaint to the original transaction ID, show its status in the app, and drive auto-resolution from my reconciliation results. That shortens resolution time and reduces manual support work.

Participants connect to NPCI over dedicated, controlled network links, not the open internet, and use encrypted, mutually authenticated channels. UPI messages are XML and are digitally signed, so NPCI can confirm they came from the right participant and were not altered. Sensitive data such as the PIN is encrypted separately by the Common Library on the device, so even the PSP cannot read it, and only the issuer bank can decrypt it in its secure environment, typically using hardware security modules. Keys are rotated and managed under strict controls. Inside the PSP, I would also use mTLS between services, secrets in a vault, and audit logging of every message sent and received.

RBI's payment data storage directive requires the full end-to-end payment data to be stored only in India, which drives region choice and backup locations. The Digital Personal Data Protection Act, 2023 adds duties around purpose limitation, consent, retention and breach handling. In practice I collect only what the flow needs, mask account numbers and VPAs in logs, never log PINs or encrypted PIN blocks, and restrict access to transaction data by role with audit trails. Retention follows regulatory and dispute requirements, then data is archived or deleted. Analytics use pseudonymised data. I would also make sure third-party SDKs in the app cannot read payment screens or payment data.

The best places are before the PIN prompt and before ReqPay goes out. At that point you know the device, the binding age, the payee's verified name and merchant category, the amount and the user's recent pattern. Checks can block, add friction such as a warning or cooling-off period for a new payee, or allow. Banks also run their own checks at debit time. The trade-off is latency against fraud loss: UPI users expect payments in seconds, so the inline model must be fast with a strict timeout, and on timeout you need a defined fallback, usually allow with lower limits or flag for review. Heavier models run asynchronously and feed back into rules.

Two-phase commit would require every bank to hold locks while waiting for a coordinator, across independent core banking systems with very different latencies. One slow or failed bank would block funds and resources, and coordinator failures can leave participants stuck. UPI instead runs a saga-like flow: debit first, then credit, and a compensating reversal if the credit fails. Unknown outcomes become deemed and are resolved later by status checks and reconciliation. This accepts a short window of inconsistency in exchange for availability and scale across many banks. Doing debit first matters because it guarantees the payer has the money before anyone is credited, so the only failure to repair is a refund to the payer.

I track success rate split into business declines, such as wrong PIN or insufficient funds, and technical declines, such as timeouts, since only the second reflects system health. I track per-bank and per-response-code rates, end-to-end latency percentiles, the count and age of pending or deemed transactions, ReqChkTxn volumes against NPCI limits, reversal turnaround against T+1, reconciliation mismatch counts per cycle and notification lag. Sensible SLOs are a technical success rate target, a latency target for the PSP's own share of the path, zero pending transactions older than the TAT, and reconciliation completed within each cycle. I would not quote NPCI's internal numbers, but I would alert on drops against my own baseline.

I would build a simulator for NPCI and banks that can inject specific failures: no response, late response after timeout, duplicate RespPay, credit failure after debit, and wrong amount in settlement files. Then I would run scenario tests that check the invariants: no double debit for one transaction ID, no transaction stuck past TAT, and every deemed case reaching a final state. Chaos tests kill PSP pods mid-request to confirm recovery picks up SUBMITTED rows. Reconciliation is tested with seeded mismatches. NPCI also requires certification against its UAT environment before going live. Property-based tests on the state machine are cheap and catch illegal transitions early.

Collect requests let anyone send a payment request that the payer approved with their PIN. Fraudsters abused it by sending requests disguised as refunds or prize money, and victims entered their PIN thinking they would receive money. Withdrawing P2P collect removes that attack path. For app design, person-to-person transfers are now push-only: the payer starts and confirms every payment. Collect flows remain for verified merchants and for mandates, so the app still needs approval screens, but they should clearly show the verified merchant, the amount and that money will leave the account. Any leftover P2P collect code paths should be removed, and new ones should not be built.

Every incoming response goes through the same guarded transition keyed by transaction ID. DEEMED to SUCCESS is a legal forward move, so the late success is applied with a conditional update on state and version, and the outbox sends the success notification. The duplicate then finds the row already in SUCCESS; the update matches nothing, so it is logged and dropped with no new notification. If a conflicting response arrives, for example failure after success, it is not applied automatically; it raises an alert and goes to reconciliation, because NPCI's status and the settlement file decide. Storing every raw response in the events table makes these cases easy to investigate.

The bank should key each credit on the transaction's unique identifiers from NPCI, such as the transaction ID and reference number, and record them in the same database transaction as the account credit, with a unique constraint. If NPCI retries the credit request or the bank receives it twice, the second attempt finds the existing record and returns the original result without crediting again. The response must be the same as the first one, including success, so NPCI does not think it failed. This matters most around timeouts: NPCI may never have seen the first reply, so a repeat request is normal. Without this, a retried credit could pay the payee twice.

UPI Lite is an on-device balance for small-value payments. The user loads money into it from their bank account with a normal PIN-authorised transaction. After that, small payments are debited from the Lite balance without a PIN and without hitting the issuer's core banking for each payment, which cuts failures caused by bank downtime and reduces load on banks. The trade-offs are lower per-transaction and balance limits set by NPCI and RBI, and the need to keep the device-side balance and the bank-side record in sync. Losing the device is a risk, so the limits are kept small. It is a good example of moving small payments off the critical bank path.

A mandate is created once: the payer approves it with their PIN, setting the payee, maximum amount, frequency and validity. Later debits within those rules are executed without a PIN for each one, subject to limits, and the payer gets a pre-debit notification before each execution. Mandates can be paused, changed or revoked by the payer. Design-wise you need a mandate store with its own state machine, a scheduler that triggers executions, idempotency on each execution so a retried run does not debit twice, and handling of failures such as insufficient balance. Because P2P collect has been withdrawn, mandates and verified merchant collect are where the 'payee starts it' pattern still matters.

Both sites must be in India because of data localisation. I would run active-passive or carefully partitioned active-active, with synchronous or near-synchronous replication of the transaction store so a failover does not lose the record of submitted payments. If some recent writes might be lost, the recovery process must treat recent transactions as unknown and resolve them through ReqChkTxn and reconciliation rather than guessing. Network links to NPCI need redundancy at both sites. Idempotency keys and transaction IDs must be globally unique across sites. I would run regular failover drills and measure real recovery time and data loss against the targets, not just document them.

1. ABy the payer PSP bank's switch
2. BBy the payer's issuing bank after NPCI forwards the encrypted PINCorrect answer
3. CBy NPCI's central switch
4. DBy the payment app's backend

Why: The PIN is captured and encrypted by NPCI's Common Library on the device, and only the issuing (remitter) bank verifies it. Apps and PSPs never see it in clear text.

1. AThe NPCI UPI switch
2. BThe payer's issuing (remitter) bankCorrect answer
3. CThe payee's bank
4. DThe payer's PSP app

Why: The PIN is encrypted by NPCI's Common Library and only the issuing bank decrypts and verifies it in its secure environment.

1. APending, with resolution to followCorrect answer
2. BSuccess
3. CCancelled by bank
4. DFailed, please retry

Why: Money may already be credited, so showing failed could trigger a duplicate payment; the correct state is pending.

1. ABecause NPCI limits how many IDs a PSP can create
2. BTo speed up PIN verification
3. CTo reduce message size
4. DSo downstream systems can deduplicate and avoid a double debitCorrect answer

Why: A single ID per intent lets NPCI and banks recognise retries as the same payment rather than new ones.

1. AImmediately issue a refund
2. BResend ReqPay with a new transaction ID
3. CMark it failed and notify the user to retry
4. DCall ReqChkTxn for the same transaction ID with backoffCorrect answer

Why: A status check on the original ID finds the true outcome without risking a duplicate debit. Refunds or reversals only follow once the credit is confirmed to have failed.

1. ACollect requests settle outside NPCI
2. BPay requests need the payee's account number
3. CCollect requests skip PIN authentication
4. DIn a collect request the payee initiates and the payer approves with their PINCorrect answer

Why: In a collect flow the payee sends the request and the payer must approve it with their PIN. In a pay flow the payer initiates. NPCI has withdrawn P2P collect, so collect is now limited mainly to merchant use cases.

1. AReqValAdd
2. BReqChkTxnCorrect answer
3. CRespPay
4. DReqPay

Why: ReqChkTxn is the check-transaction API used to resolve unknown or deemed outcomes.

1. ADebit and credit in parallel
2. BDebit first, then creditCorrect answer
3. COnly the debit; credit happens at settlement
4. DCredit first, then debit

Why: NPCI debits the payer first and then sends the credit request, so a failure only requires a reversal to the payer.

1. AT+5
2. BT+30
3. CT+0 within one hour
4. DT+1Correct answer

Why: RBI's harmonised TAT framework sets T+1 for auto-reversal of failed UPI transactions.

1. ATo check the payer's balance
2. BTo show the verified payee name and fail fast on invalid VPAsCorrect answer
3. CTo generate the transaction ID
4. DTo settle funds in advance

Why: Validation returns verified name or merchant details so the payer can confirm the recipient before any debit.

1. AThe payer raises a collect request to the merchant
2. BThe original transaction is edited to a lower amount
3. CNPCI reverses the original debit
4. DA new credit transaction linked to the original is createdCorrect answer

Why: The original payment is final, so refunds are new linked credit transactions.

1. ADuplicate settlement files
2. BWrong payee names
3. CSlow network latency
4. DSomeone initiating payments from another device using stolen credentialsCorrect answer

Why: Binding ties the customer to a verified device and SIM, so knowing the VPA or PIN alone is not enough.

1. ATo catch lost responses, deemed entries and mismatches that online flows missedCorrect answer
2. BTo compute the UPI PIN
3. CTo generate new VPAs
4. DBecause real-time responses are always wrong

Why: Reconciliation is the safety net that resolves anything the real-time path left inconsistent.

1. ASend ReqPay again with a new transaction ID
2. BMark it failed and ask the user to pay again
3. CQuery status with ReqChkTxn using the original transaction IDCorrect answer
4. DCredit the payee from the PSP's own account

Why: An unknown outcome must be resolved by checking status, not by sending a new payment.

1. ABBPS
2. BUDIRCorrect answer
3. CNACH
4. DIMPS

Why: UDIR is NPCI's Unified Dispute and Issue Resolution framework for UPI.

1. ANPCI's Common Library on the deviceCorrect answer
2. BThe payee PSP
3. CThe merchant's POS terminal
4. DThe PSP's backend server

Why: The Common Library captures and encrypts the PIN so neither the app nor the PSP sees it in clear text.

1. AOnly UPI Lite payments
2. BBetween any two individuals
3. CVerified merchants and mandatesCorrect answer
4. DOnly international remittances

Why: P2P collect was withdrawn to cut fraud; collect now mainly applies to verified merchants and mandates.

1. ATwo-phase commit with the push provider
2. BTransactional outboxCorrect answer
3. CFire-and-forget HTTP calls
4. DClient-side polling only

Why: Writing the event in the same database transaction as the state change avoids the dual-write problem.

1. APayment date
2. BPayer's bank name
3. CMerchant ID
4. DHash of the transaction IDCorrect answer

Why: Hashing the transaction ID spreads load evenly and avoids hot shards from big merchants or busy days.

1. ASagas never have inconsistency
2. BBanks do not support databases
3. CTwo-phase commit is illegal in India
4. DHolding locks across many independent banks hurts availability and can block on failuresCorrect answer

Why: Debit-then-credit with compensation keeps the system available across many banks, accepting a short inconsistency window.

1. ASUCCESS to PENDINGCorrect answer
2. BINITIATED to SUBMITTED
3. CSUBMITTED to SUCCESS
4. DDEEMED to SUCCESS

Why: States must move forward only; a late or duplicate message must not move a final state back.

1. AOnly on the user's device
2. BAnywhere, if encrypted
3. COnly in IndiaCorrect answer
4. DIn the payer's home state

Why: RBI's payment data storage directive requires full payment data to be stored only in India.

1. AForward it to the payer bank
2. BCredit again and reverse later
3. CReject it with a failure code
4. DReturn the original result without crediting againCorrect answer

Why: An idempotent credit returns the same response as the first attempt, so NPCI gets the right outcome without a double credit.

1. AFraud and risk scoring on payee, amount and deviceCorrect answer
2. BInterbank reconciliation
3. CUDIR complaint creation
4. DSettlement netting

Why: Risk checks before PIN entry can block or add friction before any money moves.

1. AInto business declines and technical declinesCorrect answer
2. BBy time of day only
3. CInto P2P and P2M only
4. DBy app version only

Why: Wrong PIN or low balance are user-side; timeouts and errors reflect system health and need separate tracking.

1. AEach PSP individually
2. BNPCICorrect answer
3. CThe payee's app
4. DThe merchant aggregator

Why: NPCI computes net positions per settlement cycle and settles them between banks.

1. AEach call debits a fee from the user
2. BPolling changes the transaction amount
3. CThe API returns a new PIN each time
4. DNPCI sets frequency limits on status checks, and heavy polling overloads banksCorrect answer

Why: NPCI restricts status-check frequency, so PSPs must back off and then rely on reconciliation.

1. ACheck their status with the original ID and apply the resultCorrect answer
2. BDelete them
3. CMark them all failed
4. DResend ReqPay with new IDs

Why: The real outcome is unknown, so the job checks status and applies it through the normal state transition.

1. APayments only via feature phones
2. BCross-border payments
3. CHigh-value payments without limits
4. DSmall payments from an on-device balance without a PIN for each oneCorrect answer

Why: UPI Lite holds a small balance on the device for low-value PIN-less payments, within set limits.

1. AA specific amount and merchant order referenceCorrect answer
2. BThe payer's bank account number
3. CThe settlement cycle
4. DThe payer's PIN

Why: Dynamic QR codes are generated per order with amount and reference, which makes matching exact.

1. AExecute debits within agreed limits and frequency without a PIN for each oneCorrect answer
2. BChange the payer's PIN
3. CSkip pre-debit notification
4. DDebit any amount at any time

Why: Once approved with a PIN, mandate debits run within the agreed rules, with pre-debit notifications to the payer.

1. AUnsigned JSON
2. BSMS text
3. CSigned XMLCorrect answer
4. DPlain CSV

Why: UPI messages are XML and are digitally signed by participants.

1. ABanks could not process it
2. BIt lacked encryption
3. CIt was too slow
4. DFraudsters abused it with fake requests that victims approvedCorrect answer

Why: Fake collect requests disguised as refunds or prizes tricked users into approving debits.