Carding: stolen cards tested on your checkout

Names and definitions follow the OWASP Automated Threats to Web Applications project.

1. Card data is stolen or bought in bulk. From breaches, skimming or phishing; much of it no longer works.
2. A bot finds a form that checks cards. Ideally one that answers quickly and accepts small amounts.
3. It submits cards one after another, spread across addresses, sessions and accounts to look like many shoppers.
4. Working cards are kept, then resold or used for purchases elsewhere.

Card cracking runs the same loop for a single card number, trying expiry dates or security codes until the processor accepts one.

Gift card balances are checked by number, sometimes with a short PIN. A bot that enumerates numbers on the balance-check page finds cards with value and spends them before their owners do. The defence is the same as for carding: make each check cost something and refuse fast repeated checks.

Stored balances in accounts attract a related attack, account takeover, where the attacker signs in instead of guessing a card.

• A spike in declined payments, especially for small amounts.
• Many different cards from one session, device or address range.
• New accounts that try a card and never return.
• Payments with mismatched billing details and odd hours for your audience.
• A warning from your payment processor, often the first signal a merchant sees.

Each attempt costs a transaction or authorisation fee, whether the card works or not. Cards that work are later reported as stolen, and the resulting chargebacks land on the merchant whose form was used for the test.

Processors watch decline and chargeback rates. A carding run can push both up within hours, which can lead to higher fees, holds on payouts or the loss of a merchant account. That is why carding is worth stopping even when no stolen goods ever leave the shop.

1. Limit attempts per session, account and card. A real shopper rarely needs more than a few tries.
2. Add friction only where the risk is. A check before payment on unusual sessions, not on every visitor; see CAPTCHA for the trade-offs.
3. Use the processor's fraud tools. Address and security code checks, and strong customer authentication where available.
4. Raise the minimum for anonymous payments, such as donations, which carders favour.
5. Watch declines as a metric, with an alert when they rise.

Blocking by address helps little, because carding traffic is spread across many; the useful limits are on what the request does, not where it comes from.