Carding Attack: What It Is and How to Detect the Automation Behind It

TL;DR: carding attack browser-layer defense

• The hidden cost: Fraud teams usually count carding losses as the successful fraudulent transactions, but a single attack that produces 5,000 declines and 50 approvals can trigger five-figure gateway fees before the very first chargeback ever arrives.
• What cside does: cside runs on the checkout, captures device fingerprint plus behavioral and script signals per session, and flags card fields filled by paste or script, sub-second time between load and submit, and repeat submissions across cards from one device.
• When it's urgent: If your acquirer opens a conversation about the Excessive Chargeback Program or the Fraud Monitoring Program, you have days rather than months to add browser-layer signal before the next wave lands from a rotated IP set.

Short on time? See cside's chargeback-evidence tooling. It covers everything below in one deployment.

A carding attack is what happens when someone with a batch of card numbers wants to know which ones still work. They point automation at a merchant's checkout and hammer it with low-value transactions until the good numbers surface. Every accepted transaction gets flagged for resale or larger fraud downstream. Every declined transaction still costs the merchant a gateway fee.

What a carding attack looks like

The core loop is simple. An attacker loads a list of card numbers into a script, points that script at a checkout, and waits for approvals. The card numbers come from a data breach, dark-web purchase, or algorithmic generation inside a valid BIN range. The checkouts get chosen because they are cheap to attack: guest checkout, weak bot protection, low minimum transaction amount.

Two variants matter operationally:

• Card testing on a legitimate merchant, where the attacker only wants to validate cards and does not care about the merchant's product
• Carding for goods where the attacker uses validated cards to buy resellable items such as gift cards, electronics, and high-liquidity SKUs

The first pattern floods your checkout with tiny transactions. The second uses your inventory as a laundering mechanism. When the automation is AI-driven rather than scripted, the defenses are the same but the attack looks more human. See our guide on how to block AI credit card testing agents.

The cost is not just the fraud

Merchants often underestimate the total damage from carding because they only count successful fraudulent transactions. The real cost stack is:

A carding attack that produces 5,000 declines and 50 approvals can trigger five-figure gateway fees before the first chargeback arrives. This is why chargeback indemnification with the new VAMP ratio is not a substitute for stopping the attack at the browser.

How to detect carding from the browser layer

Server-side fraud tools see the transaction stream. That is late. The attack has a much earlier signature at the browser layer, and it is nearly identical every time:

• Session opened, checkout loaded, no organic browsing beforehand
• Card fields filled by paste or by script, not by keystrokes
• No cursor movement between fields
• Sub-second time between page load and submit
• Repeated submissions from the same device fingerprint with different card numbers
• Approve-to-decline ratio inverted from normal (usually 90% or higher declines)

A single one of those signals is not enough. Two or three together, sustained across a session, is a carding attack. This is the same signal profile that catches BIN attacks and other enumeration abuse.

How to stop card testing fraud: the controls stack

Card testing fraud and carding are the same attack, so the defense is the same. Anti-carding controls fall into three tiers:

1. Reduce the reward. Raise the minimum transaction amount. Restrict guest checkout for card categories most-used in carding (gift cards, high-liquidity SKUs). Require account creation for higher-risk transactions.
2. Add friction to automation. Behavioral scoring, device fingerprinting, and browser-layer velocity limits catch the automation without punishing real customers.
3. Rate-limit at the gateway. Not a first-line defense, but useful as backstop. Attackers rotate IPs cheaply, so IP-based rate limits alone are not enough.

3-D Secure helps for some card types by shifting liability to the issuer, but it does not reduce the volume of your checkout traffic or your gateway fees. Behavioral and device signals reduce both.

Where cside fits

cside runs on the checkout page and captures device fingerprint, behavioral signals, and script activity for every session. When a session profile matches carding (automated submission, no human interaction, repeated attempts across cards), cside can flag the session before the transaction submits.

The same device fingerprint keeps working after the attack. Every real customer transaction gets identified and remembered, so returning customers do not get friction and fresh devices attempting known-good card numbers get flagged. When the attackers get through, device fingerprinting for compelling chargeback evidence uses the same signal as dispute proof.

Post-attack triage

If your checkout has already been hit by a carding attack, three actions in the first 72 hours contain the damage:

1. Turn on browser-layer session tracking on the checkout so you can identify sessions from the same attacker if they return.
2. Pull the list of transactions that succeeded during the attack window and mark them for higher-risk chargeback monitoring for the next 90 days.
3. Talk to your acquirer. Some will offer to review the attack window and reduce the excessive-transaction ratio if you can prove it was an attack rather than normal traffic.

The attack will likely return within days on a different IP set. The controls you add in that window are the ones that stop the next wave.