Das Kreditkarte Ablaufdatum ist der unscheinbarste Wert auf einer Karte und derjenige, der am häufigsten falsch verarbeitet wird. Es besteht aus genau zwei Angaben, Monat und Jahr, und es enthält weder einen Tag noch eine Uhrzeit. Trotzdem muss jedes Kassensystem daraus entscheiden, ob eine Karte heute noch verwendbar ist, und diese Entscheidung fällt an genau einem Tag im Monat falsch aus, wenn die Regel nicht sauber umgesetzt wurde.
Dieser Beitrag erklärt, was das aufgedruckte Datum bedeutet, warum eine Karte bis zum letzten Tag des Monats gültig bleibt, weshalb Formulare nur zwei Ziffern für das Jahr abfragen und welche Grenzfälle jede Prüfung bestehen muss.
Was das aufgedruckte Datum bedeutet
Auf der Vorderseite fast jeder Karte steht ein Datum in der Form Monat und Jahr, üblicherweise getrennt durch einen Schrägstrich, also etwa als zwei Ziffern für den Monat, einem Trennzeichen und zwei Ziffern für das Jahr. Ein Tag fehlt vollständig. Das ist keine Vereinfachung für den Druck, sondern entspricht der Funktionsweise des Systems: Karten laufen monatsweise ab.
Das Datum ist keine Prüfziffer und steht in keiner rechnerischen Beziehung zur Kartennummer. Es lässt sich aus der Nummer nicht ableiten und umgekehrt. Deshalb muss es in jedem Zahlungsvorgang ausdrücklich mitgeliefert werden, und deshalb kann eine Testnummer beliebig mit Ablaufdaten kombiniert werden, ohne dass die Prüfsumme darunter leidet.
Das Datum erfüllt zwei Zwecke. Erstens begrenzt es die Lebensdauer einer Karte; nach dem Ablauf verweigert der Herausgeber die Autorisierung, und der Kunde erhält in der Regel rechtzeitig Ersatz. Zweitens dient es als schwaches zweites Merkmal bei Zahlungen ohne Karte, weil es auf einem gestohlenen Datenbestand nicht zwingend mit der Nummer übereinstimmt.
Ist eine Karte den ganzen Monat über gültig?
Ja. Eine Karte ist bis zum letzten Tag des aufgedruckten Monats einschließlich gültig, gerechnet in der Zeitzone des autorisierenden Systems. Der Monat läuft also nicht am ersten Tag an und endet nicht in der ersten Woche, sondern umfasst den gesamten Kalendermonat.
| Aufgedruckt | Gültig von | Gültig bis einschließlich |
|---|---|---|
| Monat 1, Jahr 2026 | 1. Januar 2026 | 31. Januar 2026 |
| Monat 9, Jahr 2026 | 1. September 2026 | 30. September 2026 |
| Monat 12, Jahr 2026 | 1. Dezember 2026 | 31. Dezember 2026 |
Diese Tabelle erklärt den klassischen Fehler. Wer eine Karte am letzten Tag ihres Monats als abgelaufen behandelt, weist einen Kunden zurück, dessen Karte noch stundenlang funktioniert. Wer umgekehrt den Monatsanfang großzügig auslegt und den Monat erst mit dem Ersten beginnen lässt, weist eine Karte ab, die seit dem ersten Tag gültig ist.
Die Monatslänge variiert, und der Februar macht daraus einen echten Sonderfall. Im Schaltjahr endet er am neunundzwanzigsten, sonst am achtundzwanzigsten. Eine Prüfung, die fest mit achtundzwanzig Tagen rechnet, liegt in drei von vier Jahren richtig und im vierten falsch, was den Fehler besonders schwer auffindbar macht. Sauber implementiert man die Regel, indem man den ersten Tag des Folgemonats bildet und prüft, ob der aktuelle Zeitpunkt davor liegt. Damit verschwinden alle Monatslängen und Schaltjahre aus der Rechnung.
Warum fragen Formulare zwei Ziffern statt vier ab?
Weil auf der Karte nur zwei Ziffern stehen. Der Nutzer liest ab, was er sieht, und jede zusätzliche Umrechnung ist eine Fehlerquelle. Praktisch ist die Jahrhundertangabe ohnehin eindeutig, denn kein Zahlungssystem arbeitet mit Karten aus den Zwanzigern des vorigen Jahrhunderts; eine zweistellige Jahresangabe lässt sich also eindeutig dem laufenden oder nächsten Jahrhundert zuordnen.
Genau diese Eindeutigkeit muss die Software selbst herstellen. Der verbreitetste Fehler in diesem Bereich ist, eine zweistellige Jahresangabe als Jahr im aktuellen Jahrhundert zu interpretieren und dadurch einen Wert zu erzeugen, der bereits vergangen ist. Ein Formular, das eine gültige Karte als abgelaufen zurückweist, produziert Supportanfragen, deren Ursache niemand in einem Datumsvergleich vermutet.
Die Umrechnung gehört an genau eine Stelle im Code und nicht in jeden Aufrufer. Wird der Wert an mehreren Stellen in ein Datum umgewandelt, weichen die Ergebnisse über kurz oder lang voneinander ab, und der Fehler tritt nur in dem Pfad auf, den man gerade nicht testet.
Anzeigeformat und Speicherformat sind zweierlei
Für Anzeige und Speicherung gelten unterschiedliche Anforderungen, und beide zu vermischen rächt sich.
Für die Anzeige gilt, was auf der Karte steht: Monat und Jahr, zweistellig, in derselben Reihenfolge wie im Formular. Wer in der Bestellübersicht ein vollständiges Datum mit Tag anzeigt, hat einen Tag erfunden, den die Karte nicht kennt.
Für die Speicherung gibt es drei übliche Varianten, und alle sind vertretbar, solange die Wahl einheitlich bleibt. Die erste speichert den ersten Tag des Monats, die zweite zwei getrennte Ganzzahlen für Monat und Jahr, die dritte einen Zeitpunkt auf den letzten Moment des Monats. Die dritte Variante ist die einzige, die direkt mit einem Vergleich arbeitet, und gleichzeitig die fehleranfälligste, weil Zeitzonen ins Spiel kommen.
Unabhängig von der Wahl gilt: Maschinenlesbare Werte gehören nicht in Fehlermeldungen. Eine Meldung, die dem Nutzer den gespeicherten Zeitstempel vorführt, verwirrt mehr, als sie hilft.
Häufige Fehler beim Eintippen eines Ablaufdatums
Die Eingabe ist kurz, und trotzdem gibt es eine erstaunlich feste Liste von Fehlern:
- Vier Ziffern für das Jahr werden in ein zweistelliges Feld getippt. Die ersten beiden Zeichen füllen das Feld, der Rest verschwindet.
- Monat und Jahr werden vertauscht. Der Nutzer liest die Karte von links nach rechts und trägt Monat und Jahr in der falschen Reihenfolge ein.
- Die führende Null wird weggelassen. Ein einstelliger Monat wird ohne Null geschrieben und passt nicht in das erwartete Muster.
- Beim Einfügen werden Trennzeichen mitgenommen. Ein kopierter Wert mit einem Punkt oder Bindestrich scheitert, obwohl die Ziffern korrekt sind.
- Ein bereits vergangenes Datum wird akzeptiert. Die Prüfung vergleicht nicht mit dem aktuellen Datum und lässt eine offensichtlich abgelaufene Karte durch.
- Das Datum wird als Zahl behandelt. Dadurch verliert der Monat seine führende Null und die Reihenfolge der Stellen wird unklar.
Gut gestaltete Formulare fangen jeden dieser Fälle ab, ohne den Nutzer zu beschuldigen. Die Meldung nennt das erwartete Muster und nicht das Fehlverhalten.
Für Entwickler: Eingabesteuerung und Grenzwerttests
Die Eingabesteuerung sollte zwei Ziffern für den Monat und zwei für das Jahr zulassen, Trennzeichen optional annehmen und die Werte nach dem Verlassen des Feldes in eine eindeutige Form bringen. Eine automatische Verschiebung des Eingabefokus nach zwei Ziffern ist üblich und hilfreich, solange sie das Korrigieren einer falschen Eingabe nicht behindert.
Die Prüfung selbst läuft in drei Schritten: Der Monat muss zwischen eins und zwölf liegen, das umgerechnete Datum muss gültig sein, und der letzte Tag des Monats darf nicht vor dem aktuellen Zeitpunkt liegen. Auf dieser Grundlage sind vier Grenzfälle zu testen:
- Der erste Tag des aufgedruckten Monats. Die Karte muss akzeptiert werden.
- Der letzte Tag des aufgedruckten Monats. Die Karte muss weiterhin akzeptiert werden.
- Der erste Tag des Folgemonats. Die Karte muss abgelehnt werden.
- Der letzte Tag des Februars im Schaltjahr. Die Karte muss akzeptiert werden.
Diese vier Fälle decken die gesamte Logik ab, weil sie die beiden Übergänge und den einzigen variablen Monat betreffen. Wer sie in einer Suite hat, braucht keine weiteren Datumstests. Wie sie sich mit den übrigen Prüfschritten zu einer Gesamtabnahme verbinden, beschreibt die Checkliste für Zahlungsformulare.
Ein passendes Ablaufdatum aus dem Kartenwerkzeug
Für Testdaten ist es unpraktisch, Ablaufdaten von Hand zu pflegen, weil sie nach einigen Monaten von selbst veralten und eine Suite dann ohne Codeänderung rot wird. Der Kartennummern-Generator erzeugt zu jeder Nummer ein Ablaufdatum in der Zukunft, sodass ein erzeugtes Paket auch nach Monaten noch verwendbar ist.
Für die Grenzfälle oben ist das nicht ausreichend, und das ist beabsichtigt. Diese Werte gehören ausdrücklich und sichtbar in den Test geschrieben, damit erkennbar bleibt, dass sie die Randbedingungen prüfen und nicht bloß Beispieldaten sind. Erzeugen Sie also ein Paket für den Normalfall und halten Sie vier feste Datumswerte für die Grenzfälle bereit. Wer zusätzlich wissen will, in welchem Verhältnis Nummer, Ablaufdatum und Sicherheitscode zueinander stehen, findet die Übersicht im Beitrag zum Sicherheitscode.
Nächste Schritte
Prüfen Sie Ihre eigene Logik gegen drei Fragen. Wird der letzte Tag des Monats noch akzeptiert? Wird der erste Tag des Folgemonats abgelehnt? Und wird ein Schaltjahr-Februar ohne Sonderbehandlung korrekt behandelt? Wenn alle drei mit ja beantwortet sind, ist das Ablaufdatum erledigt, und Sie können sich dem nächsten Feld zuwenden.