3-D Secure 2 vs Card Testing Bots: Where the Friction Actually Helps
Card testing is not a checkout problem
Card testing, also called carding or enumeration, is bots submitting many small or zero-value authorizations to learn which stolen cards are live before cashing them out elsewhere. The merchant whose checkout gets abused pays in fees, disputes, damaged authorization rates, and, increasingly, card scheme monitoring. Visa's Acquirer Monitoring Program has included enumeration criteria since April 1, 2025, so a testing run can put the merchant's acquiring relationship under review, not just the checkout.
The mistake is assuming the attack happens at checkout. NHIMG's card testing guide is blunt about this: every card endpoint is a target, not only checkout. Attackers prefer card-save and card-update flows because validation there often does not appear on a cardholder statement, and donation pages because $1 to $5 payments look normal. A store that hardens its checkout and leaves its save-card form open has locked the front door and left the side window open.
Testers also work across merchants. Bots try one card with different expiry dates, postcodes, and CVV values across many merchants at once, which defeats per-site attempt limits. Stripe's documentation adds that testers collect 3-D Secure or issuer responses to decide which cards are valid before cashing them out or reselling them. The response itself is the product.
Where 3DS2 actually helps
3-D Secure 2, or EMV 3DS, adds an extra authentication step that lets the card issuer confirm the buyer is legitimate. The modern version sends the issuer far richer data about the device and the transaction than the original 3DS1, which sent every shopper to a full-page redirect with a static password. Most transactions the issuer trusts go through the frictionless flow and the shopper never sees a challenge. When the issuer wants more proof, it triggers a challenge: an SMS one-time passcode, a fingerprint or face scan, or an approval tap inside the banking app.
Against card testing, the challenge flow is the useful half. A bot can submit a thousand card numbers, but it cannot answer a thousand push approvals. The frictionless flow is the half that protects conversion, because a challenge at the wrong moment is what kills real sales. The OTP arrives late, or never. The banking app opens and does not return to the checkout. The customer is not a fraudster, just a legitimate buyer who gives up and closes the tab.
The right placement follows the abuse, not the page. Put step-up authentication on card-save and card-update endpoints, on donation flows, and on checkouts showing the testing signals: a spike in declines, low-value attempts, nonsense names. Keep the normal checkout frictionless for trusted signals. A merchant that flips 3DS on for every payment will block some fraud and lose some legitimate customers, and the lost customers are the ones who never complain, they just do not come back.
What to do instead of turning it on everywhere
Layer the controls. No single heuristic stops card testing: blocking IP addresses alone fails against residential proxies, so the guide's recommended stack is bot defense plus velocity limits keyed on several signals, issuer checks on CVC and postcode, and friction such as CAPTCHA or 3-D Secure under attack. A velocity rule that counts attempts per card, per device, and per account catches what a per-IP rule misses.
Watch the decline spike as your alarm. A sudden rise in failed authorizations, generic declines, and low-value payments with nonsense names is how most attacks show up first. Set the alert on the rate, not on a single transaction, and have the response ready before the spike: tighten velocity, step up 3DS on the affected endpoints, and review the card-save form the same day.
Measure the challenge rate, not the fraud rate alone. A reasonable target is keeping challenges under 8 percent of checkouts, then iterating. If the challenge rate climbs and conversions fall, the friction is landing on the wrong people. 3DS2 is a lock on the payment door. It works when it is on the doors the testers use, and it hurts when it is on every door in the store.
Keep reading: Card testing on small checkouts: why the $1 charge is the whole attack, Checkout Bots Explained: Scrapers, Card Testers, Scalpers.
Frequently asked questions
What are the two 3DS2 flows, in plain terms?
Frictionless flow, where the issuer approves silently in the background, and challenge flow, where the customer must prove identity with a one-time passcode, a push approval, or a biometric. The issuer decides which path a transaction takes based on device data, location, history, and transaction context, and the split changes from bank to bank.
Why do testers use $1 charges and donation pages?
Because the attacker does not care about the purchase. A $1 test charge validates the card for a bigger fraud elsewhere, and a donation page or a card-save form lets them test without buying anything at all. NHIMG's card testing guide notes that testers prefer card-save and card-update flows because validation there usually does not appear on the cardholder's statement.
Should I put 3DS on card-save forms even if I don't use it at checkout?
Yes, and that is often the right call. A 3DS challenge on a low-value test charge costs the attacker a step they cannot automate cheaply, while the same challenge on every real checkout would cost you customers. The control belongs where the abuse concentrates, not spread evenly across the whole store.
What is the first sign my store is being card tested?
A sudden rise in failed authorizations, generic declines, and low-value payments with nonsense names. That spike is how most card testing attacks show up first, before any chargeback or customer complaint. If your decline rate jumps and the failures cluster on small amounts, you are being tested.