Payment Gateway Test Cases Excel Payment Page New 2025

What We Are Learn:

Payment Gateway Test Cases: Payment gateway testing is common for testers in startups or the service industry. I have decided to write this post for those who have asked for the test cases for the payment gateway in this post.

The current images of the payment gateway options shown below are from CCavenue’s payment gateway used on one of India’s leading phone recharge websites. The options offered in the payment gateway are Debit cards, Credit cards, net banking, ATM cards, and EzeCard(American Express).

Post On:	Payment Gateway Test Cases Excel
Post Type:	Test Case Template
Published On:	www.softwaretestingo.com
Applicable For:	Freshers & Experience

We will follow the modular approach to test the payment gateway options. So, for manual testing, let’s start with writing test cases for each payment option. First, let’s check out the screenshot of the payment gateway options. This screenshot you can use this to write down initial test cases.

As you can see, you’re presented with multiple options for payment. So, the test cases for this part of the payment gateway test cases are as follows.

Default Payment Gateway Test Cases

Check if each of the payment options is selectable.
Check if each listed payment option opens the respective option as per specification.
Check if the payment gateway defaults to the debit card option.
Check if the default option for debit cards shows the card selection drop-down menu.

Test Cases For Debit Card Payment Options

Check if the drop-down menu of the debit card selection page has a “select” option text enabled.
Check if the dropdown menu lists the following cards – Visa, MasterCard, American Express, etc.
Check if the respective card selection opens the expiry date, card number, and CVV options.
Check if the tab offers an option to save the card.
Check if the tab offers an option to name the saved card.

Credit Card Test Cases

Check if the card options allow card number, expiry date, and CVV value text fields.
Check if the card options tab allows text to be added to the text fields.
Check if the number added to the credit card number field detects the type of card (e.g., visa, etc.).
Check if the tab offers an option to name the saved card.

Netbanking Options Test Cases

Check if the tab offers existing banks to be selected using the radio button for net banking transactions.
Check if the tab offers options to select banks other than those listed with the radio button selection.
Check if the tab offers all the leading banks from the country for net banking transactions.
Check if the tab offers a net banking option for local and international transactions.
Check if the net banking option has at least eight banks for the transaction using the radio button selection inside the tab.
Check if selecting the radio button or the drop-down menu option takes us to net banking.

ATM Card Options Test Cases

Check if the ATM-only card is allowed to be used on this tab.
Check if at least six banks are used in the tab using the radio button selection.
Check if at least one of the drop-down buttons near the bank logo is selected by default.
Check if the banks selected allow transaction processing using ATM card details.

Cash Card Options Test Cases

Check if the cash card tab lists cash or oxygen as options.
Check if the default radio button is selected for the itzcash.
Check if the transactions using cash cards are allowed by the payment gateway.
Check if the transactions are possible with the cash cards under the respective shopping site.

AMEX Ezeclick Options Test Cases

Check if the EzeClick option lets you link to the external site from which you can perform the rest of the transaction.
Check if this option is enabled by default.
Check if this option allows a transaction using the respective payment gateway for a particular website.

How to Test Payment Gateway Functionality?

Test payment gateway functionality is the same as testing any other functionality. It would be best if you had some test strategy while testing it. The following are some points kept in mind during the testing of the payment gateway:

