# Direct Payment > Testing Steps
source: https://developer.mastercard.com/mastercard-gateway/documentation/testing/test-your-int/direct-payment/index.md

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 {#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 {#testing-your-integration}

Cover at least the following steps in your testing:

1. For the payment methods you support, test all individual Operations you want to use in your integration
2. 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.
3. Test all the additional features and security-related functionality that you are using.
4. Confirm that your system reacts appropriately and overcomes all common error scenarios related to invalid requests and server problems.
5. Determine the transaction responses that require further actions from you, and test that your integration is taking expected actions.

### Testing tools {#testing-tools}

To test your integration, Mastercard Gateway provides some helpful tools:

* **Simulators**: You can test your requests using various simulators, which you can 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 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.

  Warning:   
  * If you are already given a merchant ID that has the "TEST" prefix, that is your test merchant account. Your payment service provider 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 on specific [payment methods](https://developer.mastercard.com/mastercard-gateway/documentation/payment-methods/index.md) and \[Common Browser Payment Integration\].

  <br />

* **Test cards**: If you support card payments as payment methods, the gateway provides test cards to enable you to test various scenarios, including EMV 3-D Secure authentication. For more information, see \[Test Cards\] and \[Testing your EMV 3-D Secure 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 Mastercard 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 {#chaotic-response}

The chaotic response lets you test the response that deviates from the normal testing response.

When Chaos Response is enabled, we introduce an element that is technically not part of the API response. This allows you to test the ability of a response parsing mechanism to handle non-standard responses.

## Features of chaotic response {#features-of-chaotic-response}

* This is not intended to find buffer overflows or test similar security aspects, but it is designed to help you to 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 {#execution-of-chaotic-response-header-and-its-usage}

##### Turning on chaotic responses {#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.

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 allows 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 is only sufficient to provide a 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\>**"

## Chaotic response Postman information {#chaotic-response-postman-information}

For a Postman-based example of chaotic response testing, download the [Postman collection](https://www.postman.com/mastercard/mastercard-developers/collection/4fakvrd/mastercard-gateway-api).