Testing Steps
Careful testing is the cornerstone of software development, ensuring it operates as expected. You cannot move on to a live environment and handle real payments until you have confirmed that your integration works as desired in all scenarios.
Prerequisites
Before you start testing your Hosted Checkout integration, you must complete:
- Basic integration using the Hosted Payment Page to gather payment details.
- Integration for any subsequent operations you want to handle within your order lifecycles.
- Any customizations related to the payment methods you want to support.
- All additional features and security-related functionality you need.
Testing your integration
Cover at least the following steps in your testing:
- For the payment methods you support, test all individual operations you want to use in your integration where payer interaction is needed on the Hosted Payment Page.
Test the process from creating the checkout session to providing the Hosted Payment Page to the payer and managing the callbacks from the payment page process. - For the payment methods you support, determine the payment flows (combinations of initial and subsequent transactions) you want to be able to use in your integration. Test all the flows with all possible combinations of subsequent transactions.
- Test all the additional features and security-related functionality you are using.
- Confirm that your system reacts appropriately and overcomes all common error scenarios related to invalid requests and server problems.
For examples of error scenarios to be considered, see Common Transaction Failures. - Determine the transaction responses that require further actions from you, and test that your integration is taking expected actions.
Testing tools
To test your integration, the Mastercard Gateway provides some helpful tools:
Simulators
You can test your requests using various simulators, which you access from your test merchant account. To confirm that you are using your test merchant account, check that the merchant ID supplied by your payment service provider (PSP) has the prefix "TEST". All requests sent with the test merchant ID are regarded test requests and handled by the simulators. They are not sent forward to actual providers, issuers, and acquirers.- If you have already been given a merchant ID that has the "TEST" prefix, that is your test merchant account. Your PSP sends you another merchant ID when you are ready to process live transactions.
- The test merchant account is a wholly separate account with a different API password or certificates from your regular account. When switching from one to the other, make sure to change both your merchant ID and any authentication credentials.
For the payment methods that require the payer to provide their approval on the payment provider’s web site, the gateway provides an interactive payment simulator. For more information on specific simulator features and options, see the test instructions within specific payment methods and Common Browser Payment Integration.
Test cards
If you support card payments as payment methods, the gateway provides test cards to enable you to test various scenarios, including 3D Secure authentication. For details, see Test Cards and Testing Your Integration for 3DS Authentication.Predictable response results
The test simulator is configured to generate predictable results based on the transaction request and the card details you supply. For details, see Test Cards and Common Browser Payment Integration.
You can trigger transaction responses that contain a specific Mastercard Gateway Response Code or Card Security Code validation result, as well as Address Verification response code, and ensure that your integration reacts appropriately to each. You can also receive specific response results for features like wallets.
Common transaction failures
When testing your integration, consider the following transaction failure scenarios and make sure your system reacts to them appropriately:
Payment authorization declined or card type not accepted
If theresponse.gatewayCodein your transaction response has a value starting with DECLINED, the payment authorization has not been approved by the issuing bank or the payer is attempting to use a card type that is not accepted by the gateway.
Study the exact returned gateway code and other details in the transaction to determine in more detail why the payment has been declined. You may need to ask the payer to use a different payment method to solve the problem.Invalid card information
If theresponse.gatewayCodein your transaction response is set toINVALID_CSC,EXPIRED_CARD, or similar, the problem is with the payer’s card details. The payer has either entered them incorrectly, or the card is no longer valid. You need to ask the payer to check their card details or potentially use a different card.Insufficient funds
If theresponse.gatewayCodein your transaction response is set toINSUFFICIENT_FUNDS, the payer's account does not have enough funds to cover the transaction. You need to ask the payer to use a different payment method or card.Transaction timeout
If theresponse.gatewayCodein your transaction response is set toTIMED_OUT, the gateway did not receive an answer from the acquirer. Consequently, the transaction was automatically terminated. You need to try again later.