Braintree CVV Checking: Response Codes and Rules

Braintree CVV checking compares the three or four digit security code a customer enters at checkout against the value the card issuer holds on file. Every card transaction processed through Braintree returns a single letter CVV response code, and your merchant account settings decide whether a mismatch, a missing code, or an unverified code causes the payment to be rejected.

more on this topic

What the CVV check actually does

The card verification value is printed on the card and is not encoded in the magnetic stripe or the chip. Because it is not stored with the account number during authorization, a fraudster who has only the card number and expiry cannot guess the code. When you send the code to Braintree, the processor passes it to the issuing bank, and the bank answers with one letter. Braintree relays that letter back to you in the transaction response as cvvResponseCode.

braintree cvv validation

Pass the code in the API call under the credit card object, for example creditCard: { number, expirationDate, cvv }. Braintree never returns the code itself and never writes it into the vault.

more on this topic

Braintree CVV response codes

• M: the code matches the issuer's records.
• N: the code does not match.
• U: the issuer could not verify the code, so the result is unknown.
• S: the issuer does not support CVV verification for that card.
• P: the code was not processed.
• I: the code was not provided or was invalid, such as a wrong length or non-numeric input.

Some processors return additional values, so treat unknown letters as unverified rather than as a match. Many merchants treat U and S as acceptable when the rest of the transaction looks normal, since those codes usually come from issuers outside the United States or from card types that do not participate.

Turning on CVV rules in Braintree

CVV rules live in the Control Panel, usually under Settings, then Processing, then the card verification section. The available options normally include the following:

1. Do not reject on a CVV result at all.
2. Reject when the code does not match (N).
3. Reject when the code is not verified (U).
4. Reject when the code is not provided (I).

Each rule is a tradeoff. Rejecting every N stops some stolen-card traffic but also turns away customers who mistyped a digit. Rejecting U is stricter still and will decline a share of legitimate international orders. Most accounts start with the N rule only, watch the decline data, and tighten later.

CVV and AVS work best together

Address verification checks the billing street address and postal code. CVV verification checks the printed code. Neither one is strong alone. A transaction that returns M on the code and a full address match is a much better signal than either result by itself, which is why Braintree lets you gate approvals on both at once.

What CVV checking cannot catch

• It does not prove the person typing is the cardholder.
• It does not stop friendly fraud or buyer's remorse chargebacks.
• It fails on issuers that do not support the check in a given region.
• It does not replace velocity limits, device checks, or manual review.

Merchants should still watch for card testing patterns, where many small authorizations arrive in a short window with different card numbers and similar data. A sudden rise in N and I responses is often the first sign.

PCI rules around the code

PCI DSS prohibits storing the card verification value after authorization, encrypted or otherwise. That means you must collect the code on each new card-not-present payment unless the transaction qualifies under a credential-on-file or recurring framework. Braintree's vault stores a payment token, not the CVV, so a stored card can be charged again for recurring or unscheduled use without the code, but not for a fresh one-time purchase.