Pak twee betaalkaarten van verschillende netwerken en de nummers lijken niet op elkaar. De ene is misschien zestien cijfers in groepjes van vier, de andere vijftien cijfers in groepjes van vier, zes en vijf, en de afsluitende cijfers gehoorzamen aan dezelfde controlesom terwijl de lengtes helemaal niet overeenkomen. Testkaartnummers per netwerk bouwen betekent bewust met die verschillen werken, want een integratie die maar één merk ooit ziet, is een integratie die het meeste van zijn eigen code nooit heeft uitgevoerd.
Dit artikel zet de verschillen uiteen die ertoe doen, laat zien hoe je de gepubliceerde bereiken leest, en legt uit waarom een nummer met de juiste prefix nog steeds bij niemand hoort.
Elk netwerk heeft zijn eigen nummeringsplan
Een kaartnetwerk registreert de bereiken van uitgeversprefixen die het zal herkennen en het aantal cijfers dat een kaart in elk bereik zal dragen. Die registratie is wat een betaalterminal in staat stelt, zonder netwerkaanroep, te bepalen bij welk merk een kaart hoort en of het nummer überhaupt aannemelijk is.
Het resultaat is een kleine verzameling families in plaats van één universele vorm. Sommige netwerken gebruiken bijna uitsluitend één lengte; andere ondersteunen meerdere lengtes voor verschillende productniveaus of regio’s. Beveiligingscodes verschillen ook, zowel in hoeveel cijfers ze bevatten als aan welke kant van de kaart ze zijn gedrukt. Een testset die die verschillen negeert, haalt de review en faalt in productie.
Hoe kies je een prefix voor een testcase?
Werk terug vanaf de vertakking die je wilt oefenen. Als je formulier zijn lay-out verandert op basis van het gedetecteerde merk, heb je minstens één nummer per merk nodig dat een afzonderlijke lay-out uitlokt. Als je validatie een vertakking heeft voor een nummer van vijftien cijfers, heb je een nummer van die lengte nodig. Als je afrekenproces een beveiligingscode van vier cijfers afhandelt, heb je een kaart nodig waarvan het netwerk er een gebruikt.
Controleer daarna of de prefix die je koos gepubliceerd is in plaats van verzonnen. Een bereik gebruiken dat geen enkel netwerk heeft geregistreerd, levert een nummer op dat je eigen prefixdetectie zal afwijzen, waardoor de test lijkt te falen op de detectielogica in plaats van op de fixture.
Een praktische snelweg is om één nummer te genereren voor elk merk dat je ondersteunt en de hele set als een benoemde fixture bij elkaar te houden, zodat de set opnieuw kan worden gegenereerd wanneer een merk wordt toegevoegd of een lengteregel verandert.
De gepubliceerde bereiken in één oogopslag
De volgende tabel vat de openbaar gedocumenteerde prefixbereiken en de bijbehorende vormen samen. Ze beschrijft nummeringsplannen, niet specifieke producten of uitgevers.
| Netwerk | Gepubliceerde prefixbereiken | Typische lengte | Beveiligingscode |
|---|---|---|---|
| Visa | begint met 4 | 16 cijfers, met 13 en langere vormen ook geregistreerd | 3 cijfers, achterkant |
| Mastercard | 51 tot 55, en 2221 tot 2720 | 16 cijfers | 3 cijfers, achterkant |
| American Express | 34 en 37 | 15 cijfers | 4 cijfers, voorkant |
| Discover | 6011, 65, 644 tot 649, en 622126 tot 622925 | 16 cijfers, langere vormen geregistreerd | 3 cijfers, achterkant |
| JCB | 3528 tot 3589 | 16 cijfers, langere vormen geregistreerd | 3 cijfers, achterkant |
| Diners Club | 300 tot 305, 36, en 38 tot 39 | 14 cijfers, met 16 ook gebruikt | 3 cijfers, achterkant |
| UnionPay | 62 | 16 cijfers, langere vormen geregistreerd | 3 cijfers, achterkant |
| Maestro | 50, en 56 tot 69 | variabel binnen de limiet van de standaard | 3 cijfers, achterkant |
Twee kanttekeningen horen naast de tabel. Bereiken worden door netwerken geregistreerd en veranderen af en toe, dus een detector moet zo worden geschreven dat hij toevoegingen tolereert in plaats van de lijst als definitief te behandelen. En lengte is een eigenschap van het bereik, niet van het merk als geheel: een regel die zegt dat een bepaald netwerk altijd zestien cijfers heeft, zal uiteindelijk onjuist zijn.
Waarom verschilt de lengte van de beveiligingscode ook?
Dat American Express vier cijfers gebruikt, is geen beveiligingsupgrade ten opzichte van drie; het is simpelweg hoe de specificatie van dat netwerk is geschreven. Het praktische effect landt op het formulier, dat moet weten hoeveel tekens het accepteert.
Als je interface één veld biedt met een vast maximum van drie tekens, wordt een American Express-code stilletjes afgekapt, en de klant ziet een fout die voor hem geen enkele zin heeft. De robuuste aanpak is de verwachte lengte van het netwerk accepteren zodra het merk bekend is, en een iets ruimere bovengrens toe te staan wanneer dat niet zo is, zodat een plakactie nooit een teken verliest dat de gebruiker terug nodig heeft.
Betekent een overeenkomende prefix dat het nummer echt is?
Nee. De prefix vertelt je bij welk bereik een nummer claimt te horen, en niets meer. Elke cijferreeks die met een geregistreerd bereik begint, kan met willekeurige middelste cijfers en een berekend afsluitend cijfer worden voltooid, wat iets oplevert dat elke lokale controle accepteert.
Hetzelfde geldt voor gegenereerde data: een nummer is structureel geldig en is nooit aan iemand uitgegeven. Dat is een eigenschap om op te vertrouwen in plaats van een beperking, want het betekent dat de waarde in een demo of een fixture kan worden gebruikt zonder enig risico dat ze naar een echt account verwijst. Het betekent ook dat een geslaagde opmaakcontrole nooit aan een gebruiker mag worden beschreven als bevestiging dat zijn kaart bestaat.
Voor ontwikkelaars: een netwerktestmatrix bouwen
Een testmatrix verandert een lijst met merken in een lijst met beslissingen, en het is de moeite waard die in een tabel met vier kolommen op te schrijven: het merk, het gebruikte prefixbereik, het verwachte detectieresultaat, en het formuliergedrag dat je als gevolg verwacht.
Van daaruit houden drie regels de matrix nuttig. Neem precies één nummer op per afzonderlijk gedrag in plaats van veel nummers per merk, omdat redundante fixtures onderhoud toevoegen zonder dekking toe te voegen. Leg de verwachte lengte voor elke vermelding vast, zodat een wijziging aan een lengteregel opduikt als een falende test in plaats van als een ongemerkte versoepeling. En houd minstens één nummer waarvan de prefix bij geen enkel ondersteund bereik hoort, zodat het pad voor onbekende merken wordt geoefend in plaats van aangenomen.
Let op de detectiefunctie zelf. Implementaties die alleen op het eerste cijfer matchen, gooien elke bankkaart op één hoop, en implementaties die bereiken in de verkeerde volgorde testen, kunnen een smaller bereik laten opslokken door een breder. Beide bugs zijn onzichtbaar totdat een specifieke kaart arriveert, en dat is precies wat de matrix bestaat om te voorkomen.
Onthoud ten slotte dat formaatdetectie geen autorisatie is. Een testmatrix is een uitspraak over je eigen code, en geen enkele schikking van prefixen zal je vertellen of een kaart geldig is voor een betaling. De validatiewalkthrough behandelt waar detectie in de reeks controles hoort, en de opmaakgids legt uit hoe de prefix zich verhoudt tot de rest van het nummer.
Eén kaart per netwerk produceren
Om de fixtureset te bouwen, open je de kaartnummersgenerator, kies je een netwerk, en kopieer je het resultaat; herhaal dit voor elk merk dat je ondersteunt, en bewaar de verzameling daarna samen met een notitie over welk gedrag elke vermelding moet uitlokken. Genereren in plaats van bereiken uit documentatie kopiëren houdt de batch intern consistent en geeft je een hoeveelheid die kan worden uitgebreid wanneer een nieuwe betaalmethode wordt toegevoegd.
De PCI DSS-notities zijn het lezen waard voordat die set ergens gedeeld wordt vastgelegd, en de gids over providertestkaarten legt uit wanneer een gescript sandboxnummer een betere keuze is dan een synthetisch nummer.
Volgende stappen
Stel de matrix op, genereer één kaart per afzonderlijk gedrag, en voeg een fixture toe voor een bereik dat je bewust niet ondersteunt zodat het onbekende pad gedekt blijft. Herzie daarna de detectiefunctie tegen de tabel, te beginnen met de smalste bereiken, om te bevestigen dat geen enkele vertakking onbereikbaar is.