The framework that matters most for card testing is PCI DSS v4.0 read together with the card network rules published by Visa and Mastercard. Those two sources define what an acquirer, payment processor, or merchant must do when authorization requests arrive in bulk, when decline rates spike, or when a fraud team opens an enumeration case. US federal criminal statutes and the FTC Act decide what happens after the fact. This guide compares each rule set on scope, enforceability, and the operational work it creates, then maps each one to the role that should own it.

card testing prevention rules

What the rule sets treat as card testing

Card testing is a pattern rather than a single transaction, and the major rule sets converge on the same signals. Visa calls the behavior enumeration: a flood of authorization requests, often from a narrow set of IP addresses, against payment credentials that a criminal group has already obtained. Issuers see repeated declines followed by an approval, small ticket sizes, and merchant category codes that do not match the cardholder's history. Networks treat this as an attack on the authorization system itself, which is a separate problem from the theft of the underlying account data. That distinction matters because it decides which rules apply to you.

related article

PCI DSS v4.0

The Payment Card Industry Data Security Standard is the baseline security framework that applies to every entity that stores, processes, or transmits account data.

Card Testing Detection Rules: A Practical Merchant Guide

• Pros: Prescriptive requirements for logging, monitoring, access control, and change management. Version 4.0 adds targeted risk analysis and explicit expectations around detecting attacks on the cardholder data environment. Assessments are standardized, so a merchant can show an acquirer a defined level of compliance.
• Cons: The standard governs the cardholder data environment, which does not automatically include authorization-only traffic that never touches stored data. Assessment cost and effort scale with transaction volume. Requirements are outcome-based in places, so two assessors can reach different conclusions.

Use case: The right first framework for merchants, e-commerce platforms, and service providers that handle card data or route it on behalf of others.

Card Testing Rules for Merchants

Card network rules from Visa and Mastercard

Network operating regulations sit closer to card testing than any other rule set because they govern the authorization messages themselves.

• Pros: Enforceable through acquirer agreements, fines, and registration programs. Network fraud disruption programs notify issuers and merchants when credentials appear compromised. Rules can be updated quickly as attack methods shift.
• Cons: The rules are not fully public and change without broad notice. Obligations typically flow down through the acquirer, so a merchant's direct visibility into its own requirements is limited. Penalty schedules vary by region and volume.

Use case: Essential for acquirers, payment facilitators, gateways, and high-volume merchants that need to act on enumeration alerts quickly.

US federal criminal law

Three statutes do most of the work in a card testing prosecution: 18 U.S.C. Section 1029 on fraud and related activity in connection with access devices, 18 U.S.C. Section 1343 on wire fraud, and 18 U.S.C. Section 1030, the Computer Fraud and Abuse Act.

• Pros: Real deterrence, with felony exposure and asset forfeiture. These statutes reach conduct that no private standard can punish.
• Cons: Purely reactive. They impose no preventive controls, no monitoring duty, and no reporting obligation on merchants. Enforcement depends on investigative resources.

Use case: Legal, risk, and investigations teams assessing exposure and preparing referrals to law enforcement or the card networks.

FTC Act Section 5 and consumer protection rules

The Federal Trade Commission can treat weak checkout controls that enable card testing as an unfair practice under Section 5 of the FTC Act, particularly when a merchant keeps charging consumers after the fraud is reported.

• Pros: Broad jurisdiction over merchants and service providers, plus the ability to obtain consent orders that mandate specific security programs.
• Cons: There is no dedicated card testing rule, so enforcement is case by case and depends on demonstrated consumer harm.

Use case: Consumer-facing merchants with recurring billing, trial offers, or high chargeback ratios.

PSD2, strong customer authentication, and UK law

Inside the European Economic Area, the revised Payment Services Directive and its strong customer authentication requirement force a second authentication factor on most electronic payments, which limits how far automated testing can get. The UK Fraud Act 2006 covers the conduct itself.

• Pros: Authentication requirements reduce the value of a successfully tested credential. Exemptions are narrow and monitored.
• Cons: Geographic scope. Traffic routed through jurisdictions outside the EEA falls back to network rules and local law.

Use case: Merchants and processors selling into the EU and UK, and any business whose authorization traffic crosses those borders.

State law and contractual add-ons

Several US states attach security obligations to card data through their own consumer protection and data security statutes, and some impose notification duties after a breach. Merchant agreements and gateway contracts often add requirements that exceed PCI DSS.

• Pros: Can be enforced by state attorneys general, which adds a second enforcement channel.
• Cons: Requirements differ by state, which complicates a single national checkout flow.

Use case: Multistate retailers and platforms that want one control set that satisfies the strictest state they operate in.

How to match the rule set to your role

1. Merchant or platform: Start with PCI DSS v4.0 for the security baseline, then map network enumeration programs onto your gateway's fraud tools and your decline monitoring.
2. Acquirer, processor, or payment facilitator: Lead with network operating rules, because your obligations are contractual and flow to your merchants. Layer PCI DSS on top for data handling.
3. Issuer: Network rules plus the consumer liability rules that apply in your market, with alerting built around account status and authorization velocity.
4. Legal and compliance: Track the federal statutes for enforcement exposure and the FTC Act for consumer-facing practices.
5. Cross-border seller: Apply PSD2 and strong customer authentication to EEA traffic while keeping network rules as the common floor everywhere else.

The practical point is that no single rule set covers card testing end to end. PCI DSS tells you how to protect the data. Network rules tell you how to respond when the authorization stream is attacked. Criminal statutes and consumer protection law tell you what happens when those controls fail.