A chargeback card testing procedure is the order of operations you follow when a burst of small, low-value disputes turns out to be an attacker validating stolen card numbers on your checkout. You contain the endpoint first, then work the disputes with evidence of a pattern rather than evidence of a single sale. Fighting them one at a time is how merchants lose money they could have kept.

more on this topic

Why card testing chargebacks look different

Normal fraud disputes are scattered. Card testing disputes arrive in clusters. Same BIN range, same hour of the day, similar dollar amounts just under your fraud threshold, and often a shared device fingerprint or IP block. The attacker is not buying anything. They are checking whether a number authorizes, and your gateway is the test lab.

chargeback card testing procedure

That distinction matters for the response. In an ordinary dispute you defend the transaction. In a card testing dispute you defend the pattern: dozens of attempts, most of them declined, a handful approved, none of them ever shipped or delivered to a real customer.

The Ultimate Guide to Chargeback Card Testing Methods

The procedure, in order

  1. Confirm it is testing, not a seasonal spike. Pull authorizations from the last 72 hours and sort by card BIN and by the first six digits. Repeated small-ticket approvals from a narrow BIN band with a high decline ratio is the signature.
  2. Stop the bleeding before you touch the dispute queue. Tighten velocity rules, force 3DS or CVV re-entry on the affected BIN ranges, block the offending IPs and device IDs, and consider disabling guest checkout for a few hours. Every hour you wait adds attempts.
  3. Void and refund what has not settled. If the goods never left and the charge is still pending capture, a void is cheaper than a chargeback and it removes the dispute from existence.
  4. Build one evidence file, then reuse it. Assemble the auth log, the decline log, device and IP data, the order timeline, and a short written statement explaining that the merchant identified an enumeration attack. Respond to each dispute inside the network's deadline with that package.
  5. Tag the disputes as fraud-related in your processor portal. Some acquirers route these into a different monitoring bucket, and the ratio matters more than the dollar amount.
  6. File the fraud report. Visa and Mastercard both have programs for reporting card testing against your own MID. Reporting it creates a record you can point to later when your chargeback ratio gets questioned.
  7. Close the gap that allowed it. Rate limits per IP, CAPTCHA on the payment step, address verification, and a minimum order value are the usual fixes.

What actually wins these disputes

A receipt and a tracking number prove nothing when the order was never fulfilled. What works is a narrative: here is the attempt volume, here is the decline rate, here is the single approval, here is the fact that the item was held and canceled. Include the cardholder's own history if the issuer supplied it. Keep the statement to one page. Reviewers read hundreds of these.

chargeback card testing system

Expect to lose some. Issuers side with cardholders on unauthorized charges when the card was genuinely not present, and that is the correct outcome. Your goal is not a 100 percent win rate. It is to stop the volume and to keep the losses from being read as merchant error.

Timing and ratio math

Dispute response windows vary by network and by reason code, and they are counted from the transaction date, not from the day you notice. If a testing attack ran for two weeks before anyone looked, part of your window is already gone. That is the real argument for daily monitoring of decline rates, not weekly.

Chargeback ratios are calculated monthly. A few hundred small disputes can push a low-volume merchant over the threshold even though the dollar exposure is trivial. Talk to your acquirer early, before the letter arrives.

Prevention habits worth keeping

  • Watch your decline rate as closely as your approval rate. Spikes there are the earliest signal.
  • Set a floor on order value and a ceiling on attempts per card per hour.
  • Log everything: IP, device, user agent, timing. Without logs you have no defense and no forensics.
  • Keep an incident note each time it happens. Repeated attacks with a documented response read very differently from neglect.