Så Fungerar Luhn-Algoritmen För Att Validera Kreditkortsnummer
Luhn-algoritmen är den kontrollsumma som avgör om ett kreditkortsnummer är matematiskt korrekt uppbyggt, innan någon betalning ens skickas till en bank. Den dubblar varannan siffra i numret, justerar resultat över 9 och summerar allt. Om summan går jämnt upp i 10 är numret giltigt. Det är precis den kontrollen som får ett formulär att markera ett felskrivet kortnummer i röd text innan du ens hunnit trycka på betala.
Regeln, kort och exakt
Så här går uträkningen till, siffra för siffra från höger:
- Börja från den sista siffran i numret och räkna den som position 1.
- Dubblera varannan siffra, alltså positionerna 2, 4, 6 och så vidare.
- Blir en dubblerad siffra tvåsiffrig (till exempel 8 × 2 = 16), dra bort 9 från resultatet. Det ger samma svar som att lägga ihop de två siffrorna i talet (1 + 6 = 7), men går snabbare att räkna för hand.
- Summera samtliga siffror: de dubblerade (och vid behov justerade) tillsammans med de som lämnades orörda.
- Är slutsumman jämnt delbar med 10 klarar numret kontrollen.
Det är hela algoritmen. Ingen hemlig nyckel, inget uppslag mot en databas, bara en fast räkneregel som vem som helst kan köra för hand på tio sekunder.
Räkneexempel: kontrollera ett riktigt kortnummer steg för steg
Ta det klassiska testnumret för Visa, 4111 1111 1111 1111, 16 siffror långt. Eftersom numret har ett jämnt antal siffror hamnar även den allra första siffran (den fyran längst till vänster) på en dubblerad position, position 16 räknat från höger.
| Position (från höger) | Siffra | Dubblas? | Bidrag till summan |
|---|---|---|---|
| 16 | 4 | Ja | 4 × 2 = 8 |
| 15 | 1 | Nej | 1 |
| 14 | 1 | Ja | 1 × 2 = 2 |
| 13 | 1 | Nej | 1 |
| 12 | 1 | Ja | 2 |
| 11 | 1 | Nej | 1 |
| 10 | 1 | Ja | 2 |
| 9 | 1 | Nej | 1 |
| 8 | 1 | Ja | 2 |
| 7 | 1 | Nej | 1 |
| 6 | 1 | Ja | 2 |
| 5 | 1 | Nej | 1 |
| 4 | 1 | Ja | 2 |
| 3 | 1 | Nej | 1 |
| 2 | 1 | Ja | 2 |
| 1 | 1 | Nej | 1 |
De sju ettorna på dubblerade positioner (alla utom fyran) bidrar med 2 vardera, alltså 7 × 2 = 14. Fyran på position 16 bidrar med 8. De åtta ettorna på ej dubblerade positioner bidrar med sitt eget värde, 1 vardera, alltså 8 i total. Lägg ihop det: 14 + 8 + 8 = 30. Trettio är jämnt delbart med 10, så numret klarar Luhn-kontrollen. Det stämmer med verkligheten: 4111111111111111 är just det numret betalleverantörer som Stripe och PayPal listar som ett giltigt Visa-testnummer i sina sandlådor.
Varför en enda felskrivning fäller kontrollen
Ändra nu bara den sista siffran, från 1 till 2: 4111 1111 1111 1112, exakt det slags fel ett finger som glider till fel tangent orsakar. Den sista siffran ligger på position 1, som aldrig dubblas, så den räknas rakt av med sitt eget värde. I originalet bidrog den siffran med 1 till summan. I den felskrivna versionen bidrar den med 2 i stället, en enhet mer. Summan går från 30 till 31.
31 går inte jämnt upp i 10. Kontrollen fallerar direkt, utan att formuläret behövt skicka något till en bank eller ett kortnätverk. Det är hela poängen med Luhn: fånga ett fel lokalt, i webbläsaren eller på servern, innan en betalningsbegäran ens skickas iväg och en runda tur-och-retur till banken slösas bort på ett nummer som aldrig kunde ha varit giltigt.
Kända testnummer per kortnätverk
Betalleverantörer publicerar testnummer som är säkra att använda i sandlådor, de tillhör inte några riktiga konton. Alla klarar Luhn-kontrollen, vilket är just poängen med dem: en utvecklare som får ett avvisat testnummer vet direkt att felet ligger i integrationskoden, inte i själva numret.
| Nätverk | Testnummer | Längd |
|---|---|---|
| Visa | 4111 1111 1111 1111 | 16 siffror |
| Visa (alternativ) | 4012 8888 8888 1881 | 16 siffror |
| Mastercard | 5555 5555 5555 4444 | 16 siffror |
| American Express | 3782 822463 10005 | 15 siffror |
| Discover | 6011 1111 1111 1117 | 16 siffror |
Lägg märke till Amex-numret: det har bara 15 siffror och en annan gruppering (4-6-5 i stället för 4-4-4-4). Luhn-formeln bryr sig inte om längden eller hur siffrorna grupperas visuellt, den arbetar på den rena sifferföljden, men själva kortnätverket avgör vilken längd som är giltig för just det nätverket.
Testa med ditt eget nummer
Klistra in ett kortnummer nedan (till exempel ett av testnumren ovan) och se nätverket och Luhn-resultatet uppdateras direkt medan du skriver.
Vad Luhn-kontrollen inte säger dig
En godkänd Luhn-kontroll bevisar bara att siffersekvensen är korrekt uppbyggd enligt formeln. Den säger ingenting om huruvida kortet faktiskt existerar, om det är aktivt, om det har täckning för köpet, eller om det ens tillhör en riktig person. Det är samma skillnad som mellan att ett personnummer har rätt format och att personen bakom det faktiskt finns registrerad, formatet kan stämma perfekt utan att någonting bakom det är verkligt. Att bekräfta att ett kort går att debitera kräver alltid en fråga till det utfärdande kortnätverket eller banken, något ett formulär på klientsidan aldrig kan göra på egen hand.
Vanliga misstag och gränsfall
Luhn fångar de allra flesta enstaka felskrivningar och de flesta fall där två intilliggande siffror har bytt plats med varandra. Men algoritmen har en känd, dokumenterad svaghet: byter två grannsiffror plats och skillnaden mellan dem är exakt 9, det vill säga en 0 och en 9 sitter bredvid varandra och kastas om, ger det exakt samma checksumma som originalet. Felet slinker igenom ospårat. Det är inte ett tecken på att algoritmen är trasig, Luhn designades aldrig för att vara kryptografiskt vattentät, bara för att billigt fånga den stora massan av mänskliga slarvfel med en uträkning enkel nog att köras för hand redan på 1950-talet. Att den missar just den ena, sällsynta kombinationen är ett känt pris för hur enkel och snabb kontrollen är.
Vanliga frågor
Vad är Luhn-algoritmen egentligen till för? Den upptäcker om ett nummer, oftast ett kreditkortsnummer men även en del andra id-nummer, är strukturellt korrekt innan numret skickas vidare för verklig behandling. Den stoppar uppenbart felskrivna nummer direkt, utan att en betalningsförfrågan behöver nå kortnätverket eller banken.
Betyder ett giltigt Luhn-resultat att kortet går att använda för att betala? Nej. Det betyder bara att sifferföljden följer kontrollformeln matematiskt. Om kortet existerar, är aktivt och har täckning avgörs enbart av det utfärdande nätverket och banken vid själva transaktionen, aldrig av en klientsidig kontroll som denna.
Kan jag lita på att Luhn hittar varje tänkbart skrivfel? Nästan alltid, men inte garanterat. Den fångar i praktiken alla enstaka felskrivna siffror och nästan alla omkastade sifferpar. Det enda kända undantaget är när två grannsiffror som skiljer sig med exakt 9 (en 0 och en 9) byter plats, då blir checksumman identisk och felet upptäcks inte.
Varför dubblas just varannan siffra och inte alla? Det är själva definitionen av algoritmen, publicerad av IBM-ingenjören Hans Peter Luhn och senare standardiserad i ISO/IEC 7812. Att bara dubblera vartannat tal, och kompensera för tvåsiffriga resultat, ger en checksumma som är känslig nog att fånga enstaka felskrivningar och de flesta omkastade par, men fortfarande enkel nog att räkna ut för hand utan dator.