Card Testing Defense Buying Guide for Merchants

The short answer: buy defense in layers, not one product. Card testing defense works when rate limiting, device and IP reputation, address verification, CVV checks, and 3D Secure step-ups run together inside a rules engine you can tune without a developer. Start with the authorization-level controls your payment processor already exposes, then add a fraud vendor once your decline and dispute data shows scripted bursts rather than ordinary fraud.

What card testing looks like from the merchant side

An attacker takes a list of card numbers and pushes small authorization attempts through your checkout. Most fail. The ones that succeed tell the attacker the card is live, and that card is later sold or used on higher-value goods. The signature is a spike in authorization attempts, low average order value, many unique card numbers coming from few devices or IP ranges, and a rise in declines and chargebacks that arrives weeks later. Each attempt is cheap, so the attacker does not mind a 90 percent failure rate.

What to look for before you buy

• Authorization-level blocking. The tool should stop attempts before they reach your processor, or at minimum before capture, since every authorization you send can carry a fee.
• Rules you control. Look for velocity limits by IP, device fingerprint, card BIN, email domain, and shipping address, with thresholds you can edit yourself.
• Step-up logic. 3D Secure and CAPTCHA challenges should fire on risk signals, not on every shopper.
• Auditable data. You need logs showing why a transaction was blocked or challenged, plus exports you can hand to your acquirer.
• Integration cost. Hosted fields and drop-in components cut PCI scope. Custom API work adds weeks and liability.

Parameter bands that hold up in production

Vendors rarely publish defaults, so treat these as starting points and tune them against your own traffic.

• Per-IP authorization attempts: two to five per minute, ten to twenty per hour, with a hard block above that.
• Per-device fingerprint: three to six attempts per hour across all cards.
• Decline ratio per IP: block when failed authorizations exceed 60 to 70 percent over a ten-minute window with at least ten attempts.
• AVS and CVV: require both for physical goods, and expect a match rather than an optional check.
• Order value: flag authorization-only traffic below a low dollar threshold combined with new accounts or guest checkout.

Pitfalls that waste money

• Buying bot management and expecting it to handle payment fraud. The two overlap but do not replace each other.
• Blocking entire countries or BIN ranges. You lose real customers while attackers move to residential proxies.
• Challenging every transaction with 3D Secure. Conversion drops and friction lands on good buyers.
• Ignoring the dispute timeline. Card testing chargebacks often arrive 60 to 120 days after the attack, so a quiet week is not proof the tool worked.
• No test plan. You should be able to replay a known attack pattern in staging before signing an annual contract.

FAQ

Do I need a dedicated vendor if my processor already blocks fraud?

At low volume, often no. Processors expose velocity and AVS controls that handle small attacks. Move to a vendor when attempts exceed what your team can watch, or when you need device-level signals.

How fast should a block take effect?

Under a second, at the point of checkout. Rules that only run in nightly batch reporting will not stop the attack happening now.

What should the contract include?

Volume-based pricing without a hard cap, a clear data retention clause, an export of block reasons, and a documented onboarding window. Ask what happens if you exceed your plan mid-attack.

Does 3D Secure alone solve it?

No. It shifts liability for eligible transactions, but attempts still reach your gateway, and some card programs do not support it.