A card testing alert is a warning from your payment processor, gateway, or fraud tool that someone is using your checkout to check whether stolen card numbers work. Testers send small authorizations, note which ones approve, and keep the live cards. The alert fires when volume, velocity, or decline rates move outside your normal pattern.
What triggers a card testing alert?
Processors watch a fixed set of signals. One bad night on a single signal can flag an account. Several at once almost always does.
- Bursts of attempts. Dozens of payment tries in minutes, often at hours that do not match your customer base.
- Low ticket sizes. $0 to $2 authorizations, digital goods, or the cheapest item in the catalog.
- High decline rates. A block of failed payments that sits far above your normal share.
- Repeated billing data. One address, email, or device tied to many different card numbers.
- Failed AVS and CVV checks. Mismatched address or security code on attempt after attempt.
- Card concentration. Many cards from one bank or one country hitting a US store.
Velocity rules and decline ratios
Gateways count attempts per card, per IP, per email, and per device over a rolling window. One card tried five times in ten minutes is a stronger signal than five cards tried once each. Your processor may not publish the exact rule set, so treat the alert itself as the signal.
Checkout signals
Testers do not fill out a form the way a shopper does. Look for missing fields, copy-paste patterns, and sessions that jump straight to the payment step. Bot traffic on the card form with no product page views is another common marker.
What the alert itself contains
Most alerts name a time window, a count of attempts, and a decline share. Some include the IP range or BIN block behind the run. Save the message. It is the baseline you compare the next attack against.
Why small merchants get hit
Testers pick targets by how easy the checkout is to script. A store with no CAPTCHA, no rate limit, and instant approval on a $1 item is an easy target. Large retailers spend on fraud tooling, which leaves small stores as the cheaper host for a test run.
The attacker does not care whether the order ships. The value is the approve or decline response, and your gateway returns that in a fraction of a second.
What to do in the first hour
- Confirm the alert. Pull the transaction log for that window. Check whether the attempts share an IP, card BIN, email domain, or device.
- Raise the floor. Set a minimum order value or require a small deposit on the cheapest item.
- Turn on the challenge. Enable CAPTCHA or a bot filter on the payment step. This cuts most scripted traffic.
- Add 3-D Secure. Require the issuer challenge on high-risk orders. Testers drop off because they do not control the cardholder's phone.
- Block what you can see. Add the IPs, BINs, and email domains from the log to your deny list. Keep the list short and dated.
- Call your processor. Say you saw card testing and ask what they need from you. Some will adjust your decline threshold while the attack runs.
- Hold suspicious orders. Review anything that matches the pattern by hand before it ships.
Card testing alert or a real sales spike?
A real spike brings product page views, carts, and repeat buyers. Card testing shows up as payment attempts with thin session data and no browsing. Check your funnel before you credit a promo.
One more tell: a real spike produces a mixed spread of card brands and issuers. Testing runs draw from one narrow BIN range at a time.
Prevention that holds up
- Rate limit the payment endpoint by IP and by card fingerprint.
- Require CVV and AVS on every order, and decline on mismatch instead of flagging it.
- Put the bot check on the card form, not just the login page.
- Watch your decline rate each week. A slow climb can be a test run that has not tripped an alert yet.
- Keep the chargeback math in view. Approvals that turn into disputes cost a fee on top of the lost sale.
Frequently asked questions
Does a card testing alert mean my site was breached?
No. Card testing uses card numbers stolen elsewhere and pushed through your public checkout. Your database and customer accounts are untouched in most cases. The damage lands on processing fees, chargebacks, and your standing with the processor.
Do failed card testing attempts cost money?
Yes, in several ways. Many plans bill per authorization, decline-heavy accounts draw scrutiny, and any approval that becomes a dispute adds a chargeback fee. Enough of them can put a merchant account at risk.
How long does an attack last?
Hours, sometimes days. Attackers move on when the approval rate drops. Blocking the scripted path with CAPTCHA and 3-D Secure ends most runs faster than manual review does.
Should I report it?
Tell your processor and keep the log. In the US, if you handle card data and suspect a breach of your own systems, state and federal rules can require notice. Card testing alone does not trigger that duty in most cases.
Can I just refund the test orders?
You can, but refunds do not erase the authorization attempts or the fees. Cancel the orders, keep records, and fix the control that let the run through. Repeat testers return to stores that stay open.