# Integration and Testing
source: https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/testing/index.md

## Integration Testing {#integration-testing}

Thorough testing must be conducted by merchants during the development phase of the integration to ensure the foundational functionality is in place during the final validation stage before going to Production. This testing must also be repeated during the smoke testing stage of Production/Go-Live to ensure issues were not missed during Integration testing.

Your test environment must remain available to Ethoca after you go to Production. Notify your Ethoca integration contact if your test environment ever becomes unavailable. Your test environment should be able to support stress testing, and should have at minimum 200 test transactions to use for testing purposes. The test transactions **must not** contain Production data, but are representative of what would be returned in a Production environment.

### Retrieving order details from the API {#retrieving-order-details-from-the-api}

Using an API client, Ethoca will invoke the API using the agreed upon sample search values. The following outcomes will be confirmed:

#### Merchant can receive requests and validate the Authorization header {#merchant-can-receive-requests-and-validate-the-authorization-header}

* Validate Authorization header as per the rules described in the merchant's API specification (see [API Reference](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/api-reference/index.md) for more details).
* Confirm that requests are rejected with an HTTP status code of 403 when the Authorization header is invalid.
* Confirm that any requests that specify an HTTP method other than POST is rejected with an HTTP status code of 405.
* Confirm that the following scenarios return the expected codes:

  |     Description     | HTTP Code |
  |---------------------|-----------|
  | Ok                  | 200       |
  | Bad Request         | 400       |
  | Unauthorized        | 401       |
  | Forbidden           | 403       |
  | Method Not Allowed  | 405       |
  | Internal Error      | 500       |
  | Service Unavailable | 503       |

For more information about response error codes, see [Code and Formats](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/code-and-formats/index.md).

#### Merchant returns valid API payload for valid sample requests {#merchant-returns-valid-api-payload-for-valid-sample-requests}

After the payload is received, Ethoca will perform the following validations:

* Validate that the payload contains all required fields as outlined in the merchant's specification (see [API Request/Response Common Elements and Headers](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/api-basics/common-elements-headers/index.md) and the [Merchant Transaction API Data Dictionary](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/api-reference/index.md#merchant-transaction-api-data-dictionary) for more details).
* Validate that all the fields containing data conform to the specified data type
* Validate that fields with specified character limits have not been exceeded
* Validate that fields requiring a specific enumerated value conform to those values

#### Merchant passes all requirements for pre-defined SLAs {#merchant-passes-all-requirements-for-pre-defined-slas}

* Merchant returns a match rate greater than 80%
* Merchant's response call latency averages less than 2500ms
* Merchant's response error rate is \< 1%   

<br />

After these outcomes are confirmed in the lower environment, your API will be promoted to our Production environment so that these tests can be repeated in Production. When your API has passed all of the same testing in Production, then it will be enabled for all Issuer clients, and considered live and available.

## Product Requirements {#product-requirements}

Your API is a component of a real-time, mission-critical system. As such it is required that this service is highly available and functions as expected. Incoming web-service requests should be fulfilled in real time, and peaks of up to several hundred requests per second should be handled without performance degradation.

Please note that pre-defined SLAs are the same across Consumer Clarity for Merchants products.

### Key product requirements {#key-product-requirements}

|                     Metric                     |                                        Requirement                                         |
|------------------------------------------------|--------------------------------------------------------------------------------------------|
| Response time                                  | 2500 milliseconds                                                                          |
| Transaction match rate                         | \> 80%                                                                                     |
| Error rate                                     | \< 1%                                                                                      |
| Data availability                              | 13 months of transactional data must always be available within 24 hours of authorization. |
| Timeout percentage (\> 7 second response time) | \< 1%                                                                                      |
| Uptime                                         | \~99.7%                                                                                    |
| Average load                                   | 100 queries per second (qps)                                                               |
| Peak load                                      | 200 qps                                                                                    |

## Next Steps {#next-steps}

* Now that you have a general understanding of testing, you can proceed to [Code and Formats](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/code-and-formats/index.md) for detailed information about error response handling. Or you can review some specific [Smart Subscriptions Test Cases](https://developer.mastercard.com/ethoca-consumer-clarity-for-merchants/documentation/testing/test-cases-subscription-controls/index.md).