foxhound
Sign in

Decline code

Invalid CVC

`invalid_cvc` means the security code submitted with the charge failed validation against the issuing bank's records. Stripe's own definition mirrors `incorrect_cvc`: "The CVC number is incorrect." Stripe applies the two codes in slightly different contexts internally, but for a merchant trying to recover the payment, the practical meaning is the same: the code the customer entered did not check out.

Back to decline codes
invalid_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

As with its close relative `incorrect_cvc`, this shows up most often around a payment-details update: a customer re-entering their card after a prompt to fix a failed payment, switching to a different card, or simply retyping information and getting the security code wrong. Nothing about the customer's underlying account or card standing is in question. A single field submitted with the charge didn't pass the bank's check.

How to fix it

Resubmitting the identical incorrect code will fail again, and again after that. There is no waiting period, no backoff schedule, and no number of attempts that turns a wrong security code into a right one. The only thing that changes the result is the customer supplying the correct code. Be straightforward about what your systems actually do here before promising customers anything specific. Foxhound's decline classifier sorts declines into four named buckets: soft, network, expired, and fraud, with an unknown bucket for anything unrecognized. `invalid_cvc` is not one of the codes given a dedicated case in the four named buckets. Anything not specifically recognized falls to the unknown bucket, which fails closed rather than retrying: no automatic retry runs. So today, an `invalid_cvc` failure goes straight to a card-update email rather than a silent retry, which is the correct outcome here since a retry has no real chance of correcting a submitted security code that simply doesn't match. That's the same reason skipping straight to a card-update message, rather than a retry, is the right call: framing the outreach plainly, without over-explaining the CVC mismatch, keeps the ask simple, confirm your card details.

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

  • Not in practice. Stripe uses the two codes in slightly different situations, but for recovery purposes both mean the submitted security code didn't validate, and both need a corrected code from the customer.

  • No. There's nothing time-dependent here. The code either matches the bank's records or it doesn't, and that doesn't change without new input from the customer.

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

  • A direct link to update payment details, with a plain ask to re-enter the card and its security code, works faster than waiting on an automatic retry that cannot succeed against a mismatched CVC.

  • No. A mismatched security code on its own is most often a data-entry slip during a routine update, not evidence of fraudulent activity.

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