What a fraud card test is

A fraud card test is a small authorization attempt made with a stolen card number. The person running it wants one piece of information: whether the issuer approves. A low-dollar charge, a donation page, or a free trial signup tells them the card is live and worth using for a larger purchase. Merchants see the damage later as chargebacks, processor fees, and a dispute ratio that climbs past the threshold their acquirer allows.

The guide below is written for merchants, payment teams, and fraud analysts who need to find a testing run in their own logs and shut it down.

Signals a card testing run leaves behind

  • Many authorization attempts from one IP address or a narrow IP range within minutes.
  • Order totals that repeat at the same odd amount, often under a few dollars.
  • A decline rate far above your normal baseline, with a few approvals mixed in.
  • Card numbers that arrive in ascending or sequential order.
  • Customer emails built from random characters, or one email reused across many cards.
  • Billing and shipping details that do not match, or fields filled with placeholder text.
  • Traffic concentrated on the cheapest item, a gift card, or a recurring trial.

Before you start

  • Access to gateway authorization logs with response codes and timestamps.
  • Permission to edit rules in your fraud tool, gateway, or web application firewall.
  • Your recent dispute report, so you can separate the pattern from real chargebacks.
  • A contact at your acquirer or processor for escalation.

Steps to confirm and stop the run

  1. Pull every authorization attempt from the last 72 hours, including declines, and export the card BIN, IP address, amount, timestamp, and response code.
  2. Sort by IP address and count attempts per address. Anything above your normal rate is the first cluster to review.
  3. Sort the same data by amount. A spike at one small, identical total confirms the pattern.
  4. Check the response codes inside that cluster. A high volume of declines means the attacker is guessing; a handful of approvals means live cards were found.
  5. Find the entry point. Testing runs hit the endpoint with the least friction: guest checkout, a free trial, a stored-card update form, or a public API key.
  6. Set a strict velocity limit on that endpoint, such as a maximum number of attempts per IP address and per card fingerprint each hour.
  7. Add a challenge to the payment form, such as a CAPTCHA or a device check, so scripted requests cannot reach the authorization step.
  8. Block the IP ranges and card BINs from the cluster, and require CVV and address verification on every transaction while the run is active.
  9. Void or refund the approved test charges before they settle, and flag the customer accounts tied to them.
  10. Log the incident with timestamps, the rules you changed, and the volume involved.

After the run stops

Report the activity to your acquirer and, if card data may have been exposed, to your processor's fraud desk. Review your rules weekly for a month, because testing groups rotate IP addresses and BINs. Keep an alert on decline rate and dispute ratio so the next run shows up in hours rather than days.