Card testing
explained.

How card testing works

Stripe describes card testers using both card setup and payments to validate card details:

• Card setup (saving a card, zero-amount validations) is popular because it often doesn't appear on the cardholder's statement.
• Small payments, which cardholders are less likely to notice.

Scripts run large batches at once and read the issuer or 3DS responses to see which cards work. Valid cards are then used elsewhere or resold. Stripe also lists carding, account testing, enumeration and card checking as other names.

BIN attacks and enumeration

A BIN (bank identification number) is the first digits of a card number that identify the issuer. In a BIN attack, the fraudster takes a known BIN and generates the remaining digits, expiry dates and security codes, firing them at a checkout until some authorize. Visa describes these enumeration attacks as automated testing to guess the full account number, CVV2 and/or expiry date.

Signs you are being tested (per Stripe)

• A spike in failed or blocked payments.
• A spike in declined API requests and generic declines.
• Many low-value payments, often with nonsense names and emails.
• Many different cards from one IP, device, email or shipping address.

What it costs you

Stripe lists the consequences: successful test charges lead to early fraud warnings and fraud disputes; high decline rates can make issuers treat all your payments as riskier, even after the attack ends; authorization and dispute fees add up; traffic strains your systems; and heavy card testing can push you into card network monitoring programs.

How to stop it

• CAPTCHA on payment and card-saving endpoints, validated server-side.
• Rate limits by IP, account and device, for example capping new customers or card additions per IP per day.
• Limit access to the payment form, for example requiring a session or login before card entry.
• Velocity rules in your fraud tool on cards per customer, per device and per IP.
• Retry carefully. Stripe warns aggressive payment retries can look like card testing to issuers.
• Refund successful test charges promptly to head off disputes.

A worked example

A donation page with a "pay what you want" field gets 2,000 attempts of $1 overnight, 140 of which succeed. The merchant refunds the 140 charges the next morning, but 9 cardholders have already reported fraud, producing early fraud warnings, and 3 become disputes at $15 each in fees. Adding CAPTCHA and a limit of 3 attempts per IP per hour stops the next wave.

How Verdikx helps

Verdikx is a fraud, chargeback and dispute platform for e-commerce and SaaS merchants, made by Verdikx LLC. On Growth and Pro, order screening on Shopify flags card testing when 3 or more different cards are tried on one order, or are used by one buyer, shipping address or IP address within 24 hours, along with IP and device velocity. On Pro, the "Hold account takeovers and card testing" risk-rule template holds matching orders before they ship. Card blocklists use the BIN, last 4 and expiry only, never a full card number. Stripe early fraud warnings from successful test charges land in the Prevention inbox, where you can refund them. Checkout-level controls such as CAPTCHA and rate limits stay with your platform or processor. See Shopify fraud detection.