How to stop card testing

What it costs you

• trending_downYour authorisation rate, which processors and issuers watch closely. A flood of declines marks you as a risky merchant and quietly lowers approvals for genuine customers.
• trending_downPer-attempt fees, since many processors charge for declined authorisations too. Ten thousand failed attempts is a real invoice for nothing.
• trending_downChargebacks on the cards that did work, plus the chargeback ratio that follows you into every future processor negotiation.
• trending_downProcessor standing itself, the worst case being reserve requirements, higher rates, or termination. Replacing a payment processor under duress is far more expensive than the fraud was.
• trending_downEngineering time at an unplanned moment, because this arrives suddenly and demands attention the same day.

How the attack runs

1. 01

   Acquire a list of card numbers

   Bought in bulk from a breach or generated against a known BIN using the Luhn check. Neither the attacker nor anybody else yet knows which entries are live.

2. 02

   Find a cheap, fast authorisation endpoint

   The target is not your product. It is any path that will attempt an authorisation with minimal friction: a donation form, a small top-up, adding a card to an account, a one-dollar trial. Forms with no cart and no shipping are ideal.

3. 03

   Test in volume, at speed

   Attempts run in parallel across many sessions. The point is throughput, because the output is a filtered list rather than any single purchase. Most attempts are expected to fail.

4. 04

   Keep the hits, discard the rest

   A card that authorises is now verified as live and worth far more than an untested number. It is usually sold on rather than used, and often not on your site at all.

5. 05

   Monetise elsewhere

   This is why your fraud team may see very little theft from you directly. You were the free validation service; the loss lands on a different merchant later, and on the cardholder.

The signals that do

These are the signals that carry weight on card testing, and why each one is the signal rather than the obvious alternative. Not all of them are ours: the ones marked you build this genuinely work and Kaidn does not check them, so you would be wiring them up yourself. Listing those unlabelled would read as a claim we cannot support.

Card testing is unusual among the abuse patterns on this site, because the money mostly does not leave through you. Your site is being used as a validation oracle: a fast, cheap way to sort a list of stolen card numbers into live and dead.

That changes what you are defending. You are not primarily protecting inventory. You are protecting your standing with your payment processor, and that is a much less forgiving thing to lose.

The real bill#

A few thousand declined authorisations produce three separate problems, and only one of them looks like fraud on a report.

Per-attempt fees are the visible one, and usually the smallest. The authorisation rate is the serious one: processors and issuers treat a poor approval ratio as a signal about the merchant, and the resulting drag applies to your genuine customers, permanently and invisibly. Then there is the relationship itself, where a sustained pattern can mean reserves, worse rates, or being asked to leave.

Being asked to leave is the outcome to design against. Finding a new processor while wearing a bad decline history is slow, expensive and sometimes not possible on your original terms.

Speed is the whole problem#

Most fraud on this site is a slow leak you can afford to study for a week. This one is not. A card testing run can put tens of thousands of attempts through a form in an afternoon, and the damage is already recorded by the time a daily report is read.

So the design constraint is different: whatever you build has to act inside the attack, not after it. That means alerting on rates rather than totals, and it means the response has to be automatic, because a human being paged at 3am is not a control.

Count the right thing#

The mistake that lets this run is counting attempts per card.

Rotate the card number on every request and every counter reads one. Nothing trips, because the thing you made unique is the thing they were always going to vary. It is the same error as one-account-per-email in multi-accounting, in a more expensive setting.

Count per session, per device, per IP, per ASN, per email, and per BIN. The attacker has to reuse something, and it is never the card.

Where we sit, and where we do not#

We score the payment attempt as an event: automation traits, velocity across every identity except the card, IP and ASN reputation, email identity, and device signals. Verdicts come back with the checks that fired and their weights, in milliseconds, so a block can happen inline.

We are not a payment processor and we do not see your authorisation responses unless you send them. The strongest version of this defence combines both: your processor's decline data, which only they have, and behavioural scoring on the attempt, which they largely do not do. If your processor offers velocity controls, turn them on as well. This is a layer, not a replacement.

Score the attempt, not the card#

The call goes before the authorisation, and the identity fields are everything except the card:

const r = await kaidn.score({
  event: "payment_attempt",
  user_id: session.userId ?? undefined,   // guest checkout often has none
  ip: req.ip,
  email: body.email,
  device_id: body.kaidn_device_id,
});

// this attack is high-volume and automated, so velocity and automation dominate
const testing =
  r.reasons.includes("device_velocity") ||
  r.reasons.includes("ip_velocity") ||
  r.reasons.includes("headless_browser");

if (testing || r.verdict === "block") {
  await recordSuppressedAttempt(r.event_id);
  return Response.json({ error: "please try again later" }, { status: 429 });
}

return authorise(body);   // only now does the card reach your processor

The point of the ordering is that a suppressed attempt never becomes a declined authorisation, which is the number your processor is actually reading.

The alarm you should build first, with no vendor at all#

This is the highest-value hour on the page and it costs nothing. Alert on the decline ratio inside a short window rather than on a count in a daily report:

SELECT
  count(*) FILTER (WHERE status = 'declined')::float / nullif(count(*), 0) AS decline_ratio,
  count(*) AS attempts
FROM payment_attempts
WHERE created_at > now() - interval '10 minutes'
HAVING count(*) > 20;

Page on decline_ratio > 0.5. A count threshold misses a slow run and fires falsely on a busy hour; a ratio does neither. Wire it to whatever already wakes somebody up, and make the automatic response a throttle rather than a notification.

What to do this week, before buying anything#

Put a live alert on your decline ratio, thresholded on the ratio rather than a count, firing within minutes. It costs an afternoon, it needs no vendor, and it converts this from an attack you discover in a processor email into one you discover while it is happening.