During our early access program, one of our marketplace customers lost $40,000 to card testing in a single week before we helped them close the pattern. What follows is a reconstruction of the attack, what their existing controls missed, and what the Riskgrove scoring layer caught.
We are sharing this because the details are instructive. Card testing attacks on marketplaces have a specific anatomy that differs from card testing on direct merchants -- the marketplace structure actually creates attack surface that a standard rules engine is not configured to see.
What card testing looks like on a marketplace
Card testing is the process of verifying that a stolen or generated card number is valid and has available balance before using it for larger-value fraud. On a direct merchant, the typical pattern is a small transaction -- a $1 or $2 purchase -- that validates the card without triggering amount-based fraud rules. The attacker tests one card at a time, rotating through a list.
On a marketplace, the attack surface is structurally different and often more permissive. Marketplaces frequently have low-priced digital goods, small nominal fees, or donation-like payment flows that make sub-$5 transactions appear legitimate. More importantly, many marketplace fraud systems are configured to look at per-seller fraud rates or per-buyer fraud rates, not cross-entity patterns. An attacker who distributes card tests across multiple sellers or multiple buyer accounts can stay below any per-entity threshold indefinitely.
In the case we are describing, the attacker created 47 guest checkout sessions across 12 different sellers over 5 days. Each session tested between 8 and 15 cards in quick succession -- the "quick succession" part was what the rules engine was not measuring. The cards were spread across sessions and sellers so that no single seller triggered a high-card-volume alert, and no single IP address appeared more than 4 times. The total transaction count was 612, of which 487 resulted in successful authorizations before the attacker ran larger purchases on the validated cards.
What the existing rules engine caught
The marketplace's existing fraud controls flagged 31 of the 612 transactions -- about 5% of the attack. The flagged transactions had in common that they came from an IP address that had been declined at least twice in the same day, which triggered a basic velocity rule. The remaining 95% of the testing went undetected because:
- The per-card velocity check measured card attempts per hour. The attacker distributed testing across 5 days, staying under the hourly threshold.
- The IP-level velocity check measured total transactions per IP, not decline rate per IP. The attacker's decline rate was about 30% but the total transaction volume per IP was low.
- There was no cross-session device fingerprint check. The 47 checkout sessions came from approximately 8 underlying device fingerprints -- a pattern that was only visible when you looked across all sessions simultaneously.
- There was no cross-seller card velocity check. The system checked how many times a given card had been used at each individual seller, not how many sellers a given card had appeared at across the platform.
What the device fingerprint graph showed
When we ingested the transaction data retrospectively and ran it through Riskgrove's behavioral graph model, the attack was clearly visible. The device fingerprint graph showed 8 distinct fingerprints, each appearing across between 4 and 9 seller sessions. That is a distribution that has no plausible legitimate explanation -- real buyers do not shop from the same device at 8 distinct marketplace sellers in 5 days, testing 8-15 cards per session.
The cross-seller card velocity signal was equally clear. Of the 612 transactions, 89% of the cards had been attempted at more than one seller. In a legitimate card-on-file scenario, a stored card is used at one marketplace seller (the one where the buyer shops regularly). Cards appearing at 2+ sellers in the same week, with decline patterns at each, is a card testing signature that is invisible to per-seller rules but obvious in cross-platform data.
The retrospective analysis also showed that 6 of the 8 device fingerprints had appeared on our platform-wide fraud graph as associated with card testing activity at other customers. That cross-customer signal is something no individual marketplace could build on their own -- it requires a shared scoring layer that aggregates signals across multiple platforms.
The week the attack escalated
The $40,000 in losses did not come from the card testing itself -- card tests at $1-5 each accumulate slowly. The losses came in the final two days, after the attacker had validated a set of high-balance cards through the testing phase. They then used 14 of the validated cards to purchase digital goods and gift cards from sellers on the marketplace, at values between $200 and $800 per transaction. Those 14 transactions totaled roughly $40,000 before the marketplace's fraud team manually flagged the pattern and shut down the buyer accounts.
By the time the fraud team noticed, the chargebacks were already in process from the card-testing phase, and the larger purchase chargebacks were incoming. Total cost including processing fees was approximately $43,000 for the week.
What would have stopped it earlier
Stopping the card testing attack before it reached the escalation phase required three signals working together:
First, a cross-seller card velocity check that measured how many distinct sellers a given card had appeared at in a 7-day window. Any card appearing at 3+ sellers with a decline rate above 20% at any of them should generate a high-risk signal. This is a rule that is straightforward to write, but only if your fraud system has access to a cross-seller transaction log in real time.
Second, a device fingerprint graph that aggregated sessions across all sellers on the platform. The 8 device fingerprints running 47 sessions would have been visible on day 1 as an anomaly -- no legitimate buyer runs 5+ sessions from the same device across multiple sellers in a day.
Third, cross-customer device reputation data. Knowing that these device fingerprints had been associated with card testing activity on other platforms would have flagged the first transactions on day 1, before any per-platform history had accumulated.
We integrated Riskgrove into this marketplace's checkout flow in the week following the attack. In the first month, the scoring layer flagged 3 separate card testing attempts before they reached the escalation phase, all of which matched the same device-fingerprint-graph pattern as the original attack. The attackers had not stopped targeting this marketplace; they had just rotated their card lists and device profiles.