Card Testing Attack? What to Do Now and How to Prevent It

A card testing attack happens when a criminal uses your checkout to find out which stolen card numbers still work. Usually a script runs it, sending hundreds or thousands of small payment attempts. If it is happening to you now, do four things in this order. Turn on your gateway’s velocity and fraud filters. Put a challenge such as CAPTCHA in front of the payment form. If the attempts keep coming, take the public form offline. Call your processor. After that, clean up: void or refund every test charge that was approved, then watch for chargebacks over the next few months.

What follows is a working guide for a merchant, or the MSP who looks after one, in the middle of an attack. It covers how to confirm what you are seeing, how to stop card testing in the first hour, what to clean up afterwards, and how to prevent the next attack. If you would rather work from a printable list, use our card testing incident checklist.

How do I know my website is being card tested?

Card testing rarely looks like ordinary fraud. You don’t see one large stolen-card order. You see a pile of small, odd transactions. Stripe’s card testing guide says most attacks show up as “a significant increase in failed authorization and payments.” The usual signs:

1. A burst of declined transactions. Dozens or hundreds of attempts in minutes or hours, with a much higher decline rate than you normally see.
2. Very small amounts. Low-value charges, or the minimum your form will accept. Donation forms and pages where the customer types the amount get hit especially hard, a point Authorize.net makes in its card testing article.
3. Odd billing data. Stripe mentions customer names and email addresses that make no sense. You may also see mismatched billing addresses, repeated names on different cards, or many card numbers that share the same first six digits.
4. Traffic from everywhere. The attempts come from many IP addresses or countries, often spread out so that no single address stands out.
5. Generic decline codes. Most of the declines carry vague, generic reasons rather than “insufficient funds”, plus a scattering of AVS and CVV mismatches.

If you see a pattern like this on your payment form, treat it as an incident now and investigate the details later. The costs grow with every minute the attack runs.

Why does a card testing attack cost me money if most cards are declined?

Declines still cost you. Many pricing plans charge a fee per authorization attempt, approved or not. In an example Authorize.net published through Visa, a business’s monthly authorization fees went from about $40 to $15,000 during an attack. Some of the stolen cards will be approved, and their real owners will dispute those charges later.

There is also a reputation cost. Stripe warns that a high decline rate “might damage the reputation of your business with card issuers,” which can push up declines on legitimate customers even after the attack is over. If the attack is big enough, it can count toward card network monitoring programs. Visa, for example, tracks enumeration under its Acquirer Monitoring Program, which we explain in Visa VAMP enumeration thresholds. Authorize.net’s own timeline adds that on day one your acquirer may stop your processing until you show a mitigation plan.

What should I do in the first hour?

Speed matters more than getting everything right the first time. Contain the attack first and tune the settings afterwards.

1. Turn on velocity limits at your gateway. Most gateways can cap how many transactions are accepted per hour, per day or from one IP address. For example, Authorize.net has an Hourly Velocity Filter and a Transaction IP Velocity Filter (see our Authorize.net card testing guide). Stripe users can write velocity rules in Radar if their plan includes custom rules. During an attack, set the limits tight and loosen them once it ends.
2. Decline or hold anything that fails AVS or CVV. If your gateway lets you choose what happens on a card code or address mismatch, choose decline, or hold for review.
3. Put a challenge in front of the form. Turn on CAPTCHA, or whatever bot challenge your payment page or hosted form offers. Stripe’s advice is to require the CAPTCHA on every request that can validate a card or take a payment, and to check it on the server, not just in the browser.
4. Raise the minimum amount. If you take donations or let customers enter their own amount, set a minimum high enough that testing becomes expensive.
5. Take the public form offline if the attempts keep coming. This feels drastic, but a few hours without online payments usually costs less than thousands of fraudulent authorizations. Put up a short notice and give real customers another way to pay, such as an invoice link or a phone number.
6. Call your processor or gateway support. Tell them you are under a card testing attack and give them the time window. They may be able to block traffic upstream, and they will want to see that you are acting. Write down the case number.
7. Rotate any exposed credentials. If the attempts are reaching the gateway without going through your payment page, your API keys or form credentials may have leaked. Stripe warns that testers can use leaked keys to create payments and save cards directly. Ask your developer or MSP to rotate them.

How do I clean up after the attack?

When the attempts have stopped, or slowed to a trickle, start cleaning up. This is where you head off chargebacks.