Gather appropriate test data for the dummy credit card numbers for various master cards.
Gather payment gateway information, like whether you used PayPal, guest pay, etc.
Gather payment gateway documents with error codes – useful if any error came during testing to identify whether it’s our application fault or payment gateway-related error.
Check if the gateway does what it is supposed to do. Does it handle order objects correctly? Does it perform additional calculations correctly?
Understanding the integration of the payment gateway with the application
Understand and test the parameters and sessions passed through the payment gateway and application
Understand and test the amount of related information passed through query strings, sessions, or variables.
Check the format of the amount with the currency format
Check the language of the application and payment gateway language
Try to change the payment gateway language during the payment process
Test after successful payment whether all the necessary data retrieved to our application or not
Check what happens if the payment gateway goes down during the payment process
Check what happens if the payment process went successful but do not return to our application
Check what happens if the session goes time out during the payment process
Check what happens in the backend during the payment process. Is the session data stored in a temporary table, or is any ID generated?
Check what happens if the payment process fails.
Check if any modification transaction goes through the payment gateway, how much is taken out as a modified amount, and whether you must pay more. For example, if the modified amount is greater than the paid amount, then only the application redirects to the payment gateway; otherwise, it should not.
Check DB entries for the transaction to see whether they store credit card details.
Check DB entries for the amount-related fields in the database for fresh, modified, and canceled transactions.
Check the error page during the payment gateway process
Check security passes for the transaction
Sometimes, the payment gateway sends confirmation through popup dialogs – so test popup blocker-related settings. What happens is the popup blocker is on and all this.
Check buffer pages between the application and payment gateway (firefox firebug add-on will be helpful to test)

Payment Gateway Test Case For Online Payment

Nowadays, most people go shopping, travel, recharge, etc. Most use credit or debit cards, internet banking, cryptocurrency, online wallets, payment gateways, etc., for online payment. Now, there is a need to test these facilities for payment, and any user can test their online payment functionality through Online Payment Test Scenarios. Testing of these facilities is essential now because where there is money, there is a risk, and due to the heavy transaction of online payment, the risk is much bigger than thought.

Check the payment button availability.
Check the payment button’s GUI (Spelling, Alignment, Color, Size).
Check the availability of all fields.
Check the navigation of payment.
Check the GUI of the payment page.
Check the GUI of the Validation alert.
Check which payment card is used, credit or debit.
Check without filling in details, then click on Payment.
Check by entering the invalid card details and then proceed to payment; it should not be successful. Proceed to payment.
Check that the validation alert is properly displayed when invalid details are entered.
Check with valid details, then click on Payment.
Check that the Validation alert is properly displayed when invalid details are entered.
Check the total amount on the payment button.
Check the status & details of payment on the payment dashboard, i.e., on stripe>>payments.
Check the Notification detail on the Email with the total amount received by the customer.
Check the Notification detail on the Email with the total amount the Merchant / Admin received.
Check the cancel button if the customer doesn’t want to proceed with payment.
Check Refund Button availability.
Check that the user’s Registered Contact No receives the one-time password.
Check Received otp on registered mobile, then submit.
After receiving the otp on the registered mobile, check the successful message, then submit.
Check invalid otp, then submit. It should not proceed for payment next step.
Check the availability of validation alert with invalid otp, then submit.
Check Resend otp availability.
Check the used otp; they should not be allowed to proceed to payment.
Check Valid CVV no., then submit.
Check Invalid CVV no, then submit.
Money should not be debited from your account if the internet is slow.
Check-in case the browser is closed; money should not be debited from your account.
Check the mobile hangs case; money should not be debited from your account.
Check-in case Money is debited from your account, but payment or recharge is not made successfully. The Total Money should be credited to your account.
Check the transaction amount.
Check the actual total Price debited from the customer’s account.
Check that the amount is valid before payment.
Check the payment return policy, which should be predefined.
Check the status of payment After the Customer Login.
Check the Thank you page or successful message after the payment is made successfully.
Check the GUI of the Thank you page or successful message.

Payment Functionality Test Cases

