Braintree Test CVV: How Sandbox CVV Values Work
Learn what a Braintree test CVV is, which digits to enter with sandbox test cards, and how to force a CVV failure for testing.
AVS Test Guide: Address Verification Testing
An AVS test is a controlled run of the Address Verification System against a billing address so you can see exactly what result your payment processor returns and what your system does with it. Merchants, developers, and fraud teams run these tests in a sandbox before real orders flow, because AVS sits inside authorization and a bad mapping quietly approves or declines the wrong customers. The criteria that decide whether a test is useful are simple: does your sandbox reproduce your live processor's codes, does your gateway map every code to a deliberate action, and are you testing with sandbox values or your own card rather than anyone else's account data.
What the Address Verification System actually checks
AVS compares the billing address a customer types at checkout against the address the card issuer has on file. It is a matching service, not an identity check.
- Only the numeric portion of the street address is compared, plus the ZIP or postal code in the United States.
- Outside the US the comparison narrows. Canadian and UK checks typically look at the postal code only, and support in other markets varies by issuer and processor.
- The result arrives as a short letter code alongside the authorization response. The issuer sends the match result, not a yes or no answer about fraud.
- Because it is issuer-dependent, the same address can produce different codes at different processors.
The response codes you will see in a test
Codes vary by processor, but the common set is worth testing one by one.
- Y street address and ZIP both match.
- N neither matches.
- A street matches, ZIP does not.
- Z ZIP matches, street does not.
- W ZIP matches, street address is not available to compare.
- U address information is unavailable, often outside AVS-supported countries.
- G not supported for that card type or country.
- R the issuer's system is unavailable and could not answer.
Test each one against your own rules. A merchant who treats U and G the same as N will decline legitimate international buyers all day. A merchant who treats them as Y will approve orders that were never checked.
Running an AVS test in a sandbox
- Switch the gateway to test mode and confirm no live keys are loaded.
- Pull the test card values and postal codes from your processor's documentation, since each processor ties specific test numbers to specific address results.
- Send each code path through your checkout: matching ZIP, mismatched ZIP, missing ZIP, non-numeric address, and an international billing country.
- Log the full request and the full response so you can prove what the processor returned.
- Confirm your accept, review, and decline branches fire the way you intended, including the manual review queue.
- Repeat after any gateway rule change, plugin upgrade, or processor migration.
Do not test with card numbers that are not yours and are not sandbox values. Card data belongs to the account holder, and using someone else's details is both a legal problem and a PCI problem.
Where AVS tests usually go wrong
- Gateway-side rules override your application logic, so your test passes and production declines.
- Address normalization differs between your form and your processor. Apartment numbers, ZIP+4, and accented characters can flip a match to a mismatch.
- Tokenization means AVS only runs on the first charge. Later charges with a stored token skip the check entirely, so recurring billing needs its own test plan.
- Sandbox environments sometimes return a fixed code regardless of the address you submit, which hides mapping bugs until launch.
What AVS does not do
AVS does not verify who is holding the card. A stolen card with a matching billing ZIP passes AVS cleanly. It does not replace a CVC check, 3-D Secure authentication, velocity limits, delivery-address screening, or manual review. Treat it as one signal among several, and set your review thresholds based on your own decline and chargeback data rather than a generic rule of thumb.
Pre-launch checklist
- Every documented AVS code mapped to an explicit action.
- International and unsupported-country behavior defined.
- Test evidence captured for each branch.
- Stored address data minimized and covered by your data-retention policy.
- Re-test scheduled after every processor or plugin change.
A short, repeatable AVS test plan catches the failures that cost the most: legitimate customers declined for no reason, and unchecked orders approved because a code was never handled.