Daily UPI Payment Reconciliation Checklist for Merchants

Daily reconciliation finds the difference between what your application believes and what authenticated payment evidence shows. It is not a replacement for signed webhooks; it is the operational control that resolves late, uncertain, or mismatched cases before they become abandoned orders or repeated customer payments.

Assign a named operator and backup. An unowned dashboard is not a control, even when it contains accurate data.

Define the Reconciliation Window

Choose a daily cutoff based on your order lifecycle and support hours. Include the environment, merchant tenant, business date, and time zone in every report. A calendar date without time zone can split one payment across two operating days.

Start with these counts:

Population	Why it matters
Orders created	Baseline for the operating window
Verified successful payments	Authenticated payment population
Fulfilled orders	Business effects completed
Aged pending orders	Confirmation or customer-action uncertainty
Failed webhook deliveries	Transport or endpoint failures
Manual payment decisions	Higher-risk operator actions
Open provider cases	External ownership and follow-up

Large totals may be processed in aggregate, but every exception needs an individual case reference and owner.

Build the Exception Queue

Create deterministic categories instead of one generic “mismatch” list:

1. Verified payment, local order still pending.
2. Local paid state without authenticated evidence.
3. Expected and verified amount differ.
4. Event or provider reference does not map to the order.
5. More than one verified payment may relate to one purchase.
6. Payment succeeded after local expiry.
7. Webhook delivery failed or timed out.
8. Fulfilment failed after payment commit.
9. Customer claim has no matching evidence yet.

Prioritize by financial exposure, customer impact, age, and fulfilment risk—not merely newest first. Keep every query tenant-scoped.

Resolve by Category

For a paid-but-pending case, compare client_txn_id, gateway order ID, expected amount, final state, and event ID. Apply one idempotent transition only after the evidence matches. For an amount mismatch or unknown reference, hold the order and route it to an authorized operator.

For duplicate candidates, check whether two distinct verified attempts exist. Prevent a second fulfilment and send the financial case through the connected provider or acquiring-bank process. Do not assume one event is a retry merely because the amount matches.

For an unresolved order, use a controlled backend payment status check. Do not ask the customer to pay again while the original result is unknown. The order mismatch runbook contains a detailed evidence matrix.

Close With Evidence

An exception closes only when the record contains:

• Tenant and merchant order reference
• Expected and verified amount
• Gateway and event references
• Original and resulting order state
• Resolution category and reason
• Operator and approval where required
• Customer communication reference
• Provider case reference when applicable
• Completion timestamp

Do not paste complete webhook bodies or credentials into the case. Store safe references that authorized staff can use to retrieve protected records.

The daily owner should sign off totals: opening exceptions, new exceptions, resolved, still open, and escalated. These numbers should reconcile mathematically so cases cannot disappear through filtering.

Weekly Control Review

Daily work resolves cases; weekly review removes causes. Group exceptions by provider, application version, endpoint response class, device surface, error category, and time to resolution. Look for repeated callback failures, order-reference reuse, stale pending copy, deployment-related signature rejection, and unauthorized manual overrides.

Create one engineering or process action for every recurring cause. Reconciliation is successful when the exception rate falls—not when the team becomes faster at processing the same defect.

Use a consistent shift handoff for cases that remain open:

Handoff field	Example of useful content
Current evidence	“Authenticated payment not yet found”
Action already taken	“Status checked once; provider case opened”
Next action	“Review provider response at 16:00 IST”
Customer instruction	“Do not request another payment”
Owner	Named person or operating queue

Avoid notes such as “please check” or “looks paid.” They force the next operator to repeat the investigation and make unsupported assumptions. A good handoff states what is known, what remains unknown, and who is accountable for the next timed action.