Card testing attack: how fraudsters probe checkout, and how to stop it

A card testing attack is when fraudsters run stolen or guessed card details through your checkout, usually with bots and small or $0 charges, to learn which cards work before they use or sell them. Visa says attack transactions are often under $10. The first sign is usually a sudden burst of small declined payments.

It costs you even when nearly every attempt fails. Declines can carry authorization and gateway fees, approved tests come back weeks later as fraud reports and chargebacks, and a high decline rate can make issuers wary of your real customers. Visa puts annual fraud losses from enumeration, its term for automated card testing, at over a billion dollars across the payments ecosystem.

The fix is layered: controls on every endpoint that can validate a card, not just the checkout page, plus a plan for the first hour. This guide follows Visa's and Mastercard's rules and guidance as of November 2026. Flux's own fraud screening is covered at the end (how Flux fits).

What is a card testing attack?

The Visa Core Rules define an enumeration attack as the systematic or routine submission of card-not-present transactions to fraudulently obtain or validate payment information. Mastercard describes card testing as small or zero-dollar transactions on stolen card numbers to find the active ones, run one at a time, through criminal testing services, or with bots and scripts.

Enumeration vs account testing

Visa splits the activity into two schemes, and different controls stop each. Enumeration, or a brute force attack, is guessing: the fraudster picks one or more BINs (the leading digits that identify the card's issuing bank) and cycles through card number, expiry, CVV2 and postal code combinations until approvals come back. Account testing starts with cards already stolen: one or two low-amount transactions per card to see which are still active. Visa notes it is also called BIN testing, card stuffing, card tumbling or Credit Master attacks. Visa also uses enumeration as a catch-all for both schemes, as in its loss figures and the VAMP criteria below.

OWASP's list of automated threats draws the same line, as carding (OAT-001) and card cracking (OAT-010). The practical lesson: a per-card attempt limit slows enumeration but does little against account testing, because each card is tried only once or twice.

Why the amounts are small or zero

The fraudster wants the issuer's answer, not your product. Testers favor card setup flows because a validation there usually doesn't show up on the cardholder's statement. Even a decline helps them: Mastercard calls it a filtering mechanism.

Visa calls enumeration "often a leading indicator or precursor to downstream fraud." Valid details are used or sold on carding sites, and in Visa's fiscal 2023 data a third of enumerated accounts saw fraud within five days. That fraud may land on another merchant, but the test ran on yours.

How fraudsters get into your payment flow

Testers use any request that makes an issuer answer. Visa says the most common way in is a legitimate e-commerce merchant with weak fraud controls.

• Checkout, especially guest checkout. Guest checkout makes testing easier, since there is no login or session to validate first.
• Save-card and $0 verification flows. Adding a card gets an issuer answer with no purchase. Visa says to rate-limit the Add Card and Save Card steps, cap cards per account and per session, and limit how many accounts one IP address can create.
• Donation and pay-what-you-want forms. Visa singles out sites that accept donations or let the payer type the amount (more on payments for nonprofits).
• 3-D Secure requests. Visa has documented enumeration run through authentication requests, not only authorizations.
• Your API. Bots can skip your form. Scripts can call your payment endpoint directly, and a leaked secret key lets attackers create payments and save cards.
• Your gateway login. Visa describes merchant account takeovers with credentials obtained by phishing, or by calling a gateway and pretending to reset them.
• Weak carts and plugins. Visa has seen fraudsters target merchants on gateways and shopping carts known to lack adequate fraud controls, then pivot to similar merchants. It also saw testers work through one merchant category at a time (in 2021, drug stores and colleges among others). If you sell through a cart platform or plugin, check whether checkout and any add-payment-method or saved-card page can take a server-side CAPTCHA and rate limits, turn off saved-card pages you don't use, and keep the cart and payment plugin updated. On plugin-based stores these controls usually need a code change or a security add-on.

Signs your checkout is being tested

Card testing is easy to spot once you know where to look, and easy to miss in a daily revenue total.

Visa notes that some issuer codes can reach you as 05, depending on whether your acquirer is set up to receive the original codes, so generic declines can hide the pattern. And don't wait for a big burst: Mastercard says smaller testing events and single tests are equally important indicators.

A worked example (hypothetical)

Say an online store normally sees about 60 card attempts a day. One night, 3,000 attempts arrive in two hours, all for $1.00, from a few IP ranges with random names. Most decline with codes 14, 54 and N7. Eighty approve, and nobody is awake to notice.

By morning the store has 3,000 authorization attempts that may each carry a fee, 80 approved charges on stolen cards that can return as fraud reports and chargebacks, and a decline rate far above normal. The code 14 cards fall in Visa's never-retry category.

What card testing costs you, even when the charges fail

Visa lists the fees an attack can generate: authorization (for approvals and declines), clearing and settlement, interchange, dispute processing, system integrity and gateway fees. What lands on you depends on your pricing and processor. Then come the indirect costs:

• Chargebacks on approved tests, which are real charges on stolen cards.
• Declines for real customers. Processors warn that a higher decline rate can hurt your standing with issuers and raise declines on legitimate payments even after testing stops.
• Lost goods and time spent fulfilling orders unrelated to legitimate customers, as Visa puts it.
• Scrutiny, including possible non-compliance assessments and identification in Visa's risk monitoring programs.

A card testing guide on Visa Canada's small business site sketches the timeline for an unprepared business: mass orders and possibly a processing shutdown on day 1, high authorization fees over days 2-30, then chargebacks on unreversed transactions over days 31-120.

Visa's enumeration criteria under VAMP

The Visa Acquirer Monitoring Program (VAMP) has its own enumeration test and requires acquirers to take proactive steps to keep merchants under it. It has two parts, and acquirers and processors read it as requiring both:

• Enumeration ratio: enumerated authorization attempts, approved and declined, are 20% or more of all authorization attempts, approved and declined.
• Enumeration count: at least 300,000 enumerated transactions, approved and declined, in the month.

This is often described wrongly. The enumeration test counts authorization attempts, declines included, and it is not part of VAMP's main ratio, which divides fraud reports plus disputes by settled card-not-present transactions.

Still, the two connect. On our reading of that formula, declined tests never enter the main ratio, but approved tests that settle add to its denominator, and if they are reported as fraud or disputed, to its numerator. The fact sheet lists no exclusion for refunds.

Visa can also require an acquirer or merchant to deploy remediation tools for unusual activity found through VAMP. A new merchant account isn't a way out: where a merchant's name, data or performance was altered to get around VAMP, Visa can charge the acquirer USD 25,000 per merchant per month and permanently disqualify the merchant and its principals. No processor can opt you out of these programs (see the chargebacks hub).

Retry rules that apply after an attack

Under the Visa Core Rules (October 2026 edition), retrying the attack's cards can break network rules:

• Category 1, "issuer will never approve": never resubmit an authorization or account verification for that card. Codes 04, 07, 12, 14, 15, 41, 43, 46, 57, R0, R1 and R3.
• Categories 2, 3 and 4: up to 20 reattempts in 30 days, covering codes such as 51, 54, 59 and N7. Older guides say 15, the 2021 rule.

Mastercard also charges acquirers for excessive authorization attempts on declined cards. Ask your processor how those limits apply to you.

How to stop card testing: layered controls

No single control stops both schemes. Filters built on a single signal, such as IP address, are usually not enough. Visa's June 2026 merchant guide on enumeration sets out the layers.

Visa also recommends session throttling, CSRF tokens and network tokens with domain restrictions. If you check cards without a purchase, Visa requires a zero-amount account verification when a card is stored or validated separately from a purchase, so a $1 authorize-and-void step doesn't fit.

Put the controls on every request that can make an issuer answer, and tune them to your own baseline, because limits that are too tight turn away good customers (see why velocity limits decline transactions). Compliance isn't a control here: PCI DSS protects payment account data, but it doesn't stop someone checking cards they already hold on your checkout.

Under attack right now? The first-hour checklist

Confirm the attack, stop new attempts, then clean up what got through. The steps below draw on Visa's June 2026 merchant guide and common processor advice.

1. Confirm the pattern from the signals above, and note which page or endpoint is being hit.
2. Add CAPTCHA and rate limits to every card-validating request. If attempts share an email, phone, IP or device, block those, then check the blocks won't catch real customers.
3. Close the door for now. Turn off guest checkout, the save-card page or the open-amount field until the controls are in place.
4. Roll your API keys if the testing goes straight to your API, as Visa recommends.
5. Call your processor. It may already see the attack. Have the source IPs, names and billing addresses entered, emails and user-agent headers ready.
6. Don't ship any order tied to the attack.
7. Void or refund the test charges that went through to head off disputes, as Visa advises. A refund won't undo a fraud report already filed.
8. Stop retrying those cards. Retrying cards set up by fraudulent customers just repeats the attack, and a Category 1 decline is never retried.
9. Keep the logs and keep watching for days afterward.

Card testing is a crime. Under 18 U.S.C. § 1029, knowingly possessing 15 or more counterfeit or unauthorized access devices (a term that covers stolen card numbers) with intent to defraud carries up to 10 years in prison for a first offense. You can report an attack to the FBI's Internet Crime Complaint Center. This is general information, not legal advice: talk to your attorney about your situation.

How Flux fits

Flux fraud detection screens each transaction in real time against risk signals and the rules you set. Suspicious payments are held or declined before they settle, clean payments pass straight through, and every decision is visible in your dashboard. You control the thresholds. It works at the processing layer, alongside the checkout controls above.

Flux supports 3-D Secure on card payments through hosted checkout and payment links and invoices, and you choose whether it runs on every card payment or only on riskier ones. Its liability shift covers eligible fraud chargebacks only.

Card details go into hosted fields, origin-isolated iframes on payments.fluxpayments.com, so card data never touches your servers. That keeps card data off your systems; it doesn't stop a bot using the form, so CAPTCHA and rate limits still belong in your checkout. Payments post to the live dashboard and webhook events as they happen, so you can watch for a burst instead of finding it in tomorrow's report, and the API makes refunds a single call. Your API keys live in the developer portal at portal.fluxpayments.com, and for anything else during an attack you can email support@fluxpayments.com.