What a card verification test is

A card verification test checks that a payment system reads card data and returns the correct result from the issuer. It covers four fields: the card number, the expiry date, the card verification value (CVV2, CVC2, CID), and the address verification system (AVS) data.

Most tests run in a sandbox. Acquirers and gateways publish test card numbers. Those numbers work in test mode. They do not authorize in production.

What the test checks

  • Card number passes the Luhn check and the issuer range lookup.
  • Expiry date format and validity.
  • CVV field is accepted, sent to the issuer, and not stored.
  • AVS compares street number and ZIP code against the issuer file.
  • Each response code maps to the correct approval or decline message.

CVV response codes

The issuer returns a single-letter code for the CVV check. Visa publishes these values:

  • M: CVV matches.
  • N: CVV does not match.
  • P: not processed.
  • U: issuer does not support the check.
  • S: merchant states the CVV is not present on the card.

A test should confirm the system handles every code, not just M and N. Codes P and U appear in live traffic. Logic that treats them as failures produces false declines.

AVS response codes

AVS returns a code for the street address and a code for the ZIP. Common pairs are Y/Y (both match), Y/N (street matches, ZIP fails), N/Y, and N/N. Code U means the issuer has no data.

Test a full match, a partial match, and a U response. Set a rule for cross-border cards. AVS data is missing for many non-US issuers, so a strict rule blocks valid payments.

Zero-amount and small-amount authorizations

A zero-amount or one-unit authorization confirms that a card is open and that the CVV and AVS checks run. The merchant voids the hold right after the response. Some issuers decline zero-amount requests. Capture the response code and route those cards to a standard authorization instead. Never leave an authorization hold open past the void window.

Decline codes to cover

  1. Insufficient funds.
  2. Expired card.
  3. CVV mismatch.
  4. AVS mismatch.
  5. Do not honor.
  6. Issuer unavailable or timeout.

Each code needs a distinct customer message and a retry rule. A timeout is not a decline and should not be shown as one.

What not to test or store

PCI DSS Requirement 3.2 forbids storage of the CVV, full track data, and the PIN block after authorization. Test data must not contain live card numbers. Use the published test PANs from your acquirer. Check that the CVV field does not appear in request logs, error traces, or application logs. Mask the PAN to the first six and last four digits in any stored record.

Test checklist

  1. Run each published test PAN and record the response.
  2. Run one case for each CVV code: M, N, P, U, S.
  3. Run AVS pairs: Y/Y, Y/N, N/Y, N/N, U.
  4. Confirm the CVV is absent from logs and database tables.
  5. Confirm the decline messages match the code.
  6. Repeat the run in the certification environment your acquirer provides.