Payment Gateway Testing: The Tester’s Hands-on Guide with Checklist

The Tester’s Guide to Payment Gateway Testing:

What are the payment processors?

As per Wikipedia, “A payment processor is a company (often a third party) appointed by a merchant to handle transactions from various channels such as credit cards and debit cards for merchant acquiring banks. The payment processor will both check the details received by forwarding them to the respective card’s issuing bank or card association for verification, and also carry out a series of anti-fraud measures against the transaction.”

Some common Payment Gateways are Braintree, Authorize.net, PayPal, Bluepay, Citrus Payments etc. 

There is a lot of literature available online and offline about payment gateways and related terminology.

 Payment Gateway testing guide

In this tutorial, I have tried to simplify some of that information and tried to add my experiences.

Recommended read => Testing Investment Banking Applications

During my first project, I was clueless about how to properly test a payment gateway. I learned gradually and worked on successfully rolling out PayPal, Braintree and Authorize.net integrations with our eCommerce applications.

We will discuss common terminology, understand end to end transaction flow and useful tips and best practices.

Payment Gateway Terminology

Let us discuss some terms that we will be using in this article:

payment-gateway-process 1

1) Merchant – A merchant is a person or company that sells products or services. Flipkart, Amazon, eBay are some examples of Merchants.

2) Credit Card – A plastic card that can be used to buy products or services through a credit account. It has a 16 digit card number, an expiration date, hologram, magnetic strip, signature panel and a Card verification value (CVV) number.

Front of Credit Card:

Front of Credit Card

Back of credit card:

Back of credit card

(Source: about.com)

3) Acquiring bank – Acquiring Bank is a financial institution that maintains the merchant’s bank account and enables a merchant to accept and process debit and/or credit card transactions on their store.

4) Issuing Bank – Issuing Bank is the financial institution that issues the customer’s debit or credit card. Whenever a customer uses a credit or debit card to make a purchase, the Issuing bank either approves or declines the transaction based on the cardholder account standing and passes that information to the Acquiring Bank.

For example, the transaction will be rejected if the card’s expiry date is incorrect, or if the purchase amount is more than the card credit limit, etc.

5) Transaction – The end to end process through which the merchant receives funds for a transaction with a customer.

6) Authorization – Authorization is requested when a customer makes a purchase. This authorization is provided by the customer’s issuing bank and confirms the card holder’s validity, the ability to pay, and the presence of sufficient funds etc. Once this is completed, funds are hold and the balance is deducted from the customer’s credit limit but is not yet transferred to the merchant account.

7) Capture – In this action, the merchant collects the relevant customer payment information and sends a settlement/capture request to the processor. The processor uses this information to initiate funds transfer between the customer’s card account and the merchant bank account.

Also read => Banking Application Testing

Difference between payment gateway and payment processors

There is a lot of literature available online about it and whether payment gateway and payment processor are distinct modules with distinct functionalities.

During the course of my projects, I have observed that Payment Processor and Payment gateways are used interchangeably without any actual distinction. The merchants usually refer the ‘Payment Gateways’ as payment processors as these process all the payments.

The ‘Payment Processors’ consider themselves as Payment Gateways as they act as a means to process and complete the secure payment transaction.

Transaction Flow

The following flow diagram summarizes the complete flow from the moment a customer places an order to the order being successful or declined.

Transaction Flow

If a customer wishes to cancel the order, the following is the flow:

cancel the order

The difference between a void and return depends on whether a transaction is captured or not.

An unsettled payment can be voided, that means the held funds are credited back to the card holders account. If a transaction is already settled or captured, then a refund is initiated which means the funds are taken from the merchant account and credited back to the card holder’s account.

Why do we need to test Payment Gateways?

If we were to shop in an actual brick and mortar store, we would pay cash or swipe our card (credit or debit) through the machine during checkout to complete the transaction.

If using credit or debit cards, the POS (Point of Sale testing) machine will indicate if the payment processing would be approved or declined.

Similarly, during online transactions, we need to have a comparable system in place, which approves or disapproves a transaction instantly.

From a customer perspective, the online payment processing on the e-Commerce website should be seamless. Customer clicks ‘Pay now’ button and should see payment successful or declined message in next few seconds.

From the e-Commerce store perspective, the merchant needs to ensure that the complete payment cycle (getting transactions from online store, capture and authorize, refund, voiding) are working fine.  If any of these subcomponents do not work as expected, then it can be a problem for the merchant.

From the merchant perspective, the testing phase allows them to get used to the chosen payment processor flow and evaluate if the chosen option is actually the best fit for their application and business.

Kinds of Testing required

Depending on the choice of the Payment processor and the product /application requirement, you may be required to perform the following kinds of testing

  • Functional Testing – Functional testing is required for newer, less established payment gateways to ensure that the application behaves as it should i.e. it handles orders, calculations, taxes, etc. exactly how it is supposed to. For more established payment processors, this kind of testing may not be required.
  • Integration Testing – Integration testing is critical while integrating with a payment gateway. As a tester, you would need to verify that the integration of your website/online store/application is working fine with the chosen payment gateways. As a tester you need to verify the entire transaction flow:
    • Place order
    • Check if funds are received in merchant account
    • Verify if transaction can be refunded or void successfully
  • Performance Testing – It is essential to test the website/online store/application for performance. The payment processor should not fail if multiple users are trying to complete transactions at the same time.
  • Security Testing – During a transaction, a customer will be providing sensitive information like their credit card number, CVV number etc. It is very important to ensure that all the sensitive information is transmitted after encryption and that the channel is secure.

