The payment dashboard looks quiet at first. Revenue hasn't moved, no large orders have failed, and support hasn't reported an outage. Then authorization declines start climbing, processor fees rise, and hundreds of tiny checkout attempts appear from accounts that never browse, never return, and never complete a normal purchase. That's often how card testing surfaces. The immediate problem isn't theft at checkout. The attacker is checking which stolen payment details still work.
What Card Testing Is and Why It Matters
Card testing is payment-card enumeration. Criminals use automated, programmatic transactions to determine whether stolen card details are valid, testing fields such as the card number, expiration date, CVV2, and billing postal code, according to Visa guidance on anti-enumeration and account testing best practices for merchants. Visa describes the activity as a global problem affecting issuers, merchants, and acquirers, and estimates that it produces more than $1 billion in annual fraud losses across the payments ecosystem in that same guidance.
The primary account number, or PAN, is the card number itself. The CVV2 is the security code. An approval tells the attacker that a tested combination may be usable. A decline tells the attacker to discard that combination or change a field. Either way, the payment response becomes an oracle, a system that leaks useful answers through normal functionality.
Why Small Attempts Still Cost Real Money
The economics are asymmetric. Attackers can submit many low-value, zero-value, or declined authorizations to identify usable credentials before attempting larger fraudulent purchases. The merchant absorbs authorization fees, operational costs, customer complaints, and potential network-monitoring consequences. Individual tests may look trivial in a transaction list. At scale, they consume support time, pollute fraud data, and create chargeback and monitoring risk.
A low approval rate can still leave attackers with useful payment details. Count provider-bound attempts and reviewed abuse outcomes, rather than assuming rejected payments have no operational cost.
Most guidance starts at checkout, but that's too narrow. Attackers also work through account creation, card-on-file setup, and promotion flows. A helpful SaaS-focused overview is available through card testing insights for SaaS, especially for teams mapping where card validation happens outside a purchase. JPMorgan identifies account creation and exception processing as part of the testing cycle, alongside purchase transactions, in JPMorgan guidance on card testing and merchant-account monitoring.
Card testing can occur in add-payment-method and account flows before checkout. Inventory every path that can trigger a provider request and apply controls at the relevant acceptance boundary.
How a Card Testing Campaign Actually Works
A campaign usually starts with stolen or guessed card data. The list may be incomplete. One record has a PAN but a wrong expiration date. Another lacks a CVV2. Automation then submits authorization attempts through merchant sites, changing fields and recording which combinations issuers approve or decline.
The next step is distribution. Attackers spread attempts across accounts, sessions, merchants, and checkout paths so no single counter trips too early. Approvals get harvested for later fraud or resale. Declines get discarded or retested with a different field value. Spending isn't the first objective. Learning is.
Distributed Guessing Across Merchants
Fragmented validation makes the attack stronger. One merchant may check the PAN, another may check expiration, and another may check security data. A University of Kent study of payment flows at the Alexa top-400 online merchants found that distributed guessing could turn ordinary payment functionality into an oracle for generating security fields, as described in University of Kent research on distributed guessing attacks. The researchers concluded that uniform security checks across payment sites would make the attack impractical.
That finding explains why single-site thresholds disappoint. An attacker doesn't need to brute-force every field in one place. Responses can be combined across sites, with each merchant seeing only a slice of activity. Controls therefore need to limit authorization attempts, not only successful charges, and correlate activity across accounts, sessions, network clusters, and browser signals where visibility exists.
The Numbers Behind the Asymmetry
Scale makes weak yield acceptable. A PCI Security Standards Council bulletin illustrates the math with 10,000 attempted transactions per hour and only a 2% success rate, yielding 200 valid card details per hour, or 4,800 per day, as summarized in Stripe guidance on Visa monitoring programs and enumeration thresholds. Stripe's published explanation also states that an account can enter excessive enumeration monitoring when it exceeds both 300,000 enumerated transactions and an enumeration ratio of 20% of authorization transactions in the applicable period, per that same Stripe guidance.
Visa's framework treats an enumeration attempt as a transaction that reaches the processor, whether approved or declined. That definition shapes engineering work. Count attempts before the processor where possible, verify the browser-originated action server-side, and stop retries from becoming free extra tests. Payment controls catch part of the pattern. Browser-side proof helps bind the attempt to the session that sent it.
Detection Signals and Forensic Indicators
Ordinary shoppers mistype cards, retry after a bank decline, and switch payment methods. Card testing looks different in aggregate. Visa identifies signals such as spikes in authorization attempts, concentration against the same issuer or BIN range, sequential PAN patterns, card-not-present activity, cross-border activity, identical or similar amounts, and activity from a new or dormant merchant in Visa guidance on guarding against enumeration attacks. A BIN is the bank identification number range at the start of a PAN. It points to the issuing bank.
No single signal is reliable alone. A sale causes spikes. Travel causes cross-border activity. Families share networks. Detection improves when grouped evidence lines up, such as rising declines against one BIN, repeated identical cart values, and many cards presented from one browser identity.
Detection Signal Categories
| Signal Family | What to Measure | Why It Matters |
|---|---|---|
| Rate signals | Authorization velocity, decline ratio, repeated amounts, BIN concentration | Testing is high-rate and low-value, unlike normal browsing and buying |
| Diversity signals | Many cards per browser, many accounts per network, sequential PANs | Shared infrastructure stays stable while card values change |
| Pattern signals | Card-not-present spikes, cross-border clusters, dormant-merchant surges | Context separates a campaign from a busy but legitimate period |
Count approved and declined provider requests separately. A successful probe can be as relevant as a decline, and a small transaction amount alone does not establish abuse.
What to Instrument First
Correlate application-owned attempt IDs, protected account references, and provider-issued payment references. Do not log raw card numbers, security codes, session cookies, or reusable browser credentials. Restrict access and retention to a documented investigation need.
Practical rule: Alert on combinations, not thresholds alone. A decline spike plus one-BIN concentration plus shared browser identity is stronger evidence than any one counter crossing a line.
Document retention and access for payment-security evidence. Keep only the protected references needed for investigation and respect provider requirements; do not retain sensitive card authentication data.
Browser Verification as One Layer of Defense
Browser verification evaluates evidence about a browser-originated action against current server state. Opaque, short-lived proof still needs action binding, expiry, consumption, and context checks. Copied credentials are not automatically harmless.
The design question is where verification lives. Client-side checks alone can be inspected and replayed. Server-side verification can confirm freshness, action binding, and prior use. That tradeoff is explored in MANDATE guidance on client-side and server-side verification decisions, which frames why hosted server checks matter for browser-originated actions.
What Browser Verification Does Not Do
Browser proof doesn't establish card ownership. It doesn't replace issuer monitoring, address verification, CVV checks, payment-provider fraud scoring, or authorization velocity limits. A real browser can still be operated by a person testing stolen cards, or by automation advanced enough to resemble one. Any vendor claim of complete protection should be treated as a red flag.
Browser verification adds an acceptance signal before the application calls a payment provider. Measure whether it reduces abusive provider-bound attempts; fees and monitoring consequences depend on provider terms and actual outcomes.
MANDATE is one example of this approach. It protects important website actions from automated abuse without CAPTCHAs, using browser proof and hosted server-side verification before the application accepts a protected action. There are no puzzles, checkboxes, or interstitials for legitimate customers. That removes a common tradeoff at checkout, where visible challenges punish buyers while determined attackers route around them. It still isn't a payment-fraud engine, and shouldn't be sold or bought as one.
Keep transport, application security, authentication, and payment-provider controls in place. Browser verification adds evidence for selected actions rather than replacing those controls.
Supporting Controls and Tradeoffs
Each supporting control does a different job. Treating them as interchangeable creates gaps. Rate limits bound volume. Token tying blocks replay. Idempotency prevents duplicate execution. Anomaly detection groups evidence. Honeypots surface automation cheaply. None of them, alone, answers whether a card belongs to the person presenting it.
Rate Limiting by Scope, Not by Hope
A single per-IP limit fails against distributed traffic and punishes shared networks. Layer scopes instead. Count attempts per account, per session, per browser credential, per card fingerprint or token, and per BIN where the payment provider exposes it. Apply limits to authorization attempts, including declines and zero-value checks, because that's the resource attackers consume.
The tradeoff is false positives during legitimate retries. A customer with an expired card may try twice, then use a second card. Caps need headroom for that behaviour, with faster tightening when diversity signals appear. Design details for scoping and storage are covered in MANDATE guidance on rate limiter design for protected actions. The core principle is simple. Limit the thing being abused, at the identity the attacker can't cheaply multiply.
Token Tying and Idempotency
Token tying binds a payment token or browser credential to one verified session and one intended action. A captured request replayed from another context then fails server-side checks. Card-testing tooling often harvests a working request shape and replays it with swapped card fields.
Idempotency is separate. An idempotency key ensures that a retried request returns the original result instead of executing twice. Without it, a network retry looks like a second authorization attempt, inflating counters and possibly creating duplicate orders. With it, legitimate retries stay safe while deliberate new attempts still count against velocity limits.
Bind the credential: Tie browser proof to the account, session, and action, such as add-payment-method or checkout.
Expire it fast: Short lifetimes shrink the replay window if a credential leaks.
Reject reuse: A credential spent on one authorization attempt shouldn't authorize a second, different card.
Anomaly Detection That Groups Evidence
Scoring single requests in isolation misses distributed campaigns. Better detection groups events across the full funnel, from signup through card storage to checkout and redemption. Visa describes attackers systematically testing combinations of PAN, expiration date, postal code, and CVV2, with issuers declining incorrect combinations while an approval signals validity, in Visa risk guidance for payment facilitators and marketplaces. Repeated invalid PAN, CVV2, or expiration responses across shared infrastructure should therefore raise risk even when amounts stay tiny.
Grouped evidence beats per-request scoring for card testing, because the campaign is the unit of abuse, not the individual authorization.
Honeypots and Decoy Fields
Honeypots use decoy inputs or endpoints to identify some simple automation. Test them against autofill, assistive technology, and legitimate clients; false-positive rates depend on implementation. Real-browser automation may not trigger them.
Application authentication, authorization, transaction validation, and payment-provider fraud controls remain necessary under all of this. Browser verification and rate limits reduce scripted volume. They don't decide whether a transaction is fraudulent. Keeping those jobs separate is what makes the stack defensible.
Staged Rollout from Observe to Enforcement
Rollout starts with choosing one specific action. Account creation, sign-in, account recovery, add-payment-method, checkout, and promotion redemption have different traffic shapes and different costs when blocked. Protecting "the API" as a vague goal produces vague thresholds and unowned rollback decisions. One action, one owner, one dashboard.
Observe Before Enforcing
Observe mode records evidence and proposed decisions without enforcing them. Teams see what a policy would have done on real traffic before any customer feels it. That sequencing is detailed in MANDATE research on observing before enforcing browser verification. The distinction matters in reporting. A proposed rejection is not a blocked customer, and treating it as one corrupts both security and impact metrics.
Dashboards should separate four outcomes that teams routinely blur together:
Proposed rejection: The policy would have intervened, but didn't in Observe mode.
Verification error: Proof was missing, expired, or malformed, which may indicate integration bugs.
Applied intervention: Record the application-owned denial or review decision. MANDATE browser verification does not add a user-facing CAPTCHA or challenge.
Failed business operation: The payment or signup failed for ordinary reasons after verification passed.
Watch verification call volume, proposed action rates, completion rates for the protected action, and decline patterns by BIN and browser credential. Compare against a pre-Observe baseline. If proposed rejections concentrate on one legitimate segment, such as an older mobile browser, the policy needs adjustment before enforcement. That finding is the entire point of observing first.
Pre-Enforcement Checklist
Synthetic example, not a customer result: a merchant observes the add-payment-method route and reviews groups of attempts presenting many distinct payment references. It evaluates legitimate retries before enforcing a narrow policy. Any reauthentication or review flow belongs to the application or payment provider.
Before flipping any action to enforcement, confirm the essentials:
Rollback boundary: Document how the application owner can disable the selected enforcement policy while keeping other protections active.
Support path: Give support a safe correlation reference and recovery process without exposing detection criteria.
Alert routing: Proposed-rejection spikes page an owner, not a shared inbox.
Evidence retention: Correlate protected references to accounts and provider attempts, with documented access and retention.
Testing the Controls Before They Go Live
Testing must never use real payment details in live mode. Stripe states that its Services Agreement prohibits live-mode testing with real payment-method details and provides test cards that simulate particular risk factors, as documented in Stripe documentation on testing with simulated payment methods. Those test cards let teams exercise fraud rules and blocked-payment handling safely in non-production environments.
Validation should confirm several behaviours before enforcement. The application handles fraud-coded declines without retry storms or duplicate orders. Rate limits and alerts trigger at the intended account, IP, session, and tokenization boundaries. Idempotency keys survive a legitimate network retry without being mistaken for a new authorization attempt. Blocked actions return errors that help legitimate customers recover without teaching attackers which field failed.
PCI Security Standards Council guidance also recommends validating security codes when present, calibrating rules to detect attack transactions, and monitoring BIN-level anomalies. None of that guarantees every automated or real-browser attack will be stopped. Evidence collected in testing shows where controls trigger, where they don't, and which layer needs tightening before real traffic depends on it.
Protecting checkout, signup, and add-payment-method from card testing takes layered controls, and browser verification is the layer that acts before an authorization attempt reaches the processor. MANDATE verifies browser proof server-side for high-value web actions without CAPTCHAs or interstitials, starting in Observe mode so legitimate-user impact is measured before enforcement. Engineering and security teams evaluating that layer can review the approach and choose a first protected action to observe.