braintree gateway rejected: cvv verification failed on a vaulted card
Handles Braintree gateway rejections for CVV verification failure on vaulted cards. Use when a stored card transaction is gateway_rejected with cvv verification failed and you need a safe retry path. Not for processor-declined soft declines, expired cards, or nonce reuse errors.
Braintree gateway rejected: cvv verification failed on a vaulted card
TL;DR
A gateway rejection for CVV on a vaulted card means the issuer checked the CVV and it did not match; the stored card details are stale or the CVV was never re-collected. Do not retry the same charge as-is. Ask the shopper to re-enter the CVV (or the full card), update the vaulted record, then charge again.
braintree gateway rejected: cvv verification failed on a vaulted cardSteps
- Confirm the rejection type is gatewayrejected (not processordeclined) with a CVV reason. Success check: the transaction status and gateway rejection reason name CVV explicitly.
- Do not retry the identical transaction; a CVV mismatch will fail the same way every time. Success check: your retry logic excludes CVV gateway rejections from automatic retries.
- Prompt the shopper to re-enter the CVV for the saved card, or to enter a new card if they no longer have this one. Success check: the UI offers CVV re-entry inline on the saved card.
- Use the fresh CVV to verify and update the vaulted payment method, then run the transaction against the updated record. Success check: the new transaction no longer carries the CVV rejection.
- If the shopper cannot provide the CVV, fall back to a different payment method rather than abandoning the order. Success check: the checkout offers an alternative before the shopper gives up.
When this applies
- Vaulted-card transactions come back gateway_rejected for CVV.
- You run recurring or one-click billing against stored cards.
- An agent flow retries stored-card charges blindly and keeps failing.
When it doesn't
- processor_declined soft declines; those are issuer decisions with different retry rules.
- Expired cards; those need a new expiry date, not a CVV.
- Nonce reuse errors (91567); that is a tokenization bug.
Tool + version compatibility
Braintree server SDKs (all current versions), Braintree Vault, CVV verification rules configured in the control panel.
"braintree cvv verification failed vaulted"
Same handling. The vaulted record needs fresh verification data.
"braintree gateway rejected cvv"
Check whether your CVV rules are set to reject on mismatch; some merchants only want a review flag, not a hard reject.
"braintree saved card cvv failed"
If it worked before and fails now, the issuer may have started enforcing CVV; re-collect it.
Why it happens
Vaulted cards are usually charged without CVV, but when CVV verification is required (by your rules, the issuer, or a re-verification flow), Braintree sends whatever CVV it has. If the stored CVV is missing or stale, or the shopper typed it wrong during a re-verification, the issuer rejects it at the gateway level before any authorization decision.
Edge cases / pitfalls
- Storing CVV alongside the vaulted card is prohibited; you must re-collect it from the shopper each time it is needed.
- CVV rules in the control panel decide reject vs review; make sure the setting matches your risk appetite before blaming the integration.
- A shopper who fails CVV repeatedly may be guessing; after a few failures, suggest a different card to avoid a fraud flag.
- Log the rejection reason, not the CVV value; CVV must never hit your logs.
Provenance
Resolved from the public thread: https://vectle.com/posts/pst2L5Z4VcQTgdgYTb2wJN2A