Your payment gateway wasn't built to stop card testing
Merchants treat the gateway and its velocity rules as the line of defense against card testing. But the gateway is the meter the attacker is feeding. By the time traffic reaches it, the authorization is already being requested, and the network is already counting. Here's why the only place to stop the burst is in front of it.
When card testing hits, the first instinct is to reach for the gateway. Turn on the velocity rules. Cap attempts per IP, per card, per minute. Most gateways ship with some version of this, and most merchants assume it’s the control that keeps enumeration out.
The problem is the gateway is the thing the attacker came for. Card testing is automated validation of stolen card numbers against a live merchant, and the gateway is the live merchant: it’s the endpoint that forwards the authorization to the network and returns approved or declined. Every rule the gateway runs, it runs on a request that has already arrived at the meter. The block, if it comes, comes after the attempt is already in flight.
A gateway can throttle card testing. It cannot prevent it, because by the time the gateway sees a request, the network is already counting.
The meter starts before the gateway decides
Card testing is cheap for the attacker and metered for you. The networks charge for the attempts themselves, approved or declined, and they have built specific programs to do it.
- Mastercard Excessive Authorizations (TPE) — $0.50 per attempt in the US, charged on every authorization after 10 declines on the same card within 24 hours. The fee was $0.10 in 2022. It is now five times that.
- Visa Authorization Management — $0.15 per declined attempt domestic, $0.23 foreign, starting at the 16th failed attempt on the same card within a 30-day window.
- Visa VAMP enumeration ratio — once confirmed enumerated transactions cross 20% of your authorization volume, you are flagged as high risk. Approved and declined attempts both count, and the floor for inclusion is 300,000 enumerated transactions. Sustained testing pushes you toward acquirer scrutiny, penalties, and the MATCH list.
A single botnet running thousands of cards against your checkout stacks these in parallel: per-attempt penalty fees on one side, an enumeration ratio climbing toward a monitoring threshold on the other. The damage is denominated in authorizations, not in successful charges.
You don’t get billed for the fraud you catch. You get billed for the traffic you accepted.
Why velocity rules arrive a step too late
Gateway velocity rules are count-based: attempts per card, per IP, per window. They are generic by design, because the gateway has to work for every merchant, and they are reactive by mechanism, because a counter only trips after the count accumulates. By the time a velocity rule fires, the attack has already established the pattern the rule was watching for, and those authorizations have already been requested and counted.
Distribution defeats the counter outright. An attacker who rotates cards across a wide IP pool and paces requests under the per-card threshold never trips a rule built around a single dimension. The rule isn’t wrong. It’s positioned at the point where the only thing left to do is forward the request or refuse it, and refusing it is already a counted authorization in some programs.
The fix has to sit in front of the gateway, where the request can be judged before it becomes an authorization at all. That means evaluating the behavior of the session, the integrity of the client, and the shape of the traffic burst before anything is forwarded to the meter.
Ask where the request is, not how many there are
Stop asking “how many attempts has this card made?” and start asking “should this request reach the gateway at all?” The first question is answered at the meter, after the network is already counting. The second is answered at the edge, before the authorization exists.
That is the position Cardvera occupies. It sits in front of the gateway and judges the enumeration burst on behavioral and edge-integrity signals, so the traffic that would have run up your authorization fees and your enumeration ratio never reaches the thing that bills you for it. The gateway was built to process payments. Stopping the burst before it becomes a payment request is a different job, in a different place.