Test case library · Payments
This flow covers paying by scanning a UPI QR code with the in-app scanner or from a gallery image, from the camera preview to the payee name check and the final status. In the field, scanning fails on creased stickers at shop counters, dim stalls, glare off another phone's screen and budget cameras that cannot focus up close, and fraud succeeds when the payee name is not clear before the PIN.
From the reviews. 42 of the 317 malfunction reviews in our India App Quality Report describe a failed, stuck or double-debited payment. 34 of them are on apps other than UPI and banking apps, where paying is one step inside a booking, order, premium, top-up or repayment; 11 on travel apps alone.
Expected: The success screen shows ₹10, the merchant's name and a UPI transaction ID. History lists it as a QR payment with the IST time.
Why a real phone: Needs a real camera focusing on a printed code.
Expected: The amount field is read-only and ₹249 is debited. The billing screen marks the order as paid with the same reference.
Why a real phone: Needs a real camera reading a code from a live billing screen.
Expected: The field accepts the new amount and ₹150 is debited. The receipt shows ₹150, not the prefilled ₹100.
Expected: The QR is read from the image and the same payee appears as when scanning it with the camera. The payment completes.
Expected: The bank-verified payee name and UPI ID appear before any amount is entered. The PIN screen repeats the payee name and amount.
Expected: The chosen UPI app opens on its payment screen with the payee and amount from the QR, and the verified name shows before the PIN.
Why a real phone: Depends on the OEM camera app's QR handling and the installed UPI apps.
Expected: The receipt shows the merchant name, the order reference from the QR, the amount and the UPI transaction ID. The shared copy masks the account number.
Expected: The amount cannot be changed by any method and shows ₹249 on every scan. Only ₹249 can be paid.
Expected: The app says each one is not a UPI payment QR and offers to scan again. A web link is not opened without showing the address and asking first.
Expected: The app says the QR has expired before the PIN screen, or the payment fails with an expiry reason and no debit.
Expected: Each one shows an invalid QR message and Pay stays disabled. The app does not crash or show an empty payee screen.
Expected: The limit message appears before the PIN screen and no money moves. The amount is shown in full with lakh grouping.
Expected: Zero, three decimal places and letters are rejected inline. 100000 displays as ₹1,00,000.
Expected: Each screen shows the encoded amount exactly, for example ₹10.50 and ₹1,00,000, with no rounding or shifted decimal point.
Expected: Each one scans, or the scanner shows a hint such as move closer or tilt the phone, with the gallery option still offered. Each scan opens the payee printed on that test QR.
Why a real phone: Creases, faded ink and light reflections need a real camera and real prints.
Expected: The QR scans at normal brightness. At low brightness or with glare the app shows a hint instead of freezing, and the payee matches the QR shown.
Why a real phone: Screen glare, refresh flicker and brightness only show up on real cameras and displays.
Expected: The torch button is visible, the QR scans with the torch on, and the torch turns off when the scanner closes.
Why a real phone: Low-light focus and the flash torch depend on the phone's camera hardware.
Expected: The app opens one payee and shows its verified name before any amount or PIN, so the user can go back if it is the wrong one. It never mixes details from both.
Why a real phone: Needs a real camera frame holding two printed codes at once.
Expected: The app says the QR is already paid or expired, or shows the recent payment to this payee before the PIN screen.
Expected: Both images are read, or the app says no QR was found and offers the camera instead. Large images do not freeze the app.
Expected: Offline, the app says it needs internet to verify the payee and keeps the PIN screen closed. Once online, the user can continue or scan again without restarting the app.
Expected: A loading state shows while the payee is verified, and Pay never appears next to an empty name. The payment ends in Success, Pending or a clear failure.
Why a real phone: Needs a real SIM on weak Jio, Airtel or Vi coverage.
Expected: The app shows Pending or Checking, not Failed, and does not prompt a rescan to pay again. History shows the final status once the phone is back online.
Why a real phone: Needs real signal loss in a lift or basement on a carrier network.
Expected: The camera preview resumes or the scanner restarts, with no black or frozen frame. Nothing is paid without a fresh scan and PIN.
Why a real phone: A real SIM call pauses the app and its camera session.
Expected: The scanner shows a live preview again, or offers a tap to restart it. The app does not crash or show a black preview.
Why a real phone: Camera hand-off between apps depends on the phone's camera driver and OEM skin.
Expected: The app returns with the QR read, or reopens on the scanner with a message to pick again. It does not crash or show a blank screen.
Why a real phone: Low-RAM phones and OEM memory managers kill the app behind the gallery picker.
Expected: The live camera preview starts right after access is allowed, without restarting the app or leaving the scanner.
Why a real phone: Preview start after the permission grant depends on real camera hardware and drivers.
Expected: The scanner explains why the camera is needed, links to settings and still offers the gallery option. After access is allowed, the preview starts on return.
Expected: The QR scans at a normal holding distance, or the app shows a hint to move closer or farther. The scanner does not freeze.
Why a real phone: Fixed-focus and low-resolution budget cameras behave unlike emulated cameras.
Expected: The scanner uses a camera that can focus up close and reads the QR. It does not stay blurred on a lens that cannot focus at that distance.
Why a real phone: Lens selection and close focus vary across real multi-camera phones.
Expected: The allowed image can be picked and read. The app explains how to share more photos instead of showing an empty or broken gallery.
Expected: The app shows the verified name of the account that would receive the money, not the shop's name. Cancelling returns to the scanner with no debit.
Expected: Every screen shows the payment as money leaving the user's account, with the amount and payee. No screen suggests the user will receive money.
Expected: The camera indicator disappears as soon as the scanner closes, and the camera is not active while the app is in the background.
Why a real phone: The camera-in-use indicator and camera release need real hardware and OS.
Expected: The app asks for its lock before showing account details or the PIN screen.
Expected: The scanner announces its purpose, and the torch and gallery buttons have labels. The payee name and amount are read out before Pay.
Expected: Payee names display in their own script without boxes or broken characters. Labels and errors appear in Hindi.
Expected: The payee name, UPI ID, amount and Pay button stay visible without cut-off text. A long payee name wraps instead of hiding the amount.
They fit the Standard package: 10 × 45-minute sessions on 4 phones or browsers of your choice, up to ~50 cases, ₹18,999 + GST ($249), verified report in 3 business days. The 9 P1 cases alone fit Starter (₹9,999 + GST).
Download the CSV, pick the package at checkout and upload the file with your build. Testers run them on their own phones, on Jio, Airtel and Vi.
A static QR carries only the payee, so the user enters the amount and the same code is used again and again. A dynamic QR is made for one bill and usually carries the amount and an order reference, and it may expire. Test that dynamic amounts are locked when the merchant intends it, that expired codes are refused and that the merchant sees the same reference that was paid.
Partly. Validation, amount parsing, payee confirmation and copy checks can be run on an emulator by importing QR images from the gallery. Camera focus, low light, glare, damaged prints, lens selection and camera release after interruptions need real phones, including budget models with basic cameras.
The app can read the code without internet, but it needs a connection to verify the payee and send the payment. It should say so clearly, keep the PIN screen closed and let the user continue or scan again once the network returns. It must never show a payee as verified when the lookup did not run.
40 cases · 13 need a real phone
37 cases · 12 need a real phone
39 cases · 12 need a real phone
40 cases · 12 need a real phone
39 cases · 11 need a real phone
99tests runs your cases, AI-generated ones included, on the phones, laptops and browsers your users own. Every finding is verified, serious bugs come with a screen recording, and each case comes back pass, fail, blocked or not run.