I can’t help with CVV sales or unauthorized card testing
Request asks for a guide tied to selling CVV data and testing merchant cards. I can’t assist with fraud; I can outline legitimate sandbox testing instead.
Merchant Card Testing Method: Signs, Costs, and Defenses
Card testing is the practice of pushing small or throwaway transactions through a merchant's checkout to find out which stolen card numbers still work. The merchant is not the target. The merchant is the lab equipment. From the outside it looks like a burst of orders, most of them declined, most of them for odd amounts, and none of them from anyone who was ever going to buy something.
I'm not going to write the fraud side of this. There is no version of that guide worth publishing. What follows is what the method looks like from behind the counter, which is the view that actually helps someone.
Why the method exists at all
Card numbers leak in bulk. A file of ten thousand numbers is worthless until someone knows which five hundred are live, and guessing is expensive. So the numbers get spent on cheap authorizations: a real payment gateway, a real checkout, a real issuer response. A decline means dead card. An approval means the number moves to a different list and gets used for something larger somewhere else.
Guide to Merchant Card Testing Methods
That is the whole logic. The method is a filter, not a purchase.
The signals that show up in the data
Merchants rarely catch this by watching a single order. They catch it in aggregate, and usually a day late. The pattern I look for:
- Decline rates that jump from a steady low single digits to something absurd inside an hour.
- Ticket sizes clustered near the smallest amount the cart will accept.
- Many different card numbers hitting the same product, the same donation field, or the same free trial.
- BINs that have nothing to do with the merchant's normal customer base or shipping geography.
- Email addresses on throwaway domains, or a run of addresses that differ by one character.
- Traffic spread across many IPs and devices with no repeat visitors, no page depth, no time on site.
- Cardholder names that are keyboard mash, or the same name across dozens of unrelated cards.
Any one of those is noise. Three of them together in the same hour is an attack.
It costs the merchant whether or not the charge goes through
This is the part people miss. A declined authorization is not free. There are per-attempt fees, and a flood of them adds up fast. Worse, the acquirer and the card networks see the merchant as the source of the noise. Too many fraudulent attempts and the account lands in a monitoring program, gets hit with fines, or gets a chargeback ratio that makes the processor nervous. Small merchants have lost their ability to take cards over a weekend of testing.
Chargebacks come later, from the approvals that slipped through, and they arrive weeks after the traffic is gone.
What actually stops it
Friction is the tool, applied where it costs real customers the least:
- Require CVV and AVS on every attempt, and fail the order when they mismatch instead of letting it ride.
- Put a floor on transaction size for card-not-present orders, so a test attempt is not worth the effort.
- Rate limit by IP, by card BIN, and by email domain, not just by account.
- Turn on 3-D Secure for high-risk segments. It moves the liability and it kills scripted testing.
- Add a challenge on the payment step, not the landing page, so bots have to solve something to reach the gateway.
- Route any order that trips two or more risk rules to manual review instead of auto-approving it.
None of this is exotic. The merchants who get hit hard are usually the ones with no velocity rules and no minimum, running a checkout built for convenience and never revisited.
Where the tested numbers go
Once a number clears a small authorization, it gets resold as verified. That market is why the testing happens at all, and it is why the merchant's decline log has value to someone. Treat the log like the fraud evidence it is: keep it, watch it, and report the pattern to your processor before they find it themselves.