Dashboard · Detection

Payments

Card testing: reading the table, and wiring it into a checkout.

Card-testing detection: one browser, or one address, presenting card after card.

Why this needs its own screen#

No single attempt gives anything away. The card is real, the amount is ordinary, and a tester with a decent residential proxy and anti-detect profile passes every other rule.

What gives it away is the history. So this screen groups by subject rather than by visit.

The KPI row#

Attempts, distinct cards, declines, and how many subjects carry a signal.

If Declines reads "Not reported", your backend has never called POST /api/v1/payments. That is not a count of zero, and the decline rule cannot fire for your site at all.

The subject table#

Each row is one browser or one address, at one site.

Column	Meaning
Subject	Browser (visitor ID) or Address
Cards / 24 h	Distinct cards in 24 hours
Declines / 1 h	Declines in one hour, or "Not reported"
Attempts / 1 h	Attempts in one hour
Reading	Signal, strong signal, or nothing fired

The thresholds#

For a browser: 3 distinct cards in 24 hours, 3 declines in an hour, or 10 attempts in an hour is a signal. 6 cards in 24 hours is a strong one.

For an address: the same limits, doubled. An office or a mobile carrier puts many honest buyers behind one address.

Each row is judged at its own newest attempt, not against the current clock. The engine's windows are 24 hours and 1 hour wide; judged against the clock, a burst from last week inside a 30-day period would read as perfectly ordinary.

A row's windows read 24 hours of history before the period you chose. So a row may count attempts the totals above do not. Without the lookback, a period opening at midnight would clip every window near its start.

A reading is a signal, not a decision. Whether a checkout was refused depends on everything else the engine measured on that request.

Wiring it into a checkout#