Industry Payment Guides

Card Testing Attacks: How to Stop Bots From Hitting Your Checkout

Hit by a card testing attack? Use this triage plan to stop bots at checkout, cut decline fees, and keep your processor relationship in good standing.

Red padlock resting on a backlit laptop keyboard

Photo: Pixabay

On this page 8 sections
  1. What a Card Testing Attack Looks Like at Your Checkout
  2. Signs Your Store Is Being Used to Test Stolen Cards
  3. Why Card Testing Costs You Money Even on Declines
  4. Emergency Steps to Stop Card Testing on Your Website
  5. Carding Attack Prevention: CAPTCHA, Rate Limits, and Velocity Rules
  6. Locking Down Donation Pages and Low-Dollar Products
  7. Talking to Your Processor About Excessive Decline Fees
  8. Next Steps for Your Online Store

Key takeaways

  • A sudden burst of many small declined transactions, often from guest checkouts and low-dollar items, is the classic sign of a card testing attack.
  • Declines still cost money through per-attempt fees, possible network penalties, fraud chargebacks on approved cards, and processor scrutiny.
  • During an attack, add friction fast: turn on CAPTCHA and rate limits, block bad traffic, pause vulnerable forms, and void approved test orders before you ship.
  • Document the attack and talk to your processor early about fees, fraud filters, and any account review.

A card testing attack happens when fraudsters use your online checkout to check whether stolen card numbers still work. Bots submit hundreds or thousands of small payment attempts. Most fail, and a few go through. The cards that get approved are then used for larger purchases elsewhere. Your store isn't the final target, but you still pay for the attack. This guide covers how to recognize one, what to do while it's happening, which controls stop it from coming back, and how to talk to your processor about the fees it leaves behind.

What a Card Testing Attack Looks Like at Your Checkout

Card testers favor stores where a payment attempt is quick, cheap, and anonymous. Common targets are e-commerce sites with guest checkout, low-priced products, open-amount donation forms, and "add a payment method" pages that run a small verification authorization.

There are two common patterns:

  • Validation of stolen lists. The attacker already has full card numbers, usually from a breach or a phishing kit. They test each one to see which accounts are still open.
  • Enumeration or guessing. The attacker starts with a known card prefix (the BIN) and cycles through possible numbers, expiration dates, or security codes until something is approved.

Either way, the bot doesn't care what it buys. It wants an approval or a decline code that tells it something useful.

Signs Your Store Is Being Used to Test Stolen Cards

Most owners find out from a gateway alert, a strange spike on the dashboard, or a batch report that doesn't match the order volume. Look for:

  • Many small declined transactions in a short window, often overnight or outside your normal traffic pattern.
  • Repeated decline reasons such as invalid card number, incorrect CVV, expired card, or "do not honor."
  • Card numbers that share the same first six to eight digits or appear in near-sequential order.
  • Lots of attempts from one IP address, or from a rotating pool of IPs that all behave the same way.
  • Guest checkouts with gibberish names, disposable email addresses, or the same billing address reused with different cards.
  • A flood of orders for your cheapest item, a free-shipping sample, or a minimum donation.
  • Gateway transactions with no matching order in Shopify, WooCommerce, or your store platform. This often means the bot is hitting your payment API directly and skipping your storefront entirely.

If your gateway shows activity your store platform doesn't, assume your API credentials or payment form endpoint are being called directly. A CAPTCHA on the checkout page won't stop that by itself.

Why Card Testing Costs You Money Even on Declines

A decline doesn't mean you're off the hook. Depending on your pricing and agreements, an attack can hit you several ways.

