The graph goes vertical at 02:00.

Card declines, specifically.

Thousands of authorization attempts per hour against an endpoint that normally sees hundreds.

Small amount processing. Cardholder details that seem ‘odd.’

By the time the morning standup starts, the attacker has what they came for: a list of cards that return valid authorizations, ready to be spent or sold somewhere your fraud team might never see.

This is card testing.

A detection posture built around the decline spike misses how card testing actually works. Card testing sits inside a larger operation.

It is a sequence. Each stage exposes different signals, needs different controls, and too often, falls between teams.

If your detection strategy treats card testing as a single event, you are measuring the validation stage. You have not established coverage of the operation.

Signifyd’s 2026 State of Fraud Report puts card-testing attacks up 175% year over year across its merchant network.⁴

The three stages

Follow the card material, and the operation has three stages: acquisition, validation, monetization. The detection question is who can see each stage, and what they can actually stop.

Acquisition. Card material comes from breaches, phishing, skimmers, or “card” markets. Merchants often have no telemetry here. For an enterprise merchant, start with the acquisition paths you can observe: payment-page tampering and access to your own payment systems. Assign those signals to security. Buying intelligence about stolen cards does not give you visibility into every source of card material.

Validation. This is what the burst at 02:00 exposes. It can also happen below the threshold of your aggregate dashboard.

The actor uses card setup or payment attempts to identify usable card details. Small payments can reduce the chance of a cardholder noticing. Some runs retry with one field changed: CVV, expiration, postal code. The responses tell the actor which combinations to keep.⁵

Visa’s merchant guidance describes this stage as: a spike in declines, approvals and declines clustering in one BIN range, reversals arriving right after approvals, and decline codes (CVV failed, Do Not Honor, Suspected Fraud) occurring during the same time range.²

J.P. Morgan adds additional signals: spikes in unique cards per minute, excessive retries where only one field changes, and waves of zero or small-dollar authorizations concentrated in specific IPs, devices, or sessions.¹

A BIN cluster is one signal, not the detection strategy. Visa also recommends device and session controls and decline-code analysis across BIN ranges.² Its network score covers VisaNet transactions; the behavioral signals belong in your detection across the card networks you process.

Monetization. Validated cards can be spent at other merchants or sold. Your endpoint may have been the testing ground; the next fraud may happen elsewhere. Refund fraudulent test payments and track fraud reports on your own endpoint.⁵ For downstream use elsewhere, work through your processor, acquirer, or trusted intelligence partners. Your dashboard alone cannot close that loop.

Figure 1 · Three stages. Different visibility.

  1. Acquisition

    Obtain card material

    Visibility
    Own checkout or system compromise, where observable.
    Response
    Security investigates observable acquisition paths.
  2. Validation

    Test card details

    Visibility
    Cards per entity, decline mix and retries.
    Response
    Payments/fraud layer controls and refund fraudulent test payments.
  3. Monetization

    Use or sell valid cards

    Visibility
    Local reports; partners for activity elsewhere.
    Response
    Fraud coordinates with processors and acquirers.

In this illustrative sequence, the authorization burst exposes validation; acquisition and downstream spending require different visibility and owners.

SOURCE · J.P. Morgan · AS OF · Visa, June 2026 · AS OF · Stripe documentation · AS OF

The measurement problem.

If you can’t name the stage, you cannot measure the control.

This is why card testing is a technique (FT030 in FT3), with its own detection strategies and control linkages, modeled as behavior with a lifecycle position rather than a transaction anomaly.

It is the technique that broke STIX for me.

When I tried to express “high-volume authorization attempts, correlated by device, spread across multiple merchant accounts, within a time window” in STIX 2.1, the payment-layer observables did not exist. The STIX teardown is here.

Why single heuristics fail

Most reach for a single block: rate-limit the IP, blocklist the BIN, CAPTCHA the checkout.

Single heuristic controls are just one measurement. Actors can adapt faster than a single block, which keeps you playing ‘whack-a-mole.’

Block an IP range, and an actor can change its source. Block a BIN, and you can block legitimate cardholders — J.P. Morgan cautions against BIN blocking for this reason.¹ Require CAPTCHA broadly, and you add customer friction without making automated testing impossible.

Visa announced an AI-based enumeration score in 2024, initially for U.S. issuers.³ Its June 2026 merchant guidance describes use by issuers and acquirers and says merchants can incorporate the score into their fraud strategy.² Confirm availability with your provider. Shifting decline codes alone do not tell you whether that score drove the decision.

That is just one vendor’s network view.

You are hunting for the validation phase: unique cards per entity, decline-code composition, single-field-change retry patterns, nonsense-identity clustering, and device and session reuse across cards with no legitimate relationship.

At scale, the spike can disappear.

An aggregate graph can hide what is obvious at a smaller endpoint.

Suppose five thousand test authorizations arrive alongside two million legitimate ones in an hour. Even if every test declines, they add less than 0.25 percentage points to the aggregate decline rate. The endpoint may look normal while a few devices do something very different.

Three things survive scale.

Per-entity counts. Instrument card attempts by device and session. Count distinct cards attempted in a time window, then compare with normal behavior for that flow. This avoids dilution by unrelated traffic. It still misses an actor who rotates identities fast enough.

Segment before you baseline. Compare decline-code composition within the same endpoint, payment flow, and entity cohort over time. A change in CVV mismatches or Do Not Honor responses is a lead to investigate alongside retry patterns, not proof of testing on its own.

Cross-entity correlation. Tests spread across merchant accounts can evade local thresholds. A processor or network with shared visibility can look for related attempts across accounts. A merchant needs a partner that can make those links; device IDs and payment tokens from separate systems are not automatically comparable.

A decline spike shows you validation, not the whole operation. Identify the stages. Measure what you can see, and identify who can see the rest. That’s attacker engineering. Build defense from the adversary backward.

Sources

¹ Card testing 101: Spot it early, stop it fast — J.P. Morgan, July 9, 2026. https://www.jpmorgan.com/insights/payments/merchant-services/preventing-card-testing-attacks

² Enumeration Mitigation and Considerations for Merchants, V1.3 — Visa Public, June 2026. https://usa.visa.com/content/dam/VCOM/global/support-legal/documents/anti-enumeration-and-account-testing-best-practices-merchant.pdf

³ Visa Announces Generative AI-Powered Fraud Solution to Combat Account Attacks — Visa press release, May 7, 2024 (VAAI Score; US issuers first). https://usa.visa.com/about-visa/newsroom/press-releases.releaseId.20661.html

⁴ State of Fraud Report 2026 — Signifyd (vendor-reported figure; single-network view, labeled as such in the text). https://www.signifyd.com/news-releases/state-of-fraud-report/

⁵ Protect yourself from card testing — Stripe Documentation. https://docs.stripe.com/disputes/prevention/card-testing