Carding and the bot economy: how stolen cards get tested at scale

A fraudster holds a flat file of card numbers. Some came from an infostealer log scraped off an infected laptop. Some were generated from scratch by taking a known bank prefix and counting through the account digits. Most of them are dead: cancelled, expired, never issued, or simply wrong. The fraudster does not know which is which, and a dead card is worthless. So before any of these numbers gets sold or spent, it has to be proven alive. The proof is a transaction. A small one, against a real merchant, watched only to see whether the issuer says yes.

That is carding. Not the theft of the card and not the eventual cash-out, but the validation step in between, the part that turns an unsorted pile of digits into a graded inventory of working cards. It runs on automation because it has to: the only way to find the live one-in-fifty is to try all fifty, and trying fifty thousand by hand is not a business. This post is about how that testing works, why it concentrates on certain merchants, what the bot layer actually does, and the signals that issuers and payment processors use to catch it. No part of it is a how-to. The mechanics are interesting enough on the defensive side that they do not need an operational manual to be worth understanding.

The sections build in order. First the supply: where the raw numbers come from and why there are so many. Then the two flavors of the attack, testing a known list versus enumerating numbers that do not exist yet, and why the distinction changes everything about detection. Then the probe itself, the micro-authorization, and why it is shaped the way it is. Then the bot economy that drives volume, and its overlap with credential stuffing. Then the merchant-side and network-side detection, including the signals payment processors lean on. And finally the economics, which is the only part of the system that explains why it never stops.

The supply: why there are always more cards to test

Carding only makes sense if the input is cheap and abundant, and it is both. The dark-web supply of card data is continuously refilled from two streams that feed at industrial scale.

The first is malware. Infostealers, the commodity credential-and-card grabbers that run on infected consumer machines, pull saved card details straight out of browsers and autofill stores. A 2025 Kaspersky analysis of stealer log files from 2023 and 2024 found roughly 2.3 million bank cards exposed across the logs it examined, and noted that about 95 percent of the observed numbers were technically valid in form. The same analysis put the infection scale at nearly 26 million Windows devices over the two-year window, more than 9 million of them in 2024 alone, and estimated that on average every fourteenth infostealer infection yields at least one stolen card. Redline was the most common family in 2024 at around a third of infections, with newer entrants like Risepro climbing from under two percent to roughly a quarter of the total in a single year. The point is not any one family. It is that the pipeline is large, automated, and refreshed faster than the cards can be cancelled.

The second stream is skimming and breach data, the classic point-of-sale and e-commerce compromises, plus the magecart-style script injections that lift card details at checkout. These tend to produce fresher, higher-quality dumps than the malware logs, because the data is captured at the moment of a real transaction rather than scraped from a saved-card store that may be months stale.

This supply distinction matters for everything that follows. A high-quality dump of full card details, with expiry and security code intact, needs only a light touch of validation to confirm the cards are still live. A pile of bare numbers, or numbers with missing fields, needs heavy testing to fill in the gaps. The quality of the input decides the shape of the attack.

*Three supply streams feed one validation step; the test sorts an unsorted pile into a graded inventory of live cards.*

Two attacks that look the same and are not

The OWASP Automated Threat Handbook splits this into two named threats, and the split is the cleanest way to think about it. OAT-001 Carding is multiple payment-authorization attempts to verify the validity of bulk stolen card data, full records you already hold. OAT-010 Card Cracking is the variant where you hold partial data, the number but not the expiry or the security code, and you brute-force the missing fields. OWASP also lists OAT-012 Cashing Out as the downstream step where validated cards get turned into goods or money, which is a separate problem and not this post.

Card cracking shades into a third pattern that the card networks call enumeration, and the industry often calls a BIN attack. Here the attacker does not start from stolen numbers at all. A card number is mostly structured. The first six to eight digits are the Bank Identification Number, now formally the Issuer Identification Number, which identifies the issuing bank and network. The middle digits are the account identifier. The final digit is a checksum computed with the Luhn algorithm. Because the BIN is public knowledge and the checksum is a fixed formula, an attacker can hold one BIN steady, count through the account digits, append the correct Luhn check digit to each candidate, and produce an endless stream of numbers that are structurally valid. The Luhn check guarantees the number is well-formed. It says nothing about whether the card exists, which is exactly the gap the testing fills.

