# Card Testing for Acquirers
source: https://developer.mastercard.com/mastercard-threat-intelligence/documentation/use-cases/card-testing-for-acquirers/index.md

## Overview {#overview}

This document provides practical usage scenarios for the Card Testing API from an Acquirer perspective. The use cases demonstrate how Acquirers can identify merchants within their portfolio that exhibit observed card testing activity or behaviors commonly associated with card testing.

These workflows help Acquirers strengthen merchant risk management, support merchant investigations, and proactively address activity that may increase fraud exposure across their portfolio.

## Investigate Merchants Exhibiting Card Testing Activity {#investigate-merchants-exhibiting-card-testing-activity}

### Context {#context}

Card testing activity often occurs when compromised payment credentials are validated through small or low-risk authorization attempts before they are used for larger fraudulent transactions. Certain merchants may become targets of card testing due to weaknesses in transaction controls, while others may exhibit transaction patterns commonly associated with card testing behavior.

Acquirers are responsible for monitoring merchant activity within their portfolios and identifying merchants that may present elevated fraud risk. When card testing activity is observed, Acquirers need a mechanism to quickly identify affected merchants, investigate the underlying transaction patterns, and determine whether merchant outreach, monitoring, or risk mitigation actions are necessary.

The Card Testing API enables Acquirers to discover merchants associated with observed card testing activity and retrieve the related transaction intelligence for investigation.

### Goal {#goal}

Find merchants confirmed for card testing and merchants that show card testing patterns.

### Main actors {#main-actors}

The analyst, your application, and the Mastercard Threat Intelligence API.

### Preconditions {#preconditions}

* The Acquirer has access to Mastercard Threat Intelligence APIs.
* OAuth 2.0 credentials and access tokens have been obtained.
* Merchant monitoring or fraud investigation activities are in place.
* Internal merchant risk assessment procedures have been established.
* The organization maintains a portfolio of active merchants subject to risk monitoring.

### Desired outcome {#desired-outcome}

* Merchants exhibiting card testing activity are identified through the Observed Testing API endpoint.
* Merchants exhibiting potential card testing behaviors are identified through the Testing Behaviors API endpoint.
* Merchant risk assessments are enhanced with card testing intelligence.
* Merchants requiring additional review are prioritized.
* Findings are documented and operational actions can be initiated.

## Steps {#steps}

Tip: This is a multi-step flow. The first request discovers which identifiers have data. The second request searches transactions within those identifiers.

1. Call the filter options endpoint with `type=OBSERVED_TESTING` to discover CIDs and ICAs that have data.
2. Search observed testing data, filtered by an ICA from the previous step.
3. Call the filter options endpoint with `type=TESTING_BEHAVIORS`, then search testing behavior data.
4. Review the merchant records, severity, and transaction metrics.

### Sequence {#sequence}

Diagram mti-card-testing-acquirers

## Endpoints and step mapping {#endpoints-and-step-mapping}

**Step 1** discovers the filter values.

API Reference: `GET /threats/card-testings/filter-options`

**Step 2** searches merchants confirmed for card testing.

API Reference: `POST /threats/observed-testings/searches`

**Step 3** searches merchants that show card testing patterns.

API Reference: `POST /threats/testing-behaviors/searches`

### Filter options request and response {#filter-options-request-and-response}

```text
GET /threats/card-testings/filter-options?type=OBSERVED_TESTING
```

```json
{
  "cids": ["123456"],
  "icas": ["1234", "6789"]
}
```

### Observed testing request and response {#observed-testing-request-and-response}

```json
{
  "filters": {
    "fieldFilters": { "acquirerIcas": ["1234"] },
    "cardTestingDateRange": { "start": "2025-10-01T00:00:00Z", "end": "2025-10-31T23:59:59Z" }
  },
  "page": { "limit": 20, "offset": 0 },
  "sort": { "by": "cardTestingDate", "direction": "DESC" }
}
```

```json
{
  "records": [
    {
      "acquirerName": "FAST MONEY BANK, N.A.",
      "acquirerIca": "1234",
      "merchantName": "GIFTS 4 EVERYONE, INC",
      "merchantId": "000000012345678",
      "cardTestingMethod": "ACCOUNT_STATUS_INQUIRY",
      "cardCheckerName": "SNEAKY_BOT",
      "cardTestingDate": "2025-10-21T12:34:56Z"
    }
  ],
  "page": { "limit": 20, "offset": 0, "total": 1 }
}
```

### Testing behaviors request and response {#testing-behaviors-request-and-response}

```json
{
  "filters": {
    "fieldFilters": { "acquirerIcas": ["1234"], "classificationSeverity": "HIGH" },
    "classificationDateRange": { "start": "2025-10-01T00:00:00Z", "end": "2025-10-31T23:59:59Z" }
  },
  "page": { "limit": 20, "offset": 0 },
  "sort": { "by": "classificationDate", "direction": "DESC" }
}
```

```json
{
  "records": [
    {
      "acquirerIca": "1234",
      "merchantName": "GIFTS 4 EVERYONE, INC",
      "classificationSeverity": "HIGH",
      "classificationDate": "2025-10-28T09:15:00Z",
      "approvalRate": 6,
      "asiTransactionCount": 4820
    }
  ],
  "page": {
    "limit": 20,
    "offset": 0,
    "total": 1
  }
}
```

## Error Handling and Scenarios {#error-handling-and-scenarios}

Every endpoint uses the same error model. An error response includes `source`, `error`, `recoverable`, and `error_description`. The `recoverable` field indicates whether retrying could change the outcome.

The most common scenarios across all use cases are:

* `400 Bad Request`: a field fails validation, for example an out-of-range `limit` or an invalid `reason`. Correct the request and send it again.
* `403 Forbidden`: your project lacks access to the requested feature or data scope. Confirm your product enrollment, credentials, environment, and entitlements.

For card testing use cases, filter your searches to the CIDs, ICAs, and BINs returned by the filter options endpoint. Searching identifiers outside your access scope can lead to a `403 Forbidden` response.

For detailed error questions and troubleshooting, see the [Codes and Formats](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/code-and-formats/index.md) page. For the full list of status codes and error fields, see the error models in the [API Reference](https://developer.mastercard.com/mastercard-threat-intelligence/documentation/api-reference/index.md).