Professional Documents
Culture Documents
Payment Gatewat Testing
Payment Gatewat Testing
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.
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.
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.
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.
#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.
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.
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.
3) You will be redirected to the Braintree sandbox website. Fill 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 ‘Agree and Create your account button’
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.
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
Alpha Testing and Beta Testing (A Complete Guide)
QA Testing Tools
Functional Testing Vs Non-Functional Testing
Perfect Software Testing Resume Guide (with Software Tester Resume Sample)
Build Verification Testing (BVT Testing) Complete Guide
SalesForce Testing Beginner's Guide
Testing Primer eBook Download
68 Essential Resources To Be A Successful Tester (Don't Miss!)