Check that any or all Payment facilities are available, like Payment by Credit Card, Debit Card, Internet Banking, Paypal, Paytm, Stripe, ATM to ATM fund transfer, Cash On Delivery, Cheque, Demand Draft, Cash, etc.
Check that Payment should be stopped or timeout if it takes more time.
Check that the Amount is valid before Payment.
Check that all valid security measures are matched correctly according to the Payment type before the Final Payment.
Check that Payment should be made if all valid processes are completed step by step according to the Payment type.
Check that after Payment, an Invoice should be generated.
Check that the invoice is correctly mentioned in all the details and that the paid amount is the same.
Ensure that any product or service’s pre- or post-payment information is clear.
Check that Payment details such as products or service names, their costs, total cost, discounts, Terms & Conditions, etc. Multiple products, services, or combinations should be clearly shown before and after Payment.
Check that any discrepancies in the order should lead to the cancellation of the payment.
Check that the Payment return policy should be predefined.
If no service or product is selected, it should not affect the Payment functionality.
Check that if any error or discrepancy arises while Payment processing (example: 90% done), then the total Payment should be canceled.
Check that in the case of By Part Payment, and Payment should be canceled after delivering some parts of the full payment according to the Terms and Conditions.
Check that Payment should be made by multiple users or single users to multiple providers or a single provider.
Check that the valid amount should not be paid by invalid mode, currency, cheque, etc.
Check that valid mode, currency, cheque, etc., should not be used to Pay the invalid amount.
Check that Payment should not be made for illegal products, services, or activities.
Check that Payment by force should not be made, and proper security measures should be followed to stop this activity.
Checking fake payments like invalid credit or debit cards, card cloning activity, username or password theft, hacking, snatching, forgery, false signature, etc., should not be done at any cost.

Test Cases For Mobile Recharge & Payment

Check the services and features mentioned on the pricing page.
Check to spell out whether the content on the pricing page is correct.
Check the trial period in days or queries function properly if provided.
Check that the trial expires. Service should not be accessible until the user purchases the plan.
Check user data should be saved as the user purchase plan after the completion of the trial period.
Do not allow the user to purchase a plan without email verification.
Check as the user purchases the plan; the user plan status should be updated to paid without forcing the user to log out and then in.
Check whether the user can buy the plan successfully after email verification.
Check if the invoice generated on the purchase of a plan is accessible to the user. Sent in email or shown on the Dashboard.
Check whether users can download an invoice or not.
Check whether an invoice is sent to the user’s registered email on the purchasing plan.
Check the user login with social links to purchase the plan.
Check the plan assigned to the user is the same one selected by the user.
Verifies plan queries or offered services shown on the user profile.
Verifies whether or not the remaining plan queries are shown on the user profile.
Check whether or not the expiry date for the purchased plan is shown on the profile.
Check whether the plan expiration notification should be on the dashboard/profile. Email may also be sent to the user.
Check whether the renewal plan link is added to the Dashboard or not.
Click on the renew link, which should redirect to the plan and pricing page.
Check that the user cannot enjoy services once the plan expires and the user does not renew the plan.
Check whether users can downgrade their plan or not during the plan activation.
Check whether the user can downgrade their plan after the plan expires, and the user renews it.
Check the test case; the user can upgrade or purchase a plan when the purchased plan is active, and the user-allowed queries end.
If the user can purchase a new plan, it will add queries in the already purchased plan or not as per requirement.
The check plan expiration date increases if the days and queries remain and the user upgrades the plan.
Check whether auto-renewal is working or not.
Check auto-renewal mentioned clearly on the pricing page.
Check that the user can cancel their plan at any time.
Check that the user can purchase the plan successfully after the user cancels the plan.
Check if the user cancels the plan; don’t access the user pro feature until the plan expires.
Check if the user can not access the dashboard if the plan expires.

Conclusion:

These are some of the test cases that should be included in your test design. You can add validation for the text fields. You can also go for validation for the automatic option detection.

I can add even more to the above options, like checking each bank option and seeing if the gateway transfers the user to the respective website. Again, this will take a lot of time for sandbox usage and manual testing. But these are pretty much simple enough test cases for the payment gateway.

Please let me know if you have any other suggestions or feedback. I’d appreciate your comments on the test cases.

Test Case For Payment Gateway