Test Case For Payment Gateway

Payment Gateway Test Cases: Payment gateway testing is quite common for testers who work in the startup 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
Join Here:	Software Testingo Telegram Group

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 payment gateway options screenshot. 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 payment 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 is 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 both local and international banks for 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 for a particular website using the respective payment gateway.

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 is going on through the payment gateway, how much is taken out as a modified amount, and whether you are required to 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 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, Travelling, Recharging, etc. Most of them use Credit or Debit cards, Internet Banking, Crypto Currency, Online wallets, payment gateways, etc., for payment online. 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 detail and then proceed to payment; it should not be successful. Proceed to payment.
• Check the validation alert is properly displaying when invalid details.
• Check with valid details, then click on Payment.
• Check the Validation alert is properly displaying when invalid details.
• 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 received by Merchant / Admin.
• Check the cancel button if the customer doesn’t want to proceed with payment.
• Check Refund Button availability.
• Check one-time password is received by the user’s Registered Contact No.
• 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 should not be allowed to proceed to payment.
• Check Valid CVV no., then submit.
• Check Invalid CVV no, then submit.
• If the internet is slow, money should not be debited from your account.
• Check-in case the browser is closed; money should not be debited from your account.
• Check in the case of mobile hangs; 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 the amount should be valid before payment.
• Check the payment return policy should be predefined.
• Check the status of payment After the Customer Login.
• Check the Thank you page or successful msg after Payment is made successfully.
• Check the GUI of the Thank you page or successful message.

Payment Functionality Test Cases

• Check that anyone or all types of Payment facilities should be available like Payment by Credit Card, Debit Card, Internet Banking, Paypal, Paytm, Stripe, Payment by ATM to ATM fund transfer, Cash On Delivery, By Cheque, Demand Draft, Cash, etc.
• Check that Payment should be stopped or timeout if it takes more time.
• Check that Amount should be valid before Payment.
• Check that all valid security measures should be 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 Invoice should be correctly mentioned in all the details and that the Paid amount should be the same.
• Check that pre Payment or post Payment information should be clear for any particular product or service.
• Check that Payment details such as products or services 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 Payment cancellation.
• Check that the Payment return policy should be predefined.
• If no service or product is selected, it should not lead to 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, 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 time in days or queries functional 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 invoice generated on the purchase of a plan is accessible to the user or not. Sent in email or shown on 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 can 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 plan remaining queries are shown on the user profile or not.
• 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.
• Check on click on the renew link should redirect to the plan and pricing page.
• Check 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 user can downgrade its plan or not after the plan expires and the user renews its plan.
• Check test case user can upgrade or purchase plan during the purchased plan is active and the user allowed queries end.
• Check the case if the user can purchase a new plan, it will add queries in the already purchased plan or not as per requirement.
• Check plan expiry date increased or not if the days and queries are remaining and the user upgrades its plan.
• Check whether auto-renewal is working or not.
• Check auto-renewal mentioned clearly on the pricing page.
• Check user can cancel its plan at any time.
• Check user can purchase the plan successfully after the user cancels its plan.
• Check if the user cancels its plan, don’t access the user pro feature until its 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 the validation for the automatic options 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 for sandbox usage and with manual testing, this will take a lot of time. 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.