This is the part worth being precise about, because it is where guesswork creeps into write-ups. The Luhn check catches typos, not fraud. Generating a Luhn-valid number is trivial and proves nothing on its own. To make a generated number useful, the attacker still has to find the expiry and, for most flows, the security code, and the only way to find them against a remote merchant is to guess and submit. Expiry has a bounded space, typically a few years of months. The three-digit security code has a thousand possibilities. Against a merchant that does not verify those fields and does not rate-limit, that search is feasible. Against one that does, it collapses.

So the two attacks diverge sharply on detection. Testing a real stolen dump produces a high authorization rate, because most of the cards are real and many are live, and the fraud hides inside an ordinary-looking stream of approvals. Enumeration produces a very high decline rate, because almost every generated candidate is wrong, and that flood of declines against a narrow BIN range is itself the signature. A defender tuned only to look for declines will miss the verification attack entirely. This is the shift Stripe described when it noted that fraudsters had moved away from low-success enumeration toward verification attacks against fresh, high-quality dumps, where issuers were authorizing the test transactions at higher rates than before.

The probe: anatomy of a micro-authorization

The unit of work in carding is a single authorization request, shaped to reveal whether a card is live while drawing as little attention as possible. Two properties define it.

It is small, or it is zero. A common pattern is a charge of a dollar or less, sometimes a few cents, sometimes framed as a donation or a small digital good. The amount is kept low for a reason that has nothing to do with the value extracted, which is nil: a small charge is less likely to trip a cardholder’s own alerting, less likely to be noticed on a statement, and in many cases less likely to draw issuer scrutiny than a large one. Even better from the attacker’s side is a zero-value or account-verification authorization, the kind that never posts to the statement at all. Payment processors document that fraudsters prefer card-setup and validation flows precisely because validations and authorizations do not appear on the cardholder’s statement, which removes the one feedback loop that would otherwise tip off the victim.

The signal the attacker reads is the issuer’s response. A successful authorization, or specific response codes, confirm the card is live and the supplied details match. A decline confirms the opposite, and the decline code itself can leak which field was wrong, separating a dead card from a live card with a mistyped security code. Processors note that fraudsters collect the 3-D Secure or issuer responses to grade which records are valid. The transaction is never the goal. The response to it is the entire product.

*The probe's payload is throwaway; the issuer's verdict travelling back, including the decline code, is the only thing the attacker keeps.*

Why the bots, and what they share with credential stuffing

You cannot do this by hand. The arithmetic forbids it. If a dump is one-in-twenty live, finding a thousand live cards means submitting twenty thousand probes, and a generated-number enumeration run is far worse because the live rate is a fraction of a percent. The attack is automation by necessity, and the automation looks a lot like the rest of the bot economy.

The tooling is recognizable to anyone who has read the credential-stuffing toolchain. There is a list of inputs, here card records instead of username-password combos. There is a request engine that replays a checkout or card-add flow thousands of times. There is a proxy layer, usually residential or mobile IPs, to spread the requests across many source addresses so that no single IP shows an implausible burst. And there is a results file that sorts the inputs into live and dead. Swap the wordlist and the verdict parser, and a credential-stuffing rig becomes a carding rig. The two attacks share infrastructure, share operators, and share the same fundamental shape: a cheap, low-yield probe run at enough volume that a tiny hit rate becomes a usable harvest. The mechanics of that shared model are covered in credential stuffing mechanics.

The bot layer also drives the cat-and-mouse on detection. Payment processors and anti-bot vendors increasingly fingerprint the client, not just the transaction. A real shopper types a card number; a script pastes it, or injects it through the field without any keystroke events at all. A real shopper takes seconds to move through a form; a bot submits in milliseconds. These behavioral tells, the absence of human input timing and the speed through checkout, are exactly the signals that behavioral biometrics and device fingerprinting systems are built to read, and they are why so much carding traffic now arrives through anti-detect browsers trying to look like ordinary checkout sessions.

Visa, describing the scale, put it plainly: threat actors are using automated scripts and botnets to amplify card-testing attacks, exploiting weaknesses at a speed and scale that manual fraud never reached. The botnet is not incidental to carding. It is the thing that makes the economics work.

Merchant-side detection: the symptoms before the cause

A merchant rarely sees the attacker. It sees the wake. Card testing produces a distinctive disturbance in a payment stream, and most merchant-side detection is pattern recognition on that disturbance rather than identification of any individual bad transaction.

