Adyen explains its defence against distributed card testing

On 4 October 2026, Adyen published a technical account of its Bot Attack model. It reports an average 28% increase in blocked card-testing attacks without harming legitimate shoppers in its evaluation. This is a provider-reported result; the article does not offer independent verification or detailed test boundaries.

Card testing uses payment attempts to check whether card credentials work. When an attack is distributed across many identifiers, an individual shopper or IP may not appear unusual. Adyen describes evaluating aggregated traffic groups and their health in real time, looking for a broader pattern where individual counters show disconnected events.

More blocks are not a complete result

An increase in stopped attempts is useful only with an understanding of what was stopped. Tightening a rule can raise the blocked count while also rejecting more genuine purchases. The publication's separate claim about legitimate traffic therefore matters. Whether that result is reproducible still needs to be tested on the merchant's actual payment portfolio.

There is an engineering point as well. Adyen describes consistent feature calculation between model training and production, with monitoring of input data, computations, predictions and final decisions. Our reading is that this is more informative than the AI label itself. Protection depends on whether the live system receives the signals it was trained to use and whether the team detects drift promptly.

For a high-risk merchant, the useful lesson is to separate different sources of payment failure. A surge in declines may reflect attempts to validate stolen credentials rather than deterioration in ordinary customer traffic. Combining both into one conversion figure can encourage a team to weaken controls simply to restore a headline percentage. An evaluation should distinguish suspicious sequences, genuine purchases and the decision changes following deployment.

The architecture gives fraud teams a concrete subject to examine. The reported 28% should not be inserted directly into a merchant's savings forecast: blocked attempts are not equivalent to prevented financial losses. The article is evidence of a provider's technical approach and claimed internal outcome, not a universal performance benchmark.

What this means for merchants and PSPs

For a merchant, the main takeaway is less about choosing a vendor and more about how its own fraud evaluation is built. Enumeration attacks hit several cost lines at once: fees for authorisation attempts, gateway load, a rising decline ratio as seen by issuers and, potentially, weaker approval rates for ordinary shoppers. The discussion should therefore be framed in terms of costs and losses rather than only the number of stopped requests.

PSPs and payment orchestrators will probably face more client questions about how their own rules detect distributed attacks. It helps to prepare a clear answer in advance: at what level signals are aggregated, how quickly decisions adapt and how a client learns that a control has fired.

What to check internally

• Whether reporting separates suspicious attempt sequences from ordinary declines, or merges everything into one conversion metric.
• Which attributes group traffic: BIN, device, session, amount, checkout entry point.
• Whether feature calculation matches between test and production, and whether data drift is monitored.
• What declined attempts cost under the acquiring agreement, and whether that is included in the protection business case.
• Whether there is a plan for false positives: who lifts a restriction and how quickly.
• What to ask the provider: how the effect on legitimate traffic was measured, over what period and for which merchant segments.

A list like this makes it possible to compare solutions on substance. A provider's reported percentage and the outcome on a specific portfolio can differ noticeably; that is a normal part of deployment rather than a reason to skip the test.

Sources: Adyen engineering disclosure; Adyen Protect product description; Stripe documentation on card-testing effects