Menu

Creditcardvervaldatum: formaat, regels en grensvoorwaarden

De creditcardvervaldatum wordt gedrukt als een maand en een jaar, en de kaart blijft geldig tot het einde van die maand. Hier lees je hoe je hem leest, opslaat en test.

Gepubliceerd

  • testdata
  • betalingen
  • formuliervalidatie

Een creditcardvervaldatum neemt vier tekens op het plastic in beslag en veroorzaakt een onevenredig aantal bugs in de software die hem leest. De gedrukte waarde is kort, maar draagt twee afzonderlijke regels tegelijk: in welke maand de kaart ophoudt te werken, en op welk tijdstip op de laatste dag van die maand dat werkelijk gebeurt. De grens verkeerd leggen is een van de klassieke manieren waarop een afrekenproces een kaart afwijst die nog volkomen bruikbaar is.

De volgende secties leggen uit wat de gedrukte datum betekent, hoe de einde-van-de-maandregel werkt, waarom formulieren en databases zelden hetzelfde opslaan als de kaart toont, en hoe je de lastige gevallen test.

Wat de gedrukte datum betekent

De datum op een kaart is een maand en een jaar, elk geschreven als twee cijfers, met de maand eerst: bijvoorbeeld maand negen en jaar zesentwintig, of maand één en jaar dertig. Er staat geen dag op de kaart, wat de eerste bron van verwarring is — mensen zoeken er een, omdat elke andere datum die ze hanteren er een heeft.

De maand en het jaar beschrijven wanneer de kaart ophoudt geldig te zijn, niet wanneer ze is uitgegeven. Een kaart met een datum die meerdere jaren vooruit ligt is normaal, omdat uitgevers een kaart doorgaans ruim voor het verstrijken vervangen.

De waarde is niet afgeleid van iets anders op de kaart. Het is geen controlesom en hij wisselt niet met het nummer. Dat is belangrijk voor testen: een vervaldatum kan niet met rekenkunde worden verzonnen, dus moet hij worden aangeleverd, en daarom komen gegenereerde kaarten met een datum eraan vast.

Is een kaart de hele maand geldig?

Ja. Dit is de regel die mensen eruit pikt. Een kaart met een gegeven maand en jaar wordt geaccepteerd tot en met de laatste dag van die maand, tot het laatste moment van die dag, in de tijdzone die het autorisatiesysteem van de uitgever gebruikt.

Een kaart met maand negen en jaar zesentwintig is dus bruikbaar op dertig september van dat jaar, en houdt op bruikbaar te zijn op het eerste moment van oktober. Elk systeem dat de kaart al aan het begin van september afsluit, of om middernacht op de laatste dag, wijst geldige betalingen af gedurende een periode die in uren of dagen wordt gemeten.

Gedrukte maand en jaar Eerste dag geldig Laatste dag geldig
Maand 1, jaar 2026 1 januari 2026 31 januari 2026
Maand 9, jaar 2026 1 september 2026 30 september 2026
Maand 12, jaar 2026 1 december 2026 31 december 2026

De tabel laat ook zien waarom het aantal dagen ertoe doet. Februari is de lastige, omdat de laatste dag van het jaar afhangt, en een formulier of geplande taak die achtentwintig dagen aanneemt, legt de grens in een schrikkeljaar verkeerd.

Waarom vragen formulieren om twee cijfers in plaats van vier?

Kaarten drukken het jaar alleen als twee cijfers af om ruimte te sparen, en formulieren vragen meestal om dezelfde twee omdat dat is wat de gebruiker voorleest. Die conventie verschuift een beslissing naar de software: bij welke eeuw hoort de waarde?

De eeuw in proza opschrijven in plaats van in code, is de gangbare aanpak om een tweecijferig jaar te behandelen als behorend tot de huidige of volgende eeuw, afhankelijk van hoe dicht het bij vandaag ligt. Een jaarwaarde die ver in het verleden lijkt te liggen is bijna altijd een typefout, geen kaart uit een eerder tijdperk, en een waarde die naar de verkeerde eeuw wordt gedecodeerd, wordt ofwel afgewezen als verlopen ofwel voor altijd geaccepteerd.

De veiligste aanpak voor een formulier is accepteren wat de gebruiker heeft, het één keer omzetten naar een ondubbelzinnige weergave — een maand en een volledig jaar van vier cijfers, of een eerste dag en een laatste dag — en die weergave daarna overal te gebruiken. Vergelijk nooit tweecijferige jaren rechtstreeks, want de vergelijking herdefinieert stilletjes de betekenis van de eeuw bij elke overgang.

Weergaveformaat en opgeslagen formaat zijn verschillende dingen

De reeks die een klant ziet en de waarde die een systeem bewaart zijn zelden hetzelfde, en ze door elkaar halen is een betrouwbare bron van defecten.