1. Export the attack window. Pull every transaction from the start of the attack to now from your gateway report. Keep the export for disputes and for your processor.
2. Void approved test charges that haven’t settled. A void cancels the charge before it settles. With Authorize.net, for instance, unsettled transactions are voided and settled ones are refunded.
3. Refund the ones that already settled. Stripe’s checklist for an active attack says to “refund fraudulent payments to avoid disputes.” A refund costs you less than a chargeback.
4. Don’t ship anything. Cancel any physical orders that came from attack traffic, even if the payment was approved.
5. Don’t retry declined cards. Stripe cautions that retrying cards saved by fraudulent customers just repeats the attack. Turn off automatic retries for anything created during the attack window.
6. Watch for chargebacks. Authorize.net’s timeline expects chargebacks and their fees to arrive between day 31 and day 120. Mark the attack window in your records so whoever handles disputes can spot those charges.
7. Write a short incident note. Record when the attack started, how you noticed it, what you turned on, and how many attempts and approvals there were. Your processor, your insurer or your next PCI assessment may ask for it.

How do I prevent card testing on my website?

No single setting stops every attack. Stripe notes that simple rules built on one signal, such as IP address, are usually not enough on their own, because testers rotate addresses and browsers. Prevention works in layers:

1. Keep sensible velocity limits on permanently. Base them on your normal hourly and daily volume, with some headroom, and review them every quarter.
2. Use a hosted payment form or hosted fields. These keep card data off your servers, and many include built-in rate limits or a CAPTCHA option. They can also make your PCI scope smaller. See which PCI SAQ do I need.
3. Don’t leave a payment form wide open. Stripe suggests requiring a login or a session check before payment where your business allows it, and protecting the form with CSRF tokens.
4. Set realistic minimum amounts on donation and custom-amount forms.
5. Send the data your fraud tools need. IP-based filters only work if the customer’s IP address is passed with each transaction, and the same goes for billing address and email.
6. Watch your decline rate. Set up an alert, such as a daily email or a dashboard, so a spike gets noticed within minutes instead of at month-end.
7. Agree who responds. If an MSP manages the site, decide in advance who can turn on filters, who calls the processor, and who can take the form offline. The CardSecurity MSP program is built for this kind of shared responsibility across many merchants.

Where does CardSecurity fit?

CardSecurity card-testing protection is live in pilot. It scores every checkout attempt before anything reaches the processor. The signals include rapid retries from one browser or network, repeated issuer declines, attacks spread across a merchant’s traffic, and issuer fraud alerts. Low-risk customers go straight through. Riskier attempts are asked to verify. Scripted attackers are blocked. Each attempt is claimed once: replays and duplicates are refused, and an attempt whose result is unclear is held for reconciliation and never resubmitted. Flagged payments go to a review queue. Merchants choose Relaxed, Standard or Strict protection, and MSPs can manage many merchants from one partner portal. Card entry runs in Payroc Hosted Fields, so CardSecurity never sees card numbers.

Today CardSecurity works with Payroc. Support for other processors, including Authorize.net, is in testing. If you use a different processor, tell us which one.

Frequently asked questions

What is a card testing attack?

A card testing attack is when criminals use your online checkout to find out which stolen or guessed card numbers are still valid. They usually run a script that sends many small payment attempts, often from many IP addresses. Cards that are approved get used or sold elsewhere. Your business pays the authorization fees, absorbs the declines and deals with any chargebacks. Other names for it include carding and enumeration.

Should I refund card testing transactions?

Yes. Void any approved test charges that haven’t settled, and refund the ones that already have. A refund is almost always cheaper than a chargeback, and the real cardholders will often dispute charges they don’t recognize. Stripe recommends refunding fraudulent payments to avoid disputes. Keep an export of the attack window, because some chargebacks can still arrive weeks or months later.

Will my processor freeze my account after a card testing attack?

It can happen. Authorize.net notes that during an attack an acquirer may stop processing until the merchant shows a plan to deal with it. Calling your processor early, showing what you have already turned on and refunding approved test charges usually helps. Every processor has its own risk policy, so ask directly what they need from you to keep or restore processing.

Does CAPTCHA stop card testing?

CAPTCHA stops a lot of scripted card testing, but not all of it. It only works if it is checked on every request that can take a payment or save a card, and if it is verified on the server. Stripe suggests switching CAPTCHA type if attacks continue. Use it together with velocity limits, AVS and CVV handling, and decline-rate monitoring, not on its own.

How long does a card testing attack last?

An active burst can last from minutes to days, and attackers often come back to a form that worked for them. The consequences last longer. Authorize.net’s timeline puts authorization fees in the first month and chargebacks between roughly day 31 and day 120. Plan for at least four months of monitoring after the attack window, and leave your new controls switched on.

If card testing keeps hitting your checkout, see how CardSecurity card-testing protection scores each attempt and stops scripted attackers before they reach your processor.