Decline code

Incorrect CVC

`incorrect_cvc` means the CVC or CVV security code submitted with the charge does not match what the card's issuing bank has on file. Stripe's own definition: "The CVC number is incorrect." The card itself is fine and the account is in good standing. What failed is a single piece of submitted data.

Back to decline codes
incorrect_cvcNo automatic retry
Draft content: this page's explanatory copy is Pass 3 template writing pending a dedicated content pass. The classification badge above and the recovery behavior described below are live, not draft: both come directly from the recovery engine.

Why it happens

Every card carries a security code, typically three digits on the back for Visa and Mastercard, four digits on the front for American Express. When a charge runs, Stripe passes that value to the issuing bank for verification. If it doesn't match, the charge fails with `incorrect_cvc`. On subscriptions, this shows up most often right after a customer updates their card details and mistypes the code, or copies it down wrong from the card itself. It is a small, human data-entry slip, not a sign of a compromised or invalid card.

How to fix it

Retrying with the same incorrect CVC produces the same decline no matter how many times it runs. The issuing bank will not authorize a charge against a security code that doesn't match its records, and nothing about time or network conditions changes that. The fix is a corrected CVC, not persistence. The direct, honest answer here matters. Foxhound's decline classifier sorts recognized declines into one of four named buckets: soft, network, expired, or fraud, with an unknown bucket for anything unrecognized. `incorrect_cvc` does not have a dedicated case in the four named buckets today. A code that isn't specifically recognized falls to the unknown bucket, which fails closed rather than defaulting to a retry: no automatic retry runs against it. In practice, that means an `incorrect_cvc` failure goes straight to a card-update email rather than a silent retry attempt, which happens to be the right outcome anyway, since retrying cannot fix a genuinely wrong security code any more than retrying fixes a wrong password. That's exactly why going straight to a card-update prompt, rather than waiting on a retry, is the right approach here: a simple, non-alarming message such as "we had trouble processing your payment, please confirm your card details" resolves this faster than any retry could have anyway.

How Foxhound recovers it

This code has no dedicated bucket in the recovery engine's classification sets, so it fails closed rather than defaulting to a silent retry: no repeat charge runs against a code Foxhound cannot classify. Recovery goes straight to the same email sequence expired cards get, carrying the hosted card-update link, until this code earns its own bucket.

Questions

  • No. It means the specific security code submitted with the charge didn't match the issuing bank's records. The card and account are otherwise unaffected.

  • No. The same wrong CVC produces the same decline every time. Only a corrected code changes the outcome.

  • Yes. `incorrect_cvc` isn't specifically classified in Foxhound's decline handling, so it falls to the unknown bucket, which fails closed: no automatic retry runs, and it goes straight to a card-update email instead.

  • Go straight to the payment-update page and re-enter their card's security code carefully, rather than waiting for an automatic retry to sort itself out.

  • A simple typo when a customer updates their payment details and mistypes the three or four digit code from their card.

See what this looks like on your account

The free audit shows what Stripe already recovered and what is still dying, no signup required.

Run your free audit