Stop card-testing bots before
they reach your checkout
Fraudsters use automated checkout flows to test stolen or incomplete card details. Your shop may not be the final target. It is the validation tool - and the authorisation noise, operational work and processor scrutiny land on your account
ADPAL adds an upstream bot-control layer before the payment request reaches the gateway. Your payment service provider still makes the financial decision, but it receives fewer automated test attempts
.SCALE OF THE PROBLEM
Your checkout can be abused without
your business being breached
Card testing is attractive because attackers do not need to compromise the merchant’s database. They need a payment or saved-card endpoint that can answer a repeated question: does this card data work?
A recognised automated threat
OWASP defines carding as testing lists of full stolen card data against a merchant’s payment process. It separately defines card cracking as guessing missing expiry or security-code values
Payment providers treat it as a deployment risk
Stripe publishes dedicated card-testing controls, and Adyen’s go-live checklist strongly recommends protecting integrations against card testing, also called BIN attacks.
Enumeration can affect monitoring
Visa’s current VAMP framework includes enumeration monitoring. Stripe’s documentation notes that Visa counts identified enumeration attempts reaching the processor whether approved or declined
It is broader than tiny orders
Attackers may attempt low-value purchases, zero or small authorisations, saved-card setup, customer creation or direct payment-endpoint requests. A €1 order is one pattern, not the definition
A small store is not automatically the preferred target, and size alone does not explain exposure. Risk depends on how easy the payment flow is to automate, what data reaches the PSP, which controls are enabled and how quickly anomalies are detected
.SNIPPET DEFINITION
What is card testing?
Card testing is often called carding, card verification, card enumeration or a BIN attack. These terms overlap in everyday use, but the mechanics differ
Card testing is automated payment abuse in which bots submit stolen or guessed card details to a real checkout or card-saving endpoint to learn which details are valid. The merchant becomes the testing ground, creating failed authorisations, suspicious payment activity and possible disputes or processor monitoring
TERM
Plain-English meaning
Why the distinction matters
Carding
Full stolen card details are tested for validity
OWASP OAT-001. The attacker is checking whether known data still works
Card cracking
Missing expiry dates or security codes are guessed through repeated attempts
OWASP OAT-010. The pattern may include many values around one PAN or BIN.
Cashing out
A validated card is used to obtain goods, cash or value
A later monetisation stage, not the same as validation.
Payment fraud
The broad category covering many fraudulent payment behaviours
This page addresses automated card testing, not every fraud scenario.
.What it looks like
How it plays out in a small online store
The scenario below is illustrative. It is not presented as an ADPAL customer result
A gift shop opens its dashboard and sees hundreds of payment attempts overnight. Most are declined. Some use small baskets; others try to save a card before checkout. Emails look disposable, but the traffic comes from many networks and devices
At first, the owner sees a payment problem. The deeper pattern shows an automation problem: one session tests several cards, several accounts share the same device traits, and attempts arrive with machine-consistent sequencing
The shop did not lose its card database. Its payment flow was used to classify somebody else’s stolen data. The immediate result is noisy authorisation traffic and emergency cleanup. The longer risk is processor review, stricter issuer decisions and disputes from any test payments that were captured
The exact cost depends on the PSP, acquiring agreement, payment method and whether the attempt was
authorised, captured, refunded or disputed. Avoid calculating a universal ‘fee per decline’ without checking the
merchant’s actual pricing
.Symptoms
Signs of card testing or card enumeration
Look across the storefront, payment integration and PSP dashboard. One symptom alone is not proof
Products show “sold out” or “unavailable” without matching paid orders
Reserved stock rises sharply while revenue remains flat
Add-to-cart activity surges at the start of a promotion or drop
Cart holds expire in groups, then the same SKUs are reserved again
Abandoned-cart rates jump far above the normal baseline for one product
Customers report stockouts while warehouse inventory still exists
Payment requests with no credible product-browsing or cart-building journey
irect traffic to payment, tokenisation or card-attachment endpoints
Many attempts distributed across residential or mobile networks, each staying below simple IP limits
Disposable or synthetic identity details combined with high card velocity
A rise in processor blocks, early fraud warnings, disputes or enumeration alerts
Issuer declines increasing for legitimate customers after a fraud wave
Support contacts from customers whose valid payments fail during emergency restrictions
A mismatch between payment-attempt volume and real orders, sessions or revenue
Recognise two or more? It is worth checking
The strongest pattern is cross-identity velocity:
many payment instruments, accounts or sessions linked by behaviour, device, sequence or endpoint activity
.Business impact
What card testing can cost an SMB
The cost is not limited to the fraudulent amount. A validation attack can damage the
economics and reliability of the whole checkout
Processing and verification costs
Some providers charge for authorisations, verifications, fraud tooling or related events. The exact cost varies; use the merchant statement, not a generic estimate
Disputes and refunds
If a test payment is approved and captured, it may need refunding or may later become a dispute. Not every validation attempt becomes a chargeback at the testing merchant.
Monitoring and remediation
Visa’s VAMP framework monitors fraud, disputes and enumeration. Exceeding applicable thresholds can trigger mitigation requirements and, in some cases, fees.
Lower payment acceptance
Large waves of suspicious attempts can cause issuers or the PSP to harden risk decisions. Genuine customers may see more declines until traffic quality improves.
Emergency checkout friction
Small businesses are hit hardest: no security team, and attackers know it. The attacker isn’t picking you. A bot is picking everyone — and staying wherever the door opens
Operational distraction
Owners, developers and support teams spend hours reviewing logs, refunding payments, contacting the PSP and tuning controls instead of serving customers
Polluted analytics
Checkout conversion, decline reasons, customer creation and product-demand reports become unreliable when automated attempts dominate the funnel
Merchant-account risk
Acquirers and PSPs can require remediation, reserves or restrictions under their agreements. Do not promise that one technical change will immediately clear an existing review
Card testing is also a customer-experience problem. A checkout flooded with automation can become slower, stricter and less predictable for the people actually trying to buy
.HOW THE ATTACK WORKS
How a card-testing campaign works
Stage
What the bot does
Why a simple rule misses it
Obtain data
Acquires full or partial stolen card records, or generates combinations around a BIN
This happens outside the merchant and may have no connection to a breach of your site
Find an endpoint
Locates checkout, saved-card, donation, subscription, customer-creation or payment API flows
Monitor every function that can validate a payment method, not only the final ‘Buy’ button
Automate attempts
Submits values through browsers, mobile/API calls or direct requests, often across distributed infrastructure
Correlate session, device, account, card and endpoint velocity rather than relying on one IP
Read responses
Uses approval, decline and validation responses to sort data or infer missing values
Do not expose unnecessary detail in client-visible errors; keep useful detail in secure logs
Monetise elsewhere
Uses or resells validated data for later fraud
Stopping validation removes value from the attack even when the final cash-out happens elsewhere
Why it can bypass ordinary controls
The requests use legitimate payment functionality rather than exploiting broken code
A bot can vary email, account and basket details while reusing the same automation stack
Distributed infrastructure can stay below simple per-IP thresholds
An attacker can slow the campaign to resemble failed customers rather than a sudden burst
Guest checkout and card-saving flows may expose validation opportunities before a full purchas
Generic error handling can still leak enough success/failure information for sorting
Card testing vs a fraudulent purchase
Card testing asks whether payment details work. A fraudulent purchase uses working details to
obtain goods or services. The same campaign can include both, but the controls and evidence
differ. This page focuses on stopping automated validation upstream
.How ADPAL prevents it
How ADPAL reduces automated card-testing traffic
ADPAL evaluates the web or API journey that leads to a payment-method validation request before high-risk automation reaches the payment gateway
It does not approve cards, replace the PSP’s fraud engine or determine chargeback liability. It adds an upstream protection layer around checkout, card-saving and other covered payment flows
This upstream position can reduce the volume of automated validation requests reaching the payment provider, especially when an attack is distributed across many IP addresses
It also adds application context the PSP may not see, including browsing sequence, form use, account behaviour and endpoint access before the payment attempt
The objective is not to block every unusual customer. It is to make repeated automated card validation harder and less reliable while keeping genuine checkout traffic moving
ADPAL should complement payment-provider fraud controls, secure integration, velocity rules and authentication. It does not replace them
01
Observe how the session reaches the checkout or card-saving endpoint
02
Compare the request sequence with normal browsing and payment behaviour
03
Correlate activity across accounts, sessions, devices and networks
04
Identify repeated automated validation across payment endpoints
05
Block high-confidence automation before the request reaches the PSP
06
Use adaptive CAPTCHA only in rare cases when the risk remains uncertain
07
Keep PSP fraud tools, 3D Secure, CVC/AVS checks and server-side validation as later layers
.DIY VS PERIMETER
What you can do yourself — and where
each layer helps
No single control solves inventory hoarding. The strongest approach combines sound reservation
design, launch-specific limits, monitoring and bot filtering. Start with the measures your platform
can support without harming genuine buyers
CONTROL
ROLE
Practical limit
Use a PSP-recommended integration
Strong — keep it
Stripe says its recommended integrations add automated and manual card-testing controls and collect richer risk data
SP fraud engine / Radar / RevenueProtect
Strong — keep it
Evaluates payment risk using network and transaction context. It complements, rather than duplicates, upstream bot control
3D Secure / SCA
Useful layer
Adds cardholder authentication and can affect liability. It may not prevent every enumeration or card-saving attempt
CVC, AVS and bank checks
Useful layer
Rejects mismatches and improves risk decisions. Repeated guessing can itself be part of card cracking
Adaptive CAPTCHA
Partly
Stripe recommends CAPTCHA for targeted endpoints. Risk-based use can help; visible challenges may add friction and must be validated server-side
Multi-dimensional rate limits
Useful
Limit cards per account, customers per IP, attempts per device and payment velocity. One-dimensional limits are easy to distribute around
Require session or login
Context-dependent
Reduces anonymous access but adds checkout friction and can shift abuse into fake account creation
Minimum order value
Weak alone
May remove one low-value route. Attackers can use card saving, donations, subscriptions or adapt the basket
Block countries, BINs or IPs
Risky alone
Can stop a known wave but may block good customers. Use evidence, expiry and narrow scope
Manual review
After the fact
Useful for a small number of approved orders, not thousands of validation attempts
Classic WAF rules
Limited alone
A rule-only WAF is strongest against exploits. Legitimate-looking business-logic abuse needs bot and behavioural context
Perimeter bot filtering
Upstream layer
Assesses automation before the request reaches the payment provider. It still needs tuning and outcome review
Actionable first step today:
ilter for sudden clusters of failed or blocked payment-method validations, then group them by account, device, session and endpoint. Do not use ‘transactions under €5’ as the only test — many card-testing flows never create a normal low-value order.
BUSINESS FEATURES
Built for an online business, not a fraud
operations centre
Upstream payment-flow protection
Reduce automated requests before they reach the PSP, while keeping the provider’s own fraud controls enabled
Checkout and card-saving coverage
Protect the relevant web and API endpoints routed through ADPAL. Confirm exact coverage for hosted or third-party payment pages
Correlate patterns across accounts and endpoints instead of relying only on IP address
Monitor, allow, limit, challenge or block according to the confirmed ADPAL policy options
Avoid forcing every customer through a challenge. Adaptive handling can protect the payment step with less conversion cost
Apply tighter controls to a targeted endpoint or campaign, then review and roll back safely
See which routes are targeted and how automated attempts change. Confirm event detail, exports and retention before publication
Keep PSP fraud tools, 3DS, secure payment integration, CVC/AVS checks and dispute monitoring
Confirm cookieless claims, data residency, retention and subprocessors with the actual service configuration
Start in monitor mode where available, compare against PSP outcomes and tighten the policy without guessing
Stores facing card testing often also face scraping, fake accounts, inventory hoarding and scalping. See the broader storefront protection model
.Proof
Evidence that belongs on this page
X
Sorem ipsum dolor
X
Sorem ipsum dolor
Corem ipsum dolor sit amet
.Learn more
Go deeper on payment
fraud and checkout abuse
Guide
How bad bots ruin business logic
Guide
Bot mitigation strategies that actually work
Guide
How to detect bot traffic during a product launch
.FAQ
Questions about card testing and payment fraud bots
What is card testing in simple terms?
It is automated validation of stolen or guessed card details through a real payment flow. The bot submits many attempts and reads the response to learn which data is valid. The merchant’s checkout becomes the testing tool even when the card data was stolen elsewhere
Is card testing the same as carding?
The terms overlap. OWASP uses carding for testing full stolen card records and card cracking for guessing missing expiry dates or security codes. In payment-industry guidance, ‘card testing’ is often used as the umbrella term for automated validation and enumeration
Are card-testing attacks always tiny €1 transactions?
No. Low-value purchases are a common signal, but attackers can also save cards, create customers, start subscriptions, use zero or small authorisations, target donation forms or call payment endpoints directly. Monitor validation functions, not only low-value orders
Does ADPAL replace Stripe Radar, Adyen RevenueProtect or another PSP fraud tool?
No. The PSP has transaction, network and issuer context that an upstream bot layer does not. ADPAL is designed to reduce automated traffic before it reaches that layer. Keep the PSP’s recommended integration, fraud engine and monitoring enabled
Does 3D Secure stop card testing?
It can add strong cardholder authentication and may reduce successful fraudulent payments. It does not automatically remove every enumeration, card-saving or pre-authentication attempt. Use it with bot controls, velocity rules and PSP risk decisions
Should I use CAPTCHA on checkout?
CAPTCHA can help when targeted correctly. Stripe recommends it as one card-testing control and stresses server-side validation. A visible challenge on every purchase can add friction, so many businesses prefer adaptive or risk-based use rather than a universal puzzle
Why is a WAF not enough?
A WAF is essential for many web attacks, but card testing often uses valid checkout requests rather than malicious code. A modern platform may include bot management, yet simple exploit signatures or IP blocks alone are unlikely to understand cross-account payment velocity
Will legitimate orders be declined?
The PSP still decides whether a card payment is approved. ADPAL decides whether an automated request should reach that point. Any automated policy can make mistakes, so rollout should include monitoring, conservative thresholds, allowlists and comparison with real payment outcomes
Can protection help after Visa or my PSP flags the account?
Reducing new automated attempts is important, but it does not guarantee immediate removal from a monitoring or review programme. Contact the acquirer or PSP, follow the remediation plan, preserve evidence and monitor the applicable fraud, dispute and enumeration metrics
Why would attackers use a small shop?
Attackers look for payment flows that are easy and cheap to automate. A small shop is not automatically more exposed, but guest checkout, weak endpoint controls, limited monitoring or an outdated integration can create an opportunity
Can card testing happen through an API or mobile app?
Yes. Any endpoint that creates customers, attaches payment methods, performs authorisations or initiates payments can be targeted. Protect web, mobile and API flows consistently and avoid assuming the visible checkout page is the only route
How do I distinguish a bot attack from a broken retry process?
Stripe warns that excessive legitimate retries can resemble card testing. Compare account ownership, payment method reuse, timing, device/session signals, retry policy and billing events. Fix automated dunning loops before treating every spike as hostile
What should I do during an active card-testing wave?
Contact the PSP, preserve logs, identify targeted endpoints, enable or tighten the provider’s controls, add multi-dimensional rate limits, restrict exposed payment functions and deploy upstream filtering. Use narrow temporary controls and watch genuine checkout conversion
Can ADPAL stop all payment fraud?
No single product can. Card testing is one automated fraud vector. Stolen-account purchases, friendly fraud, refund abuse, triangulation, social engineering and manual fraud need additional payment, identity, operational and dispute controls
Make your checkout a dead end for
card-testing bots
The stolen card list may exist already. The part you control is whether
automated validation can use your payment flow as a free sorting service
Measure the attack surface, reduce the bot traffic upstream and keep
your PSP focused on genuine payment decisions
No credit card
GDPR-ready wording subject to final product and privacy verification.