Helpful Tips

Based on my personal experience, the following are some helpful tips for testers:

#1) Research if a free sandbox environment (for trial and exploratory purposes) is available for the Payment gateway that needs to be tested or implemented. Having a sandbox available is definitely helpful and gives the team that extra flexibility to customize the tool and test as in depth as required.

#2) Make sure the transaction is tested end to end. In our projects, we tested and reported numerous bugs related to data capture and data flow from application to the Payment gateway. Some of the specific bugs were:

------------

  • Customer (buyer) name information was not getting captured correctly
  • The customer Credit card expiry date was getting captured incorrectly due to an incorrect function which was causing the transactions to be declined by the issuing bank on account of incorrect credit card information.
  • Duplicate transaction showing in Payment Processor

#3) Research the limitations of the payment gateway sandboxes.

For example, Authorize.net sandbox supports one currency per sandbox, so if you need to test multiple currencies, you will need to configure different sandboxes. Also with that, you would never be able to ‘truly’ test how the system will behave when the Live Authorize.net account will process Multi-currency transactions.

#4) If payment fails during a transaction for any reason, a suitable message should be shown to the customer. Any error message that is too technical like ‘Object not set to instance’ or ‘404 error’ can confuse the customer and impact user experience.

It is also a good idea to display a generic message like ‘There seems to be some issue in processing the transaction, please contact us at 1-800-800-8000’.

#5) For the purpose of post production release verification, the client (application business owner) would need to create a live payment processor account, set up their Merchant ID etc.

Depending on the payment processor chosen, it may take anywhere from 2 days to few weeks to set up the account. This should be communicated by the project manager to the client in advance with sufficient time to set up the live account before the application and payment processor integration are go live.

Payment Gateway Testing Checklist and Test Cases

Like any other application, testing payment processors involves proper test planning.

The following checklist can be helpful for testers and could be used as a reference:

1) Set up payment processor sandbox.

2) Gather test credit card numbers that would be used for testing different credit cards. As an example, such information for Braintree payment processor can be found at Braintree payments.

3) Verify the behavior of the application when a transaction is successful.

4) After successful transaction verify if the payment gateway returns to your application to show some kind of successful transaction/confirmation message.

5) Verify that the customer gets some kind of transaction confirmation notification like Order confirmation email, etc. if the transaction is successful.

6) Check what happens if a payment fails or payment processor stops responding- is there any error message?

7) Verify the application behavior with browser popup blocker on and off. This may be helpful if any confirmation messages are being displayed in the popup.

8) Verify different fraud prevention/security settings.

For example, if customer billing information does not match with the address provided to issuing bank- any mismatch will result in transaction decline.

9) Verify the transaction entries in the database if the tester has access to the Application database.

10) Check what happens when a customer session expires.

11) Check the console during entire transaction and report any console errors that are observed.

12) Verify that that transaction is done on a secure channel.

For example, the checkout pages may be HTTPS versus rest of website that are HTTP pages.

13) Verify that the payment processor currency is setup correctly.

For example, if the application/website is a Canadian company/retailer, the payment processor should be set up to accept CAD currency.

14) If the applications have multiple payment options like Credit card and PayPal together, both payment options need to individually tested from end to end.

15) Verify that refund or void amount (from payment processor admin portal) is same as the transaction amount. In no case, the refund/void amount should exceed the transaction amount.

Read also => Testing Retail Banking System

Setting up Sandbox: Braintree Payments Example

1) Navigate to Braintree website.

2) Click on ‘Try the sandbox’ button.

(Note: Click on any image for an enlarged view)

Try the sandbox

3) You will be redirected to the Braintree sandbox website. Fill all the required information and sign up for the sandbox

sign up for the sandbox

4) You will receive an email notification at the email address provided during sign up regarding confirmation of account creation

confirmation of account creation

5) You need to fill in the user information form to process further where you would be required to choose a password. Click on ‘Agree and Create your account button’

Agree and Create your account button

6) You will be logged in and redirected to the Braintree Admin portal

Braintree Admin portal

7) Note the Sandbox keys and use them in your application to integrate with this Braintree sandbox.

integrate with this Braintree sandbox

8) After integration is done, the sandbox is ready for use. If you need to update the sandbox settings you can do so using the settings menu.

settings menu

Commonly used settings menu option:

settings menu

Conclusion

The payment processor is a very important component for any e-Commerce application that is designed to accept payments from its customers. Therefore it is essential to test this component thoroughly. Any missed scenario can impact the sales /transactions of the seller and negatively impact the user experience for the customer or buyer.

Testers need to prepare or set up the test environment (sandboxes, gather dummy credit card information, response codes etc.) and formulate a testing strategy- both for the Test environment and live/post production release testing.

