Braintree Test CVV Values for Sandbox Testing

What the Braintree test CVV is

Braintree's sandbox uses a small set of fixed CVV numbers to trigger specific verification responses. You do not invent these values. You send one of the documented test CVVs together with a documented test card number, and the sandbox returns the matching response code, such as CVV matches or CVV does not match. This lets you exercise decline paths, retry logic, and your own error handling without touching a real card.

Those values work only in the test environment. Live credentials ignore them and pass the CVV to the real issuer.

Prerequisites

• A Braintree sandbox account with API credentials.
• The Braintree server SDK for your language, or direct calls to the sandbox API host.
• A test card number from Braintree's published list.
• Access to the sandbox Control Panel so you can read transaction response codes.

How to test CVV responses

1. Open the sandbox Control Panel and confirm the account is in test mode.
2. Pick a test card number from the official test values reference, for example a Visa test number.
3. Select the test CVV that matches the response you want to reproduce.
4. Send the card number, expiration date, and CVV through your normal authorization call.
5. Read the CVV response code on the returned transaction result object.
6. Compare that code against the expected value and confirm your application routes it correctly.
7. Check the AVS or postal code result on its own, because CVV and AVS return separate codes.

Documented CVV test values

• 123: CVV matches.
• 200: CVV does not match.
• 201: CVV not verified by the issuer.

Braintree also publishes values for a CVV that is missing from the card and for processor level declines. Treat the official test values page as the source of truth, since the list changes as processors change. The sandbox matches these digits exactly. Numbers such as 000 or 999 carry no special meaning.

Pitfalls to avoid

• Sending a real card number in sandbox. It fails, and it can violate your gateway agreement.
• Treating CVV and AVS as one check. They are independent results on the same transaction.
• Sending a test CVV with a live token. Live requests reach the real issuer instead.
• Storing the CVV after authorization. PCI DSS forbids it.
• Assuming a CVV mismatch always blocks the charge. Depending on your account settings, the transaction may still authorize.

Verifying your integration

Run each CVV value through your full checkout path and log the response code. Confirm that a does not match result lands where you expect, that retries do not create duplicate charges, and that the CVV never reaches your database, logs, or analytics events. Repeat the run after each SDK upgrade, because response object fields change between major versions.