ik bouw Toolz.devidd, en daarvoor heb ik jaren bezig geweest met het verzenden van WordPress plugins en Laravel API's, waarvan er verschillende betalingen moesten aannemen, het eerste checkout formulier dat ik ooit schreef stuurde elk verkeerd getypt kaartnummer direct naar de betalingsgateway en wachtte tot het stuiterde Het werkte, technisch gezien, maar het was traag en het brandde door gateway verzoeken op nummers die nooit geldig kunnen zijn geweest in de eerste plaats De oplossing was beschamend klein: voer de Luhn controlesom in de browser voordat je het indienen Die ene verandering ving de meeste typefouten onmiddellijk en stopte een stroom van zinloze API-oproepen Deze gids gaat over die controle, de prefix regels die ernaast zitten, en de Creditcard Validator Ik heb gebouwd zodat jij ook nooit meer opnieuw hoeft te implementeren vanuit je geheugen.
tl;dr: Een creditcardvalidator bevestigt dat een getal structureel correct is, niet dat het tot een echt account behoort, Het voert twee onafhankelijke tests uit: de Luhn-controlesom van ISO/IEC 7812-1, die bijna elke typfout met één cijfer en aangrenzende transpositie opvangt, en een lengte-en-voorvoegselcontrole van elk netwerk' s gepubliceerde emittentbereiken Een getal kan het ene passeren en het andere niet halen, dus de twee resultaten worden afzonderlijk gerapporteerd Het draait volledig in uw browser, dus er wordt nooit een kaartnummer geüpload, en het kan u nooit vertellen of er geld op een kaart staat Alleen de emittent weet dat.
Wat betekent het dat een kaartnummer geldig is?
Een betaalkaartnummer, formeel een Primair Rekeningnummer of PAN, is geen willekeurige reeks cijfers De structuur ervan wordt gedefinieerd door ISO/IEC 7812. De eerste zes tot acht cijfers zijn het Issuer Identification Number, of IIN, dat vroeger het Bank Identification Number (BIN) werd genoemd. Die cijfers identificeren het netwerk en de uitgevende bank. De cijfers daarna tot en met de voorlaatste zijn de individuele rekeningidentificatie, en het allerlaatste cijfer is een controlecijfer berekend met het Luhn-algoritme.
Dus "valid" heeft twee aparte betekenissen, en het helpt om ze uit elkaar te houden De eerste is dat het getal voldoet aan de Luhn controlesom, wat betekent dat het controlecijfer consistent is met de rest van het getal De tweede is dat het getal de juiste lengte en prefix heeft voor een echt kaartnetwerk Een getal kan aan de ene voorwaarde voldoen en niet aan de andere. 4111 1111 1111 1112 heeft een Visa-voorvoegsel en een Visa-lengte, maar faalt Luhn. Een willekeurige reeks van zestien cijfers die toevallig eindigt op het juiste controlecijfer passeert Luhn, maar kan beginnen met een voorvoegsel dat geen enkel netwerk bezit. Een goede validator vertelt u welke van de twee faalde, omdat de oplossing in elk geval anders is.
Wat geen van beide cheques kan doen, is u vertellen dat de kaart echt is Structurele geldigheid gaat over de vorm van het nummer, niet over de staat van de rekening erachter Het account bestaat mogelijk niet, is misschien bevroren, is misschien over de limiet, of is misschien al jaren geleden gesloten Het enige systeem dat het weet is de uitgevende bank, en het antwoordt precies één keer, tijdens een autorisatieverzoek in een live transactie Alles wat een browser-side validator doet is een goedkoop voorfilter dat draait voordat je ooit op dat punt komt.
Hoe werkt het Luhn-algoritme?
Het Luhn-algoritme, ook wel het mod-10-algoritme genoemd, werd in 1960 gepatenteerd door Hans Peter Luhn bij IBM en bevindt zich nu in het publieke domein Het is een controlesom, wat betekent dat het hele doel is om toevallige fouten op te sporen, geen enkele beveiliging te bieden Het werkt zo Beginnend bij het meest rechtse cijfer en naar links bewegend, verdubbel je elk tweede cijfer Als verdubbeling een getal oplevert groter dan negen, trek je er negen van af (wat hetzelfde is als het optellen van de twee cijfers bij elkaar) Dan tel je alle cijfers op, de verdubbelde en de onaangeraakte Als het totaal deelbaar is door tien, gaat het getal voorbij.
Hier is de check on 4111 1111 1111 1111, van rechts naar links werken Het meest rechtse cijfer is positie één en wordt niet verdubbeld Verdubbeling van elk tweede cijfer geeft een set van enen en tweeën, de tweeën komen van de verdubbelde posities Tel ze allemaal op en het totaal komt op een veelvoud van tien, dus het getal gaat over. Verander elk enkel cijfer en de som stopt bijna altijd met een veelvoud van tien te zijn, wat precies is wat de controle nuttig maakt.
De waarde van Luhn zit in wat het vangt Het detecteert elke fout van één cijfer, wat betekent dat elk cijfer verkeerd getypt wordt Het vangt ook bijna elke transpositie van twee aangrenzende cijfers op, de klassieke & quot; Ik typte 21 in plaats van 12" fout, met één bekende uitzondering: het vangt geen swap op van 09 en 90, omdat beide op dezelfde gewogen som zijn afgebeeld Dat is een echte dode hoek, maar het is een zeldzame, en het is de reden dat Luhn eerder een controlesom dan een cryptografische garantie is Voor formuliervalidatie is het meer dan goed genoeg, en daarom zit het achter de kaartvelden van vrijwel elke kassa op internet.
Hoe wordt het kaartnetwerk gedetecteerd?
Het netwerk wordt gelezen van de leidende cijfers, de IIN. Elk netwerk bezit specifieke prefixbereiken, en de meeste beperken ook de totale lengte De validator komt eerst overeen met het langste, meest specifieke prefix, omdat sommige bereiken elkaar overlappen Hier zijn de bereiken die het controleert:
| netwerk | Begint met | Geldige lengtes | Beveiligingscode |
|---|---|---|---|
| Visa | 4 | 13, 16, 19 | 3 |
| Mastercard | 51-55, 2221-2720 | 16 | 3 |
| American Express | 34, 37 | 15 | 4 |
| Discover | 6011, 65, 644-649, 622126-622925 | 16, 19 | 3 |
| Diners Club | 300-305, 309, 36, 38-39 | 14, 16, 19 | 3 |
| JCB | 3528-3589 | 16-19 | 3 |
| UnionPay | 62 | 16-19 | 3 |
| Maestro | 50, 56-69 (geselecteerd) | 12-19 | 3 |
De overlappingen zijn het interessante deel, en als je ze verkeerd begrijpt, misvuren naïeve detectoren. Mastercard voegde de 2221-2720 bereik in 2017, dus een detector die voor die tijd geschreven is meldt die kaarten als onbekend Discover bezit een smal stukje van de 62 ruimte, 622126 doorgaand 622925, terwijl UnionPay de rest van bezit 62, dus de volgorde waarin u ze test, bepaalt of a 6221 kaart leest als Discover of UnionPay De validator test het specifieke Discover-venster vóór het brede UnionPay-voorvoegsel, zodat beide correct landen. American Express is degene die de opmaakcode activeert, omdat het vijftien cijfers gebruikt, gegroepeerd op 4-6-5 in plaats van de gebruikelijke vier groepen van vier, en het gebruikt een viercijferige beveiligingscode (de CID gedrukt op de voorkant) in plaats van de driecijferige CVV op de achterkant.
Hoe de creditcardvalidator te gebruiken
De tool is bewust simpel Je plakt een nummer en leest het resultaat Er is geen submit knop en niets te configureren.
Stap 1: Voer het nummer in
Typ of plak het kaartnummer in het veld Ruimtes en streepjes worden genegeerd, dus 4111-1111-1111-1111, 4111 1111 1111 1111, en 4111111111111111 valideer allemaal identiek Dit is belangrijk omdat echte invoer in elk formaat binnenkomt: gekopieerd van een spreadsheet, een kaart afgelezen of uit een testopstelling gehaald.
Stap 2: Lees het vonnis
De bovenkant van het resultaat vertelt je duidelijk of het nummer geldig is, en als dat niet het geval is, noemt het de reden. Daaronder worden de twee controles afzonderlijk weergegeven: of de Luhn-controlesom is geslaagd en of de lengte overeenkomt met het gedetecteerde netwerk. Als je ze uit elkaar ziet, is het punt. Een getal dat Luhn passeert maar de lengte niet haalt, betekent bijna altijd dat een cijfer is gevallen of toegevoegd, terwijl een getal dat Luhn niet haalt maar de juiste lengte heeft, meestal betekent dat één cijfer gewoon verkeerd is.
Stap 3: Controleer het gedetecteerde netwerk
De tool toont het netwerk dat het heeft geïdentificeerd aan de hand van het voorvoegsel, de lengtes die het netwerk toelaat en hoe lang de beveiligingscode moet zijn. Dit is op zichzelf handig als u een formulier bouwt en het juiste kaartlogo wilt weergeven, of als u moet weten of u een drie- of viercijferige CVV kunt verwachten.
Stap 4: Kopieer het opgemaakte of gemaskeerde nummer
U kunt het nummer gegroepeerd kopiëren zoals het netwerk het afdrukt, of een gemaskeerde versie kopiëren die elk cijfer verbergt, behalve de laatste vier. Het gemaskeerde formulier is het gewenste formulier in logboeken, screenshots en ondersteuningstickets, omdat het opslaan of weergeven van een volledige PAN precies het soort is dat mensen in de problemen brengt met naleving.
Waar past validatie, en waar stopt het?
De eerlijke framing is dat een validator een filter is, geen poort Het hoort aan de voorkant van een proces om duidelijk afval goedkoop af te wijzen, en het mag nooit worden vertrouwd als bewijs van iets stroomafwaarts In een afrekenformulier, met Luhn client-side kunt u een typefout markeren op het moment dat de gebruiker klaar is met typen, voordat ze op loon slaan, wat een betere ervaring is en een gedoemde heen- en terugreis naar de gateway bespaart In een datapijplijn worden kaartvormige velden vangt beschadigde rijen voordat ze een systeem bereiken dat erop zal stikken. In testsuites heb je cijfers nodig die de validatie doorstaan, zodat het formulier zich gedraagt zoals het zal zijn in de productie, en dat is waar gepubliceerde testnummers voor zijn.
Wat het niet doet is autoriseren, en dit is de moeite waard om bot over te zijn Een geldig nummer is geen werkkaart De tool kan een saldo niet controleren, kan niet bevestigen dat de rekening bestaat, en heeft geen verbinding met een bank Het kan en mag ook geen nummers genereren die zijn gekoppeld aan echte rekeningen De voorbeeldnummers die het biedt zijn de standaard testwaarden die worden gepubliceerd door betalingsproviders, die Luhn-geldig zijn en netcontroles doorstaan, juist zodat ontwikkelaars hun formulieren kunnen uitoefenen, maar die op niets kunnen betalen Als u iets bouwt dat raakt aan echte betalingen, gebeurt de daadwerkelijke validatie van de vraag of een kaart in rekening kan worden gebracht via uw betalingsprocessor, en de kaartvalidatie zelf moet worden gesprongen, zodat uw eigen de deur nooit een onbewerkte PAN opside aan de clientzijde opszijde is.
Hoe verhoudt dit zich tot valideren op de server?
Beide hebben een plaats, en ze beantwoorden verschillende vragen Client-side validatie met Luhn en prefix controles is direct en privé, het geeft de gebruiker feedback voordat ze indienen, en het kost je niets De limiet is dat het alleen weet over structuur Server-side validatie via een betalingsprocessor is het enige dat kan bevestigen dat een kaart echt en belastbaar is, maar het kost een netwerk aanvraag, het kan geld kosten per autorisatie poging, en het gebeurt nadat de gebruiker heeft toegezegd om in te dienen Het verstandige ontwerp gebruikt beide: de browser vangt de typfouten en de vormfouten gratis, en de server doet de enige controle die ertoe doet wanneer de gebruiker betaalt Het overslaan van de client controle zorgt ervoor dat het formulier traag aanvoelt; het overslaan van de server controle betekent dat u nooit echt iets gevalideerd werkt. Productiviteitstools voor ontwikkelaar roundup omvat de andere nutsvoorzieningen die er vaak naast wonen.
Gerelateerde tools en verder lezen
Een kaartvalidator reist zelden alleen Wanneer u een formulier of een gegevenspijplijn aan het uitharden bent, genereert u meestal ook identificatiegegevens, hashingwaarden en controleert u andere soorten invoer. De hash generator is waar u naar reikt als u een vingerafdruk van een waarde moet maken in plaats van de vorm ervan te valideren, en de controle van de wachtwoordsterkte past hetzelfde " op in de browser, stuur het nooit ergens naartoe" principe naar inloggegevens Aan de netwerkzijde, de IP subnet calculator is de begeleidende tool voor iedereen die de infrastructuur bouwt waarop een kassa draait.
Voor de bredere context is de Gegevensprivacy en online tools gids legt uit waarom het uitvoeren van gevoelige controles aan de clientzijde ertoe doet, en de Handleiding voor coderingshulpmiddelen plaatst de validator in de context van de rest van een developer' s dagelijkse kit Alles op Toolz.dev draait in uw browser, dat is de hele reden dat een kaartnummer veilig is om erin te plakken: het verlaat nooit uw apparaat.
Veelgestelde vragen
Wat controleert het Luhn-algoritme?
Het Luhn-algoritme is een mod-10-controlesom die verifieert dat een getal niet verkeerd is getypt. Het verdubbelt elk tweede cijfer van rechts, trekt negen af van elk resultaat boven de negen, telt alle cijfers op en bevestigt dat het totaal deelbaar is door tien. Het vangt elke fout van één cijfer op en bijna elke ruil van twee aangrenzende cijfers, maar het is een controlesom, geen beveiligingskenmerk, en het kan niet bewijzen dat een kaart echt is.
Betekent een geldig nummer dat de kaart werkt?
Nee Een geldig nummer betekent alleen dat de cijfers structureel correct zijn, dus de controlesom gaat voorbij en de lengte komt overeen met het netwerk Of de rekening bestaat, een saldo heeft, of nog steeds actief is, kan alleen worden bevestigd door de kaartuitgever tijdens een echte autorisatie Structurele geldigheid is een voorfilter, geen bewijs van een bruikbare kaart.
Hoe wordt het kaartmerk gedetecteerd op basis van het nummer?
Het merk wordt gelezen vanaf de eerste cijfers, het Issuer Identification Number Visa begint met 4, Mastercard met 51-55 of 2221-2720, American Express met 34 of 37, enzovoort Elk netwerk staat ook slechts bepaalde totale lengtes toe, dus de validator controleert samen het voorvoegsel en de lengte en rapporteert het netwerk dat het heeft gematcht.
Is het veilig om een kaartnummer in deze tool in te voeren?
Ja. 't nummer wordt volledig verwerkt in uw browser en wordt nooit geüpload, gelogd of verzonden. U kunt dit bevestigen door de verbinding met internet te verbreken, omdat de validator zonder verbinding blijft werken. Dat gezegd hebbende, moet u nog steeds voorkomen dat u een echt kaartnummer plakt waar u dat niet nodig heeft, en geeft u de voorkeur aan de gepubliceerde testnummers voor ontwikkeling.
Waarom gaat mijn echte kaart aan Luhn voorbij, maar mislukt de lengtecontrole?
Dat betekent meestal dat er een cijfer is gevallen of toegevoegd tijdens het typen De Luhn-controlesom kan toevallig passeren op een getal van de verkeerde lengte, dus de tool controleert de lengte onafhankelijk aan de hand van het gedetecteerde netwerk Voer het volledige nummer opnieuw in en beide controles moeten samen worden doorgegeven.
Wat zijn testkaartnummers en waarom bestaan ze?
Testkaartnummers zoals 4111 1111 1111 1111 worden gepubliceerd door betalingsproviders zodat ontwikkelaars afrekenformulieren kunnen uitoefenen Ze zijn Luhn-geldig en passeren netwerkcontroles, zodat het formulier zich precies gedraagt zoals het zal in de productie, maar ze worden toegewezen aan geen echt account en kunnen nooit in rekening worden gebracht Ze zijn het juiste ding om overal te gebruiken waar u anders in de verleiding zou komen om een echte kaart te typen.
Wat is het verschil tussen de CVV en het kaartnummer?
Het kaartnummer is het lange Primaire Rekeningnummer dat de rekening identificeert De CVV, CVC, of CID is de korte beveiligingscode, drie cijfers voor de meeste netwerken en vier voor American Express, afzonderlijk van het nummer afgedrukt Deze tool valideert alleen het kaartnummer; het controleert niet de beveiligingscode, die door de uitgever wordt geverifieerd tijdens een transactie.
Kan deze validator werkende creditcards genereren?
Nee. Het controleert alleen getallen die u invoert, en het heeft geen manier om een nummer te produceren dat is gekoppeld aan een live account De voorbeeldnummers die het biedt zijn de standaard gepubliceerde testwaarden die geen echt account bereiken Het genereren van getallen voor een echte kaart is niet iets wat een structurele validator kan doen, en het is niet iets dat deze tool probeert.
