Braintree CVV Test Guide: Sandbox Values and Response Codes

What are Braintree CVV test values?

Braintree's sandbox pairs fake CVV numbers with test card numbers so you can trigger a chosen verification result on demand. Enter 123 to get a CVV match, 200 to get a mismatch, and any other listed sandbox value to see how your code handles an unverified response.

Braintree CVV Test API Guide: How to Use It for Security

These numbers are fake. They work only in the Braintree sandbox and cannot charge a real account.

related article

Which CVV values does the sandbox accept?

• 123 returns a CVV match (response code M).
• 200 returns a CVV mismatch (response code N).
• Remaining values in the official test table return a not-verified result (response code U).
• All of them must be submitted with a sandbox test card, such as 4111 1111 1111 1111 for Visa.

Braintree publishes the current list on its test values page. Card numbers and CVV values change with new sandbox features, so check that page before you write assertions into a test suite.

Braintree CVV Test Tool: Sandbox Card Verification Guide

How does CVV verification work in a Braintree transaction?

The CVV travels with the authorization request to the card issuer. The issuer compares it to the number on file and returns a result, which Braintree passes back to your integration as a CVV response code.

Braintree does not store the CVV after authorization. The response code plus your CVV rule decide whether the transaction continues.

What do the CVV response codes mean?

• M: the CVV matches.
• N: the CVV does not match.
• U: the issuer did not verify the CVV, often because it does not take part in the check.
• Error and unsupported-card codes also exist and appear in the transaction response object.

You read the value from the cvvResponseCode field on the transaction. Most integrations log it and act on it in one place rather than scattering checks across the checkout flow.

How do CVV rules change the outcome?

Braintree lets you set CVV rules in the Control Panel. A common rule rejects any transaction that returns an N response, so a mismatched CVV becomes a decline instead of a flagged sale.

Without a rule, a mismatched CVV can still settle. The response code shows the mismatch, but nothing blocks the charge. Test both setups before you go live.

How do you test CVV handling step by step?

1. Switch your API credentials to sandbox keys. Production keys ignore test card numbers.
2. Open a checkout form that submits a card number, expiry, and CVV to your test environment.
3. Run one transaction with CVV 123 and confirm the response code reads M and the sale authorizes.
4. Run a second transaction with CVV 200 and confirm the code reads N.
5. Check that your CVV rule fires: the N transaction should decline if the rule is active.
6. Test address checks at the same time with AVS test values, since most rules combine CVV and postal code.
7. Log every response so you can compare sandbox output with a real issuer response later.

What CVV data must you never use in testing?

Sandbox values are the only CVV numbers that belong in a test form. Card numbers pulled from a card, and CVV strings bought or sold on forums, are not test data. Running them through a gateway is card fraud and ends a merchant account.

PCI DSS Requirement 3.2 prohibits storing sensitive authentication data, CVV included, after authorization. That rule covers test databases, spreadsheets, and log files, not only production systems.

A real CVV also tells you nothing useful in a test. Sandbox responses come from a fixed table, so a genuine number gives no extra signal and creates legal risk.

Sandbox CVV behavior vs. production

In the sandbox, Braintree decides the response. Submit 123 and you always get M. The result is deterministic, which is what makes it useful for automated tests.

In production, the issuer decides. Banks differ in how they treat a missing CVV, a foreign card, or a card from a country that does not support the check at all.

The sandbox also skips fraud tools and never touches a bank network. Treat a passing sandbox test as proof that your code handles the response code, not as proof that live approvals will follow.

Frequently asked questions

Does Braintree store the CVV after a transaction?

No. The CVV is used for the authorization request and not kept afterward. Vaulted payment methods store the card number and expiry, not the CVV.

Why did my sandbox transaction succeed with a mismatched CVV?

No CVV rule is active on the account, or the rule is set to flag rather than reject. Add a reject rule and rerun the test with CVV 200.

Do CVV test values work with any test card?

They work with the test card numbers Braintree lists for each card brand. A random 16-digit number fails card validation before the CVV is ever checked.

Are CVV test values the same in every Braintree environment?

Only the sandbox honors them. Production ignores the test table and sends the CVV to the issuer, so a response you saw in testing may not repeat live.

Do I need to test AVS as well as CVV?

Yes. Braintree returns an AVS code alongside the CVV code, and most fraud rules check both. Testing one without the other leaves half your decline logic unverified.