The pick, up front

If you are reading this because you need to prove your checkout handles a failed CVV check, start with Braintree. Its sandbox lets you drive a CVV mismatch from the digits you put in the card form, and it hands back a processor response code your tests can assert on. Square's sandbox is good for approvals and general declines, but it treats CVV as something that mostly happens upstream of you.

Braintree Test CVV Related

The rest of this is the reasoning, plus what changes if Square fits your stack better.

Braintree Test CVV: What You Need to Know

Where the CVV test lives in Braintree

Braintree splits verification across a few places: Control Panel CVV and AVS rules, per-transaction options like skipping CVV for a stored card, and card verification calls you can run for a small amount before charging. In sandbox, an ordinary test card such as 4111111111111111 goes through with any three digits. To force a rejection you use the documented magic values, which I keep open in a tab: 200 for CVV does not match, 201 for CVV not verified. Postal code works the same way. The response comes back with a CVV code (M, N, U, I, S) plus the raw processor text, so a unit test can tell "declined because CVV failed" apart from "declined because the bank said no." That distinction is the whole point of testing this.

braintree test cvv compared to

Square's model is different by design

Square does not want your server touching a card number, and that shapes everything about testing. Card details go into the Web Payments SDK in the browser, which returns a payment token. Your backend only sees that token, so there is no CVV field on your side to set to 200 or anything else. In sandbox you use the published test card numbers and token values that produce an approval or a decline, then build cases around the token result. If you want the decline reason string for a CVV failure, you are reading what the sandbox returns for a rejected token, not choosing a CVV that fails.

read more

Side by side

  • Trigger: Braintree uses CVV digits on test cards. Square uses sandbox tokens and amounts.
  • Granularity: Braintree returns CVV and AVS codes separately. Square returns a decline with a reason.
  • Server-side card object: Braintree allows it in sandbox. Square does not, on purpose.
  • Verification before charging: Braintree has a dedicated verify flow. Square handles it inside authorize and capture.
  • Setup friction: Braintree wants a merchant account and a sandbox login. Square is faster if you already take payments in person.

What I would actually test

  1. Card passes CVV, payment succeeds.
  2. CVV mismatch, order blocked, customer message readable.
  3. CVV not verified because the issuer did not answer, and you decide whether to accept.
  4. AVS mismatch with CVV pass, handled as a separate rule.
  5. Retry after a decline, with no duplicate charge.

Braintree lets you cover all five from server-side tests alone. Square covers 1, 4 and 5 cleanly. Cases 2 and 3 depend on what the sandbox token gives you, which makes them integration tests rather than unit tests.

When Square is the better first choice

If your volume is modest, your team is small, and most payments happen on a card reader at a counter, Square's simpler surface is a feature. Fewer knobs means fewer ways to misconfigure your rules. The trade is that you give up the fine-grained CVV matrix, so your automated tests lean harder on the SDK.

Pick Braintree first if you have a risk team, multiple processors, or a checkout where a CVV failure has to route somewhere specific. Pick Square first if you want to ship and you are content to let CVV behavior stay the bank's problem.