The Mystery Behind Testing ''The Integration of Payment Gateways''

Payment gateways are one of today's most important integrations that are done in the ever trending online market space. Any online market space that requires a transaction needs a payment gateway, be it Amazon, Flipkart, Uber, Airbnb, MakeMyTrip, Big Basket, etc.

Integration testing remains a mystery for an application with a payment gateway. I say so because most of us usually do not unveil the actual testing efforts required to test the gateway integration. We have a tendency to ensure payments happen with a valid card, and it does not happen with an invalid card. But trust me, it's much more than that.

Before we dig into how to test payment gateway integrations effectively, it's important to understand the payment options available provided by third-party gateways.

Payment Options

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 don't need to design the payment page or the validations. It provides greater security, as all card details and control are 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 completes the transaction without redirecting away. The only essence in case of an embedded form is no redirection to the payment gateway is done. You need to design your own payment page and provide a validation check at the application end only. PCI DSS compliance is required for integration, as all card details are saved at the application end.

Embedded payment form — Amazon

Hosted payment page — Bigbasket

Testing the Integration

So, what is the approach or strategy to test a payment gateway? As a newbie in the testing world, the simplest approach for testing the integration between the payment gateway and the application test is the mere redirection of the application to the gateway. But as a QA, we need to test the integration more thoroughly.

So first, let's understand how the payment gateway works (this could be a more in-depth topic in and of itself, but I am explaining it in the easiest and most narrow way, as of now). A request from the application is sent to the payment gateway to process the payment. After 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 that are manipulated correctly at the application end.

How to Evaluate Responses at the Payment Gateway End

All API documentation across payment gateways carry 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 enlists 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. To evaluate the response received at the payment gateway across the test cards, you can verify by logging into the payment gateway and checking the response across the payments made for the above-listed cards. For example, if 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 that the same response is manipulated at your application end. Since the examples highlighted show failure in terms of payment, either due to insufficient funds or expired card code, the payment should fail for the end user too. 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, it's 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. If there's 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 allow authentication of cardholders by issuing their bank at participating merchants. It helps to reduce the likelihood of fraudulent activities. All Master and Visa cards support 3D secure payments, and therefore, gateways support this automatically without the need of extra implementation. But few payment gateways require 3D secure payments to be implemented separately. Therefore, it's required to test it specifically. As a rule of thumb, 3D secured-enabled cards should be tested across payment gateways 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 options, 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. The same goes for UI. Since embedded forms capture card details at the application end, we need to test the security of the application and verify whether 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 function and UI.

Miscellaneous Testing

There are other important criteria that should be tested apart from the above-mentioned ones:

• Check the payment status on the application and gateway while the user refreshes the page when processing a payment or when the 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 the payment gateway and the application end.

Thorough testing across the integration is needed from the functional and security perspectives in order to provide a seamless experience to your end users. As technology is advancing, the act of fraudulance is increasing, and since there are so many available options in the market, there is no room for a flawed system. Hence, deeply driven testing is required for testing the integration between your application and the payment gateway.

I'll end 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)