How to Prevent Card Testing with 3DS

Enable EMV 3-D Secure (3DS2) on every card-not-present authorization and let risk-based authentication decide when the issuer challenges the cardholder. Card testing depends on silent approvals: a fraudster submits many stolen numbers and keeps the ones that return an approval. 3DS breaks that loop because the issuer can require authentication data the fraudster does not have, and every attempt returns a result you can score, block, or send to manual review.

3ds challenge vs card testing

Why 3DS disrupts card testing

Card testing produces a pattern: many attempts, small amounts, short time windows, and mismatched data. Standard authorization checks catch part of it, but they cannot prove the person at the keyboard holds the card. 3DS adds that proof. In the frictionless flow the issuer approves without a challenge when its risk models are confident. In the challenge flow the cardholder completes a one-time code, biometric check, or app confirmation. A fraudster hitting random numbers fails most challenges, and the failures arrive as structured data: authentication result, ECI value, CAVV, and reason code. You can act on those signals across every channel.

Does 3DS Stop Card Testing?

Prerequisites

  • A payment gateway or PSP that supports EMV 3DS2 and returns authentication results to your systems.
  • 3DS switched on for the merchant account across every card brand you accept.
  • Access to your gateway risk rules, velocity limits, and blocklists.
  • Logging that stores the 3DS transaction ID, authentication status, and ECI value.

Steps to prevent card testing with 3DS

  1. Turn on 3DS2 for all card-not-present transactions, including low-value ones, since fraudsters test with small amounts when merchants exempt them.
  2. Set the authentication request to risk-based authentication instead of forcing a challenge on every order, so legitimate customers stay in the frictionless flow.
  3. Send full transaction data to the 3DS server: cardholder name, billing address, shipping address, email, phone, device fingerprint, and account age.
  4. Configure velocity rules in your gateway to count authorization attempts per card, per IP, per device, and per email over rolling windows of 10 minutes, 1 hour, and 24 hours.
  5. Block or step up any card that produces three failed authentication attempts in 24 hours, then decline after a second failure on the challenge.
  6. Require AVS and CVV checks on every order and reject transactions where either fails, because these checks work with 3DS and not instead of it.
  7. Review your exemption strategy and skip low-value or transaction risk analysis exemptions for new customers, new devices, and high-velocity sessions.
  8. Monitor authentication result codes, since a spike in "not authenticated" or "unavailable" responses is an early card testing signal.
  9. Feed 3DS results into your order rules and decline orders where authentication fails and the device or IP already links to failed attempts.
  10. Log every 3DS event with the transaction ID so you can contest chargebacks and trace repeat attackers.

What to verify after launch

  • Frictionless rate: most repeat customers should clear authentication without a challenge.
  • Challenge rate: a sudden rise means your risk thresholds are too tight or an attack is running.
  • Decline reasons: group them by issuer, card brand, and BIN range to find the ranges fraudsters target.