incorrect_cvc: what this Stripe decline code means and why a retry can't fix a typo

What it means

The issuer checked the security code against its records and it did not match. That is the entire finding. The card number can be real, the account open, the standing fine; three digits were wrong, or four on an American Express. Nothing about the cardholder is in question, which makes this one of the least alarming declines to receive and one of the most pointless to retry, because the charge can't guess the digits it wasn't given.

The check only runs when a code is submitted. Stripe skips CVC verification when the field is empty, and charges on a saved card usually don't carry one, so this decline points at a moment when a person typed a code: the original card entry, a checkout, an update form. On a subscription that places the failure at collection or replacement rather than at a quiet renewal.

Stripe splits code problems in two. invalid_cvc is the malformed value, the wrong length or shape, and fails before any comparison with the issuer. incorrect_cvc means the value was plausible and the issuer says it is not the card's code. The second doubles as a fraud signature: stolen card numbers often circulate without their security codes, so a spread of incorrect_cvc across many different cards is what card testing looks like in your logs, and it is why Radar has rules keyed to the CVC check.

Like expired_card, this one can arrive under its own top-level error code, incorrect_cvc, rather than inside card_declined. A handler that only branches on card_declined lets it fall through.

Why it happens

1. A typo at entry

   Three or four digits, read off the back of a card, typed on a phone, at speed. The plainest cause, and the reason the fix is re-entry rather than anything on your side.

2. Autofill and a hand-typed code

   Browsers store the number and expiry but never the security code, so a form can fill an old card's number while the customer types the code from the card now in their hand. The number and the code belong to different cards, and the issuer notices.

3. A code that changed with a reissue

   A replacement card usually carries a new security code even when the number survives. A customer entering the code from memory, or from an old note, supplies the one that used to be right.

4. Card testing

   Stolen card numbers often travel without their codes, and someone running a list through a checkout produces incorrect_cvc declines in a pattern no customer produces across many different cards.

Common mistakes

• Retrying without new input

  Nothing in a retry changes the digits, so the same submission produces the same mismatch. Repeated CVC failures on one card are also the pattern issuer fraud systems and your own Radar rules watch for, so the case needs a person at a form rather than a schedule.

• Sending the customer to their bank

  The bank did its job; the code on file didn't match. Contact your issuer is the right advice for opaque declines and the wrong advice here, where re-entering the card is the fix and the bank has nothing to add.

• Missing the pattern

  One incorrect_cvc is a typo. A run of them across many different cards is card testing, and the response to that is Radar rules and controls at the door rather than customer emails.

How Lirova handles it

Lirova routes incorrect_cvc to request_update: no retries are scheduled, and the customer is asked for their card details. For this code the request usually means the same card entered again, because a fresh entry carries a fresh security code, and that is the only thing that can change the outcome; a retry would resubmit the mismatch. The lane is one input rather than the decision, and an issuer advice code or the payment's own state can route the case ahead of it.

FAQ

Related codes

• expired_card
• fraudulent
• card_declined