Bursts and retries
Many attempts from one browser or network in seconds or minutes, the classic shape of a testing script.
Available in the MSP pilot
CardSecurity checks each payment attempt before it reaches the processor. Genuine customers pay without friction, risky attempts are asked to verify, and scripted attackers are blocked. You manage every merchant from one portal.
Signals
No single signal decides. Evidence adds up to a risk score, and the score decides whether a customer pays, verifies or is stopped.
Many attempts from one browser or network in seconds or minutes, the classic shape of a testing script.
Repeated low-value payments, which testers use to validate cards cheaply.
Many different names and emails claimed from the same browser or network.
Confirmed declines from the card issuer, counted once and weighed over short and hourly windows.
A rising decline rate across many networks at once, so attacks spread over a merchant's whole traffic still trigger verification.
Fraud-related responses from issuers hold the source immediately, whatever its score.
Protection levels
Set protection per merchant. Behind each level the CardSecurity team tunes the thresholds and tests them against scripted attack patterns.
Fewest checks for genuine customers. Attacks are still stopped, a few attempts later.
Balances fast checkout with early attack detection.
Stops attacks at the first signs. Genuine customers are asked to verify more often.
After the decision
Each payment attempt is claimed once. Replays and duplicates are refused. A payment with an unknown result is held for reconciliation, never resubmitted.
Flagged payments wait for a person. Approvals and rejections are recorded with who made them and why.
When an attack starts, the source is held and unrelated visitors are asked to verify for a short window, so the attack can't simply rotate around the block.
Attempts, decisions, review outcomes and response times per merchant, as CSV or PDF, plus alerts with owners and escalation.
Card data stays out
Card entry stays in your processor's hosted fields. CardSecurity works with payment tokens, the amount and the merchant, so adding protection doesn't pull card data into scope.
FAQ
Card testing is when fraudsters run stolen card numbers through a real checkout, usually as many small payments, to learn which cards still work. The merchant pays authorization and decline fees on every attempt and can face processor reviews, holds and chargebacks.
Each checkout attempt is scored on how it behaves: rapid retries from one browser or network, repeated issuer declines, many identities from one source, attacks spread across a merchant's traffic and issuer fraud alerts. Low-risk customers pay straight through; risky attempts are asked to verify or blocked.
No. Keep your processor's filters on. CardSecurity stops scripted attempts before they reach the processor, so you pay for fewer of them, and it gives your MSP one view across every merchant.
No. Each payment attempt is claimed once. Replays and duplicates are refused, and a payment with an unknown result is held for reconciliation instead of being resubmitted.
Payroc today, with Authorize.net in sandbox testing. Tell us which processors your merchants use and we'll prioritise them.
Join the CardSecurity pilot for managed service providers. 30-day trial, up to 5 merchants.