Card Testing Data: Signals Merchants Can Use

Card testing data is the set of authorization, device, and response records that reveal a scripted run of card checks against a payment page. The top pick for spotting an attack is the pairing of authorization velocity with ticket size: a burst of small-value attempts from one merchant account, spread across many card numbers, arriving with a decline rate far above baseline. That single combination outranks every other signal because it survives proxy rotation, new card batches, and changes in the attacker's tooling. The criteria below compare the data sources that carry this signal, with the strengths and blind spots of each.

read more

What card testing data actually contains

Most teams already hold the raw material. The work is in joining it at the session level instead of the order level.

card testing data

• Authorization logs: amount, currency, timestamp, card BIN, issuer country, response code, and the approval or decline reason.
• Gateway response detail: address verification result, card verification result, and the specific decline family rather than a generic failure.
• Session and device signals: IP address, autonomous system number, user agent, browser fingerprint, and whether the device has been seen before.
• Checkout behavior: time from page load to submit, paste events in card fields, and whether the same session tried multiple cards.
• Account context: email age, order history, shipping and billing mismatch, and prior chargebacks on the customer record.

Criterion 1: Authorization velocity against ticket size

Count attempts per merchant account, per IP, and per card BIN over rolling windows, then normalize by the median ticket. A test run looks like dozens of low-value attempts where the merchant's normal ticket is ten times higher.

card testing data

Pros

• Works before any money moves, so nothing is lost on a successful guess.
• Cheap to compute from logs you already keep.

Cons

• Needs a baseline per product line; a dollar-store catalog has a low median ticket already.
• Distributed attacks can keep each individual IP under the threshold.

Criterion 2: Response-code mix

Real customers occasionally mistype a card number. A script generates a different distribution: long strings of the same decline family, repeated address and card verification failures, and a handful of approvals scattered through the noise.

Pros

• High precision when a single decline reason dominates a short window.
• Catches attacks that arrive slowly enough to dodge velocity rules.

Cons

• Issuer decline codes are not standardized across the card networks, so mapping takes maintenance.
• Thin history means ratios swing on small samples.

Criterion 3: Device and network repetition

Fingerprint reuse, datacenter autonomous system numbers, and mismatches between the issuer country and the connection country all point at automation. Treat each as a weight, not a verdict.

Pros

• Links attempts that use different cards but the same infrastructure.
• Useful for blocking a campaign rather than a single order.

Cons

• Shared corporate networks and mobile carriers produce false positives.
• Fingerprints degrade as browser privacy features change.

Criterion 4: Checkout timing and interaction

Humans pause, scroll, and correct entries. Scripts submit in near-identical intervals across sessions, often faster than a person can read the form.

Pros

• Independent of the card data itself, so it still fires when card details look clean.
• Low false-positive rate on guest checkout flows.

Cons

• Autofill and saved-payment flows shorten timing for legitimate buyers too.
• Requires client-side instrumentation that privacy rules may constrain.

Where the data usually fails

Most misses come from three habits: reviewing orders instead of sessions, letting the payment gateway and the storefront keep separate logs, and setting static thresholds that never get revisited. Combine at least two criteria before you block. A single weak signal should trigger a step-up challenge, not a permanent ban.

Recommended setup by merchant size

Small catalogs get most of the value from velocity plus decline-mix rules, reviewed weekly by hand. Mid-size merchants should add device linking and a shared fraud queue across storefronts. High-volume merchants need session-level scoring with a written rule for what each score does, plus retention long enough to investigate a chargeback filed ninety days later.

After a confirmed attack

1. Freeze the affected payment path and preserve logs before any cleanup.
2. Pull every authorization tied to the campaign's device or network cluster, not just the approved ones.
3. Export the BIN range and attempt timestamps for your acquirer and the card networks.
4. Refund or void approved test charges and notify affected cardholders through the issuer channel.
5. Write the detection gap into your rule set so the same shape trips an alert next time.