CVV Test AVS: How to Verify Card Checks in a Sandbox

Answer first

CVV and AVS tests run against a payment processor sandbox, never live card data. You use the processor's published test card numbers, each wired to return a specific CVV or AVS result, then confirm your checkout reacts with the correct message, routing, and retry path. The goal is to prove your rules fire before real transactions depend on them.

What the two checks do

AVS compares the numeric part of the billing street address and the ZIP code you collect with the address the issuer has on file, and the issuer returns a single-letter code. CVV compares the 3- or 4-digit verification value with the issuer's record and returns a match, no-match, or not-processed result. Both checks run at authorization, and both are advisory: your gateway rules decide whether a mismatch blocks the charge.

Prerequisites

• Sandbox (test mode) merchant account with API keys
• Access to the processor's current test card list
• A staging checkout you can point at the sandbox endpoint
• Raw request and response logging turned on

How to test CVV and AVS response handling

1. Open the test-mode area of your processor dashboard and confirm the account sits in sandbox mode. Live keys produce real authorizations and real fees.
2. Pull the current test card list from the processor developer documentation and save a local copy. Processors revise these lists without notice.
3. Set the AVS and CVV rules you plan to use in production, such as reject on CVV no-match and allow on a street-only AVS match. Store the thresholds in a config file your test suite can read.
4. Build a matrix that pairs each test card number with a specific expiry, CVV, street address, and ZIP. Every row maps to one expected avs_result and cvv_result pair.
5. Run each row through the staging checkout with the sandbox key. Submit address fields the same way your production form submits them, including ZIP+4 if you collect it.
6. Capture the raw response object and compare avs_result and cvv_result against the expected pair. Log the request payload next to the response so any mismatch is reproducible.
7. Confirm the customer-facing outcome for each code: approved, declined with a specific message, or held for review. A partial AVS match should not surface the same message as a full mismatch.
8. Test the recovery path. Send a transaction that fails CVV, correct the data, and resubmit. Verify you do not create a duplicate authorization.
9. Add the matrix to your regression suite and re-run it after any gateway rule change or processor API version bump.

Common AVS response codes

• Y: street and ZIP both match
• A: street matches, ZIP does not
• Z: ZIP matches, street does not
• N: neither matches
• U: issuer unavailable, no address check performed
• G: non-US issuer, address check not supported

Common CVV response codes

• M: verification value matches
• N: no match
• P: not processed
• S: value should have been on the card but was not indicated
• U: issuer unable to verify

Mistakes that break the test

• Using live keys in a staging environment
• Hard-coding one test card and skipping the rest of the matrix
• Reading only the approval status and ignoring avs_result
• Testing full matches only, never partials or no-matches
• Writing the CVV into logs, error trackers, or the database, which PCI DSS forbids

Before you go live

Re-run the full matrix against your production ruleset in sandbox mode, confirm decline messages match your published terms, and search your logs for any stored verification value. Ship only when every row returns the code and the customer message you designed for it.