I Entered a Fake CVV — Here’s Why the Bank Immediately Rejected It

Source: Dev.to

Introduction

Recently, while adding a credit card to an online payment system (without making a purchase), I entered a fake CVV. The card was immediately declined. This raises two technical questions:

• Is the CVV verified even when no payment is made?
• How is the CVV generated and validated by banks and card networks (Visa, Mastercard)?

How CVV Is Generated

CVV (Card Verification Value) is not a random three‑digit number. It is a cryptographic value derived by the issuing bank from several data elements:

• PAN – Primary Account Number (the card number)
• Expiry date – YYMM format
• Service code – e.g., 101
• Secret cryptographic key – known only to the bank
• Encryption algorithm – DES or 3DES
• Hardware Security Module (HSM) – stores the secret key securely

Step 1: Data Preparation

The bank concatenates the data elements into a single block. Example:

PAN:          4539148803436467
Expiry:       2708
Service code: 101

Step 2: Encryption

The concatenated block is encrypted with DES/3DES using the secret key stored in the HSM. The key never leaves the bank’s secure environment.

Step 3: Extract CVV Digits

The encryption output is a long numeric/hexadecimal string. The bank selects specific decimal digits—typically the first three—to form the CVV. Example:

Encryption output: 839275192837465
CVV (first 3 digits): 839

The resulting three‑digit CVV is printed on the back of the card.

How CVV Is Verified When Adding a Card

Even when you are only “saving” a card, most merchants perform one of the following checks:

• Zero‑amount authorization
• Small temporary (refundable) authorization
• Network‑level card validation

These checks involve sending the card details (including the entered CVV) to the payment gateway, which routes the request through the card network to the issuing bank. The bank recalculates the CVV using the same algorithm described above and compares it to the submitted value:

• Match → transaction approved (or card saved)
• Mismatch → transaction declined

Thus, the CVV is indeed verified during the “add‑card” process.

Detailed Flow

User
  |
  |  Enter Card + CVV
  v
Merchant Website
  |
  |  Encrypted Request
  v
Payment Gateway
  |
  |  Routed via Network
  v
Card Network (Visa / Mastercard)
  |
  v
Issuing Bank
  |
  |  Recalculate CVV using:
  |    - PAN
  |    - Expiry
  |    - Service Code
  |    - Secret Key (HSM)
  |
  |  Compare with entered CVV
  |
  +--> Match → Approve
  |
  +--> Mismatch → Decline

Merchant Restrictions (PCI‑DSS)

Under PCI‑DSS compliance, merchants are prohibited from storing:

• CVV
• PIN
• Full magnetic‑stripe data

Consequently, even after a card is saved, the CVV must be re‑entered for subsequent transactions.

Security Considerations

• Limited space: Only 1,000 possible CVV combinations (000–999).
• Rate limiting & fraud detection: Banks monitor attempts, apply rate limits, and block repeated failures.
• Brute‑force mitigation: Multiple failed attempts trigger transaction blocks and alerts.

In the experiment, the fake CVV failed because the issuing bank performed a real authorization check, recalculated the CVV, detected a mismatch, and declined the request.

Conclusion

What appears to be a simple three‑digit number is actually the output of a secure cryptographic process involving symmetric encryption, hardware security modules, network routing, and fraud‑detection systems. Even a seemingly harmless “add‑card” operation triggers a full CVV verification, illustrating the complexity and robustness of the global payment infrastructure.