iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Card-testing bots probe a SaaS checkout or saved-card flow with stolen payment details to find which cards still work. Respond by tracing activity across the whole payment flow, then layering endpoint rate limits, session checks, adaptive challenges, processor rules, and monitoring. A VPN or changing IP address is not proof of fraud, and IP blocking alone may miss a distributed campaign.
The question’s wording does not identify the affected service, payment processor, or what its operator actually implemented, so there is no verified incident outcome to report. The steps below are a practical response based on documented payment-industry guidance.
What card testing looks like in a SaaS payment flow
Card testing is an attempt to validate stolen payment credentials. Stripe defines it as using scripts or manual processes to check whether raw stolen card numbers remain active (Stripe, “Radar: Rules 101”). Visa describes automated injection of payment-account information into checkout pages (Visa, “Guidance to Guard Against Enumeration Attacks and Account Testing Schemes”).
In a SaaS, the target may be more than a completed charge. Review customer or account creation, attempts to attach or save a payment method, setup or authorization flows, and low-value payment attempts. A suspicious pattern can involve many cards attached to one customer, many new customers from a source, or repeated payment attempts that produce a mix of declines and approvals.
#1 Best Overall
VPNs can make traffic appear to come from changing or geographically dispersed IP addresses, but their presence alone does not establish that requests are fraudulent. Investigate request patterns and payment-flow behavior rather than treating VPN use as a verdict.
How to investigate suspected card testing
Map the affected actions
List the endpoints and actions that can create a customer, attach or save a payment method, initiate setup or authorization, or submit a charge. Check application and processor records together where available, so you can connect a request to its account, payment result, and session or device signals.
Rank #2
Compare activity with your normal baseline
Review request and transaction velocity, approvals and declines, cards attached per customer, customers created per source, and account age. Look for correlated device or session signals as well as IP addresses. Stripe recommends monitoring customer creation, cards attached per customer, and customer creation per IP, alongside session validation and request attributes (Stripe Support, “How do I prevent card testing attacks?”).
Set thresholds using your own legitimate traffic and historical patterns. The cited guidance does not establish a universal safe request limit, and a threshold that blocks a bot for one service could disrupt another service’s customers.
Account for changing attacker behavior
Do not make low authorization rates your only signal. Stripe Engineering reported in January 2025 that some attackers were using higher-quality stolen-card datasets in verification attacks, increasing authorization rates and weakening reliance on low approval rates as a warning sign (Stripe Engineering, “How Stripe Radar responded to a new wave of card testing”). That is a documented shift, not evidence that every campaign behaves this way.
Build defenses in layers
Limit the actions attackers need
- Apply rate limits to customer creation and payment-related actions, including payment-method attachment and setup flows where appropriate.
- Require valid sessions and check request attributes before allowing sensitive actions. Where the flow permits it, require a user to be logged in before attaching a payment method.
- Use account, device, and endpoint behavior alongside IP velocity. Distributed requests can evade a rule that counts only activity from each individual IP address.
Stripe’s SaaS and API guidance recommends combining rate limits with bot management, device signals, and adaptive verification rather than relying on one IP threshold (Stripe, “Real-time API abuse prevention for SaaS and AI platforms”).
Rank #4
Challenge suspicious traffic proportionately
Consider CAPTCHA or an adaptive challenge when behavior is suspicious, rather than adding friction to every customer by default. A challenge can make automated attempts harder, but it should be evaluated against the effect on legitimate signups and payments. Monitor challenge outcomes and adjust the rules as traffic changes.
Recommended Free Tools
Apply processor-level risk controls
Use the fraud controls available through your payment processor to assess suspicious velocity and repeated card or customer patterns. Stripe documents card-testing controls in its Radar guidance and describes SaaS fraud use cases on its product page (Radar: Rules 101; Stripe Radar). Availability, compatibility, pricing, and terms can vary by account and geography; verify them with the processor before choosing a control.
Choose controls by their role and impact
Compare defenses by where they operate, what signals they can use, and what happens when a request looks risky. An application rule may see account history; an edge or bot layer may help manage request patterns; a processor may evaluate payment signals. For each, assess whether it blocks, challenges, or queues activity, how it could affect legitimate customers, how it fits the current payment integration, and what monitoring and tuning it requires. The cited sources do not provide a neutral head-to-head comparison of vendors.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Monitor the response and test safely
After applying controls, keep watching for both continued attempts and false positives. Check whether suspicious request patterns are changing, whether legitimate customers are being challenged or blocked, and whether processor alerts indicate further activity. Stripe explicitly cautions that mitigations do not guarantee that card testing will stop (Stripe Support, “How do I prevent card testing attacks?”).
Use your processor’s sandbox and documented test values to verify integration behavior. Stripe’s test-card documentation covers simulated payment scenarios and warns that test environments are rate-limited and should not be used for load testing.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →What reported results can—and cannot—tell you
Stripe reports that businesses using Stripe Checkout with Stripe-managed CAPTCHA saw an 80% reduction in card testing, with less than 2 basis points (0.02%) impact on authorization rates in the deployment it describes in its Radar: Rules 101 guide. These are Stripe-published results for that described deployment, not an independent guarantee or a forecast for a different SaaS.
Stripe also reported that it blocked more than 20 million card-testing attempts per day at the peak of a wave in 2022 (Stripe Newsroom, November 30, 2022). That is a historical company-reported peak, not a current daily rate or a prevalence estimate for SaaS businesses generally.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
