Card testing (carding) in Retail & e-commerce

How the attack works

1. The operator finds a checkout that accepts a low-value basket, a gift-card purchase or another small payment. Guest checkout is attractive because a new customer account may not be required for each authorisation attempt.
2. An automated client submits stolen card details to the payment flow and observes whether the attempt advances or fails. The objective is to establish which cards can be used elsewhere, not necessarily to receive the product in the basket.
3. The operator changes card details between attempts and distributes requests across devices or proxy addresses. A small amount and a fresh-looking request can make each individual attempt appear less urgent than the combined payment activity.
4. Cards that appear usable are retained for further fraud. Your business is left with the authorisation traffic, abandoned baskets and any disputed orders that were completed during testing, even when most attempts did not produce a sale.

Why it gets through

Payment authorisation occurs after the request has already reached your payment flow. A declined card can still consume processing work and incur fees under your payment agreement. Declines are evidence of the problem, but they are not a control over the traffic generating it.

An account-based purchase limit has limited reach when guest checkout is available. An IP limit has a similar weakness when the operator distributes attempts across residential proxies. Neither necessarily joins changing cards to the client that keeps presenting them.

Rules focused on basket value can miss testing precisely because the attempted amount is small. Signature rules can also lose relevance as the automated client changes. Reviewing only completed orders leaves out the failed attempts that reveal the scale and continuity of the campaign.

Authorisation fees and decline rate are the first metrics to examine. The payment team needs to separate failed genuine purchases from repeated tests, because both can appear in the same gateway reporting. Total checkout requests alone do not explain the difference.

Dispute rate captures another part of the damage when a test becomes a completed fraudulent purchase. Fulfilment, refund handling and support can follow even though the original purpose was simply to validate a card. The commercial loss extends beyond the value of the initial basket.

Acquirer scrutiny can increase when repeated testing changes the payment profile of the business. Your team may need to explain unusual authorisation activity and review controls. That takes time away from payment optimisation and can make routine checkout changes harder to assess.