Passing an invalid CVV creates a successful transaction

Question

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?

Answer 1

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.

Answer 2

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 pci-dss tag for more info.}