.svg)
OWASP Deep Dive Series — Part 2 of 10
OAT-001, Carding, is the mass automated testing of stolen payment card data against a merchant's payment flow to identify which cards are still valid. The cards aren't generated. They're sourced from breaches, skimmed from compromised point-of-sale systems, or purchased in bulk from criminal marketplaces, then tested at scale to separate live cards from dead ones. When a card clears authorization, the attacker knows it's worth using or reselling.
This is distinct from card cracking, where partial data like a missing expiry date or CVV is brute-forced. In carding, the attacker already has full card details. They just don't know which ones still work. A stolen dataset might contain hundreds of thousands of card numbers, but only a fraction will authorize. Carding is the sorting step.
The business impact extends beyond fraud losses on successful transactions. Every failed authorization attempt generates a processing fee. A campaign testing 50,000 cards against your checkout can rack up thousands of dollars in processor charges before a single fraudulent purchase is made. Chargeback rates climb. Payment processors flag your merchant account. Acquiring banks start asking questions. In severe cases, your processing agreement gets renegotiated or terminated. The cards being tested may never be used on your site again, but the damage to your payment infrastructure is already done.
How the attack moves through the stack
The attacker starts with a card list. Stolen PANs, expiry dates, CVVs, sometimes cardholder names and billing addresses. The list is loaded into a carding tool or custom script and distributed across a proxy network, typically residential IPs that blend in with normal consumer traffic. Each address submits only a handful of transactions, staying well below any velocity threshold.
Each request targets your payment flow. It might be a full checkout with a low-value item, a gift card purchase, a donation form, or a card-on-file addition. The payload is structurally correct: valid card format, realistic billing details, proper field lengths. Many carding operations use small transaction amounts, often under $1, specifically to avoid fraud detection thresholds. Some don't even complete a purchase. If your site lets users save a payment method to their account, the card validation call during the save is enough to confirm whether the card is live.
A single request looks like a normal customer entering their payment information and getting declined. Failed transactions happen constantly in e-commerce. Typos, expired cards, insufficient funds. There's nothing anomalous about one declined payment.
The pattern only becomes visible at scale. Hundreds of failed authorizations across unrelated sessions, compressed into a narrow time window, using cards with no prior history on your site, often targeting the lowest-friction payment path on the site. The requests originate from sessions with no browsing behavior, no cart activity, no product views before the payment attempt. Detection depends on correlating that activity across requests and sessions, not evaluating any single one.
What happens when the alert fires
Your fraud detection tooling or bot vendor picks up the activity. Authorization failure spikes. Velocity anomalies across sessions. Cards being tested against your cheapest SKU or your gift card endpoint. The signal is unambiguous.
Now you need to act on it.
The detection platform surfaces the finding. Your security team reviews it. Mass card testing, high confidence bot, thousands of attempts spanning hundreds of sessions. Nobody disputes the conclusion. The next step is turning that finding into something that actually stops traffic.
For many teams, the WAF is the only place where blocking happens. So someone builds a rule. Maybe a rate limit on the payment endpoint. Maybe a block on sessions that hit checkout without any prior page views. Maybe a geo-restriction targeting the countries dominating the current campaign.
None of these capture what the detection tooling actually identified. The upstream system saw payment authorization velocity across sessions with no browsing history, using cards with no prior relationship to your platform, targeting a single low-value SKU. You can't translate that into a WAF policy. The WAF has no visibility into session depth. It doesn't see the payment response. It can't correlate behavior across transactions. Each request is evaluated on its own merits, without the surrounding context that made the detection possible in the first place.
So the rate limit catches the customer buying five gift cards for their team. The session-depth rule blocks the returning customer who bookmarked the checkout page. The geo-restriction locks out legitimate international buyers. Meanwhile, the attacker adjusts the proxy pool, rotates session tokens, and spreads the campaign across three product pages instead of one. The attack resumes within the hour.
Many teams end up here. The rule is either too aggressive and generates false positives in the payment flow, which is the one place you absolutely cannot afford them, or too narrow and evaded immediately. The third option, which is the most common outcome, is that the team dials the rule back and revisits when the next campaign arrives. The detection was right. The enforcement never landed.
What we see when detection and enforcement share a request path
When detection and enforcement operate in the same layer, inside the application's request path, the operational dynamic shifts.
At this layer, you have access to the signals that actually reveal carding. You can correlate authorization attempts across sessions and track payment velocity as it happens. You can observe whether a session navigated to a product page, added an item to a cart, and proceeded to checkout, or jumped directly to the payment endpoint with no upstream interaction. You can track whether the billing address on the card matches any prior address associated with the session or account. You can see the authorization response, not just the request, and use decline patterns as a live enforcement signal.
Evaluation happens inline, while the request is in flight. The same system that assembles the behavioral picture is the one deciding whether to allow, challenge, or block the request. There's no detection alert waiting to be reinterpreted as a WAF rule. No gap between the tool that sees the pattern and the tool that acts on it.
Before any policy takes effect, shadow mode evaluates it against real production traffic. Every request is scored, every decision is recorded, and nothing is enforced. You get full visibility into what would have been blocked, along with the complete evidence chain: which behavioral signals contributed, what thresholds were met, and which sessions exhibited the carding pattern. Once the results align with your expectations, you promote to active enforcement.
The policy is managed as code, versioned and deployed through your existing CI/CD pipeline. You can scope it to your payment endpoints, validate it in shadow mode against actual checkout traffic, audit the decisions against real transaction data, and roll it back in seconds if anything looks off. Building a carding detection policy follows the same workflow as shipping application logic, because that's what it is.
The improvement isn't in detection quality. Most fraud and bot vendors already identify carding accurately. The improvement is that detection and enforcement are co-located in the request path, so the signal retains its full fidelity through the enforcement decision. Nothing is lost in translation between tools.
See what you would block before you block it.
Impart closes the enforcement gap for carding and all 21 OWASP automated threats. Shadow mode against live traffic. Full decision evidence. Enforcement when you're ready.
OWASP Deep Dive Series
This post is part of a 10-part series examining how OWASP automated threats expose the gap between detection and enforcement, and what changes when both move into the application's request path.