Test cases for UPI payment
Updated 2026-11-13 · 6 min read
Thirty cases for merchant UPI Intent and dynamic QR flows. Distinguishes app handoff from confirmed payment and identifies the limits of simulator evidence.
How to answer in an interview
Ask whether the merchant uses app Intent, QR, or another explicitly supported flow, and which devices are eligible. Describe a payment that completes while the customer never returns to the merchant. The key assertion is agreement between the provider-confirmed transaction and the merchant order, not whether an app opened.
Scope and test data
Assume a ₹499 INR test order, mobile Intent and desktop dynamic QR with a configured validity period. For the expiry fixtures, the provider accepts initiation strictly before expiry and refuses initiation at or after expiry; adapt this boundary to the selected provider contract. Use provider sandbox fixtures or an approved simulator; never scan a production QR or enter a real PIN for this suite. Razorpay’s current UPI documentation directs integrations toward Intent or QR and describes restrictions and exemptions for Collect. Confirm merchant eligibility instead of assuming a manual UPI-ID field exists. These cases exclude mandates, refunds to arbitrary recipients and UPI app enrolment. Device handoff and bank outcomes need separate authorised integration testing; a simulator cannot prove them.
The 30 cases below are a test design, not an execution report. Replace the example rules with approved requirements before recording pass or fail. Performance budgets and supported device versions must be agreed before execution.
Entry and app handoff
| ID | Category | Test case | Expected result |
|---|---|---|---|
| U01 | Functional | Choose UPI for the ₹499 order on an eligible mobile device | Merchant creates a linked attempt for ₹499 INR |
| U02 | Functional | Open the chosen supported UPI app through Intent | App receives the configured test payee, amount and transaction reference |
| U03 | Functional | Choose between two supported installed test apps | Selected app opens and attempt remains tied to the same order |
| U04 | Negative | Launch Intent when no compatible app is installed | Merchant shows a supported fallback instead of a success message |
| U05 | Negative | Cancel the app chooser | Order remains unpaid and user returns to a usable checkout |
| U06 | Negative | Return from the app without authorising | Merchant checks status and does not infer success from the return alone |
| U07 | Functional | Simulate approval and a verified successful provider result | Order becomes paid exactly once |
| U08 | UI | Compare merchant review with the app test confirmation screen | Amount and configured merchant identity agree before approval |
QR lifecycle
| ID | Category | Test case | Expected result |
|---|---|---|---|
| U09 | Functional | Display the dynamic QR for the test order | QR belongs to the active attempt and the page shows ₹499 and validity information |
| U10 | Functional | Scan a valid QR in an approved test environment | Payment references the intended order and test payee |
| U11 | Boundary | Scan immediately before configured QR expiry | Initiation is accepted; merchant still waits for verified payment success |
| U12 | Boundary | Scan at or after configured QR expiry | Expired request is not presented as a fresh valid payment; UI offers a new attempt |
| U13 | Functional | Refresh QR after expiry | New reference is tracked and old reference remains available for reconciliation |
| U14 | Negative | Scan a QR for another test order | Only the referenced order can become paid |
| U15 | UI | View QR at supported zoom and phone widths | Entire QR and surrounding quiet area remain visible without clipping |
| U16 | Security | Alter QR amount or recipient in a controlled test fixture | Mismatched payment cannot satisfy the merchant order |
Asynchronous outcomes and recovery
| ID | Category | Test case | Expected result |
|---|---|---|---|
| U17 | Negative | Simulate insufficient funds or provider-declared failure | Failure is shown without fulfilment and the attempt is retained for audit |
| U18 | Negative | Simulate pending status after returning from the app | Merchant shows pending and offers status recovery without claiming failure |
| U19 | Functional | Deliver success after a period of pending | Pending changes to paid once and duplicate submission is prevented |
| U20 | Negative | Drop network access after approval in the simulator | Merchant restores authoritative status after reconnection |
| U21 | Functional | Close and reopen checkout while payment is pending | Existing attempt is recovered rather than automatically starting another charge |
| U22 | Functional | Deliver duplicate successful notifications | One paid transition and one fulfilment action occur |
| U23 | Functional | Deliver an older pending notification after success | Paid state is retained |
| U24 | Negative | Simulate debit reported by customer but no provider confirmation | Order stays under reconciliation with a reference; no invented success or refund promise |
| U25 | Negative | Receive success for an older attempt after a retry also succeeds | Duplicate payment is flagged for the approved refund workflow; order is fulfilled once |
| U26 | Security | Send a fake app-return success parameter | Server ignores the unverified success claim |
Privacy, speed and platform coverage
| ID | Category | Test case | Expected result |
|---|---|---|---|
| U27 | Security | Inspect merchant forms, telemetry and support logs | No UPI PIN is requested or recorded in this external-app integration |
| U28 | UI | Use keyboard or screen reader to choose UPI and check pending status | Method label, status and recovery control are accessible |
| U29 | Performance | Measure attempt creation and status refresh at agreed peak load | Merchant operations meet their budgets; bank delay is measured separately |
| U30 | Compatibility | Repeat Intent and QR flows on each supported OS, browser and app combination | Supported flows complete; unsupported combinations show an explicit fallback |
Evidence and prioritisation
Prioritise U06, U16, U18, U22 and U25. Capture order/attempt references, selected app and status timestamps; do not collect PINs or unrelated account data. A common mistake is treating a screenshot of a debit as enough to fulfil an order. Ask how reconciliation finds late success and who owns a duplicate-payment refund. Use the gateway cases for signature validation and refund accounting.
Downloads
Quick answers
Should I always test entering a UPI ID?
Only if that flow is supported for the merchant and platform. This suite focuses on Intent and QR.
Can a sandbox prove a real bank transfer?
No. It can exercise merchant state handling; real device and provider certification testing is a separate activity.
Sources
Want a project you can show in interviews?
The portfolio project kit walks you through testing a deliberately buggy app with Selenium or Playwright and API tests, then explaining it. The app itself is free.