UPI Payment Operations Runbook for Order Mismatches

When a customer says “money deducted” but the order is pending, support needs a runbook—not a guess. The goal is to identify the correct merchant order, find authenticated payment evidence, classify the exception, and apply one authorized resolution without leaking data or creating a second financial error.

Start With a Case Reference

Create a support case before changing order state. Store:

• Merchant tenant
• Customer-visible order reference
• Expected amount
• Approximate customer payment time
• Current local order state
• Assigned operator
• Safe contact channel

Do not paste complete event payloads into chat tools. Do not request UPI PINs, OTPs, passwords, screen-sharing access, or full bank credentials. A screenshot may help identify what the customer saw, but it is not proof of payment.

Classify the Exception

Use a specific category:

Category	Meaning
Paid but local order pending	Verified payment exists; local transition is missing or delayed
Amount mismatch	Payment and expected order total differ
Unknown reference	Payment evidence does not map to the submitted order
Duplicate payment	More than one verified payment may relate to one purchase
Late success	Payment verified after local expiry
Customer-only claim	No authenticated evidence found yet
Merchant-provider issue	Connected provider record needs official support review

A category controls the next action and makes recurring causes measurable.

Collect Minimum Evidence

Query only inside the authorized tenant. Compare:

1. client_txn_id
2. Gateway order ID
3. Expected and verified amount
4. Final payment state
5. Event ID and delivery result
6. Provider or UTR reference when available
7. Related replacement or duplicate orders

Never match by amount and time alone. Common prices produce ambiguous results. The UTR-to-order guide provides a safer matching sequence.

If the gateway result is still unknown, use a controlled backend payment status check. Repeated browser refreshes or creating a second order do not resolve the original evidence.

Resolution Matrix

Evidence	Resolution
Verified exact match, order pending	Apply authorized idempotent paid transition and fulfil once
Verified amount mismatch	Hold for merchant policy review
Verified late success	Move to late-payment review; decide honour or refund
Duplicate verified payment	Prevent duplicate fulfilment and escalate provider/finance handling
No verified evidence	Keep unresolved; give customer case reference and accurate next step
Reference belongs to another order	Do not disclose that order; escalate inside tenant controls

Manual actions should require role authorization and write an audit event containing actor, reason, previous state, resulting state, and evidence IDs. Direct database edits bypass these controls.

Refund timing and method depend on the connected acquiring bank or merchant provider. NPCI advises merchants to raise transaction grievances with their acquiring bank and follow the bank-defined refund process. Source: NPCI UPI FAQ.

Close and Learn

Close a case only after:

• Order and payment states agree, or an explicit exception owner remains assigned.
• Customer receives an accurate outcome.
• Duplicate fulfilment risk is checked.
• Audit record contains the resolution reason.
• Root cause category is captured.

Review weekly patterns: delayed webhooks, signature rejection, wrong callback URL, order-reference reuse, amount mismatch, late success, and unclear customer UX. Link each pattern to an engineering or merchant-operations action.

Use customer messages that describe what is known without claiming a result too early:

Case state	Safe support message
Verification still pending	“We are checking payment reference ORD-123. Please do not pay again while this review is open.”
No matching evidence yet	“We have not yet matched a completed payment to this order. Your case remains open while we check the merchant records.”
Exact payment verified	“Payment for ORD-123 has been verified and the order is moving to fulfilment.”
Provider review required	“This transaction needs review by the merchant payment provider. We will update this case through the same support channel.”

Do not promise a refund date unless the authorized bank or provider process gives you one. Set an internal follow-up time, record every ownership handoff, and keep one case reference across customer support, engineering, and finance. This prevents three teams from making conflicting decisions about the same payment.

A good runbook protects both sides. Customers receive a traceable answer, while merchants avoid screenshot-based fulfilment, cross-tenant data exposure, repeated credits, and undocumented payment-state edits.