Key takeaways
A carding attack is the automated use of stolen payment-card details, either to test whether cards are valid, or to spend on cards that have already passed that test. Knowing which one you’re dealing with is the first step toward an effective response. But before getting into the mechanics, it helps to understand why there’s so much stolen-card inventory for fraudsters to work with in the first place.
Fraudsters aren’t short on raw material. The FTC estimates more than 1 billion credit cards are stolen every year.¹ That’s not a handful of bad actors probing your checkout. It’s a growing problem, fueled by breaches, phishing, malware, and marketplaces that make stolen credentials easier to access and faster to test.
That inventory gets put to work in two distinct ways, and most merchants only build defenses for one of them.
The first step in a carding attack is card testing. A fraudster runs stolen card numbers through your checkout, often for a few cents or a token verification charge, just to see which ones are active. The cards that clear get used or resold. Card details that decline get discarded, at no cost to the fraudster beyond a wasted attempt other than the original card purchase.
The tell is volume: a rapid increase in payment attempts within minutes or hours, a high ratio of issuer declines, and traffic clustering around a small number of IPs, devices, or browser fingerprints. Customer information during these attempts is often thin or nonsensical, because there’s no customer behind it, just a script working through a list of stolen payment details.
Card testing gravitates toward the path of least resistance. Checkout flows that skip account registration, CVV checks, or reCAPTCHA validation make ideal targets. Nonprofit donation pages, digital-goods sellers, and other low-friction checkouts end up disproportionately exposed, not because fraudsters target them personally, but because thin friction makes them easy places to validate stolen cards.
Once a batch of cards clears testing, they move into the next phase.
Card use is the payoff stage. Once fraudsters have validated the card details, their goal is to extract as much value as possible before the legitimate cardholder notices and the card is shut down. Electronics, auto parts, gift cards, travel, and apparel are common targets, prized for resale value and how quickly they can be converted to cash.
The signature is different from card testing. Typically, there are fewer cards in play but higher spend per card, more completed checkouts, and more realistic, if occasionally mismatched, customer data. The financial impact flips too: instead of operational noise, merchants are dealing with chargebacks, lost product revenue, and reputational damage.
Side by side, the two attack types look almost like opposites:
Aspect | Card testing bot activity | Card use, purchase bot activity |
Main goal | Find valid cards, avoid detection at scale | Extract value (goods/cash), keep cards usable |
Amount per transaction | Very small, cents to a few dollars | Normal or high order values |
Success vs. decline ratio | Many declines, few approvals | More approvals, fewer declines |
Cards per device/IP | Many different cards per device/IP | Fewer cards, more spend per card |
Checkout behavior | Stalls at payment step, little cart completion | Looks like complete orders, full checkout |
Customer data quality | Fake or minimal emails, bad addresses | More realistic data, but risk flags (mismatch, odd geography) |
Risk outcome | Operational load, fees, reputational risk | Chargebacks, product loss, financial loss |
Spotting which pattern you’re facing is only half the battle. The harder question is why fraudsters are getting so much better at pulling it off in the first place.
Here’s what’s changed. Fraud bots used to need a human in the loop: someone reviewing declines, adjusting parameters, deciding what to try next. That feedback loop has largely collapsed. Bots can now read processor and issuer responses directly and adjust the next batch of attempts automatically, in near real time, with little manual input.
Note: the same high-level workflow can also apply to stolen-card purchase attempts, although the automation and tactics may differ.
These aren’t bots plugged into a mainstream AI product. Fraud networks are increasingly building and circulating their own purpose-trained models, often through the same marketplaces where the stolen cards themselves change hands.
Two patterns show up most often.2
Supervised models can use labeled historical outcomes such as issuer-decline reasons or approved transactions to identify responses from the issuer, such as insufficient funds or transaction approved, and predict which combinations of attributes may be more likely to succeed. Relevant signals can include BIN ranges, transaction amount, time of day, device characteristics, and prior outcomes.
Unsupervised models go hunting for patterns nobody labeled yet: an unusual pairing of device, IP, BIN, and velocity that doesn’t match any known fraud signature but doesn’t look like a normal customer either.
Put plainly, the bots are running their own experiments, reading the results, and improving between attempts with little human intervention. Set that velocity against fraud rules that only change when someone manually updates them, and it’s easy to see why merchants are struggling to keep up.
None of this means merchants are defenseless. However, it does mean merchants need to bolster their defenses to keep pace with these attacks.
A layered defensive approach remains the right answer for combating automated, adaptive attacks. What matters is making the layers work in tandem rather than as isolated tripwires. Rate limits, bot detection, device and browser intelligence, CVV and AVS checks, and risk-based authentication are all still relevant tactics for minimizing risk.
The bigger shift in fraud prevention is when the decisioning gets made. AI-based fraud tools, including PayPal’s Fraud Protection Advanced solution, can score risk pre-authorization, drawing on patterns across billions of transactions rather than just the transaction immediately in front of it. That may allow a suspicious attempt to be stopped before it ever reaches the issuer, with the model continuing to tune itself based on how each transaction resolves.
When evaluating a fraud protection provider, the questions that actually differentiate the tools are which solutions run pre-authorization, what signals feed the model, how much the decisioning can be tuned, and whether the product treats card testing and account-based abuse as the same problem or two different ones.
That last point matters most. Difficulty telling card testing apart from legitimate customers can lead to fraud losses, blocked good customers, or both.3
Carding attacks don’t just cost the transaction. Sustained attacks can drive up dispute rates, invite additional scrutiny from card networks and payment partners, and quietly erode the operational and reputational headroom merchants need to grow.
Fraudsters running these attacks are iterating faster than most fraud teams can patch their rules by hand. Matching that pace means treating fraud decisioning as a live, learning system, not a static rulebook.