How to Run Functional and UI Testing for Payment Solutions

Why Is Functional Testing Essential?

Functional testing aims to verify that the real behavior of the implemented features matches the requirements and specifications described in the project documentation.

In other words, QA specialists check the functionality to make sure that a buyer can pay for a product or service, and a provider can receive this money in full amount. That’s the basic requirement of the correctly functioning payment gateways.

It is also necessary to verify that the payment form accepts only active cards, completes the transaction only if the costs are sufficient, etc. Without clarifying these and related things, there is no sense in enabling a purchasing feature on a website. In payment systems testing, when a QA team is to check a payment solution as a full-fledged piece of software, not just an integrated part, the scope of tasks increases.

Each type of payment solution will require a different approach. A common thing is a need for flawless functionality. Without the features functioning correctly, a payment solution as such is of no use. If the core features work, but there are severe defects, it will result in inconveniences for clients.

The range of consequences can also differ – from a minor decrease in customer satisfaction to considerable financial implications. Put it another way, there is a direct correlation between the quality of a payment system and the business performance of the provider and/or service using it.

Exploratory and Functional Testing for the Payment System

Payment Domain Testing Terminology and Arrangements

The term ‘payment systems testing’ can refer to testing a niche product or payment as a part of some other service. The thing is, testing of a payment solution can take place on either side. To be more specific, a provider of a payment solution (PayPal, a payment aggregator, etc.) should ensure that the functionality they offer works and can integrate with other platforms. Meanwhile, we need to examine this integration when testing a particular e-commerce platform or another website.

The software testing process starts with planning and preparation. The team needs to create a Test Strategy, write test cases or checklists (if it is not exploratory or ad hoc testing), and set up the tech stack.

As a rule, a software testing company chooses specialists with relevant background and domain expertise to work with payment solutions. Thus, the team will be familiar with the terminology and the required setup. We’ll list the core terms and needs below for those learning the basics or needing to refresh their memory.

Basic payment domain terminology

• Merchant – an account that allows businesses to accept and process payments via credit and debit cards.
• Issuing bank – a financial institution that grants credit and debit cards and makes good on charges made by a cardholder.
• Acquiring bank – a financial institution that accepts transactions from cardholders.
• Transaction – the completed process of buying and selling something from an e-commerce platform, service provider, etc.
• Authorization – a transaction that determines whether a cardholder has sufficient funds to complete the purchase.
• Capture – a process of securing the payment after it has been authorized. The money doesn’t leave a user’s account instantly but is reserved to complete the transaction so that it isn’t spent elsewhere.

Types of payment software

• Payment processor – a service that communicates transaction data between a merchant, an issuing bank, and a receiving bank (e.g. POS terminal).
• Payment gateway – a tool that transmits payments between banks (e.g. different forms of online payments). A hosted payment gateway redirects a user to another website for payment. A shared payment gateway is a part of the main website.
• Full payment platform – an end-to-end platform that offers multiple integrations with different gateways and processors in one place.

Required data and tech stack

• Product data – information about a payment system, including specifications, requirements, parameters that pass through a payment system, etc.
• Sandbox – a dedicated testing environment that copies the main elements of the live environment. It lets a QA team work with the initial versions of the product or its features that haven’t been tested without impacting current functionality and processes.
• Test data – inputs selected or created specifically for use during the software testing process. In payment domain testing, it encompasses dummy card and payment wallet information.
• Performance parameters – the expected response time, wait time, average load time, error rate, CPU and memory utilization, etc. These data are necessary for performance testing, although the team can notice the presence of performance issues carrying out other tests.
• Error codes – codes designating errors that can occur during usage of a payment system. They help to determine whether a reason for a failure is related to a payment functionality or happens due to some other reasons.

Functional Test Cases in Payment Domain Testing

The next question is ‘What exactly to check?’ We’ve explained how to write test cases in detail in our previous blog post. You can look up the structure and tips there. For now, we’ll list some of the main cases QA specialists apply during payment systems testing.

1. Each of the offered payment methods is available.
2. The flow for each method works correctly. Users can complete transactions.
3. The options for all currency and language variations, if any, work correctly.
4. A system captures the entered payment details correctly.
5. A system proceeds with payment only after a user enters data in all mandatory fields.
6. A user can complete a transaction only if all the parameters (card number, expiry date, and CVV number) are correct. It is necessary to test different combinations of invalid details.
7. An attempted transaction using a blocked card or a card with insufficient funds is rejected.
8. The system calculates and discharges the fees correctly (for example, if service charges are added before the payment).
9. A system requires contact details (email and/or phone number) to send a payment confirmation.
10. A user and a merchant get notifications about the completed transaction via an email.
11. The time between checkout and displaying a confirmation page is appropriate.
12. It is not possible to submit payment information after a session timeout.
13. If a transaction is unsuccessful, incomplete, etc., a system shows a correct error message.
14. If a transaction fails, a user can return to the previous page and easily navigate through the website.
15. Check the behavior of a payment in progress after disconnecting and reconnecting to the web.
16. Make sure that a double payment doesn’t happen at any stage of the checkout process.

The Importance of UI Testing in Payment Domain

The audience expected to use payment systems is vast. Therefore, it is essential to work on empathic design – human-centered and based on the deep understanding of the realities of the future users. It is one of the reasons why payment functionality on the majority of websites looks similar.

Creating such a design is a task for a different team. QA engineers are the ones to check the result and verify that graphical elements look and work as planned. Below, you can see some of the essential things to check during UI testing services:

1. The page outline is visually consistent and without broken elements.
2. All payment options are listed, visually comprehensible, and clickable.
3. Input fields allow entering data in a defined format (e.g. numbers only for card details).
4. All buttons are clickable and perform the intended actions.

How to Test the Graphical User Interface: a Comprehensive Guide

To Sum Up

Functional testing in the payment domain is essential. Without a careful inspection of such a complicated solution, a company is likely to end up with a product that sabotages their business performance and affects brand image. Functional testing always goes hand in hand with UI testing.

In this article, we explained the importance of these testing types and the peculiarities of the QA process in general. Many aspects of testing will differ depending on the type of payment software and its features.