The clearest tell is a sudden change in the shape of authorization traffic. J.P. Morgan’s guidance lists the symptoms a merchant should watch for: an unusual spike in low-value authorization attempts in rapid succession, a high volume of near-identical requests, a sharp rise in declines carrying particular decline codes, and a jump in authorization mismatches reported back from the issuing banks. Stripe’s account of the same problem points at a spike in failed payments and a surge of 402 errors, often with nonsensical customer names and email addresses attached, and small or strange transaction amounts. None of these is a single fraudulent charge that can be pointed at. Each is a deviation from the merchant’s own baseline, which is why detection depends on having a baseline to deviate from.

The second-order damage is what makes merchants care. A flood of declines is not free. Each failed authorization can carry a fee. A run of testing pollutes a merchant’s decline ratio, which the card networks watch, and a poor ratio damages the merchant’s standing with issuers and can pull legitimate approvals down with it. Sustained abuse can trip the networks’ own monitoring programs, with penalties attached. The infrastructure strain of tens of thousands of probes can degrade service for real customers. The fraud loss on a fifty-cent test is trivial; the collateral cost of being used as a test rig is not.

The controls merchants reach for are mostly about raising the cost of a probe. Address and security-code verification turn a bare-number test into a much harder problem, because now the attacker has to know or guess those fields too. Velocity rules cap how many attempts a single email, device, IP, or address can make in a window, which directly attacks the volume the economics depend on. A challenge served only when the machine-learning layer suspects testing, rather than to everyone, blocks the script while leaving the human alone. Requiring a session or login before the payment form is reachable removes the open guest-checkout endpoint that testing prefers. And device fingerprinting ties many probes back to one machine even as the IP rotates underneath them.

The CAPTCHA case is worth dwelling on, because it is where the bot economics and the merchant defense meet most directly. Stripe reported that adding a managed challenge to its hosted checkout, served by a model only when a testing attack was detected, cut card testing by 80 percent while costing less than two basis points of authorization rate on legitimate traffic, because real users almost never saw the challenge. That is the defender’s ideal: a cost imposed almost entirely on the attacker. It also explains the arms race, because a challenge that bots cannot solve is a challenge that bots will pay a solving pipeline to get past, and the equilibrium moves again.

*The attack is invisible at the level of one transaction and obvious at the level of the stream: a sharp burst of low-value, high-decline attempts against a baseline.*

Network-side detection: where the whole picture lives

The merchant sees its own traffic. The card network sees everyone’s. That difference is the reason the most effective enumeration detection has moved up to the issuer and network layer, where a single attacker hitting a hundred merchants with the same BIN looks like one coordinated event rather than a hundred unrelated blips.

Visa quantified the problem when it announced its enumeration-focused scoring in May 2024. Enumeration attacks, by Visa’s accounting, drove around 1.1 billion dollars in fraud losses in a single fiscal year, and a striking share of the damage was fast: roughly a third of enumerated accounts saw fraud within five days of the credentials being compromised. The detection response was a real-time score, trained on more than 15 billion network transactions, returning a risk value in about 20 milliseconds and built with several times the feature count of Visa’s earlier models, with a claimed 85 percent reduction in false positives against comparable risk models. The number that matters there is the 20 milliseconds. Enumeration is a volume game measured in transactions per second, and a defense that cannot keep up with the authorization path is a defense that does not run.

The structural advantage of the network view is correlation. An enumeration run spreads its probes across many merchants to stay under each one’s local velocity threshold, but every one of those probes touches the same BIN range and flows through the same network. What is invisible at any single merchant, a handful of declines, is a glaring pattern in aggregate: thousands of sequential or near-sequential account numbers under one BIN, declining at a rate no legitimate merchant ever produces. The network is the only party positioned to see that, and so the network is increasingly where the line is drawn.

Issuers add the last layer by acting on the BIN. When a network or a monitoring service flags a BIN as under enumeration, the issuer can tighten authorization on that range, alert the affected merchants, and in the worst case reissue. This is reactive and expensive, which is the whole argument for catching the pattern earlier in the stream rather than cleaning up after the cards are graded and sold.

3-D Secure, and why it changes the target

One protocol sits across this whole problem and deserves its own treatment, because it changes which merchants get tested. EMV 3-D Secure, the EMVCo authentication protocol behind the Verified-by-Visa and Mastercard Identity Check brands, inserts an issuer-side authentication step into a card-not-present transaction. In its modern form it usually runs frictionless: the issuer evaluates device and behavioral signals passed in the authentication request and, if the risk looks low, authenticates the cardholder silently with no challenge. If the risk looks high, it steps up to a challenge, a one-time code or an app approval.

