Braintree CVV Validation: Response Codes and Rules Explained

How Braintree CVV validation works

Braintree does not verify the CVV itself. It passes the three-digit code from the back of a Visa, Mastercard, or Discover card (four digits on the front of an American Express card) to the issuing bank as part of the authorization request. The issuer compares that code against the one on file and returns a single-letter response. Braintree relays that letter in the transaction result, and your account rules decide whether the transaction is approved, rejected, or flagged for review.

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

The full code is never stored. It travels through the gateway, reaches the issuer, and is discarded after authorization. If you are building on the API, the value appears once in the request and then only as a response code in the result object.

Braintree CVV Test Guide: Sandbox Values and Response Codes

What each CVV response code means

• M — the code matches what the issuer has on file.
• N — the code does not match. This is the classic mismatch.
• U — the issuer does not support CVV verification or could not check it.
• S — the card requires a CVV, but the request did not include one.
• P — the code was not processed by the issuer.

An empty or missing value means the issuer returned nothing usable. Treat it the same as a soft response until your rules say otherwise.

braintree cvv validation

Turning on CVV rules

1. Sign in to the Braintree Control Panel with an account that has Settings access.
2. Open Settings, then Processing.
3. Find the CVV section and select the response codes you want to reject.
4. Choose whether rejected transactions should be declined outright or routed to manual review.
5. Decide separately how AVS results combine with CVV results. Most merchants require a match on at least one of the two.
6. Save the rule and run a sandbox transaction to confirm the behavior.

Rules apply to the whole account unless you use multiple merchant accounts with different profiles. A rule that rejects every N will also reject a legitimate customer who mistyped a digit, so most merchants allow a retry before a hard decline.

Reading the response in a transaction

After a sale or authorization call, inspect the result object for the CVV field before you treat the payment as settled. A successful authorization with a CVV code of N still means the funds are reserved — the mismatch is a risk signal, not an automatic reversal. If your rules place the transaction in review, hold the order until someone checks it rather than shipping immediately.

Common causes of a mismatch

• The cardholder typed the wrong code or mixed it up with a PIN.
• The card was recently reissued and the old code is still in the customer's records.
• A digital wallet or virtual card generates a rotating code that only works for one transaction.
• The request dropped the CVV field during form submission or tokenization.

Testing before you go live

Braintree's sandbox returns fixed CVV responses based on the test card number you submit, so you can verify that a rejection rule fires and that your review queue populates. Use the documented sandbox values, confirm each branch of your logic, and check that the code is never written to your own logs or database.

Storing a CVV after authorization violates PCI DSS, regardless of whether your gateway returns a response code. Keep it out of order records, support tickets, and analytics.