Carding is card-not-present fraud, and attackers use stolen card details to test which cards are still active before they monetize them. In practice, that means your checkout, signup, or payment API can become the test bench.
You might see it as a burst of tiny authorizations, a strange run of failures, or a wave of account creation and checkout attempts that don't look like normal buyers. The cardholder still has the physical card, which is part of why the abuse can sit unnoticed for a while.
Table of Contents
- What Is Carding in Plain Terms
- From Bulletin Boards to Bot-Driven Fraud
- How a Carding Attack Actually Works
- Carding Versus Account Takeover and Card Stuffing
- Where Carding Hits and How Attackers Monetize
- Defenses Merchants Can Apply Today
- What to Remember About Carding
What Is Carding in Plain Terms
Carding is a card-not-present fraud pattern, which means the attacker isn't swiping a physical card at a terminal. Instead, they use stolen card data, usually the card number, billing address, CVV or security code, and expiry date, to make unauthorized online purchases and to test which cards still work. A common first move is a small validation transaction, then the attacker scales up if the card passes validation, as described in Investopedia's carding overview.
For a product team, the important detail is that the merchant is part of the attack path. A fraudster can point stolen card details at your checkout, your registration flow, or your payment API, then watch which requests clear authorization. The cardholder often still has the physical card, so they may not see the misuse right away.
A simple checkout example
A customer lands on your SaaS pricing page, starts a trial, and enters a card for the first monthly charge. A carder does something similar, but with stolen data and a bot instead of a real customer. The bot submits the card data, checks whether the authorization passes, and moves on to the next record if it doesn't.
Practical rule: if a request pattern looks like testing, not buying, treat it like abuse even when the amount is small.
That's why what is carding is more than a definition. It's a workflow that blends fraud, validation, and automation.
The rest of this topic comes down to four questions: where the term came from, how the attack works, how it differs from neighboring abuse patterns, and what defenses belong in a real checkout stack.
From Bulletin Boards to Bot-Driven Fraud
Carding didn't start with modern ecommerce. The term emerged in the 1980s on dial-up bulletin board systems, where hackers used it to describe acquiring and testing stolen card numbers, and by 1990 U.S. Secret Service Operation Sundevil was aimed at BBS groups involved in credit card fraud and other illegal computer activity, according to the historical record in Wikipedia's carding entry. That matters because it shows the problem isn't new, only the tooling is.
The old version was noisy and manual. A person would test one card at a time, then move on. The current version looks very different, because the attacker can run many attempts in parallel against a merchant's checkout or payment API.
The shift is operational, not just technical
Modern carding is about throughput. Bots send repeated authorization attempts at speed, looking for cards that are still active and usable. That turns your payment surface into a validation target, not just a purchase target. The merchant sees the fallout as a stream of failed auths, tiny test charges, and suspicious request patterns that don't match normal buyer behavior.
The anti-bot verification guidance is relevant here because it focuses on stopping automated abuse before it reaches the action that matters. The core lesson is simple. If the request is automated, you want to catch it before your payment system starts acting like a validator.
Carding is old fraud with new automation. The attacker's advantage now is speed, not creativity.
How a Carding Attack Actually Works
The attack usually starts with stolen card data traded on forums, marketplaces, or automated shops. Once the attacker has a list, they don't always spend it immediately. They test it first, because a live card is worth more than dead data.
The validation loop
The bot submits the stolen card details to a merchant checkout or payment API. If the first request fails, the bot rotates to the next card, the next site, or the next variation of billing data. If it passes, the attacker has confirmed the card can still authorize, which raises its value and opens the door to larger fraud.
Here's the practical sequence in plain English:
- Acquire stolen data. The attacker gets a card number, expiry date, CVV, and often billing details.
- Test small transactions. The bot starts with a low-friction authorization or tiny purchase.
- Check for a pass. A valid authorization means the card is still active.
- Scale the abuse. The attacker can use the card for larger purchases or resell the validated record.
- Cash out. The value is extracted through purchases, resale, or related fraud paths.
Why velocity matters
The economics depend on how fast the attacker can test. A fast validation workflow lets them sort good cards from bad cards before the merchant or issuer notices a pattern. That is why a merchant may see a cluster of tiny authorizations, repeated retries, or a spike in failed attempts across one endpoint rather than a single obvious theft.
The Carding overview from Human Security points out a useful nuance, carding is increasingly described as automated testing across many sites, not just theft and spending. That framing matches what defenders see in logs, where the abuse looks like credential validation against checkout and payment APIs.
What the merchant actually sees
- Bursty auth attempts: many tries in a short window.
- Low-value probes: small or repeated validation purchases.
- Mixed surfaces: checkout, registration, and login forms all get hit.
- Disposable success paths: once a card passes, the bot moves on quickly.
If your logs show those patterns, the attacker is probably testing for live payment instruments, not browsing like a real customer.
Carding Versus Account Takeover and Card Stuffing
A checkout page can attract more than one kind of abuse, so the label matters. A merchant may see a bot enter stolen card data, try login credentials, or reuse payment details across many sites, and each pattern points to a different goal.
| Abuse pattern | What is stolen or tested | Primary target surface | What the attacker gains |
|---|---|---|---|
| Carding | Stolen card details, then authorization responses | Checkout and payment APIs | Validated cards, unauthorized purchases, resale value |
| Account takeover | Login credentials or session access | Login flows and user accounts | Control of an existing customer account |
| Credit card stuffing | Card data or card credentials reused at scale | Checkout and payment forms | Approval of payment attempts across many sites |
| Gift card cashout | Payment value, then gift card redemption paths | Gift card purchase or redemption flows | Spendable store credit or resaleable gift cards |
Carding is the pattern behind live card testing. The attacker submits stolen card details, watches for an approval response, and uses that result to separate working cards from dead ones. Account takeover is different because the target is the customer account itself, not the payment instrument. Gift card cashout is different again, because the attacker is trying to convert approved payment into a redeemable balance.
The overlap is what makes this messy in practice. One bot campaign can test cards, probe logins, and look for gift card abuse in the same run. A product team that only tags the traffic as “fraud” can miss the path the bot followed, which matters when the fix is tied to checkout rules, login controls, or gift card limits.
The supply side helps explain why validation speed matters. As noted earlier, coverage of a Human Security summary said Recorded Future reported more than 142 million stolen card records advertised on dark web marketplaces in 2025, down from 2024. That points to a market where stolen card inventory may be changing, while bot-driven validation remains fast enough to compensate. Attackers can answer that shift with quicker testing, bot evasion, or more selective merchant targeting.
Where Carding Hits and How Attackers Monetize
Checkout is the classic target, but it isn't the only one. Attackers also hit registrations and logins, because those forms can help them validate whether a card, a browser, or a session is worth using. The shared pattern is scale, not the business purpose of the page.
The monetization path
A validated card can be monetized in more than one way. The attacker may make unauthorized purchases, resell the verified record, or convert value through gift cards and related cashout paths. The merchant sees the downstream cost as chargebacks, failed authorizations, operational noise, and payment-provider friction.
Most victims don't notice right away because they still hold the physical card. That's the part many teams miss. The card isn't stolen from the wallet, so the fraud can sit below the victim's awareness until a statement, alert, or issuer review surfaces it.
The merchant-side signals that matter
If your payment team is looking for carding, focus on the shape of the traffic:
- Repeated validation attempts against the same or similar checkout fields.
- Signup or login probes that accompany payment tests.
- Small or odd-value purchases that look like proof-of-life checks.
- Authentication mismatch between a normal customer session and a machine-driven request stream.
Payment-industry guidance still starts with AVS and CVV checks. PayPal notes that these are primary defenses, and that CVV is the card's 3- or 4-digit security number verified during authorization, as described in PayPal's carding defense guidance. Those checks help, but they don't solve the automation problem on their own.
For merchants, that's the operational lesson. You want to reduce the number of cheap validation attempts that ever reach your payment processor. The checkout use case for MANDATE fits that same idea, because it's about protecting high-value actions from automated abuse before they become expensive to process.
Defenses Merchants Can Apply Today
Carding defenses work best as layers, not as a single gate. If you rely only on payment declines, you'll still absorb the cost of the attempt. If you rely only on puzzles, you'll create friction for real buyers and still miss some automation.
Start with the controls closest to money movement
AVS and CVV checks should be enabled where your payment flow supports them. They won't stop every bad actor, but they raise the cost of a failed test and give your risk stack better signals. If your processor exposes more granular authorization telemetry, keep it.
Velocity monitoring matters just as much. Track repeated authorization attempts, repeated declines, and strange bursts from the same IP, device, account, or card family. The point isn't to block every retry, it's to separate real customer friction from machine-driven probing.
Protect the request before it becomes a payment
Google's reCAPTCHA guidance recommends protecting payment workflows and validating that tokens are fresh and above a configured score threshold before allowing a transaction to proceed, as noted in Google's reCAPTCHA best practices. That's useful, but not every team wants visible puzzles on a checkout page.
Invisible or background verification is the cleaner trade-off for many flows. It evaluates browser or behavioral signals in the background, then decides whether to allow, flag, or challenge the request, while still relying on server-side verification of a short-lived token or risk signal before acceptance, as described in this overview of invisible challenge-response verification.
Trade-off: puzzles are obvious to attackers and annoying to users, background verification is quieter but depends on good server-side enforcement and tuning.
Where MANDATE fits
MANDATE is one option for protecting important website actions from automated abuse without CAPTCHAs. It collects browser proof in the client, verifies it server-side, and supports Observe mode so you can review decisions before enforcing them. That makes it useful when you want to protect checkout, signup, or login flows without turning the experience into a puzzle gate.
A practical rollout checklist
- Verification at checkout: protect purchase and payment endpoints first.
- Verification at signup and login: stop the same bot fleet from pivoting across surfaces.
- Fresh tokens only: reject stale proof or replayed requests.
- Observe before enforce: watch real traffic before blocking it.
- Tune by surface: checkout, registration, and login rarely need identical thresholds.
The e-commerce fraud detection resource is a good companion if your team is deciding where to place controls in the stack. The right answer is usually layered and boring, which is exactly what you want in fraud defense.
What to Remember About Carding
Carding is no longer just stolen card data being tried by hand. It's a bot-driven validation workflow against checkout, signup, and payment APIs, and the defender's job is to make that workflow expensive, noisy, and unreliable.
Start by auditing authorization logs for validation bursts, confirming your AVS and CVV handling, and protecting the endpoints that move money or create accounts. If you're planning a new control, use observation first, then enforce once you've tuned the false positives.
Layered defenses don't eliminate exposure, but they do reduce it in ways you can measure in your own logs. That's the right mental model for a product team that has to keep legitimate buyers moving while blocking automation.
MANDATE helps teams protect checkout, signup, login, and other high-value actions from automated abuse without CAPTCHAs. If you're tightening your fraud stack around carding and related bot traffic, visit MANDATE to see how browser proof, server-side verification, and Observe mode fit into a staged rollout.