I built a shop and integrated a card payment system. On the checkout page, we have:

  • The card number
  • Expiration date
  • CVV

If I use an invalid expiration date, the payment fails, as expected. But if the card number and the expiration date are correct, even if I pass an invalid CVV, the transaction is successful.

Is that expected? If it's not expected, is it a vulnerability of my bank or of the payment service I use?

Update: It does seem it is related to the bank. I tried with a different credit card I have from another bank, and I cannot reproduce the problem. In this case the transaction is created only if the CVV is correct.

Again, should I report this somewhere or it's an expected behavior?

2 Answers 2


It's not expected, but it's not impossible.

The minimum data required to perform a credit card transaction is the card number (Primary Account Number, or PAN).

The expiration date, the cardholder name, the CVV, the billing zip code can all be used to validate the PAN. But they aren't required.

The merchant can choose to require and validate more or less information, and takes on more or less risk and fees as a result. Clearly you went through a merchant who asked for the CVV but then either failed to submit it as part of the transaction, or submitted it and then ignored the advice to decline the transaction based on CVV mismatch.

  • Hmm, I don't get it. In this case I'm the merchant as well. I'm just testing few things before launching the e-shop. I do require the CVV on the page because that's how the payment gateway recommended it. Can this be considered a vulnerability? Dec 13, 2016 at 15:01
  • You should work with your processor / payment gateway, as it seems that you're not actually validating that CVV. Ask them why, find out your options for correcting it. The world's oldest vulnerability is being exhibited here - the system behaving as implemented, and not as you thought it was implemented :).
    – gowenfawr
    Dec 13, 2016 at 15:18
  • Based on the update, it sounds like the bank is the one failing to validate the CVV. I'd probably email the bank to let them know—they probably have a security email published somewhere. They'll either fix the issue or ignore it, but you'll have notified them about it.
    – demize
    Dec 13, 2016 at 20:57

In order to tell what's actually going on, you need to look at the CVV response code. The CVV response is purely an advisory field, because the CVV isn't actually mandatory (you just get charged more and/or risk more declines if you don't send it.

There are six or seven possible response codes (see here, here, or here, for example) for a transaction that sends a CVV. It's up to the processor or merchant to decide which codes are acceptable and which should fail the transaction. This may be something configured in your processor's web portal, phone support, or something you need to manage yourself.

Most likely, the card in question is coming back with a U, S, or P response, which indicates that the issuing bank wasn't able to verify the CVV for some reason. It's a business decision whether that's carries an acceptable level of risk or not. The ones that are failing are probably coming back with an N, which is a definitive "That CVV is WRONG!" response (and thus a really good reason for rejecting the transaction).

Unrelated, it's unclear whether you're collecting the credit card numbers yourself (and passing them to your processor/gateway) or serving a page provided by your integration. If you are collecting them, be aware of the various PCI SAQ levels - it sounds like you'd be under SAQ A-EP. See the questions in the tag for more info.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.