A failed transaction and a disputed transaction are not the same event, but UAT plans frequently test them with one shared "transaction problem" scenario. They have different triggers, different timelines, different liability rules, and different remediation paths — a system that handles both correctly needs to distinguish between them from the moment the problem is detected, not after a customer complains.
Failed Transaction: Fast, Automatic, No Customer Action Required
A failed transaction is one where money moved (or was supposed to move) but the underlying technical process didn't complete — a UPI payment where the debit happened but the beneficiary was never credited, for instance. RBI's framework is specific and fast: for UPI, the beneficiary's bank must auto-reverse the failed transaction within T+1 day. Miss that window and the bank owes the customer ₹100 per day of delay, automatically, without the customer needing to file anything.
A UAT plan needs to verify both halves of this: the auto-reversal actually triggers without manual intervention, and — separately — the compensation accrual logic correctly starts counting from T+1, not from the original transaction date. Testing only "the money gets reversed eventually" misses the compensation clock entirely, and that clock is a real regulatory liability if it's wrong.
UPI failed-transaction auto-reversal triggers without manual queue intervention at T+1. Compensation accrual (₹100/day) begins correctly at T+1, not transaction date. Auto-reversal failure escalation — system correctly flags for manual review when auto-reversal itself fails.
Disputed Transaction: Slow, Customer-Initiated, Evidence-Based
A disputed transaction is different in kind — the transaction completed technically as designed, but the customer disputes it was authorised, or that goods/services were never received, or that the amount is wrong. This is not a system failure; it's a customer-initiated chargeback process, and it runs on a completely different and much longer timeline — commonly cited ranges run from roughly 30 to 120 days depending on the card network and the bank's internal process, with separate stages for the customer raising the dispute, the issuer reviewing it, the merchant providing evidence, and final resolution.
A UAT plan that tests "transaction reversed" as a single outcome for both failed and disputed transactions has conflated two systems that need to operate on entirely different logic — one largely automatic with a one-day SLA, the other a multi-party evidence workflow that can legitimately take months.
A failed transaction is the bank's operational failure — liability and compensation are automatic. A disputed transaction's liability depends on the dispute outcome — it isn't automatic, and a test plan that treats the two the same will incorrectly apply automatic compensation logic to a dispute that hasn't actually been resolved yet.
Dormancy and Reactivation: The State Transition That's Easy to Skip
CASA dormancy reactivation looks simple — a dormant account is reactivated, transactions resume. What gets skipped in UAT is the in-between state: an account that's dormant but mid-reactivation should not yet permit the full range of transactions a fully active account would, and the system needs a test case for what happens if a transaction is attempted during that transitional window, not just before and after it.
Cards: A Chargeback Isn't a Single Event, It's a Sequence
Card dispute test cases often verify only the end state — chargeback approved, amount credited. The sequence that actually matters operationally runs through distinct stages: dispute raised, issuing bank review, evidence collection from the merchant/acquirer side, and final resolution — each with its own timing and its own failure mode if a stage is skipped or its evidence window mishandled. A test plan needs a scenario for a dispute that is rejected after the evidence stage, not just one that resolves in the customer's favour, since the rejection path has its own notification and escalation requirements that are easy to leave untested.
Credit card disputes are generally easier to manage operationally because the disputed amount hasn't actually left the customer's account yet. Debit card disputes involve real funds already debited — your test plan should treat these as genuinely different risk profiles, not the same workflow with a different card type label.