Test case library · Payments
This flow covers paying at checkout through a payment gateway with a card and the bank's OTP page, a saved card, net banking, a wallet, EMI or a pay-later option, through to the result screen and the invoice. Most field failures happen between the app and the bank's page: a redirect that never returns, a back press, a late OTP SMS or an app killed while the user reads it. Each one can leave a customer charged for an order that shows unpaid.
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 OTP arrives by SMS while the bank page waits. The app then shows the order as Paid with the card's last four digits.
Why a real phone: OTP SMS delivery depends on the carrier network and a real SIM.
Expected: The card appears as saved with only its last four digits and network label. Paying with it asks for the CVV or the configured check, then the bank's step.
Expected: The app returns to its result screen on its own and shows the order as Paid. The receipt names the bank used.
Expected: The wallet balance drops by the order total and the order shows Paid. The receipt shows the wallet as the method.
Expected: Each tenure shows the monthly amount and the total payable before the user pays. The receipt shows EMI with the chosen tenure.
Expected: The order shows Paid with pay later as the method. The receipt shows the due date the provider gave.
Expected: The invoice opens and shows the order number, the amount with lakh grouping and the IST date and time. The payment method shows only the last four card digits.
Expected: The notification and SMS show the same amount and order number as the result screen. Tapping the notification opens that order.
Why a real phone: SMS and push delivery depend on carriers and OEM battery savers.
Expected: The bank page shows an error for each wrong OTP. The app then shows the payment as failed with a retry, and the order stays unpaid.
Expected: Each field shows an inline error, and Pay stays disabled or is refused until all fields are valid.
Expected: The app shows the decline reason in plain words and offers another payment method. The order stays unpaid.
Expected: The app shows the shortfall and offers to add money or choose another method. Nothing is deducted from the wallet.
Expected: The app shows the payment as cancelled with a retry option. The order stays unpaid and nothing is debited.
Expected: EMI is hidden or disabled with a reason in both cases, and no EMI plan can be selected.
Expected: Only one bank page opens and the card is charged once. The order shows a single payment attempt.
Expected: The order shows Paid once, with the first attempt listed as failed. The first method is not charged for this order.
Expected: The app shows ₹1,00,000 with lakh grouping, and the bank page shows the same value. No amount is rounded, multiplied by 100 or shown in another currency.
Expected: The screen shows Pending or Processing with advice not to pay again. The order then moves to Paid, or to Failed with a refund note, without a second charge.
Expected: The app says the session expired and starts a fresh payment attempt or returns to checkout. Nothing is charged on the expired session.
Expected: The order shows Paid, or Pending that turns to Paid, and the app does not ask for payment again.
Expected: The app reopens on the order with its current payment status, not an empty cart or a blank page. It never shows the order as unpaid after the bank has taken the money.
Why a real phone: Low-RAM phones and OEM memory managers kill apps left behind the messages app.
Expected: The app asks before leaving the bank page, then shows Cancelled or a status check. If the payment went through on the bank side, the order still ends up Paid.
Expected: The app shows Checking or Pending instead of Failed, and settles on the right status once online. It does not ask the user to pay again.
Why a real phone: Real dead zones lose packets slowly; an emulator's network cut is instant and clean.
Expected: The bank page loads on mobile data, or the app shows a clear error with a way to check the status. There is no blank web view or endless spinner.
Why a real phone: Needs a real SIM on Jio, Airtel or Vi to hand over from Wi-Fi.
Expected: The OTP page is still open and submitting the OTP completes the payment. The app does not restart the payment or lose the bank page.
Why a real phone: Needs a real incoming SIM call over the bank's web page.
Expected: The app shows the payment as failed or timed out with a retry, and the order stays unpaid.
Expected: The allowed prompt fills the OTP field. When the prompt is declined, typing the OTP by hand still works.
Why a real phone: OTP auto-read depends on real SMS delivery and the phone's SMS handling.
Expected: The OTP arrives on SIM 2 and can be entered or auto-filled on the bank page before it times out.
Why a real phone: Needs two physical SIMs receiving SMS on a real dual-SIM phone.
Expected: The payment app shows the result on return, whether the bank app sends the user back or the user switches back by hand. The order is not left on a spinner.
Why a real phone: Needs a real bank app installed and a switch between apps.
Expected: The page scrolls so the OTP field and the Submit button stay visible above the keyboard.
Expected: The bank pages load and submit, or the app asks the user to update the web view component. No blank page appears.
Expected: The phone returns to the payment app with the result. If the browser stays open, the app shows the correct status when reopened.
Why a real phone: OEM default browsers on Xiaomi, Vivo and Oppo handle return links differently.
Expected: The thumbnail does not show the card details, and screenshots of the card form are blocked or blank.
Why a real phone: Recent apps thumbnails and screenshot gestures vary across OEM Android skins.
Expected: Only the last four digits and the card network label are shown, never the full number. The CVV or the configured check is asked before the bank step.
Expected: The card is gone on both phones and is not offered at checkout.
Expected: The card number field is empty or shows only the last four digits, and the CVV is never prefilled. The card does not appear in saved cards.
Expected: Each option and field is announced with its label, and the error is read out. The result is announced as paid, pending or failed.
Expected: Option names, EMI terms and statuses such as Pending appear in Hindi with no English leftovers. Amounts keep lakh grouping, such as ₹1,00,000.
Expected: Labels, fields and the Pay button stay visible without cut-off text, and the bank page can be scrolled to its Submit button.
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 10 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.
Note the order number, the payment attempt ID and the time, and look up that attempt in the payment provider's test dashboard. The app should move the order to Paid once the provider confirms, or show that a refund is on its way, without asking the customer to pay again. Repeat the case with the app killed and with the network dropped after the OTP, since those are the usual causes.
Most of it can. Card form validation, net banking redirects with test banks, EMI screens, retries and double taps behave the same on an emulator against the provider's test environment. OTP SMS delivery and auto-read, dual-SIM phones, apps killed on low-RAM phones, OEM default browsers and real network drops need real devices.
The bank may still be processing when the user leaves the page, and leaving can lose the result the app is waiting for. A well-built app asks before leaving the bank page, then checks the payment status with its server instead of assuming a failure. Test back presses and swipes at each step of the redirect to confirm the order still ends in the correct state.
39 cases · 14 need a real phone
40 cases · 13 need a real phone
38 cases · 16 need a real phone
39 cases · 12 need a real phone
40 cases · 12 need a real phone
38 cases · 16 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.