Here is the Tester’s Guide to Payment Gateway Testing:
What are the payment processors?
According to 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 of the most 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.
Table of Contents:
Payment Gateway Testing
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:
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, expiration date, hologram, magnetic strip, signature panel and a card verification value (CVV) number.
Front 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’s 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 on hold and the balance is deducted from the customer’s credit limit but has not yet been 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 transfers between the customer’s card account and the merchant’s bank account.
Also read => Banking Application Testing
Difference between payment gateways and payment processors
There is a lot of literature available online about it and whether payment gateways and payment processors 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. Merchants usually refer to Payment Gateways as payment processors as these process all payments.
“Payment Processors” consider themselves Payment Gateways as they act as a means to process and complete a 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.
If a customer wishes to cancel the order, the following is the flow:
The difference between a void and a return depends on whether a transaction is captured or not.
Unsettled payments can be voided, which means the held funds are credited back to the card holder’s account. If a transaction is already settled or captured, then a refund is initiated which means the funds are taken from the merchant’s account and credited back to the card holder’s account.
Suggested Reading =>> Top 12 Virtual Credit Cards and Debit Cards in the USA
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 will be approved or declined.
Similarly, during online transactions, we need to have a comparable system in place which approves or disapproves of a transaction instantly.
From a customer perspective, online payment processing on the e-Commerce website should be seamless. The customer clicks the ‘Pay Now’ button and should see payment successful or declined messages in the next few seconds.
From an e-Commerce store perspective, merchants need to ensure that the complete payment cycle (getting transactions from online stores, capturing, authorising, refunding, voiding) is 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 the best fit for their application and business.
Types of Testing required
Depending on your choice of 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 be. 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 will 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 the transaction can be refunded or voided 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 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 the application to the Payment gateway. Some of the specific bugs were:
- Customer (buyer) name information was not getting captured correctly
- The customer’s 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 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 will 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 an object not set to instance’ or ‘404 error’ can confuse the customer and impact the 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 purposes, the client (application business owner) will 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 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 a payment processor sandbox.
2) Gather test credit card numbers that will be used to test different credit cards. Such information for Braintree payment processors can be found in Braintree payments.
3) Verify the behavior of the application when a transaction is successful.
4) After a 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 the payment processor stops responding – is there any error message?
7) Verify the application behavior with the browser popup blocker on and off. This may help if any confirmation messages are being displayed in the popup.
8) Verify different fraud prevention/security settings.
For example, if the customer’s billing information does not match the address provided to the issuing bank – any mismatch will result in the transaction being declined.
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 the 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 the rest of the 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 be individually tested from end to end.
15) Verify that refund or void amount (from the payment processor admin portal) is the same as the transaction amount. In none of the cases, the refund/void amount should exceed the transaction amount.
Read also => Testing Retail Banking System
Setting up Sandbox: Braintree Payments Example
1) Navigate to the Braintree website.
2) Click on the “Try the Sandbox” button.
(Note: Click on any image for an enlarged view)
3) You will be redirected to the Braintree sandbox website. Fill out all the required information and 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
5) You need to fill in the user information form to process further where you would be required to choose a password. Click on the “Agree and Create Your Account” button.
6) You will be logged in and redirected to the Braintree Admin portal
7) Note the Sandbox keys and use them in your application to 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.
Commonly used settings menu option:
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 missing scenarios 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 a 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.
Do you have any queries or want to share your experience with Payment Gateway Testing? Let us know in the comments section below.
Was this helpful?
Recommended Reading
-
Build Verification test is a set of tests run on every new build to verify that build is testable before it is released to test team for further testing. These test cases are core functionality test cases that ensure application is stable and can be tested thoroughly. Typically BVT process…
-
If you are preparing for the ISTQB Foundation Level certification exam then here are some sample question papers to make your preparation a little easier. Each ISTQB mock test contains 40 questions and answers are provided at the end of the page. Mark all the answers on a separate paper…
-
Have you performed Software Installation Testing? How was the experience? Well, Installation Testing (Implementation Testing) is quite an interesting part of the Software Testing Life Cycle. Installation Testing is like introducing a guest to your home. The new guest should be properly introduced to all the family members in order…
-
Introduction to Portability Testing: Portability testing is a non-functional testing methodology that determines the ease or difficulty with which a software component or an application can be moved from one environment to another. The test results obtained from Portability Testing helps in finding out how easily a software component from…
Nice Article !!
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 ?
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.
Such a great informative article! Thanks a lot.
Thanks Safi
Glad you liked the article :)!
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.
Can u pls provide sample test cases /test data for Authorize.net .?
Sure, here you go : https://developer.authorize.net/hello_world/testing_guide.html !
Hi Neha,
Thanks for this tips to test payment gateway. Do you have some tips to test a payment processor?
Regards,
Nelson S.
Hi Nelson
Glad you found the article helpful!
Payment gateways often work in tandem with a payment processor and so the scenarios I explained in the article cover both areas. If you are looking for test cases specific to payment processors, you can focus on test cases related to testing the services responsible for sending messages between business – your customers-customers’ bank accounts and business bank account.
Very informative.
Glad you like the article !
Can I integrate upai or bhim app to my software. Anoop
@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.
nice explaination with nice example..do many more like this
Hi Ravindra
Thank you for the feedback. Glad you liked the article 🙂 !
Hi neha,
thanks for this article. it is really helpful. Can you please explain what happens when amount is deducted from the customer’s debit/credit card but at the same time customer sees an error on the screen saying PROCESSING failed or some other error. here customer might contact the bank or the site people but how can we test these scenarios while testing. how is it technically handled? Can you also share some of the negative scenarios of testing of these payment gateways.
Hi Priyanka
Glad you likes the article :)!
We have encountered similar error during testing , the exact same issue – Customer tries to make a purchase, see’s error message, but the payment is deducted from their account. We were able to catch this during testing because we always verify the backend/DB as well. For every transaction, if there is an error or it’s declines, or is successful, we record that response in our DB. So during testing, when we saw, the error message, we checked DB to see if the reason why error message was showing to customer and we realized that actually the transaction was approved but due to Javascript error in the website – the correct database response (success message) was not displaying on the website. So for us, all we need to do is fix the website code to show correct message as per DB response.
To summarize, in order to catch such issues, the tester needs to do more than just GUI functionality testing. So my recommendation is to look out for console errors, DB responses, etc above and beyond testing website from customer perspective.
Hope this helps.
Thanks
Really Useful article for everyone…….
Hi Niraj
Glad you liked the article 🙂 !
Thanks for this extremely detailed article on payment gateway testing. It is very useful for testers when others share their experiences.
Thank you Neha for taking the time to write this article consolidating all your experience.
Thank you Jana for the kind words ! Glad you found the article helpful!
Nice article..:)
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.
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.
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:)
Thank you for the valuable information and tips. I can use some for testing the payment gateway system.
Kind regards,
Kerry
Hi Kerry
Thank you. Glad you liked the article:) !
Neha what an amazing article which covers a lot of things. When i was told i was going to help on the test cases of a payment gateway system i was a bit lost but thanks to this article i feel secure and that i know what i have to test and check.
Thanks Neha for this article.
Hi Miguel
Thank you for the feedback :)!
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.
. Hope this helps 🙂
hi @shikha
Thank you for the positive feedback 🙂
nice article but can u plz provide negative testcase that explains the scenarios where payment gateway may crash
Hi MM
Glad you liked the article!
The test scenarios outside of the ‘Happy path testing’ could be:
– Payment card decline
– Testing various AVS codes
– Testing CVV responses
– Partial payment authorizations
– redirects in case of payment failures
– Logging
– Exception handling and exception messages
– refunds
– captures
– partial refunds
– etc
Most payment gateways have resources / documentation to support the testing , e.g. https://developer.authorize.net/hello_world/testing_guide.html
thanks for sharing.
very interesting topic and I love to do this testing.
Thanks for sharing. Really helpful.
Great write up Neha.
How is user acceptance testing done on Payment gateway implementation? Should the coverage be just placing orders using variety of cards and checking Refund flow? or should it also include validating error codes ?
Since most of the error code validations are covered as part of SIT , is it essential to cover that in end user testing? Please guide.
Hi Priya
Glad you liked the article!
I would say the extent of testing done during end user testing depends on the business needs and the test environment being used. For example, if the end users e.g. Finance team is testing on QA or STG environment, then in-depth tests can be run till we receive sign off or are confident that the implementation is acceptable. However if the test are being done directly on production environment, then its recommended that we test happy paths and monitor the rest of the implementation. e.g. Placing lots of test orders with real credit card on production and then cancelling them could impact the business in negative way in financials , so a balanced approach should be followed.
Glad you liked the article @Suresh Ananth S 🙂 !
Hi Neha,
can u tell me how can i load/performance test an non GUI and TCP connection application (eg. card swipe in petrol pump). can u suggest me any tool name by which i can capture and replay it.
Hi Yogeshwar
I have never been involved in testing POS system , so my knowledge about that is really limited.
I found the following online resources that may help :
softwaretestinghelp.com/how-to-test-point-of-sale-pos-system/
Hope this helps
Thanks
@Asad Rasheed Glad you liked the article 🙂 !
Hi @Aswathylal Mohanlal
Thank you for the positive feedback 🙂
Very Interesting and Useful article .
@venkadesh
Glad you liked the article 🙂 !
Hi!
I’m doing functional payment testing and it’s hard to track the reimbursements. as I use several payment methods/day.
These are PayPal, MasterCard & VISA
Is there a (free) way to track the reimbursements?
Thanks!
Hi Mar
Seems like you may be looking for options to allow easy reconciliation. There are many ERP solutions that help with those e.g. Netsuite, GreatPlains, etc. If you have an Engineering team at disposal, they could be able to create a custom in-house solution with ease as well!
Hi,
Thank you for detailed checklist.
I am going to test the PSP plugin such as Unzer (BNPL) in Ecommerce platform. Which is recently created by an external agency for us and currently need testing from our side before it will be released for the general public.
What do you recommend? the checklist you posted will be enough, or anything else you recommended? I will alter the checklist according to Unzer products.
Is there anything else to consider? Your reply will be appreciated and thanks again for writing this blog.
Dan
Hi Dan
Thank you for the feedback, glad you liked the article!
I would say that the checklist in this article is general checklist and this checklist used along with business/context specific checks could be a good way to go.
Can we have a post on automation of Payment gateways/processors using REST APIs?
Good suggestion for a next article 🙂 !
Hi @Sri
Glad you liked the article 🙂 . Thank you for contributing more payment gateway examples.
Can u post few sample test cases on payment processor testing.
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.
Glad you liked the article @MikhilS 🙂
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?
Very informative, helpful article – we can update the same with latest payment options like:
– BHIM
– Google Tez
– Paytm
Thank you very much for this beautiful article.
Hi Dhvanil
Thank you for the feedback 🙂 ! Sure, good idea!
Really so valued article with simple explanation.
hi @Ahmed Fathi Elgaly
Thank you for the positive feedback. Glad you liked the article 🙂
any one having idea on what is cfredit card bin trace.please msg me in 6300146833
Hi Neha,
Very helpful article. I wanted to know where can we get these dummy card details for testing on sandbox.
Hi Kanchan
Glad you liked the article 🙂 !
Regarding dummy credit cards and expected responses, they can vary from one payment processor to another. Usually this information is available in the Payment processor development guide or integration related technical documentation.
Thanks