Before we dig into the fact of how to test payment gateway integration effectively, it’s important to understand the payment options available and provided by third-party gateways like Payu, ccavenue, telr, stripe etc.
Majorly all payment gateways help applications collect payments via two payment options, one is Hosted Page and the other is Embedded Form.
In case of a hosted page, the end user is redirected from the application to the payment gateway page where he/she selects the payment options and the card details. We need not design the payment page nor the validations. It provides a greater security as all card details and control is with the payment gateway page. PCI DSS compliance, in this case, is not required for integration
In case of an embedded form, the end user remains on the application and complete the transaction without redirecting away. The only essence in case of an embedded form is no redirection to the payment gateway is done. One needs to design there own payment page and provide validation check at the application end only.PCI DSS compliance required for integration as all card details are saved at the application end.
|Embedded Payment form-Example Amazon
|Hosted payment page- Example Bigbasket
Testing the integration
So what is the approach or strategy to test a payment gateway. Basically, as a fresher into the testing world, the simplest approach we think of while testing the integration between the payment gateway and the application under test is the mere redirection of the application to the gateway, which in a sense is the most humanly of the test we can think of. But as a QA we need to test the integration more thoroughly and exhaustively.
So first let’s understand how does the payment gateway work?[This could be a deeper topic in itself, but I am putting it down as of now, in the easiest and narrow down explanation as of now] A request from the application is sent to the payment gateway to process the payment. Post verification of the payment, the gateway sends a response to the application which is either manipulated in terms of success or failure. So our key area in integration testing should be to evaluate all responses from the payment gateway are manipulated correctly at the application end.
How to Evaluate responses at the payment gateway end
All API documentation across payment gateway carries all the vital information required to test the integration. So it’s important not just from the development end but also from the QA end to study the API documentation thoroughly. All API documentation enlist there response codes and how to perform testing across them with each test card.
|Test Cards for testing
|Response codes to be tested across cards
The example highlighted above is a payment gateway, showing the different available test cards and the response codes to be tested across. To evaluate the response received at the payment gateway across the test cards, you can verify by logging into the payment gateway and check the response across the payments made for the above-listed cards. For example, you tested across the card with response code detailing out as insufficient funds available or expired card code, the same response would be visible on the dashboard of the payment gateway. Now you need to test across that the same response is manipulated at your application end appropriately. Since the examples highlighted shows failure in terms of payment either due to insufficient funds or expired card code, hence the payment should fail for the end user also. Some applications also display the specific error to the end user while highlighting the failure of payment, for example, “Payment failed due to insufficient funds”
Different payment gateways have multiple and different response codes.Hence its important to test the application integration across these response codes.For example, I came across a use case where a disputed transaction was put on hold at the payment gateway and confirmed at the application end.A scenario where no clarity in terms of transaction status is been provided by the payment gateway, its best to fail the transaction or create a worker at the application end to check at intervals the final status across that transaction from the gateway end.
3D secure payments
Apart from testing the integration from the response code perspective, it’s important to validate the support of 3d secure payments. 3D secure payments allows authentication of cardholders by there issuing bank at participating merchants.It helps to reduce the likelihood of fraudulent activities. All master and visa card support 3d secure payments and therefore majorly gateways support this automatically without the need of extra implementation. But few payment gateways require 3D secure payments to be implemented separately(example stripe, telr), therefore its required to test it specifically. As a thumb rule, 3D secured enabled cards should be tested across payment gateway to ensure 3D secure payments work.
|Cards to test across 3D secure payments with differents condition sets
Validation, UI and Security checks for Embedded payment form
As mentioned above, for embedded payment option, the UI and validations are implemented on the application end, hence its required to test those too. Validations like card number, cvv and validity checks need to be tested. Same goes out to the UI. Since embedded forms capture card details at the application end, hence we need to test the security of the application and verify the card details stored are secure or not. Also, an important aspect is to test the embedded forms in multiple browsers and mobile devices to ensure proper functioning and UI.
There are other important criteria that should be tested apart from the above-mentioned ones. Highlighting few of the points on the same:
- Check the payment status on the application and gateway while user refreshes the page when processing a payment or user closes the browser session.
- Verify the payment processing on throttling network(2G,3G,4G, wifi).
- Verify the payment statuses while payment is processing and network connectivity goes off.
- Verify proper message handling when payment gateway stops responding.
- Email notifications post transactions or pending transactions are required for proper timely communication to the end user, for the transaction status. These notifications are triggered by both payment gateway and application end.
A thorough testing across the integration is the need of the hour from the functional and security perspective in order to provide a seamless experience to your end users. As we are advancing towards technology, the act towards fraudulent activities is increasing and since there are so much of available options in the market, there is no room of a flawed system. Hence a deep driven testing is required for testing the integration between your application and the payment gateway.
Ending with the below reference quote:
“If you don’t like testing your product, most likely your customers won’t like to test it either.” (Anonymous)
Author: Sadhvi Singh