A card testing pattern is the trail left when someone pushes a batch of stolen card numbers through a payment form to find out which accounts still approve. The signs repeat across merchants: many tiny orders, a spike in failed authorizations, and attempts that arrive in bursts from the same device, IP block, or email domain. Catching the pattern in the first hour matters, because a completed test run turns into a fraud spree on your store.
Card Testing Attack Patterns Guide
What does a card testing attack look like?
Card testing is a validation step, not a shopping trip. The attacker already holds a list of numbers and needs to sort live cards from dead ones before selling them or using them for larger purchases. Your checkout page is the cheapest testing lab available.
The small-charge probe
Test orders sit at the bottom of your price range. The attacker buys a $0.50 item, a $1 digital download, or a donation in the smallest amount the form allows. A run of these orders from one source inside a short window is the clearest single signal.
The failure burst
Most tests fail. A batch of 100 numbers might yield a handful of approvals, so the transaction log fills with declines in a tight cluster. Watch the ratio: a source with 40 attempts and 2 approvals is not a confused customer.
Repeated identifiers
Attackers switch card numbers but reuse infrastructure. The same IP, device fingerprint, user agent, or email naming pattern shows up across dozens of attempts. Free email domains and disposable phone numbers appear far more than they do in normal traffic.
Which data points reveal the pattern?
- Attempt velocity from a single IP or device.
- Number of distinct card BINs per session.
- CVV and AVS mismatch rates that run above your baseline.
- Order values clustered at the minimum amount.
- Time between attempts measured in seconds, not minutes.
- Billing country that does not match the IP country.
- New accounts created in bulk with similar naming.
No single field proves card testing. The pattern lives in the combination, which is why rules built on one metric such as IP address alone miss most waves.
How is card testing different from normal decline traffic?
Real customers who fail a payment retry once or twice, often on the same card, and they leave if it keeps failing. Testers keep going with new numbers and no change in behavior. Genuine decline traffic also tracks your normal sales hours, while test runs often land at 2 a.m. in your local time.
What stops a card testing run?
- Rate limit checkout attempts per IP, device, and card BIN. Block after a threshold instead of letting the run finish.
- Require CVV and full AVS on every order. Testers work from dumps that lack one or both.
- Turn on 3-D Secure for high-risk or first-time buyers. Authentication kills the cheap probe because the cardholder is not there to approve.
- Block disposable email domains and known proxy ranges at the form level.
- Add a CAPTCHA or proof-of-work step when velocity crosses your limit.
- Review the decline log daily instead of monthly. A wave can drain a small store in a weekend.
How do you build a detection rule set?
Start with the data you already log, and keep card numbers out of it. Tokenized card IDs, IP, device ID, and timestamps give a rule everything it needs without touching cardholder data.
- Set a baseline for declined attempts per source over 24 hours.
- Flag any source that triples the baseline inside one hour.
- Score each attempt on BIN diversity, AVS result, and CVV result.
- Route scores above the line to 3-D Secure or manual review.
- Log the outcome so the rule tunes itself over time.
What does the fraud cost you?
Each test charge carries a chargeback fee, and fees stack fast when the volume runs into hundreds. Card networks track fraud-to-sales ratios, and a store that crosses the threshold lands in a monitoring program with fines attached. The processor may freeze funds or close the account, which hurts more than the stolen goods.
Which mistakes make it worse?
- Refunding test charges without reporting them, which hides the volume from your fraud data.
- Blocking one IP when the run rotates across hundreds.
- Setting the velocity rule so high that a slow, spread-out wave passes under it.
- Ignoring failed attempts because they never settled. Declines still count as traffic.
Frequently asked questions
Is card testing the same as a data breach?
No. Card testing uses numbers taken from somewhere else. Your site is the testing ground, not the source. That said, a successful run shows attackers your checkout is soft and invites repeat visits.
How fast does a wave hit?
Hours, sometimes minutes. Bots fire requests in parallel, so a store can see hundreds of attempts before a human looks at the dashboard.
Do all small charges mean fraud?
No. Low-value digital goods sell all day. Judge the source, the velocity, and the failure rate together before you flag an order.
Should I refund test transactions?
Void them while the authorization is still open, and document the event for your processor. Refunding a settled charge can still trigger a fee, and the cardholder never authorized the payment.
Key takeaways
- Card testing shows up as bursts of small orders and heavy declines from shared infrastructure.
- Detection depends on combined signals, not one metric.
- Rate limits, CVV and AVS checks, and 3-D Secure cut the volume before chargebacks start.
- Watch declines daily. The window to stop a wave is short.