Key takeaways
- Card testing is when fraudsters use your checkout to check whether stolen card numbers work, usually with small, automated transactions.
- Warning signs include bursts of small payments, high decline rates, many cards from the same IP or device, and mismatched CVV or address data.
- Costs include authorization fees, fraud chargebacks, network scrutiny and potential account reviews.
- Layered defences work best: bot protection, rate limits, velocity rules, CVV and AVS checks, 3-D Secure and active monitoring.
What a card testing attack is
Criminals who obtain stolen card numbers often do not know which ones still work. To find out, they run small test transactions through a legitimate merchant’s checkout. Cards that are approved get used for larger fraud elsewhere or sold on. Cards that decline are discarded.
Most card testing is automated. Bots submit card numbers rapidly, often cycling through many cards, names and addresses. Some attacks use guessed or generated card numbers and try different expiry dates and security codes until something works. Any business that accepts card-not-present payments can be targeted, whether through a website, a donation form or an API. See card-present vs card-not-present transactions for why online payments are more exposed.
Why some checkouts get targeted
Fraudsters look for the path of least resistance. Checkouts are more attractive when they:
- Allow very small payment amounts, such as donations or low-priced digital goods
- Have no bot protection or CAPTCHA
- Allow unlimited payment attempts without rate limits
- Return detailed decline reasons that help attackers refine their guesses
- Do not require an account or any verification before payment
- Expose payment APIs that can be called directly
Warning signs to watch for
Card testing often shows up as a pattern rather than a single suspicious payment. Watch for:
- A sudden burst of transactions, especially outside your normal hours
- Many small or identical amounts, often the minimum your checkout allows
- A spike in declines, particularly for incorrect card numbers, expiry dates or security codes
- Many different cards from the same IP address, device or browser session
- Card numbers that share the same first digits, suggesting a batch from one issuer
- Mismatched or nonsense billing details, such as random names or failed address checks
- New accounts created in quick succession with similar details
A sudden drop in your approval rate can also be an early clue. Our guide to reducing credit card declines explains how to tell normal declines from suspicious ones.
What card testing costs you
Even when the test transactions are tiny, the damage can be real:
- Per-attempt fees: depending on your pricing, authorizations and declines can carry fees, and these add up quickly across thousands of attempts.
- Network fees and scrutiny: card networks have programs aimed at excessive declines and retries, which can lead to additional fees. Check current network rules or ask your processor how they apply.
- Fraud chargebacks: approved test transactions may later be disputed by the real cardholders, raising your chargeback ratio.
- Account risk: a large attack can trigger reviews, holds or reserves from your processor.
- Operational cost: refunding, investigating and cleaning up fake orders or accounts takes time.
How to stop card testing
No single control is enough. The most effective approach layers several defences so that an attacker who gets past one is caught by another.
- Add bot protection. Use a CAPTCHA or invisible bot detection on checkout, donation and account-creation forms.
- Rate-limit payment attempts. Cap how many attempts can come from a single IP, device, session, email or account within a time window.
- Set velocity rules. Flag or block when many different cards are tried from one source, or when one card is tried with many different expiry dates or security codes.
- Require CVV and use AVS. Decline or review payments that fail security code or address checks.
- Use 3-D Secure where appropriate. Issuer authentication adds friction that automated attacks struggle with. See 3-D Secure authentication explained.
- Return generic decline messages. Tell customers the payment did not go through without revealing which field was wrong.
- Review minimum amounts. If you accept very small payments, consider whether a higher minimum makes sense for your business.
- Protect your API. Use secure keys, keep secret keys off the client side and restrict who can create payments.
- Require verification for new accounts. Email confirmation or similar checks before the first payment can slow automated sign-ups.
Our payment fraud prevention guide covers these and other controls in more depth.
It is not only the checkout page
Attackers look for any path that leads to an authorization. Beyond your main checkout, review:
- Donation and tip forms, which often accept any amount
- Card-update and “add a payment method” pages in customer accounts, which may run a small verification authorization
- Free trial sign-ups that validate a card before the trial starts
- Payment links and invoices that are shared publicly or never expire
- Gift card purchase flows, which are attractive because value can be moved quickly
Apply the same bot protection, rate limits and velocity rules to each of these. A strong main checkout does little good if an unprotected side door is open. Periodically list every page and endpoint that can create a payment or verify a card, and confirm each one is covered by the same controls.
What to do if you are under attack
If you see the signs of card testing happening now:
- Contact your payment provider immediately. They can help apply blocks and tighten rules quickly.
- Temporarily tighten controls, for example by adding a CAPTCHA, raising minimums or pausing the affected form.
- Block the sources you can identify, such as IP ranges, devices or email patterns.
- Refund or void approved test transactions where appropriate to reduce the chance of later fraud disputes. Your provider can advise on the best approach.
- Review afterwards what allowed the attack and which permanent controls to add.
How Cirqle helps
Cirqle combines real-time fraud screening with 24/7 platform monitoring to help detect unusual patterns, and uses tokenization so card numbers are not stored on your systems. See tokenization vs encryption for why that matters. You can follow transaction activity through the dashboard, read more on our security page, and reach our support team Monday to Sunday, 7am to 9pm EST. Keeping your PCI compliance current is also part of a strong defence.
The bottom line
Card testing is common, automated and often quiet at first. Watch for bursts of small payments and rising declines, layer your defences and act quickly when something looks wrong. If you suspect an attack or want to review your checkout’s protections, contact our team.
Frequently asked questions
What is a card testing attack?
It is when fraudsters use a merchant's checkout to check whether stolen or generated card numbers work, usually through many small, automated transactions.
Why would fraudsters test cards on my small business?
Smaller checkouts sometimes have fewer protections, such as no bot detection or rate limits, and low minimum amounts make tests less noticeable.
Should I refund card testing transactions?
Often yes, since approved test payments may later become fraud chargebacks. Talk to your payment provider about the best approach for your account.
Payments that never stop moving.
Talk to a Cirqle payment specialist about stable processing, fast onboarding and payouts that keep cash flowing.
Get approved