Een creditcardnummer-generator produceert kaartnummers die voldoen aan de structurele regels die een betaalformulier controleert, zodat een checkoutflow kan worden beoefend zonder dat er ooit een echte kaart bij betrokken is. Het nummer is geen inloggegeven, het hangt niet aan een account, en het zal niets autoriseren — maar het zal de formaatcontroles, de issuer-voorvoegselregels en het controlecijfer doorstaan die een formulier toepast voordat het iets doorstuurt.
Deze gids legt uit wat de onderdelen van een kaartnummer betekenen, waarom het controlecijfer bestaat en wat het niet doet, waarom de beveiligingscode en de vervaldatum in een testrecord met het nummer moeten overeenstemmen, en waar de grens tussen een testomgeving en een kaarthoudergegevensomgeving ligt. Aan het einde weet je wat je in een test van een betaalformulier moet toetsen en wat je volledig uit je repository moet houden.
Wat betekenen de onderdelen van een kaartnummer?
Een kaartnummer is een cijferreeks met vaste lengte die uit drie delen bestaat. De voorste cijfers identificeren de uitgever en het netwerk, de middelste cijfers identificeren het individuele account binnen die uitgever, en het laatste cijfer is een controlewaarde die uit alle andere wordt berekend. De totale lengte varieert per netwerk en per kaartproduct, en een formulier dat één lengte aanneemt, zal geldige invoer afwijzen.
Het issuer-identificatienummer is het voorvoegsel, en dat is wat een formulier in staat stelt het juiste logo te tonen en de juiste regels toe te passen voordat een verzoek wordt verzonden. De voorvoegsels van de grote netwerken bezetten afzonderlijke numerieke bereiken, en die bereiken zijn gepubliceerd zodat een systeem een nummer kan routeren zonder iemand te contacteren. Wanneer een gegenereerd nummer een voorvoegsel uit het verkeerde bereik draagt, zal het formulier het ofwel ronduit afwijzen ofwel het netwerk in de interface verkeerd labelen.
Het middelste deel is het deel dat een generator verzint. In een synthetisch record staat er geen account achter, en dat is juist het punt. In een echte kaart verwijst het naar een specifiek account bij een specifieke uitgever, en precies daarom mag het nooit in een testfixture voorkomen.
Er is een praktische consequentie voor iedereen die een generator bouwt. De veiligste synthetische nummers blijven binnen de numerieke bereiken die de netwerken voor tests reserveren, omdat die bereiken zo zijn gedefinieerd dat er geen echt account kan bestaan. Een generator die door de hele voorvoegselruimte zwerft, kan uiteindelijk een combinatie produceren die aan iemand toebehoort, en een nummer dat aan iemand toebehoort is geen testdata meer, hoe onschuldig het ook is geproduceerd.
Waarom het controlecijfer bestaat en wat het bewijst
Het laatste cijfer wordt berekend door een gewogen checksum over de voorafgaande cijfers, een regel die meestal als het Luhn-algoritme wordt beschreven. Het doel is om overtypfouten op te vangen: een enkele verkeerd getypte cijfer, of twee aangrenzende cijfers die zijn omgedraaid, levert bijna altijd een nummer op dat de controle niet doorstaat. Het artikel over het Luhn-algoritme werkt de rekenkunde stap voor stap door.
Wat het controlecijfer bewijst is beperkt, en het verkeerd begrijpen ervan veroorzaakt echte fouten. Het bewijst dat de cijfers intern consistent zijn. Het bewijst niets over de vraag of het account bestaat, of de kaart actief is, of er geld beschikbaar is, of het nummer aan iemand toebehoort. Een formulier dat een geslaagd controlecijfer behandelt als verificatie van iets meer dan rekenkunde, is een formulier dat elk goed gevormd verkeerd getypt nummer dat een gebruiker kan produceren, zal accepteren.
Dat is de reden waarom een gegenereerd nummer zo nuttig is bij het testen. Het draagt precies de eigenschap die een formulier controleert — interne consistentie — en geen van de eigenschappen die een formulier niet kan controleren. De kloof tussen die twee verzamelingen is waar de meeste fouten in betaalformulieren leven.
Het is ook waarom tijdelijke waarden falen. Een veld dat met een herhaald cijfer is gevuld, of met een korte oplopende reeks, zal het controlecijfer niet doorstaan en dus nooit de codepaden bereiken die je werkelijk wilt testen. Een bruikbaar testnummer is een geldig nummer.
Waarom de beveiligingscode en de vervaldatum bij het nummer moeten passen
Een kaartrecord is een kleine verzameling velden die elkaar beperken, en een betaalformulier zal combinaties accepteren die geen enkele uitgever ooit zou uitgeven. De lengte van de beveiligingscode hangt van het netwerk af, dus een driecijferige code gekoppeld aan een netwerk dat vier cijfers gebruikt, is een mismatch. De vervaldatum moet voor de meeste stromen in de toekomst liggen, en de maand moet binnen de twaalf van de kalender vallen.
Of de kaart een debit- of een creditproduct is, beïnvloedt in sommige stromen ook het gedrag. Sommige checkouts behandelen ze identiek en sommige passen verschillende regels toe, en een testsuite die slechts één producttype beoefent, zal het verschil niet ontdekken. Een generator die beide kan produceren, met netwerken die bij de voorvoegsels passen, geeft je de variatie om die paden te vinden.
Het issuer-voorvoegsel en de netwerkbranding in de interface hebben dezelfde relatie. Als het formulier de naam van het ene netwerk toont terwijl het voorvoegsel bij een ander hoort, is de mismatch op zichzelf al een testgeval, en het is een fout waar een handmatige tester zelden op stuit omdat die de nummers typt die hij kent.
Zijn officiële testkaarten beter dan gegenereerde?
Betaalproviders publiceren testkaartnummers voor hun sandboxomgevingen, en die nummers zijn de juiste keuze voor één specifiek doel: het beoefenen van het gedrag van de provider zelf. Een gepubliceerd testnummer is gekoppeld aan gedocumenteerde uitkomsten — een geslaagde afschrijving, een geweigerde afschrijving, een specifieke foutcode — en het reproduceren van die uitkomsten hangt af van het gebruik van precies dat nummer.
Gegenereerde nummers dienen een ander doel. Ze zijn voor de delen van de stack die jij bezit: je validatie aan de clientzijde, je voorvoegseldetectie, je opmaak, je foutmeldingen, je opslag en je omgang met ongebruikelijke lengtes. Een sandbox zal geen gedocumenteerde uitkomst hebben voor een nummer dat hij nooit heeft gezien, dus gegenereerde nummers zijn voor alles wat gebeurt voordat het verzoek je applicatie verlaat.
De twee benaderingen vullen elkaar goed aan. Gebruik gegenereerde nummers voor de brede matrix van validatiegevallen, en een kleine verzameling gepubliceerde providernummers voor het handjevol integratietests dat op providerantwoorden toetst. Het artikel over Stripe-testkaarten behandelt de tweede categorie, en de checklist voor het testen van betaalformulieren behandelt de eerste.
Welke je ook gebruikt, houd de nummers in de testcode en uit de fixtures die een echt eindpunt bereiken. Een sandboxnummer dat per ongeluk naar een productiegateway wordt gestuurd, wordt afgewezen, maar vertrouwen op afwijzing als vangnet is geen beheersmaatregel.
Nog één eigenschap is het ontwerpen waard: een vervaldatum die nooit veroudert. Een fixture met een hardgecodeerde vervaldatum zal op een dag een kaart beschrijven die vorige maand is verlopen, en de test zal beginnen te falen om een reden die niets met de wijziging onder review te maken heeft. Een generator die de vervaldatum berekent ten opzichte van de huidige datum, houdt de fixture onbeperkt geldig, en dat verwijdert een hele klasse van verwarrende fouten uit de suite.
Wat betekent PCI DSS voor een bedrijf zonder echte kaarten
De Payment Card Industry Data Security Standard bepaalt hoe kaarthoudergegevens worden opgeslagen, verwerkt en verzonden. De centrale regel is eenvoudig te stellen en makkelijk te onderschatten: een testomgeving mag geen echte kaartnummers bevatten. Niet in een fixture, niet in een seedscript, niet in een commentaar, en niet in een log.
De reden is dat een kaartnummer samen met een naam en een vervaldatum beschermde gegevens is, ongeacht de omgeving waarin het staat. Een productierij naar staging kopiëren creëert een nieuwe locatie met kaarthoudergegevens, meestal met zwakkere toegangscontroles en een langere back-upgeschiedenis. Het artikel over PCI DSS-testdata onderzoekt de consequenties in meer detail.
Voor een team dat geen echte kaarten bezit, is naleving betrekkelijk eenvoudig. Als elk nummer in de omgeving synthetisch is en er geen echte kaart kan aankomen, beantwoordt de scopevraag zich grotendeels zelf. De vereiste discipline is om dat zo te houden: plak nooit een echt nummer in een bugrapport, maak nooit een screenshot van een live checkout, en importeer nooit een productie-extract om testdata realistisch te laten lijken.
De organisatorische faalwijze is meestal intentie in plaats van onachtzaamheid. Iemand moet een productiefout reproduceren, importeert daarvoor een stuk productie, en laat het stuk staan. Een regel dat testdata gegenereerd moet worden in plaats van gekopieerd, is makkelijk vol te houden zolang die nooit is versoepeld.
Welke gevallen voor betaalformulieren zijn het schrijven waard
De gevallen die echte fouten vangen, zijn de gevallen die op de grenzen zitten. Test een nummer dat één cijfer korter en één cijfer langer is dan de verwachte lengte voor elk ondersteund netwerk, en toets dat het formulier beide afwijst met een melding waarop een gebruiker kan handelen. Test een voorvoegsel dat bij een netwerk hoort dat je checkout niet accepteert, en bevestig dat de afwijzing duidelijk is in plaats van generiek.
Test het controlecijfer expliciet door een geldig nummer te nemen en één cijfer in het midden te wijzigen, en toets dan dat het formulier het afwijst. Dit geval is waardevol omdat het formulieren onderscheidt die de checksum werkelijk uitvoeren van formulieren die alleen cijfers tellen, en de tweede soort komt vaker voor dan zou moeten.
Test opmaak en plakken. Gebruikers plakken nummers met spaties, met koppeltekens en met een voorloop- of volgspatie, en een veld dat die tekens ongewijzigd opslaat, zal stroomafwaarts falen. Test het veld voor de beveiligingscode tegen de verwachte lengte van het netwerk, en test een vervaldatum voor de vorige maand en voor de huidige maand, want de grens tussen die twee is waar off-by-one-fouten leven. Het artikel over het formaat van kaartnummers somt de structurele regels op die aan al deze zaken ten grondslag liggen.
Test dan wat er gebeurt na een mislukking. Een gebruiker die een cijfer verkeerd typt, moet het kunnen corrigeren zonder het hele formulier opnieuw in te voeren, en de fout mag de andere velden niet wissen. Dat gedrag wordt zelden getoetst en is vaak stuk. De kaartnummergenerator op deze site is gebouwd om nummers te produceren over de ondersteunde netwerken met de juiste lengte en een geldig controlecijfer, zodat een matrix van deze gevallen kan worden samengesteld zonder voor elk geval een fixture met de hand te schrijven.
Wat een gegenereerd kaartnummer wel en niet is
Een gegenereerd kaartnummer is synthetische testdata. Het heeft een goed gevormd voorvoegsel, een correcte lengte voor zijn netwerk en een geldig controlecijfer, en het is ontworpen om software te beoefenen. Het is geen betaalinloggegeven, het wordt door geen enkele bank of geen enkel netwerk uitgegeven, het hangt aan geen enkel account, en het kan niet worden gebruikt om een aankoop te doen, een transactie te autoriseren of een echte verificatie te doorstaan.
Het mag niet worden gebruikt om goederen of diensten te verkrijgen, om een live betaalsysteem te testen met de bedoeling te transacteren, om een kaarthouder na te doen, of om een controle te omzeilen die bestaat om echte accounts te beschermen. Het bestaat zodat je eigen formulieren, parsers en validatielogica kunnen worden getest, en voor niets anders.
Waar een kaartnummer in een record wordt gecombineerd met een naam, een adres en een geboortedatum, is het hele record synthetisch. Correcte structuur en interne consistentie zijn de eigenschappen die het bruikbaar maken; het zijn geen beweringen over iets echts, en geen enkel deel van zo’n record mag ooit worden gepresenteerd als iemands financiële gegevens.