A card verification test is a controlled check that confirms your payment stack validates card details correctly, including the card verification value (CVV/CVC), without moving real money. Teams run it in a processor sandbox using published test card numbers and confirm that each scenario returns the expected approval or decline. A passing test shows the checkout reads, validates, and routes card data the way it should before live traffic arrives.
What does a card verification test check?
It exercises the same data checks a gateway runs on every authorization request. Most suites cover five areas at once.
- Card number format and Luhn checksum
- Expiration date validity
- CVV/CVC length and match result
- Address Verification System (AVS) response for billing street and ZIP
- 3-D Secure challenge and authentication outcome
How do you run a card verification test?
- Switch to sandbox or test API keys so no live authorization is created.
- Use the processor's published test card numbers instead of real card data.
- Trigger every response path: full match, CVV mismatch, AVS mismatch, expired card, insufficient funds, and a 3-D Secure challenge.
- Confirm your application maps each response code to the right message on screen.
- Save request IDs and results so the run is repeatable after the next code change.
Why should you never test with real customer cards?
Using live card numbers in a test environment exposes sensitive authentication data outside the systems built to protect it. PCI DSS forbids storing the CVV/CVC after authorization, even in encrypted form, so test data that carries a real CVV is a compliance problem from the moment it is written down. Keep test numbers separate from production records and never copy a production database into a test environment.
What is the difference between CVV verification and AVS?
CVV verification compares the code printed on the card with the issuer's record. AVS compares the billing street address and ZIP code submitted with the card against what the issuer has on file. Each returns its own result code, and a processor can approve a charge with a CVV match and an AVS mismatch, so read the two fields separately.
Which test card numbers should you use?
Every major processor publishes its own set of test numbers, and those numbers only work inside that processor's sandbox. A number that returns a CVV mismatch at one gateway may simply decline at another. Pull the current list from the documentation of the processor you integrate, because ranges change when issuers retire them.
What does a passing test suite look like?
- Approval when card, CVV, and AVS data all match
- A clear customer message for a CVV mismatch decline
- Declines for an expired card and for an invalid number
- A completed 3-D Secure challenge and a failed authentication
- No sensitive authentication data written to logs or the database
What mistakes show up most often?
Teams test the happy path and skip the declines, so a CVV mismatch later surfaces as a vague payment failure screen. Others hardcode sandbox keys into a release build and only learn about it when live orders stop processing. A short checklist run before each deploy catches both.
How often should you rerun card verification tests?
Rerun the suite after any change to checkout, payment routing, or the processor integration, and at least once per release cycle. Processors also retire test card ranges, so confirm the numbers still behave as documented every few months.