Card verification testing is how you confirm that a card is valid and that the details a customer entered match what the issuer has on file, without moving money. In practice that means running a zero-dollar authorization, reading the CVV and AVS responses, and making sure your code does the right thing on both approvals and declines. You do this with cards you are allowed to handle: sandbox test numbers while you build, and your own cards or your customers' cards through a processor that is cleared to do it.

read more

What a verification check actually looks at

A card check is really several checks stacked together, and each one answers a different question.

card verification number test

• PAN validity. The Luhn checksum and the issuer identification number tell you the number is well formed and which network issued it. This catches typos before anything hits the network.
• Expiry. A date in the past fails immediately, no issuer call needed.
• CVV or CVC match. The three or four digit code is verified by the issuer. A mismatch returns a code that tells you the code was wrong, not that the card is bad.
• AVS. The billing street address and postal code are compared to what the issuer has. Responses come back as partial matches often enough that you need a rule for each combination.
• 3D Secure. An authentication step that shifts fraud liability in some cases. Useful for testing whether your challenge flow works on a phone.

Zero-dollar auths versus real charges

A zero-dollar or small-amount authorization reserves nothing and posts nothing, but it does prove the account is open and the credentials are right. Most processors support it and most issuers approve it. The catch is that some card types, prepaid cards in particular, behave badly with zero-dollar auths and will decline them even when the card is fine. If you see a strange decline rate, try a one-dollar auth before you assume the card is dead.

card verification check

Authorization and capture are separate steps. Verification stops at authorization. If your code captures after a verification call, you have converted a check into a sale.

read more

Testing in a sandbox

Every major processor publishes test card numbers that only work in test mode. Visa's classic is 4111 1111 1111 1111, Mastercard's is 5555 5555 5555 4444, American Express uses 3782 822463 10005, and Discover uses 6011 1111 1111 1117. They pass the Luhn check so your validation logic accepts them, and the sandbox returns whichever response you ask for.

Build a table of scenarios before you write code: an approved card, a generic decline, an insufficient funds decline, an expired card, a CVV mismatch, an AVS mismatch, and a card that requires 3D Secure. Run all of them in CI so a refactor cannot quietly break decline handling.

Declines you should force on purpose

The declines matter more than the approvals. A soft decline, one that says try again later, is worth a retry with backoff. A hard decline, stolen card or closed account, is not. Retrying hard declines burns your approval rate and can get your merchant account flagged. Test that your code knows the difference.

Mistakes that cause real problems

• Storing the CVV after authorization. PCI DSS forbids retaining sensitive authentication data post-authorization, even encrypted.
• Using live card numbers in a sandbox. You will get errors and you may create a compliance problem for yourself.
• Running verification against cards you do not have permission to use. Customer consent and a processor agreement come first.
• Treating a CVV mismatch as proof of fraud. People mistype. Log it, weigh it with other signals, and move on.

Where this fits in PCI scope

If card data touches your servers at all, you are in scope, and verification traffic counts. The cleanest setup is to let the processor's hosted fields or SDK collect the number and CVV so they never land in your logs, your database, or your error tracker. Test that path too. A stack trace that includes a full card number is the kind of bug that turns into a fine.