Op de kaart, en in een invoerveld, verschijnt de waarde als twee cijfers voor de maand en twee voor het jaar. In een database wordt ze vaak opgeslagen als een datum op de eerste van de maand, of als afzonderlijke gehele kolommen voor maand en jaar, of als een tijdstempel van het laatste geldigheidsmoment. Elke keuze heeft consequenties. Een tijdstempel op de eerste van de maand is makkelijk te sorteren en te vergelijken, maar vertelt je niet wanneer de kaart verloopt tenzij je ook de einde-van-de-maandregel kent. Een tijdstempel van het laatste moment codeert de juiste grens, maar ziet er alarmerend uit in een beheerscherm waar niemand een tijdstip naast een vervaldatum verwacht.

Welke weergave je ook kiest, houd de conversie op één plek. De bug die in productie opduikt is meestal een tweede conversie, geschreven door iemand die niet wist dat de eerste bestond, en de twee verschillen een maand van mening.

Veelvoorkomende fouten bij het intypen van een vervaldatum

De fouten die mensen in dit veld maken volgen een korte lijst, en elk heeft een verstandige reactie:

  • Het jaar als vier cijfers typen in een veld van twee. Accepteer het als je het ondubbelzinnig kunt koppelen, en laat de leidende tekens niet stilletjes vallen.
  • De maand en het jaar omwisselen. Maand dertien en jaar achtentwintig zijn beide ongeldig, dus valideer elk deel tegen zijn eigen bereik in plaats van alleen hun combinatie.
  • Een maand met een voorloopnul invoeren in een veld dat één cijfer verwacht. Behandel één en nul-één als dezelfde maand.
  • Een waarde plakken met een scheidingsteken dat het veld niet verwacht, zoals een koppelteken waar een schuine streep hoort.
  • Een datum invoeren die al is verstreken, wat een weigering is die het formulier moet uitleggen in plaats van alleen te markeren.

Voor ontwikkelaars: invoercontroles en grenstests

Twee kleine controles voorkomen het meeste van deze pijn. Ten eerste: splits maand en jaar in afzonderlijke invoervelden, of gebruik één veld dat de verwachte vorm zichtbaar begeleidt, zodat een omgewisselde waarde onwaarschijnlijk is in plaats van alleen maar detecteerbaar. Ten tweede: valideer elke component tegen zijn eigen bereik voordat je de combinatie valideert, zodat de gebruiker leert welk deel fout is.

Test voor de grenslogica de uiteinden van het bereik in plaats van het midden. De vier gevallen die het opschrijven waard zijn, zijn de eerste dag van de gedrukte maand, de laatste dag van de gedrukte maand, de dag na de laatste dag, en hetzelfde laatste-daggeval in een schrikkeljaar. Een test die tegen het midden van een maand is geschreven, bewijst bijna niets over de regel die je probeert te beschermen.

Controleer daarna hoe je systeem zich gedraagt wanneer de klok verschuift. Als een opgeslagen vervaldatum één keer op het moment van indienen wordt geconverteerd en nooit opnieuw wordt bekeken, zal een formulier dat over een maandgrens heen open blijft, een datum indienen die net ongeldig is geworden. Beslis bewust of dat een fout is die het tonen waard is of een acceptabele rand, en zorg dat het betaalverzoek en je eigen administratie het erover eens zijn.

Een passende vervaldatum uit de kaarttool halen

Elke kaart die de kaartnummersgenerator produceert, komt met een vervaldatum die dezelfde conventie volgt: een maand en een jaar in de toekomst, consistent over een hele batch. Die consistentie is wat een set fixtures bruikbaar maakt — een test die een nummer aan een datum koppelt, verwacht dat het paar geldig blijft zolang de suite in gebruik is, wat een reden is om gegenereerde data structureel correct en nooit uitgegeven te houden in plaats van waarden met de hand te verzinnen.

Als je meerdere kaarten nodig hebt die allemaal dezelfde vervaldatum delen, genereer dan een batch en kies daaruit in plaats van de datum opnieuw te typen, want één verkeerd getypt jaar is moeilijk te zien in een fixturebestand. De checklist voor betaalformulieren behandelt de bredere set stromen rond dit veld, en de gids over beveiligingscodes legt de andere vier tekens uit die een klant van de kaart leest.

Volgende stappen

Beslis, op papier, wat je systeem met een vervaldatum bedoelt — een maand, een eerste dag of een laatste moment — en zet de conversie achter één functie. Voeg daarna de vier hierboven beschreven grenstests toe, inclusief het schrikkeljaargeval, en bevestig dat een kaart met de huidige maand op haar laatste dag nog steeds wordt geaccepteerd.

Verder lezen

Handleidingen over Generator voor valse creditcardnummers (testkaarten)