Card Testing: The Smallest Charge, the Loudest Signal
Card testing (also commonly called carding) is the earliest link in the fraud chain: once a batch of card numbers of unknown origin is in hand, the first step is to spend the least possible effort figuring out which ones are live.
It uses the exact same action as legitimate account verification—small or zero-amount authorizations. The real difference lies in four dimensions:
| Normal account verification | Card testing | |
|---|---|---|
| Initiated by | Merchants with a genuine business relationship | Unauthorized parties in possession of the card data |
| Frequency | A small number of attempts per card | Many cards, many attempts, in a short period |
| Amount | Relevant to the transaction, not deliberately small | Deliberately set to the minimum |
| Relation to user behavior | In sync with a card-binding action | Unrelated to any user action |
| Purpose | To confirm the card can be charged later | To screen for live cards and use them in fraud |
The difference is not in the action itself but in frequency and context—this is exactly what risk control bases its decisions on.
On the cardholder's side, it looks like this: a few small transactions you never made suddenly appear on your card, amounts small enough to be easily overlooked, with no clear source. This is exactly why it deliberately picks small amounts—small, because it doesn't want you to notice.
Once you spot it, there is only one correct response: deactivate the card and get a new card number immediately—don't wait for a real charge to go through. The account verification page covers how these three differ: see Account verification, zero-amount authorizations and billing descriptors.
Enumeration: It's Not About Randomly Guessing Card Numbers
Enumeration is often described as "guessing card numbers," but that description isn't accurate. A 16-digit card number is not a random string—it is constrained in three ways:
- It must start with a valid BIN: the first 6 digits (extendable to 8) must fall within an assigned range, which dramatically shrinks the space of possible numbers;
- The last digit is a check digit: it is derived from an algorithm, so a casually invented combination gets rejected before submission;
- Beyond the card number, you also need the expiry date and the security code: neither of these has a check digit, so they can only be tried by guessing.
So enumeration in practice is three things: mass-testing the trailing digits within the same BIN range, trying expiry date and security code combinations against known card numbers, and piecing together fragments leaked from different sources into a single card.
ATO: The Card Isn't Lost—Your Account Is
ATO (account takeover) is different from the previous two: the card hasn't been lost—the account has.
| Card testing / Enumeration | ATO | |
|---|---|---|
| Target | The card number itself | The card saved in a merchant or platform account |
| Method | Mass probing | Credential stuffing, phishing, interception of one-time verification codes |
| What the cardholder sees | Unknown small transactions on the card | Orders in the account that the cardholder never placed |
| Primary defense | Issuing side and acquiring side | Merchant and platform (this is where two-factor authentication lives) |
The key point in the right-hand column: the account taker doesn't need to obtain the card number to place an order.
Why it is dangerous: many platforms already have your card details and billing address stored, so when an account taker operates in your name, none of the payment elements need to be re-entered.
The two most direct things you can do personally sound like common sense, but they are exactly what blocks the "credential stuffing" path: don't reuse the same password across platforms, and enable two-factor authentication. Intercepted SMS and email verification codes are another path, which is why two-factor authentication shouldn't rely on SMS alone.
The Four Types of Signals Risk Control Watches
A risk control system doesn't judge whether "this card is good or bad"—it judges whether this transaction looks like what it should. The signals roughly fall into four categories:
| Signal category | What it looks at | Typical example |
|---|---|---|
| Speed and frequency | Number of attempts from the same card / IP / device within a short period | Dozens of small authorizations within minutes |
| Geography and network | IP origin, whether traffic comes from a proxy or a data center | Billing address in one place, requests coming from another continent |
| Device and fingerprint | Device identifiers, browser characteristics, whether it's a device seen before | A large charge from a device never seen before |
| Behavioral deviation | How much the amount, merchant category, and timing deviate from the historical baseline | Long-running small subscriptions that suddenly jump to one large charge |
Looked at individually, any one of these could be a coincidence. Risk control looks at how they stack up.
Caught in the Crossfire: Why Normal Behavior Gets Blocked Too
Normal behavior running into these signals is common—especially these five situations:
- A new card goes straight to a large charge: with no historical baseline to compare against, it naturally looks abnormal;
- A subscription charge lands in the middle of the night: the timing is set by the merchant and the card network, not by your daily routine;
- Cross-time-zone and cross-border activity: you're dealing with a merchant on another continent from UTC+8, so geographic signals inherently don't align;
- Using a proxy or a remote environment: your exit IP falls within a data-center range;
- Switching between multiple devices: logging in alternately from phone and computer means the device fingerprint looks new every time.
The right response after being blocked is not to try again with a different setup—that only makes the speed and device signals messier. What you can do is align your behavior with the card's real purpose: start with small amounts before moving to larger ones, and complete a few normal transactions in the same network environment first, so a baseline can establish itself.
Beyond the Signals: Three Things You Can Do
Use one card for one purpose
A card with a stable purpose finds it easier to build a clean normal baseline. If the same card subscribes to a service today, runs ads tomorrow, and buys physical goods the day after, the behavioral profile itself is messy.
Judge insufficient balance and risk-control declines separately
The two can look identical, but the responses are completely different: for insufficient balance, just top up; for a risk-control decline, retrying with a different setup only makes things worse. To tell them apart, see What to Do After a Declined Payment.
Turn on transaction notifications and keep records
Replace the card the moment an unknown small transaction appears. For how to keep failure records, see Checking failed payment records for Claude and ChatGPT—it's most useful when manual intervention is needed.
To be clear: we don't promise any charge approval rate, and we don't offer ways to bypass merchant or card-network risk control. Risk-control decisions are made independently by the issuing side, the card network, and the merchant, and none of them can or should guarantee the outcome. What we can be responsible for is keeping a card's purpose clear and its status queryable; for the security rules covering accounts and funds, see Security and Compliance.
The three things you can do beyond the signals are all laid out. The real practice is using the card in the right scenario: first choose a card type, then issue a card.
FAQ
What is card testing?
It means using small or zero-amount authorizations to mass-test which card numbers are valid. It's the earliest link in the fraud chain. It uses the same actions as legitimate account verification—the difference lies in frequency and context.
Why are card-testing amounts so small?
To avoid being noticed by the cardholder and to lower the cost if discovered. That small amount is therefore a key signal for recognizing it: a flood of small authorizations in a short period is rarely legitimate business.
What should I do if unknown small transactions appear on my card?
Deactivate the card and get a new card number immediately—don't wait for a real charge to occur. Small amounts at high frequency are a hallmark of card testing, and it means the card number may have been compromised.
Is enumeration just guessing card numbers?
Not entirely. A card number must start with a valid BIN and end with a check digit, so the real probing is concentrated beyond the card number itself: mass-testing the trailing digits within a BIN range, or trying expiry date and security code combinations against known card numbers.
How risky is it if only the card number leaks, without the security code?
Relatively limited. Many card-not-present scenarios require the card number, expiry date, and security code all together to complete a transaction—which is exactly why it's recommended to record the card number and the security code separately.
What's the difference between ATO and card fraud?
Card fraud uses the card itself; ATO takes over the account. The account usually already has card details and addresses saved, so the account taker can place orders without ever getting hold of the card number.
What signals does risk control mainly look at?
Four categories: speed and frequency, geography and network, device and fingerprint, and behavioral deviation. A single signal rarely tells the whole story on its own—risk control looks at how they stack up.
Why do normal transactions also get blocked by risk control?
Because a first large charge on a new card, cross-time-zone activity, scheduled charges in the middle of the night, using a proxy, and switching between devices all trip these signals. Aligning the card's purpose with its scenario is the right fix; retrying with a different setup only muddies the signals further.
Is there any way to guarantee a transaction won't be blocked by risk control?
No. Risk-control decisions are made independently by the issuing side, the card network, and the merchant, and none of them can promise an outcome. What you can do is keep the card's purpose single, start small before going large, and use it consistently within the same network environment.
Got the idea in a few minutes? Go open a card
Cards start at $1, no monthly fee; account top-up is $0 with a $20 minimum per deposit. See the pricing page for full details.