A failed payment is never just a technical failure. It is the moment a customer loses confidence in your platform, abandons their purchase, and often does not return. Unlike most bugs, a payment failure has a direct and immediate cost. This guide gives you the test cases to prevent that.
Below you will find over 50 test cases organised by type and filterable by category, guidance on using AI to speed up your test suite, and a pre-launch checklist you can work through before every release. Take what is useful and adapt it to your stack.
Most functional testing is a conversation between your application and its own logic. Payment gateway testing adds a third party to that equation: the gateway itself, and behind it, the issuing bank and card network. Failures can originate at any of those layers, and they do not always come back with a clear error message.
Always test in sandbox. Every major gateway (Stripe, Razorpay, PayU, PayPal) provides a sandbox environment with test card numbers and simulated decline codes. Use those. Never run test transactions against a live account, and make sure no real card numbers appear anywhere in your test data or logs.
Error handling is at least half the work. A successful payment gives you one data point. A failed one can mean dozens of different things: insufficient funds, a blocked card, a network timeout, an incorrect CVV, an OTP expiry, or a gateway error. Your test suite needs to cover all of them, not just the happy path.
You are also dealing with redirects and webhooks in ways most application flows do not require. The user leaves your application, completes authentication on a third-party page, and returns. A lot can go wrong in that gap, and edge case testing is where you find it.
The test cases in this guide fall into four types. Understanding what each one is for makes it easier to know which cases belong in your daily regression suite versus a full pre-release run. If you are new to writing test cases, our guide on how to write test cases covers the fundamentals before diving in here.
Use the filters to focus on a specific category. Every test case includes a suggested priority: High cases belong in your P1 regression suite, Medium in a full pre-release run, and Low in periodic or exploratory testing. You can also use the test case template from our library to document these in your preferred format.
AI tools can meaningfully speed up the first draft of a test suite. They are not a replacement for domain knowledge: they get gateway-specific error codes wrong surprisingly often, and edge case coverage can be thin. But as a starting point they save real time, particularly when you need to cover a new payment method quickly or produce a first-pass regression list.
Here are three prompts that produce solid results.
Swap in your actual gateway and application type for noticeably better output.
This works equally well for adding net banking, wallet, or BNPL cases to an existing suite.
Useful when you have a large suite and need to build a fast, CI-friendly regression set.
One thing to watch for. AI-generated expected results for edge cases are often plausible but wrong, particularly around what happens when a gateway returns an error mid-redirect or how partial payments should be handled. Always review with someone who knows the implementation before these cases go into your suite.
Once you have your test cases, you need somewhere sensible to manage test cases at scale. A few things that make payment gateway testing easier in Katalon True Platform:
Not every test case needs to run with every deployment. A practical structure for most teams:
The goal is a P1 suite fast enough to run in CI and a P2 suite thorough enough to catch regressions before they reach users. Most teams find that P1 cases can be automated; P3 cases are often best kept as manual checks.
The test cases above apply broadly, but the risk profile shifts depending on what you are building. For ecommerce applications, the highest-risk scenarios tend to be cart abandonment after a declined card and duplicate order creation from double-clicks. For banking applications, the focus shifts to precise amount validation, transaction reversal handling, and regulatory compliance flows. BFSI teams can find additional context in our guide to BFSI testing.
If you are building or expanding your regression suite for payment flows, our regression testing starter kit provides a reusable structure you can adapt for gateway-specific coverage.