Braintree CVV Testing: Sandbox CVV Values & Response Codes

Braintree CVV testing means submitting specific card verification value inputs in the Braintree sandbox so the gateway returns a predictable cvv_response_code. The sandbox does not check real cardholder data: it maps your submitted CVV to a canned result, letting you confirm that your CVV rules, decline handling, and order logic behave correctly. Nothing you test in the sandbox settles funds, and no live issuer is contacted.

read more

Which CVV values should you use in the Braintree sandbox?

Braintree publishes a set of sandbox test values that map a CVV number to a verification result. The widely used default is CVV 123 for a match on Visa and Mastercard, with a small set of neighboring values reserved for no-match and not-verified outcomes.

Braintree CVV Test Guide: Sandbox Values and Response Codes

American Express uses a four digit CID rather than a three digit CVV, so test with a four digit value on Amex test cards such as 378282246310005. Because Braintree revises its test value list over time, confirm the current numbers on the sandbox test values page before you hard code assertions in your test suite.

related article

• Match (M): CVV supplied and verified by the issuer.
• No match (N): CVV supplied but incorrect.
• Not verified (U): issuer could not verify the CVV.
• Issuer does not participate (S): the card issuer does not support CVV checks.
• Not provided (I): no CVV was sent with the request.

How does Braintree return the CVV result?

The verification outcome arrives on the transaction object as cvv_response_code, alongside avs_response_code for the street address check. Your integration should read that field rather than infer the result from a generic decline message.

Send the CVV in the credit_card.cvv parameter of the transaction or verification call. Omitting it produces the I code and can change the outcome when your CVV rules require a value.

How do CVV rules change the test outcome?

CVV rules live in the Control Panel under Settings, then Processing, then CVV rules. The rule set determines whether a transaction is rejected, flagged for review, or accepted when the CVV does not match.

This means the same sandbox CVV value can produce a hard decline in one merchant account and an accepted transaction in another. Test each rule configuration you plan to ship, and re-run the suite after any rule change in the Control Panel.

Why does a sandbox test card keep declining on CVV?

A repeated decline usually means the CVV sent does not map to the expected response code, or your CVV rule rejects any non-match value before your code can inspect it. Log the full transaction response, not just the failure message.

Also check that the test card number is one Braintree documents for that card type and that you are sending the correct digit count. Mixing an Amex test number with a three digit CVV produces an invalid request rather than a verification result.

What should you confirm before going live?

Cover the match, no-match, not-verified, and missing-CVV paths in automated tests, and assert on cvv_response_code rather than on decline text. Confirm that your order flow voids authorizations that fail your CVV rule instead of leaving them open.

Never log or store the CVV value itself, in the sandbox or in production. Only the response code belongs in your records, and the full value must be discarded after the authorization request.