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 Direct Payment integration, you must complete:
- Basic integration.
- 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
- For the payment methods you support, determine the payment flows, like combinations of initial and subsequent transactions, you want to be able to use in your integration. Test all the flows.
- 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.
- 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, ANZ eGate payment 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 ANZ Worldline Payment Solutions 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 are already given a merchant ID that has the "TEST" prefix, that is your test merchant account. ANZ Worldline Payment Solutions 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 more information, see test cards and testing your 3DS integration .
- Predictable response results: The test simulator is configured to generate predictable results based on the transaction request and the card details you supply. For more information, see Test Cards and Common Browser Payment Integration. You can trigger transaction responses that contain a specific ANZ eGate payment gateway Response Code or Card Security Code validation result, as well as Address Verification Service response code, and ensure that your integration reacts appropriately to each. You can also receive specific response results for features like fraud management and wallets.
Chaotic response
The chaotic response lets you test the response that deviate from the normal testing response.
An introducing element of this which is not technically part of the API response is that you would be able to better test your response parsing mechanism.
Features of chaotic response
- This is not intended to find buffer overflows or test similar security aspects, but it is designed to help you in flawlessly parse the response and ignore response items that are not needed or not wanted.
- It only applies to REST-JSON requests and only applies to test merchants.
- Whilst it is not currently obligatory, it is highly recommended that you test to avoid future issues.
- It modifies both standard and error responses.
Execution of chaotic response header and its usage
Turning on chaotic responses
The chaotic responses are enabled by a header sent in with the request. This allows the injection of chaotic nodes in the response body.
You should send a chaotic response header when testing that your integration can handle unexpected response data.
Header name: X-MC-Chaotic-Response
It is the chaotic response header that allow a REST-JSON request to send back a chaotic response.
Header value: Not needed and will be ignored.
The header does not need any value and the header name only is sufficient to provide chaotic response.
Real life request:
The header being sent in is X-MC-Chaotic-Response
Real life response:
The header received is "X-MC-Chaotic-Response-<12 last characters of an UUID>"