Braintree Test CVV: Sandbox Values and How CVV Checks Work

Short answer

In the Braintree sandbox, use 123 as the CVV for Visa, Mastercard, and Discover test cards, and 1234 for American Express. The sandbox does not compare the CVV against the card, so any value in the correct format passes. Actual CVV verification, where an issuer compares what you sent to what it has on file, only happens in production.

related article

Why the sandbox does not validate CVV

Braintree's sandbox exists so you can exercise your integration without hitting the card networks. Card numbers, expiration dates, and CVVs are accepted by format, not looked up against a real account. If you need to see what a failed CVV check does to your order flow, you do not get there by typing a different three-digit number. You force the response with dedicated test values, or you flip the CVV rules in the Control Panel and let the sandbox replay them.

braintree cvv verification

Braintree's own test values reference is the source of truth here, and it gets revised from time to time. Pull the current values from the documentation rather than copying a number out of a two-year-old blog post.

related article

CVV format by card type

• Visa, Mastercard, Discover, JCB: 3 digits, printed near the signature panel on the back.
• American Express: 4 digits, printed on the front, above the card number.

If you send four digits for a card that expects three, or three for an Amex, Braintree rejects the request during validation. That failure looks a lot like a CVV decline, which sends people down the wrong debugging path. Check the error code before you assume the issuer said no.

CVV response codes you will actually see

When a verification result comes back, Braintree reports it as a single letter on the transaction or verification object:

• M matches. The issuer confirmed the value.
• N does not match.
• U unverified, meaning the issuer does not support verification of that value for that card.
• S should have been present, but the request arrived without one.
• P not processed.

Forcing a mismatch on purpose

Sandbox transactions can be steered to a specific response using Braintree's published test values for card verification. If your goal is simpler, go to Settings, then Processing, and set your CVV rules: decide whether an N, U, S, or P should reject the transaction outright or just flag it for review. The sandbox applies those rules the same way production does, so you can run the full path from request to rejection without a live card.

Two mistakes worth avoiding

1. Mixing key sets. Production API keys with test card numbers produce confusing gateway errors that read like CVV problems. Confirm you are pointed at the sandbox before you debug anything else.
2. Trying to store the CVV. PCI DSS prohibits retaining the CVV or CVC after authorization, and Braintree will not return it to you. If you charge a saved payment method token, there is no CVV on that request, and the response will usually come back as S or U rather than M.

Quick reference

Sandbox CVV: 123 for Visa, Mastercard, Discover. 1234 for Amex. Any correctly formatted value works. To test a failure, use Braintree's card verification test values or configure CVV rules in the Control Panel. Never send production keys, and never try to persist the value after the authorization.