Menu

Testcreditcardnummers: wat ze zijn en waar je ze gebruikt

Testcreditcardnummers voldoen aan de opmaak- en controlesomregels, maar horen bij niemand. Dit is waar ze vandaan komen, waar ze veilig zijn en welke valkuilen je moet vermijden.

Gepubliceerd

  • testdata
  • betalingen
  • kaartnummers

Testcreditcardnummers zijn cijferreeksen die elke structurele regel van een echte kaart volgen — een geloofwaardige netwerkprefix, een toegestane lengte en een laatste controlecijfer dat klopt — terwijl ze nergens bij een account horen. Ze bestaan zodat afrekenformulieren, staging-systemen en geautomatiseerde testsuites kunnen worden beproefd zonder echt geld te verplaatsen of een echte betaalreferentie te kopiëren naar een plek waar die niet thuishoort. Deze pagina legt uit waar zulke nummers vandaan komen, in welke omgevingen ze veilig zijn, en welke fouten een onschuldige test stilletjes veranderen in een poging tot betaling.

Wat een testcreditcardnummer precies is

Een kaartnummer is geen willekeurige reeks. Van links naar rechts gelezen bevat het drie delen: een uitgeversprefix dat het routersysteem vertelt tot welk netwerk en welke uitgever de kaart behoort, de accountcijfers die de uitgever toekent, en een afsluitend controlecijfer dat uit al het voorgaande wordt berekend.

Een testnummer houdt het eerste en het laatste van die drie en verzint het midden. De prefix wordt overgenomen uit een gepubliceerd bereik van een netwerk, zodat merkdetectie zich gedraagt zoals in productie, het accountgedeelte wordt gevuld met willekeurige cijfers, en het controlecijfer wordt berekend zodat het klopt. Niets in de resulterende reeks wijst naar een persoon, een saldo of het grootboek van een uitgever.

De praktische consequentie is dat geldig in deze context goed gevormd betekent. Het is een uitspraak over rekenkunde en lengte, niet over eigendom of status.

Eigenschap Een echt kaartnummer Een testkaartnummer
Prefix en lengte Binnen de regels van het netwerk Binnen dezelfde regels
Controlecijfer Correct door constructie Correct door constructie
Gekoppeld aan een account Ja Nee
Kan een betaling autoriseren Ja, als het account open is Nee
Veilig om in een repository te bewaren Meestal niet Ja

Waarom bestaan testnummers eigenlijk?

Elke betaalinterface heeft twee verplichtingen die tegen elkaar indruisen. Hij moet typefouten, afgekapte invoer en verzonnen cijfers weigeren, en hij moet elke kaart accepteren die een echte klant zou kunnen hebben. Om aan de eerste verplichting te voldoen is bewust kapotte invoer nodig; om aan de tweede te voldoen is invoer nodig die er volkomen gewoon uitziet.

Echte kaarten zijn ongeschikt voor die tweede rol. Een levend nummer intypen in een staging-formulier kopieert een werkende betaalreferentie naar een omgeving die zelden zo streng wordt gecontroleerd als productie, en één onbedoelde verzending wordt een echte afboeking. Netwerken reserveren daarom bereiken voor documentatie en sandboxgebruik, betaalproviders publiceren een korte lijst met nummers die hun eigen sandboxen herkennen, en al het overige is synthetisch.

Die laatste categorie is waar gegenereerde data thuishoort. Een generator produceert nummers op verzoek volgens dezelfde openbare nummeringsregels, zodat voor elk netwerk en elke hoeveelheid een batch kan worden gemaakt zonder iemand om een account te vragen.

Kan een testnummer ooit worden afgeschreven?

Nee — en begrijpen waarom is wat teams uit de problemen houdt. Een gegenereerd nummer slaagt voor een opmaakcontrole en een controlesom. Geen van beide betrekt een bank erbij. Wanneer een betaalformulier verbonden is met een echte gateway, stuurt de gateway een autorisatieverzoek naar de uitgever van de prefix in het nummer, het verzoek vindt geen overeenkomstig account, en de poging mislukt.

Die mislukking is nog steeds een gebeurtenis. Ze verschijnt in het dashboard van de gateway, telt mogelijk mee voor fraudedrempels, en laat in sommige configuraties een auditspoor achter met de naam van jouw team erin. De eerlijke regel is dus niet dat gegenereerde nummers overal onschadelijk zijn, maar dat ze onschadelijk zijn in omgevingen die niet gevraagd wordt iets te autoriseren.

Elk nummer dat de generator op deze site produceert, is een reeks die een validatieroutine accepteert en die geen enkele uitgever ooit heeft uitgegeven. Het is structureel correct, nooit aan een echt account toegekend, en mag nooit op een live endpoint worden gericht.

Waar testnummers veilig te gebruiken zijn