About the author: This useful article is written by Neha. She is currently working as a Quality Assurance Manager and specialized in leading and managing in-house and offshore QA teams.

Have queries or want to share your experience on Payment Gateway Testing? Let us know in comments below.



Recommended reading

25 comments ↓

#1 MikhilS

thanks for sharing.
very interesting topic and I love to do this testing.

#2 Suresh Ananth S

Thanks for sharing. Really helpful.

#3 Anoop

Can I integrate upai or bhim app to my software. Anoop

#4 Irfan

It’s ok but not great! I understand in just one blog, one couldn’t explain in detail but the title and the content didn’t make sense to me.

#5 Gaurav Khurana

Thanks the article is nice and came to know the various terms that are being used.

THough it says that functional testing is less but i can see most of the bugs are functionality related .

How you make sure that data was encrypted ?

We see there is an option for net banking and so many banks are there.. So did you test all banks ?

#6 Aswathylal Mohanlal

Thanks for this extremely detailed article on payment gateway testing. It is very useful for testers when others share their experiences. Saves a lot of time. Thank you Neha for taking the time to write this article consolidating all your experience.

#7 sri

Hi Folks,

This is exactly the way we validate our payment gateway Process. Depends on the client, it may varies to use different payment gateways, like here we use Bridgeport Payment Gateway methodand it is a Europe based company ( we are testing EPOS (Electronic point of sales on ipads/iphones through card readers.) Post will be very useful for freshers. Very interesting topic to learn and keep up the good work guys. Thanks a lot for sharing knowledge:)

#8 Neha

Glad you liked the article @MikhilS :)

#9 Neha

Glad you liked the article @Suresh Ananth S :) !

#10 Neha

Hi @Anoop

I have not personally worked on BHIM integration or any related testing .However I did find the steps to integrate BHIM app with Mobile number or Virtual Payment Address (VPA) at http://www.npci.org.in/BHIM_Product_Overview.aspx
. Hope this helps :)

#11 Neha

Hi @Aswathylal Mohanlal

Thank you for the positive feedback :)

#12 Neha

Hi @Sri

Glad you liked the article :) . Thank you for contributing more payment gateway examples.

#13 Shikha

Very Interesting and Useful article .

#14 Neha

hi @Gaurav

Glad you liked the article :) !

The amount of functional testing depends on the application and the payment processor being tested. For a well designed and stable payment processor, the functional testing effort will be less as you would not need to test the functionality of payment processor itself. Rather we can focus on testing the integration of the application and the payment processor.

While rolling out a payment processor, different business units (depending on the organisational structure) may need to work together to verify the end to end functionality. As an example, functional testing can be done by QA, security testing can be undertaken by dedicated Security tester or Devops, finance department can help to verify if the payment is being captured correctly and that the amount is credited to correct merchant account. This includes any kind of pre-release or post production release testing.

We usually ensure that all the payment related pages, wheres sensitive information is being captured is always on https even if the entire application is on http . Again this would vary based on the application being integrated.

We do not test at the bank level, our main focus is to ensure that our application is working in sync with the payment processor and the data being passed between them is correct. We also include testing of different dummy credit cards like Visa, mastercard, etc. How the payment processor interacts with the banks – that i have never tested myself .

Hope this answers your queries.

#15 Neha

hi @shikha

Thank you for the positive feedback :)

#16 Ahmed Fathi Elgaly

Really so valued article with simple explanation.

#17 Neha

hi @Ahmed Fathi Elgaly

Thank you for the positive feedback. Glad you liked the article :)

#18 Asad Rasheed

Nice Article !!

#19 venkadesh

Nice article..:)

#20 JYOTI

Thanks Neha…My question is Whos the Merchant in above Payment gateway figure as it is written MERCHANT below Visa/Plastic card image? Please reply.

#21 Neha STH Author

@Asad Rasheed Glad you liked the article :) !

#22 Neha STH Author

@venkadesh
Glad you liked the article :) !

#23 Neha STH Author

@Jyoti

Glad you liked the article :) !

A merchant is a person or company that sells products or services. Flipkart, Amazon, eBay are some examples of Merchants. The merchant can chose to accept Visa, Mastercard,debit, American Express etc. The Visa and Master card symbols in the image just depict the mode of payment that a merchant may use for transactions.

#24 Pavan

Really interesting article. I would like to know a bit more on what kind of testing would you be performing post production. Would you be initiating a real transaction in Production and performs a real transaction with valid credit card details or will the Payment gateway companies provides some dummy cards even in Production?

#25 Neha

Hi @Pavan

Glad you liked the article :) !

Regarding post production release verification, we use real credit cards to do end to end transaction – from transaction to capturing, refunding payment etc.

It is essential to note that as part of production release planning and preparation, the client needs to set up real account with the payment processor and set up their merchant ID. The client would also need to configure their security settings like checking for invalid CVV numbers etc. Once the account is set up, the integration keys from that live account need to be integrated with the application on production once the application goes live. After all this groundwork is done, we can use real credit cards to test on production.

Leave a Comment