For carding, two consequences follow. First, a successful 3-D Secure authentication shifts chargeback liability for fraud from the merchant to the issuer, which removes much of the merchant’s direct financial exposure to a fraudulent approval. Second, and more important to the attacker, the authentication step adds a gate that a script cannot easily pass, because clearing a challenge requires the genuine cardholder’s second factor. A merchant that enforces 3-D Secure on card-not-present payments is a poor test target, because even a live card may not clear authentication in the attacker’s hands.

The result is selection pressure. Testing flows toward the merchants that make a probe cheapest: those that allow open guest checkout, skip address and security-code verification, do not enforce 3-D Secure, and do not rate-limit. The attacker does not need every merchant to be weak. One soft endpoint is enough to validate a whole dump, and the cards graded there will be spent elsewhere. This is why advice to merchants converges on the same set of frictions, and why the weakest checkout in a sector tends to absorb the testing traffic for cards that will be cashed out against its competitors.

The economics that keep it running

Strip away the technique and what is left is an arbitrage, and the arbitrage is the reason nothing here goes away. The input is cheap to the point of being nearly free, refilled continuously by malware and breaches faster than cards expire. The test is cheap, a fraction of a cent of compute plus a slice of a proxy pool, with the fee burden falling on the merchant rather than the attacker. The output is a graded list of live cards, which has real resale value, and a live card with confirmed details sells for more than a raw unverified number precisely because someone did the testing. Validation is value-added work in this market, and carding is the labor that adds it.

Run the funnel. A verification attack against a fresh, high-quality dump may find live cards at a high rate, because the data was good to start with. An enumeration run against generated numbers finds them at a fraction of a percent. Either way the response is the same: turn up the volume until the absolute count of live cards is worth the run. A two-percent yield is irrelevant when the probes cost almost nothing and you can send a hundred thousand of them overnight. This is the same logic that makes credential stuffing profitable at a one-to-three-percent hit rate, and it fails to the same defense: not a better guess, but a higher cost per attempt. Every effective control here, the verification fields, the velocity caps, the challenge, the network score, works by making the probe expensive enough that the arbitrage closes.

What is left is a system where the defender’s job is never to make carding impossible, only to make a given merchant the wrong place to do it. The attacker has near-infinite cheap inputs and will route around any single hardened endpoint to the next soft one. The cards graded at the soft endpoint get spent against everyone. Visa’s billion-dollar figure and the five-day window from compromise to fraud are the same fact stated two ways: the supply is large, the loop from test to cash-out is short, and the only durable lever is the cost of the probe. Lower that cost anywhere and the testing finds it within days. The merchants that survive carding are not the ones with the cleverest fraud model. They are the ones who made themselves boring to attack.

---

Sources & further reading

• OWASP (2018), OAT-001 Carding — the canonical definition of carding as bulk payment-data validation, with its mapping to card cracking (OAT-010) and cashing out (OAT-012).
• Visa (2021), Visa Guidance to Guard Against Enumeration Attacks and Account Testing Schemes — Visa’s merchant-facing description of enumeration and account-testing mechanics and controls.
• Visa (2024), Visa Announces Generative AI-Powered Fraud Solution to Combat Account Attacks — the VAAI Score announcement, with the $1.1B loss figure, the 20-millisecond score, and the 15-billion-transaction training set.
• Stripe (2024), Protect yourself from card testing — processor-side mechanics of card-setup versus payment testing, the symptoms merchants observe, and the velocity and challenge controls.
• Stripe (2023), How Stripe Radar responded to a new wave of card testing — the shift from enumeration to verification attacks against high-quality dumps, and the layered response that cut successful testing by 80 percent.
• J.P. Morgan (2024), Six ways merchants can help prevent card testing attacks — the merchant symptom list and the six-control prevention framework, including velocity rules and 3-D Secure.
• Kaspersky (2025), Stealer malware leaked over 2 million bank cards — the 2023–2024 infostealer analysis: 2.3 million leaked cards, the every-fourteenth-infection figure, and the dominant stealer families.
• Fingerprint (2024), The comprehensive guide to preventing digital payment BIN attacks — BIN structure, the Luhn check’s limits, and device-identity-based correlation across rotating transactions.
• Conscia (2024), Enumeration attacks: a deep dive into threat actors generating valid payment data — the generate-validate-monetize stages and the role of weak-verification merchants as test targets.
• Cybereason (2024), Cracking the code: how to identify, mitigate, and prevent BIN attacks — failed-authorization patterns, BIN-range monitoring, and issuer notification as a response.
• Privacy.com (2023), Anatomy of a PAN enumeration attack — an issuer-side account of enumeration volume and the defensive view from the card-issuing side.