A card test transaction is a small authorization, usually under one dollar, run against a card number to learn whether the account is still open. The attacker does not care about the goods. The approve or decline response is the product, because it tells the buyer whether a stolen card number is worth using or reselling. For a merchant, the visible symptom is a burst of tiny authorizations that never turn into orders, followed weeks later by chargebacks on the cards that passed.

Card testing lands on the merchant because the attacker needs a live payment page to query. Defending against it is a log-and-rules job, not a code rewrite. The procedure below works with the tools already in your gateway.

Prerequisites

  • Admin access to your payment gateway or processor portal
  • Permission to edit fraud rules, CVV rules, and AVS rules
  • At least 90 days of authorization history, including declined attempts
  • A named contact at your acquirer or processor risk desk

Signals of a card test transaction

  • Authorization amounts of $0.00 to $1.00 with no matching order in the order table
  • Dozens of attempts from one IP address across many different card numbers
  • Many attempts on one card number from many different IP addresses
  • BINs from issuing banks you have never seen in your normal order mix
  • Checkout sessions that end at the payment step with no shipping address entered
  • Decline rate above 40 percent on a single day for one payment channel

Do not wait for chargebacks to confirm the pattern. Authorization-only tests never settle, so chargeback data will not show them at all.

How to detect and block card testing

  1. Export 90 days of authorization records from the gateway, including declines.
  2. Filter the export to rows with amounts at or below $1.00.
  3. Match each row against your order database and mark rows with no order record.
  4. Group the unmatched rows by card BIN and by source IP address.
  5. Sort each group by attempt count over a rolling 24-hour window.
  6. Write down the top 20 BIN and IP groups with counts above your normal baseline.
  7. Open the fraud rules section of the gateway and set a velocity limit of three attempts per card per hour and ten per IP per hour.
  8. Enable rejection on CVV mismatch and AVS mismatch for the affected checkout channel.
  9. Add the top offending IP ranges to a temporary block list with a 30-day expiry.
  10. Require a 3-D Secure challenge for any authorization under $1.00 on the affected channel.
  11. Send the BIN list, IP list, and five sample transaction IDs to your acquirer risk desk.
  12. Log the rule change with a timestamp and the name of the person who made it.

Verify the fix

  1. Re-query the authorization logs 24 hours after the rule change.
  2. Compare the count of sub-$1.00 authorizations against the pre-change daily average.
  3. Confirm the decline rate on those attempts rose above 90 percent.
  4. Check your legitimate low-value orders for a rise in false declines.
  5. Repeat the query at day 7 and day 30.

A short burst that dies within a day is the expected result. If attempt volume holds steady after the rules are live, the attacker has moved to a different endpoint, such as a stored-credential path or a secondary checkout your rules do not cover. Pull the logs for every payment endpoint you run, not just the primary one.

Keep the baseline current

Record the normal daily count of sub-$1.00 authorizations when traffic is clean. That number is your tripwire. Review it each week and re-run the grouping step whenever the count doubles. Testers rotate IP ranges and BINs, so a static block list decays in value within a month.