This is happening in Visa/MasterCard/American Express, etc. I tried checking in many payment apps and payment gateways that if I enter the correct debit card number, name, valid date, and wrong CVV number, I am able to receive OTP. however, the transaction is unsuccessful due to validation at the last for wrong CVV.

But shouldn't it suppose to verify before I get the OTP? What's the reason, Isn' it a security issue?

  • 1
    Even I experienced this issue with paypal also . amount deducted with wrong CVV. Jul 2, 2019 at 12:41
  • 5
    @TejasPandya That's not the same issue at all. In the OP's case the "transaction is unsuccessful".
    – DocRoot
    Jul 2, 2019 at 16:02
  • 3
    @DocRoot im not telling that its a same scenario . Im just representing another scenario in which even after invalid OTP amount can be deducted in that flow Jul 3, 2019 at 4:57

4 Answers 4


But shouldn't it suppose verify before I get the OTP? What's the reason, Isn' it a security issue?

This is absolutely NOT a security issue! quite the opposite it's a protection.

Lets go through the steps.

  1. You put in card details.
  2. You put in CVV
  3. You put in the OTP.

The payment is processed if and only if the combination of all of it are correct.

Now assume a scenario where it tell's you the CVV is wrong before the 2FA that is just going to simply give the attacker a chance to better attack.Now the attacker knows the CVV is wrong and can simply change that.While in the correct scenario attacker will have to break 2 Factor authentication to gain that information

  • 61
    This is an extension of the old rule that one does not reject an invalid username before prompting for the password, because doing so gives an attacker information about what names are valid. Better to let him try to access a nonexistent account than tell him he's wasting his time. Jul 1, 2019 at 18:34
  • 24
    @MontyHarder - Also, despite being somewhat frustrating sometimes, that's why sites also tend to say "Either the username or password entered is incorrect", instead of just telling you which of the two are wrong.
    – BruceWayne
    Jul 1, 2019 at 20:05
  • 7
    Anecdotally, my bank accepts payments with wrong CVV and correct OTP. I don’t know if that’s the case for the OP’s bank, but it’s an actual risk handling model — completely ignoring CVV in the presence of OTP.
    – Spc_555
    Jul 2, 2019 at 5:54
  • 20
    @MontyHarder Despite it being completely useless as a security measure on sites with open registration, as you can check username availability by yourself using the registration form.
    – user11153
    Jul 2, 2019 at 14:00
  • 2
    @user11153 This can be avoided by using confirmation emails during a signup process, so I would disagree with your statement about that practice being "completely useless". Upon signup you simply send an email either asking the user to confirm their email, or alert the user that someone has attempted a signup with their email or tell the user to use the "Forgot Password" option if they forget they had an account already. Jul 3, 2019 at 22:50

As well as the general rule of not giving the attacker information by rejecting too early, there are some things specific to the payment industry which are somewhat relevant.

Although often presented to the customer as mandatory, the authentication information on a payment is generally used to evaluate risk and to assign liability.

For instance:

  • A payment with no CVV provided at all may be accepted by the issuing bank, but if challenged as fraudulent, the merchant will be liable for the refund. If the payment had been fully authenticated, the card scheme or issuer will assume that liability instead.
  • A payment with an incorrect CVV but correct address, interactive one-time password, and order details consistent with previous behaviour may be accepted as "low risk" by a fraud scoring system.

The reduction of security in both cases is traded for the convenience to the customer. The new version of 3-D Secure (branded as "Visa Secure" and "MasterCard ID Check") is explicitly designed around this idea, with a large amount of automated information capture up-front meaning that interactive authentication will simply be skipped if the transaction is already considered low-risk. The CVV entered is now just one piece of data in this complex analysis.


Developer here. I have worked with a couple systems that send OTP's. Neither required the CVV in order to send it.

As per Vipul Nair's answer, it is good practice to not let an attacker know some input is wrong until the end, so as not to leak what might be wrong. I'd like to add that usually online shops may keep your PAN and other data in their databases, but they are not allowed (by law or by the card issuer) to store your CVV. In some (not all) cases it is the store that sends an OTP, so they would not have a way to validate with your CVV anyway.


Nope, it is not a security flaw. Its instead enhances security. The following 2 cases illustrate why.

Case 1: OTP is only received only if CVV is correct: Since CVVs are commonly 3 digit numbers, it easy to crack - only about 1000 possible combinations. The hacker may try all the possible combinations since cracking this wont take much time. So you CVV can be considered hacked once you get your OTP. Now the hacker has to only crack your OTP which is generally (~ 6 digit number = 1000000 combinations). Total number of combinations needed to hack your account 1000000+1000 = 1001000 combinations. Not much time will be required to generate these many combinations. Hence the card can be hacked easily

Case 2: OTP is received even if CVV is incorrect In this case, you need to get a combination of CVV (3 digits) and OTP (9 digits) correct. Thus the total number of combinations are 10^9. This is about 1000 times the combinations needed in the above case. More number of combinations => More time required to crack and thus hard to crack.

  • 1
    In Case 1, wouldn't the card issuer block the card long before 1001000 attempts have been made? Jul 4, 2019 at 11:00
  • 1
    This kind of brute force is extremely improbable. It's highly likely that the system would either rate limit the attempts, or simply start blocking them as obvious abuse. And that's just the static CVV part; the OTP system can issue a new token (or require you to wait for a new time-based token) after a very small number of attempts. Knowing that 123456 was incorrect 30 seconds ago tells you nothing about whether it's valid now, but the friction for a user who genuinely made a mistake is low if the OTP system is decently built.
    – IMSoP
    Jul 4, 2019 at 14:27

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