A single operator used the store's guest checkout as a free validation service for stolen card numbers — and the campaign escalated 589% overnight.
Across two days, an automated script pushed 1,420 card-testing attempts through the checkout. It carried card numbers and expiry dates only — no security code, no billing address — and used the live authorization response to sort dead cards from live ones. It found roughly 38 live cards, and the gateway's velocity rule never fired.
The timeline, the anatomy of the attack, what it cost, and why the existing controls missed it. Enter your work email to keep reading.
No spam. No drip campaigns.
Day one looked like reconnaissance: 180 attempts spread across the afternoon. The operator came back the next night with 7× the volume, compressed into the early hours and fired 9 seconds apart. That's a script iterating, not a person.
| Metric | Day 1 | Day 2 | Change |
|---|---|---|---|
| Test attempts | 180 | 1,240 | +589% |
| Active window | 13:00 – 19:00 | 01:00 – 06:50 | overnight |
| Median gap between tries | 34s | 9s | 4× faster |
| Distinct BINs | 2 | 7 | fanned out |
| Approved (live cards found) | 6 | 41 | +583% |
Shared y-axis · peak 268 attempts per hour.
The security-code check fails or isn't processed, and address verification is unavailable on nearly every attempt. The operator has card numbers, not full stolen profiles.
The store's cheapest item, bought as a guest. Small enough to pass unnoticed, large enough to confirm a real authorization.
Every attempt hit the same guest-checkout path with a fresh session, skipping the account flow entirely.
Day one used 2 BINs. Day two fanned out to 7 — and the approvals clustered on two of them, so the operator found "good" ranges and leaned in.
Card testing isn't measured in dollars stolen from the store. It's measured in validated cards. Every approval is a live card the operator can now resell or use elsewhere.
| 03:41 | 424242••••1881 | $4.99 | APPROVED |
| 04:06 | 400000••••3063 | $4.99 | APPROVED |
| 04:52 | 555555••••4444 | $4.99 | APPROVED |
| 05:17 | 222300••••7296 | $4.99 | APPROVED |
| Gateway + processor auth fees | 1,420 × $0.25 | $355 |
| Visa APF | 1,420 × $0.0195 | $28 |
| Visa Misuse of Auth | 47 × $0.15 | $7 |
| Total | $390 |
The fees are the smallest part. 1,373 declines in two days drag down the approval rate that the processor and the card networks watch, and every approved test that's later disputed adds a chargeback. The real victims are the ~38 cardholders whose cards are now validated for resale.
The gateway blocked any IP making more than 25 attempts an hour. The attack spread across 312 IP addresses and never sent more than 6 from any one of them. A per-source threshold can't see a cross-source pattern: 1,240 attempts across 7 BINs in under six hours.
Sub-10-second submissions sustained for hours, measured across the whole checkout rather than per IP.
Dozens of cards sharing a handful of six-digit prefixes — the hallmark of a BIN attack.
Security code never matching, address never available, amount fixed at $4.99. No real customer base looks like this.
Fresh guest sessions that fill the form at machine speed and never browse — caught before the card is ever charged.
About this sample: the merchant and every figure on this page are fictional, and the masked cards come from public test ranges. Real assessments are built from your own gateway exports, with card numbers masked to BIN + last 4, and they're shared only with you.