CostWhen It HitsWhat to Know
Per-attempt or authorization feesEvery attempt, approved or declinedMany gateway and processor agreements charge per authorization. Check your statement and contract.
Network fees on authorizationsOften on every attemptCard networks can assess fees on authorization activity, including declines. Your processor passes these through according to your pricing.
Excessive decline or misuse penaltiesWhen decline volume or retry patterns cross network thresholdsNetworks monitor authorization behavior. Processors may pass along resulting fees. Ask your processor for current specifics.
Fraud chargebacksWeeks later, on attempts that were approvedReal cardholders dispute charges they didn't make. Each chargeback typically carries a fee and counts against your ratios.
Account scrutinyDuring or after the attackSpikes in declines and fraud can trigger reviews, holds, reserves, or termination.
Lost inventory and shippingIf approved test orders get fulfilledShipping a fraudulent order adds product cost to the fees.

Illustrative example only: if your agreement charged a hypothetical $0.10 per authorization attempt and a bot ran 5,000 attempts overnight, that's $500 in attempt fees before any network charges or chargebacks. Your actual fees depend on your contract.

Online payments already cost more to process because of the higher fraud risk. Our explainer on card-present vs. card-not-present fees, fraud, and rules covers why. A card testing attack makes that exposure worse. And if approved test charges turn into disputes, it helps to understand the full chargeback dispute lifecycle before the notices arrive.

Emergency Steps to Stop Card Testing on Your Website

When an attack is underway, speed matters more than elegance. Losing an hour of sales costs less than thousands of fraudulent attempts. Work through these in order:

  1. Confirm the pattern. Pull the last few hours of gateway activity. Note the time the spike started, the number of attempts, the decline reasons, and the IPs or countries involved.
  2. Call your processor or gateway support. Tell them you're under a card testing attack. They may be able to apply temporary blocks, tighten filters on their side, or flag the activity in your account notes.
  3. Turn on friction immediately. Enable CAPTCHA on checkout and on any payment form. Temporarily require customer accounts, or add email verification for guest checkout.
  4. Tighten AVS and CVV rules. Set your gateway to decline transactions that fail the security code check or have serious address mismatches, if it isn't already.
  5. Block the obvious sources. Block offending IP addresses and ranges. If you don't ship to certain countries, block traffic from them at your firewall or CDN.
  6. Pull the bait. Unpublish or hide the low-dollar product, sample, or donation form the bots are targeting.
  7. Pause payments if you have to. If attempts keep coming, put checkout into maintenance mode or disable the payment method until your controls are in place.
  8. Rotate credentials. If you see gateway transactions without matching store orders, regenerate your API keys and transaction keys. Update your store integration and check that no keys are exposed in front-end code or public repositories.
  9. Stop approved test orders. Hold fulfillment on suspicious approved orders. Void them if they haven't settled. Ask your processor whether to refund settled ones, since refunding before a dispute can sometimes head off a chargeback.
  10. Document everything. Save screenshots, exports, timestamps, and support ticket numbers. You'll need them when you ask about fee relief.

Carding Attack Prevention: CAPTCHA, Rate Limits, and Velocity Rules

Once the fire is out, put layered controls in place so the next attack fails quickly and cheaply. No single tool stops every bot, so stack them.

ControlWhat It StopsTrade-Off
CAPTCHA (preferably invisible or risk-based)Simple scripted checkout submissionsVisible challenges add friction for real shoppers
Rate limits per IP, session, or accountRapid-fire attempts from one sourceAttackers can rotate IPs, so pair it with other rules
Velocity rules at the gatewayToo many attempts per card, BIN, email, or device in a set windowRules set too tight can block legitimate retries
AVS and CVV enforcementCards with guessed or missing dataSome legitimate international or address-change orders may fail
3-D Secure authenticationMany fraudulent card-not-present paymentsAdds a step for some customers
Bot management or web application firewallAutomated traffic before it reaches checkoutMay carry added cost and setup time
Hosted or tokenized payment fieldsDirect abuse of exposed payment endpointsRequires your gateway and platform to support them

Setting Velocity Rules That Make Sense

Good velocity rules reflect how your real customers behave. A shopper might retry a card two or three times after a typo. They almost never try a dozen different cards in ten minutes. Start with limits like:

  • A cap on payment attempts per IP address per hour
  • A cap on distinct cards used per session, email, or device
  • A cap on declines per account before checkout locks temporarily
  • Alerts when total declines in an hour exceed your normal pattern

