Card test verify is shorthand for pushing a tiny authorization through the payment network to find out whether a card is live and whether the data printed on it matches what the issuer has on file. A zero-dollar auth, a one-dollar hold, a CVV check, an address check. That is the whole idea. Merchants run it before the first real charge on a subscription. Cardholders run a version of it every time they tap a card at a register and wait to see if it goes through. Using it on a card that is not yours is carding, and that is a federal offense under 18 U.S.C. 1029.
Card Test Automation Buying Guide
What actually gets verified
- Account status. Whether the issuing bank will approve an authorization at all, or whether the account is closed, frozen, or over limit.
- Card number. A Luhn checksum plus a real BIN lookup against the issuer's range.
- Expiration date. A mismatch here usually gets declined before anything else is even evaluated.
- Security code. CVV2, CVC2, or CID depending on the network. The issuer checks it. The merchant is not allowed to store it.
- Billing address. AVS compares the street number and ZIP you entered against what the issuer holds.
How legitimate verification is done
Zero-dollar and one-dollar authorizations
A merchant sends an auth request for $0.00 or $1.00, gets an approve or decline, then voids it. No money moves. The cardholder may see a pending line for a day or two. This is the standard way to validate a card at signup without charging anyone.
Micro-deposits
Mostly used for bank accounts rather than cards. Two small deposits land, the owner confirms the amounts, and the link is verified. Slow but hard to fake.
3-D Secure
The cardholder gets bounced to their bank for a password, a code, or a biometric check. When it passes, the merchant gets a liability shift. When it fails, the transaction stops there. Banks push this hard because it kills a lot of automated abuse.
Reading the response
Approvals come back with an authorization code. Declines come back with a reason: do not honor, insufficient funds, incorrect CVV, AVS mismatch, expired card, restricted card. The reason tells you where the problem lives. A CVV mismatch on an otherwise healthy card is a data entry problem. "Do not honor" is the issuer saying no without saying why. I look at the reason code first, before I look at anything else.
If you run a store
- Require CVV and AVS instead of treating them as optional. Leaving them off invites automated testing.
- Set velocity limits per card, per IP, and per email. Card testing shows up as a burst of tiny declines, not one big fraud.
- Turn on 3-D Secure for high-risk orders and new customers.
- Watch for a spike in declines. That pattern is the signature of a BIN attack.
- Never store the security code after authorization, under any circumstances.
If you are checking your own card
Make a small purchase somewhere you already shop, or open your bank app and look at the pending items. If a charge you do not recognize shows up, call the number on the back of the card. Do not test a card by running it through a random site you found five minutes ago.
Where the line sits
Verifying your own card is normal. Verifying someone else's is fraud, and buying or selling card data is a separate crime on top of it. Issuers log every authorization, including the declined ones, and card testing leaves a trail that fraud teams read easily. The safe version of this question is always about your own card, on your own account, with your own bank on the phone if something looks wrong.