Het onderscheid dat ertoe doet, is of een systeem het nummer alleen parseert of daadwerkelijk probeert af te schrijven. Ruwweg in volgorde van afnemende veiligheid:

  • Unittesten die een lengteregel, een controlesom of een vertakking voor netwerkdetectie controleren.
  • Front-enddemo’s waarin een formulier lokaal wordt gevalideerd en daarna weggegooid.
  • Staging-omgevingen die op de sandboxmodus van een provider zijn aangesloten.
  • Databaseseeding voor een scherm met bestelgeschiedenis of een beheerpaneel.
  • Belastingstests tegen je eigen endpoints, mits de betaalstap is gesimuleerd.
  • Handmatige QA van de afrekeninterface, met de betaalstap gemockt of in een sandbox.

De lijst is niet langer veilig op het moment dat een echte gatewaysleutel in de configuratie staat. Als je staging-omgeving productiegegevens deelt — en dat doen er veel — dan is een gegenereerd nummer geen testdata meer, maar een poging tot afboeking.

Nummers kiezen die je kunt reproduceren

Willekeurige batches zijn handig voor een demo en pijnlijk voor een regressiesuite. Als een test die gisteren faalde tegen een vers gegenereerd nummer liep, dan bewijst het vandaag opnieuw uitvoeren heel weinig, omdat de invoer niet meer dezelfde is.

Behandel een gegenereerde batch zoals je een gouden bestand behandelt: kies het netwerk en de hoeveelheid die je nodig hebt, genereer één keer, en bewaar die exacte set naast de test die hem gebruikt. Wanneer een regel verandert, bijvoorbeeld een lengtebeperking wordt aangescherpt, laat de opgeslagen batch je precies zien welke van je fixtures niet meer slagen.

Twee gewoonten maken dit veel draaglijker. Geef elke fixtureset een korte beschrijvende naam in plaats van een datum, en leg vast welk netwerk elk nummer claimt, zodat een foutrapport je vertelt welke detectievertakking je moet onderzoeken.

Voor ontwikkelaars: fixturedata die zich gedraagt

Een paar details bepalen of een set testnummers nuttig is of alleen maar aanwezig in de repository.

Ten eerste: maak de data leesbaar. Een nummer dat voor een mens bewaard wordt om te inspecteren, moet gegroepeerd zijn zoals het op een kaart staat, zelfs als de code scheidingstekens verwijdert voordat er wordt gevalideerd; de groepering is documentatie. Opmaakformaten en validatielogica komen aan bod in de opmaakgids en in het stuk over het Luhn-algoritme, de controle waaraan het laatste cijfer moet voldoen.

Ten tweede: dek de grenzen bewust af. Een fixtureset met alleen zestiencijferige Visanummers oefent de vertakking die vijftiencijferige American Express afhandelt niet uit, en bereikt nooit de code die een zeventiencijferige invoer weigert. Neem één nummer op per lengteregel die je denkt te ondersteunen.

Ten derde: houd zichtbaar dat de data niet is uitgegeven. Een opmerking naast de fixture, of een naamgevingsconventie die synthetisch zegt, voorkomt dat een toekomstige beheerder een van de waarden “leent” voor een handmatige test tegen een echt account.

Beslis tot slot wat je suite doet wanneer de data fout is. Een controlesomfout moet worden gerapporteerd als misvormde invoer, niet als een geweigerde betaling; het door elkaar halen van die twee verbergt echte defecten achter omgevingsfouten.

Een batch genereren in de kaarttool

De kaartnummersgenerator op deze site produceert precies dit soort data. Je kiest een netwerk of laat het willekeurig, kiest hoeveel kaarten je nodig hebt, en de tool levert nummers met bijpassende vervaldata en plaatsvervangende beveiligingscodes die je los of allemaal tegelijk kunt kopiëren. Als je al een deel van een nummer hebt, vult de aanvulmodus de onbekende cijfers in in plaats van vanaf nul te genereren, wat nuttig is wanneer een bugmelding een gedeeltelijke waarde bevat.

Omdat de uitvoer van begin tot eind synthetisch is, is de batch veilig om in een fixturebestand te plakken — wat precies het doel is van het reproduceerbaar houden ervan. De compliancenotities leggen uit waarom een synthetische waarde te verkiezen is boven een gemaskeerde echte waarde, zelfs in een staging-database die niemand buiten het team kan bereiken.

Volgende stappen

Genereer een kleine batch, bewaar die naast de test die hem gebruikt, en voeg één bewust kapot nummer toe zodat ook het faalpad gedekt is. Wanneer je moet begrijpen waarom een bepaalde reeks wordt geaccepteerd of geweigerd, begin dan met de opmaakregels voor kaartnummers, en grijp naar de netwerkvergelijking wanneer je één nummer per merk nodig hebt.

Verder lezen

Handleidingen over Generator voor valse creditcardnummers (testkaarten)