CVV, CVC, CID und CVV2: Was der Sicherheitscode wirklich bedeutet

Kaum etwas im Zahlungsverkehr sorgt für mehr Verwirrung als der dreistellige Code auf der Rückseite einer Karte. Heißt er CVV, CVC, CVV2 oder CID? Steht er bei Amex auf der Vorderseite? Dürfen Sie ihn speichern? Dieser Artikel klärt die Begriffe und die Regeln, die für Entwickler wirklich relevant sind.

Vier Namen, eine Idee

Der Sicherheitscode ist eine kurze Zahl, die nicht im Magnetstreifen oder im EMV-Chip gespeichert ist. Seine Aufgabe ist der Nachweis, dass die zahlende Person die Karte physisch in der Hand hält, was ihn für Card-not-present-Transaktionen (CNP) wertvoll macht.

Die Unterscheidung zwischen CVV und CVV2 (bzw. CVC und CVC2) ist historisch: Das Suffix „2“ bezieht sich auf die Nutzung desselben Werts bei Card not present. Im Entwickleralltag wird „CVV“ als generischer Name für das Feld über alle Kartennetzwerke hinweg verwendet.

Die zwei Dinge, auf die es im Code wirklich ankommt:

1. Amex verwendet 4 Ziffern auf der Vorderseite — jedes Eingabefeld, das auf 3 Ziffern besteht, lässt Amex-Tests scheitern.
2. Der vollständige Wert ist sensible Karteninhaberdaten und fällt damit unter PCI DSS.

Die PCI-DSS-Regeln, die Sie nicht ignorieren können

Die CVV gilt als sensible Authentifizierungsdaten. Unter PCI DSS gilt:

• Sie dürfen sie verwenden, um eine Transaktion zu verarbeiten.
• Sie dürfen sie nach der Autorisierung nicht speichern — weder in Logs noch in einer Datenbank, in einem Analytics-Event oder in einem Support-Screenshot.
• Sie dürfen sie auch verschlüsselt nicht speichern. Das Verbot ist absolut.
• Sie sollten sie Nutzern nach dem Absenden nicht wieder anzeigen.

In der Praxis bedeutet das:

• Loggen Sie niemals Request-Payloads mit cvv, cvc, cid oder security_code.
• Markieren Sie das Feld in Ihrem Observability-Stack als sensibel und entfernen Sie es an der Peripherie.
• Wenn Anbieter ein Prüfergebnis zurückgeben, speichern Sie das Ergebnis (cvv_check: pass/fail/unchecked), niemals den Wert selbst.
• Halten Sie das CVV-Feld aus Ihrer eigenen API heraus, wenn der Browser es direkt an den Tokenisierungs-Endpunkt des Gateways senden kann.

Wie sich CVV-Prüfungen in der Praxis verhalten

Eine CVV-Prüfung ist ein separates Autorisierungssignal, kein hartes Gate. Verschiedene Kartenaussteller und Gateways gehen unterschiedlich mit einer Abweichung um:

• Manche lehnen die Transaktion direkt ab.
• Manche genehmigen sie und geben einen CVC mismatch-Code zurück, sodass der Händler entscheiden kann.
• Manche sind so konfiguriert, dass sie die Prüfung in bestimmten Regionen ganz überspringen.

Sie können das gezielt testen: Stripes 4000 0000 0000 0127 liefert immer eine Antwort mit falscher CVC, ideal um Ihre Fehlerbehandlung zu testen, ohne eine echte Karte anzufassen. Weitere Nummern finden Sie in der vollständigen Liste der Testkarten.

Test-CVVs generieren

Für Sandbox-Arbeit akzeptieren die meisten Gateways beliebige 3 Ziffern (bei Amex 4). Unser Kartengenerator kann jeder generierten Nummer einen zufälligen oder festen CVV anhängen und das Ergebnis in einem pipe-getrennten Format ausgeben, das sich leicht in Fixtures parsen lässt:

4242424242424242|12|2030|123

Wenn Sie Nummern für einen bestimmten Ausstellerbereich generieren müssen, akzeptiert der erweiterte Generator Wildcard-Muster, und der BIN-Checker sagt Ihnen, zu welchem Kartennetzwerk ein Präfix gehört.

Zusammenfassung

• CVV, CVC, CID, CVV2 und CSC beschreiben alle dieselbe Idee mit netzwerkspezifischen Namen.
• Amex ist die Ausnahme: 4 Ziffern, auf der Vorderseite aufgedruckt.
• Speichern Sie den Code nach der Autorisierung nie — PCI DSS behandelt ihn als sensible Authentifizierungsdaten.
• Behandeln Sie eine CVV-Abweichung als konfigurierbares Ergebnis und testen Sie sowohl den Ablehnungs- als auch den Soft-Fail-Pfad.