Review the rules after a few weeks and loosen any that block good orders.

Keep Your Gateway Locked Down

Many attacks skip the storefront and go straight to the payment endpoint. Keep API keys server-side, limit which domains can call your payment form, and remove old integrations and test credentials you no longer use. If you're comparing options, our page on online payment gateways shows the gateways and integrations MannyPay supports, including Authorize.net, NMI, Shopify, and WooCommerce. Ask what fraud filtering each one offers before you switch.

Adding 3-D Secure authentication is another layer worth discussing with your provider. It can shift some fraud liability and raise the bar for bots.

Locking Down Donation Pages and Low-Dollar Products

Card testers look for the cheapest, least-protected way to get an authorization. On most e-commerce stores, that's one of a few places:

  • Open-amount donation forms. If donors can enter $1, so can a bot. Set a sensible minimum, require CAPTCHA, and limit attempts per visitor. If you also ask donors to cover fees, see our guide on asking donors to cover processing fees.
  • Digital downloads and samples. Nothing ships, so testers get an instant result. Consider a minimum order value or requiring an account for very low-priced items.
  • Gift cards. Validated stolen cards are often used to buy gift cards. Add review steps or stricter limits on gift card purchases.
  • "Add a card" and free-trial pages. These often run a small or zero-dollar verification. Put the same CAPTCHA and velocity rules on them as on checkout.
  • Detailed decline messages. Don't tell visitors why a card failed (for example, "wrong CVV"). A generic "payment couldn't be processed" message gives bots less to learn from.

Guest checkout is good for conversion, but it's also what bots exploit. Our comparison of guest checkout vs. forced accounts can help you decide where to add friction without hurting sales.

Talking to Your Processor About Excessive Decline Fees

Call your processor during the attack and again after it. Waivers or credits are at the processor's discretion and not guaranteed. A documented, well-handled incident gives you a much better conversation than discovering the fees on next month's statement.

Ask these questions:

  1. What fees were charged because of the attack: authorization, decline, network, or penalty fees?
  2. Can any of them be credited or reviewed, given the evidence I've provided?
  3. Was my account flagged, and did activity approach any network monitoring thresholds?
  4. What fraud and velocity filters are available on my gateway, and which do you recommend turning on?
  5. Will this affect my reserve, payout timing, or account standing?
  6. What should I do with approved test transactions: void, refund, or wait?

If funds are being held after an attack, our guide on why processors hold funds and how to fix it explains the documents that usually help. If you also sell on Amazon, see our guide to the Amazon account level reserve and why your disbursement shrank. And if your provider can't explain your fees or offer basic fraud tools, our list of questions to ask a merchant service provider is a good place to start comparing.

Fee rules, network programs, and liability terms change. Confirm current terms with your processor and read your merchant agreement. For legal or contractual questions, consult a qualified professional.

Next Steps for Your Online Store

Use this short checklist before the next bot finds you:

  • Turn on CAPTCHA for checkout, donation, and add-a-card forms
  • Set rate limits and gateway velocity rules based on real customer behavior
  • Enforce CVV and AVS checks, and evaluate 3-D Secure
  • Secure and rotate API keys, and remove unused integrations
  • Set minimums on donations and very low-dollar items
  • Set up decline-spike alerts so you hear about attacks in minutes, not days
  • Keep your processor's fraud support contact handy

MannyPay provides payment processing for eCommerce businesses, including online gateways, 3-D Secure authentication, and integrations with major store platforms. To review your current setup and fraud controls, request a free quote and a MannyPay specialist will respond within one business day, or contact the MannyPay team with questions.

About the author

MannyPay Editorial Team

Beyond the Swipe's editorial desk researches the publication's guides and news and cites its sources in every article. Articles reviewed by a named MannyPay editor carry that editor's byline.

This article is for general educational purposes and is not legal, tax or financial advice. Card network rules and state laws change; confirm current requirements for your business.

Related reading