Card testing is a fraud attack in which criminals submit large numbers of small or zero-value authorizations through a merchant’s checkout or payment API to learn which stolen or generated card numbers are still valid. In e-commerce payment security, it is treated as a distinct threat because the attacker is not trying to buy anything from the targeted store: the store is only a free validation service, and the confirmed cards are later sold or used for larger purchases elsewhere.
The attack is also called a BIN attack when the criminal starts from a known Bank Identification Number and generates the remaining digits. Both variants leave the merchant with authorization fees, chargebacks, network penalties and a damaged risk reputation, even when no goods are shipped.
How a card testing attack works
A card testing attack follows a predictable pipeline from acquisition to monetization. The attacker obtains card data from a breach, a phishing kit or a marketplace, or generates candidate numbers that pass the Luhn checksum. The candidates are then pushed through a weakly protected payment endpoint, usually by scripts or botnets that rotate IP addresses, devices and email addresses.
Each attempt produces an issuer response code. An approval, or a decline that reveals a specific reason such as an incorrect CVV, tells the attacker that the account number exists. The attacker records the result, discards dead numbers and retries live numbers to guess missing fields such as the expiry date or the security code.
The table below shows the typical stages and the signal each stage leaves for the merchant.
| Stage | Attacker activity | Signal visible to the merchant |
|---|---|---|
| Acquisition | Buys dumps or generates numbers from a BIN | None at this stage |
| Endpoint discovery | Finds a checkout, donation form or API with weak controls | Unusual traffic to low-value pages |
| Validation burst | Sends hundreds or thousands of attempts | Spike in authorizations and declines |
| Field enumeration | Cycles expiry dates and CVV values | Repeated attempts on one card number |
| Monetization | Sells or uses confirmed cards elsewhere | Later chargebacks on approved tests |
Variants and attack surfaces
Card testing appears in several forms that differ in how card data is obtained and which merchant surface is abused. Recognizing the variant helps the merchant choose the right control instead of applying generic friction to every customer.
| Variant | Typical method | Preferred target |
|---|---|---|
| Stolen list validation | Checks a purchased list of complete card records | Low-price checkouts |
| BIN attack | Generates sequential numbers from one issuer range | Endpoints that return detailed decline codes |
| Enumeration attack | Varies expiry and CVV for one known number | APIs without per-card attempt limits |
| Card-on-file abuse | Adds cards to accounts as stored payment methods | Wallets and account pages |
| Zero-dollar verification abuse | Uses account verification requests without a charge | Subscription sign-up flows |
Attackers favor donation pages, free trials, gift card stores and digital goods because these flows accept small amounts, need no shipping address and often lack the screening applied to physical orders. A publicly exposed payment intent or tokenization endpoint is equally attractive, because it can be called directly without loading the storefront.
Card testing compared with related fraud types
Card testing is a subset of card-not-present fraud, but its goals and indicators differ from neighboring threats in payment security. The comparison below helps teams route alerts to the right response.
| Fraud type | Main goal | Typical transaction value | Key indicator |
|---|---|---|---|
| Card testing | Confirm that card data works | Very low or zero | Bursts of declines across many cards |
| Card-not-present fraud | Obtain goods or services | Medium to high | Mismatched billing and shipping data |
| Friendly fraud | Reverse a legitimate purchase | Any value | Disputes from known customers |
| Refund fraud | Extract refunds without returning goods | Medium to high | Abnormal return patterns |
The key difference is that the tested merchant rarely loses inventory. The loss comes from per-attempt processing fees, chargebacks on the few approved tests, and the risk that the acquirer or the card networks place the merchant in an excessive decline or fraud monitoring program.
Detection signals and controls
Effective defense relies on layered controls that raise the cost of each attempt while keeping checkout smooth for real customers. No single control is sufficient, because attackers adapt their rate, devices and amounts once one barrier appears.
- Velocity checks limit attempts per card, per IP address, per device fingerprint and per account within a time window.
- Decline ratio monitoring alerts when declines rise sharply above the normal baseline for the checkout.
- Bot detection and challenges add friction only to suspicious sessions, not to every visitor.
- Fraud risk scoring combines device, network and behavioral signals into one decision.
- Generic decline messages stop the checkout from revealing whether the CVV or the expiry date was wrong.
The following decision table connects common symptoms with a proportionate response.
| Symptom | Likely cause | Recommended response |
|---|---|---|
| Many declines on one card number | Field enumeration | Block the card after a few failures |
| Many cards from one IP range | Scripted validation burst | Rate-limit and challenge the source |
| Small authorizations on a donation page | Weakly protected low-value form | Add bot checks and minimum amounts |
| Direct calls to the payment API | Exposed client-side keys or endpoints | Require server-side session validation |
| Sudden rise in card additions to accounts | Card-on-file abuse | Verify accounts before saving cards |
Mistakes that make merchants vulnerable
Most successful card testing campaigns exploit configuration gaps rather than sophisticated technology. A frequent mistake is protecting the main checkout while leaving a secondary flow, such as a gift card balance page or a legacy API version, without the same rules.
Another error is blocking only by IP address, which residential proxy networks defeat easily. Merchants also underestimate the cost of retrying declined authorizations automatically, which multiplies fees during an attack. Finally, teams sometimes refund approved test transactions silently, which leaves the compromised cards active and invites a repeat attack instead of reporting them through the acquirer.
Put simply
Imagine a thief with a box of keys who does not know which ones still open a door. Instead of risking a break-in, the thief tries each key quietly on an unlocked shed in your garden. Card testing works the same way: criminals use an online store’s payment form to see which stolen cards still work, then use the good ones somewhere else.
The store loses money even though nothing is stolen from its shelves, because every attempt costs a fee and the bank starts to see the store as risky. The main takeaway is that many small, odd payments are a warning sign, not harmless noise.
In practice
A small nonprofit accepts online donations with a minimum gift of one dollar. Late on a Saturday night, its payment dashboard shows about 4,000 donation attempts in two hours, almost all for one or two dollars, from hundreds of email addresses and rotating IP addresses. More than 90 percent are declined, and the few approvals come from cards issued in many countries.
The team pauses the donation form, then enables a bot challenge for suspicious sessions, a limit of three attempts per card per hour and a five-dollar minimum. It reports the approved test cards to its acquirer and refunds them. The attack stops within an hour of the changes, and the organization avoids a larger fee bill and a decline-ratio warning from its payment provider.