India: UPI and IMPS create different identifiers and different exception queues

“The customer sent it through UPI, so the money is ours” is a poor opening to an investigation. The buyer may see a confirmation, the checkout may show an unpaid order, the provider may have a later event, and the bank statement may contain an entry without a recognizable order number. These are not four payments. They are four views of one transaction that processing must connect before increasing an available balance.

Compare UPI and IMPS as payment mechanisms, rather than applications. An app name tells you where the customer pressed a button. It does not establish the recipient’s contract, available evidence, permitted business activity or refund procedure. This article addresses lawful merchant operations; access to an Indian payment method does not itself open an online gambling market.

First identify what you have actually integrated

NPCI describes UPI as an instant payment system built on IMPS infrastructure. Merchant acceptance requires an acquirer, which assigns the merchant category and supplies the integration. A UPI address, QR code or app handoff does not turn a personal account into an approved merchant product. NPCI’s description explains participant roles, but older customer journey examples should not automatically become a current launch specification.

For IMPS, familiar routing uses an account number and IFSC; the documentation also describes a mobile number combined with an MMID. IFSC belongs to bank routing, while MMID belongs to that identification scheme. Neither replaces a merchant order ID. NPCI gives an IMPS ceiling of INR 500,000 per transaction, excluding SMS and IVR channels; the customer’s bank may impose a lower limit for a particular channel.

Identifiers that should remain separate

A recommended payment record contains the internal order number, attempt number, rail type, provider payment ID, bank reference exactly as received, amount, currency, creation time and confirmation time. Store a separate snapshot of the destination instructions: the relevant payment address and merchant context for UPI, or the account and bank code for a bank transfer. The ledger should never contain a PIN, OTP or banking password.

Why a snapshot? The destination may change after an order is created, while the customer pays using the old instructions. A system displaying only the current recipient turns an investigation into an argument about recollection. Preserve the instructions issued for that attempt and the actual credit at the time. Matching amount and time remains a search clue, rather than proof that the funds belong to a particular order.

Do not make an operator guess what “UTR” means in an intermediary’s export. Request a data dictionary: who generated the value, whether it is unique within a bank or the entire integration, whether it survives a refund, and whether it can retrieve transaction status. One interface may expose a customer reference and another a gateway ID. Undocumented mappings create a genuine support cost.

A success page and a financial status are separate things

Razorpay, for example, exposes payment.authorized and payment.captured events. Its documentation explains that a webhook represents the state when the event occurred, even if the object has already changed. This is one gateway’s model, not a universal UPI status vocabulary. The corresponding checkout design principle is to authenticate events, match amount and order, retain the original status and post the financial entry once.

Consider an illustrative case: an order expires at 12:05 and confirmation arrives at 12:06. The system cannot safely declare the attempt definitively unpaid, issue a new payment and then automatically credit the old attempt again. Create a late-confirmation queue. It should decide whether to restore the order or initiate a refund under the approved procedure. Either outcome must be clear to the customer and remain linked to the original attempt in the ledger.

Failure reversal and purchase refund are different processes

RBI’s failed-transaction framework distinguishes an account debit without beneficiary credit from a UPI merchant payment lacking confirmation at the merchant location. Its published table assigns T+1 and T+5 to the relevant cases, with compensation for delays beyond the specified period. These are correction deadlines for particular failures, not a promise to refund any purchase within the same time. T is the calendar transaction date. RBI’s table.

A support case therefore needs classification first. Was the payer debited? Is there a confirmed recipient credit? Was the order cancelled commercially, or did the payment fail? Has a separate refund been executed? Sending the same amount back as a new transfer leaves the original transaction unresolved; a later automatic reversal can then create double reimbursement.

Instant payment does not describe your settlement contract

“When does the merchant get the money?” requires an account to be named. The destination may be an agreed merchant or intermediate account under the acquiring contract. A PSP ledger balance, an available balance and a credit to the enterprise’s operating bank account are not interchangeable. Ask for a settlement report showing gross receipts, fees, tax deductions, refunds, reserves and net proceeds. Then verify the net amount against the bank statement.

Confirm limits separately for each transaction, day, payer type, merchant category and channel. A number in an old FAQ is not a universal ceiling for every UPI payment. A pilot should test authorized boundary amounts and normal rejection cases; splitting payments to circumvent controls is not an acceptable solution.

The boundary for gaming businesses

India’s Promotion and Regulation of Online Gaming Act, 2025 prohibits facilitation of payments for an online money gaming service in section 7; its definition of money games is not limited to games of chance. MeitY also publishes 2026 rules and notifications. An overseas gaming licence does not authorize these payments in India. Before discussing activation, obtain a current legal assessment covering the particular product, applicable rules and court decisions.

The practical readiness test is straightforward: the team must reconstruct one payment from the displayed instructions to the credit, onward merchant settlement and any subsequent refund. If that works only through screenshots and chat messages, the integration is not ready to scale, even when its first ten transfers arrived instantly.