我建造 工具。dev在此之前,我花了數年時間運送 WordPress 外掛程式和 Laravel API,其中一些必須付款。我寫過的第一份結帳表格將每個輸入錯誤的卡號直接發送到支付網關並等待其退回。從技術上講,它很有效,但速度很慢,並且會燒毀網關對最初永遠不可能有效的號碼的請求。修復非常小:在提交之前在瀏覽器中運行 Luhn 校驗和。這一更改立即捕獲了大多數拼字錯誤並阻止了一系列毫無意義的 API 呼叫。本指南是關於該檢查、它旁邊的前綴規則以及 信用卡驗證器 我建置的是為了讓您永遠不必從記憶體中重新實作。
TL;DR: 信用卡驗證器確認某個號碼在結構上是正確的,而不是它屬於真實帳戶。它運行兩個獨立的測試:ISO/IEC 7812-1 的 Luhn 校驗和,它捕獲幾乎所有個位數拼字錯誤和相鄰換位,以及針對每個網路和#39 的長度和前綴檢查;已發布的發行者範圍。一個號碼可以通過一個號碼,另一個號碼失敗,因此這兩個結果將單獨報告。它完全在您的瀏覽器中運行,因此不會上傳任何卡號,並且永遠無法告訴您卡片上是否有錢。只有發行人知道這一點。
卡號有效意味著什麼?
支付卡號碼,正式名稱為主帳號或 PAN,不是隨機的數字字串。其結構由下式定義 ISO/IEC 7812. 前六到八位數字是發行人識別號碼(IIN),過去稱為銀行識別號碼(BIN)。這些數字標識網路和發卡銀行。之後到倒數第二位是個人帳戶標識符,最後一位是用Luhn演算法計算的校驗位。
所以&引用;有效&引用;有兩個不同的含義,這有助於將它們分開。第一個是數字服從 Luhn 校驗和,這意味著校驗位與數字的其餘部分一致。第二個是數字具有真實卡片網路的正確長度和前綴。一個數字可以滿足一個條件,而不是另一個條件。 4111 1111 1111 1112 有一個 Visa 前綴和一個 Visa 長度,但 Luhn 不能。一個恰好以右側校驗位結尾的隨機十六位字串會經過 Luhn,但可能會以網路不擁有的前綴開頭。一個好的驗證器會告訴您兩者中哪一個失敗,因為每種情況下的修復都不同。
兩次檢查都無法告訴你卡片是真實的。結構有效性取決於數字的形狀,而不是其後面帳戶的狀態。該帳戶可能不存在、可能被凍結、可能超出其限制,或者可能在幾年前就已關閉。唯一知道的系統是發卡銀行,並且在即時交易中的授權請求期間它會準確回答一次。瀏覽器端驗證器所做的一切都是在您達到該點之前運行的廉價預過濾器。
Luhn 演算法如何運作?
Luhn 演算法,也稱為 mod-10 演算法,由 IBM 的 Hans Peter Luhn 於 1960 年獲得專利,現已進入公共領域。它是一個校驗和,這意味著它的全部目的是檢測意外錯誤,而不是提供任何安全性。它的工作原理是這樣的。從最右邊的數字開始,向左移動,每隔一個數字加倍。如果加倍產生大於 9 的數字,則從中減去 9(這與將其兩位數字加在一起相同)。然後將所有數字、加倍的數字和未觸及的數字相加。如果總數能被十整除,則數字過去。
這是檢查 4111 1111 1111 1111,從右到左工作。最右邊的數字是位置一,不加倍。每隔一個數字加倍就會得到一組 1 和 2,這兩個數字來自加倍位置。將它們全部相加,總落在 10 的倍數上,因此數字通過。更改任何一位數字,總和幾乎總是不再是 10 的倍數,這正是檢查有用的原因。
Luhn 的值在於它捕獲的內容。它檢測每個個位數錯誤,即任何一位數字輸入錯誤。它還捕獲兩個相鄰數字的幾乎所有換位,即經典 "我輸入了 21 而不是 12"錯誤,但有一個已知的例外:它不會捕獲交換 09 和 90,因為兩者映射到相同的加權和。這是一個真正的盲點,但這種情況很少見,這也是 Luhn 是校驗和而不是加密保證的原因。對於表單驗證來說,它已經足夠好了,這就是為什麼它位於網路上基本上每個結帳的卡片欄位後面。
如何偵測到卡片網路?
網路是從前導數字 IIN 讀取的。每個網路都有特定的前綴範圍,大多數也限制總長度。驗證器首先匹配最長、最特定的前綴,因為某些範圍重疊。以下是其檢查的範圍:
| 網路 | 開始於 | 有效長度 | 安全碼 |
|---|---|---|---|
| 簽證 | 4 | 13、16、19 | 3 |
| 萬事達卡 | 51-55、2221-2720 | 16 | 3 |
| 美國運通 | 34、37 | 15 | 4 |
| 發現 | 6011、65、644-649、622126-622925 | 16、19 | 3 |
| 大來俱樂部 | 300-305、309、36、38-39 | 14、16、19 | 3 |
| JCB | 3528-3589 | 16-19 | 3 |
| 聯合支付 | 62 | 16-19 | 3 |
| 大師 | 50、56-69(選定) | 12-19 | 3 |
重疊是有趣的部分,而搞錯它們就是天真的探測器失火的原因。萬事達卡補充道 2221-2720 範圍在 2017 年,因此之前編寫的探測器將這些卡片報告為未知。發現擁有一小部分 62 空間, 622126 通過 622925,而銀聯擁有其餘部分 62,所以你測試它們的順序決定是否a 6221 卡片讀作 Discover 或 UnionPay。驗證器在寬闊的 UnionPay 前綴之前測試特定的 Discover 窗口,以便兩者正確著陸。美國運通是格式代碼跳閘的,因為它使用 15 位數字,分組為 4-6-5,而不是通常的四組,每組四,並且它使用四位安全代碼(正面印有 CID)而不是三位代碼背面有CVV。
如何使用信用卡驗證器
該工具故意簡單。您貼上一個數字並讀取結果。沒有提交按鈕,也沒有任何可配置的內容。
第 1 步:輸入號碼
將卡號輸入或貼上到欄位中。空格和破折號將被忽略,因此 4111-1111-1111-1111, 4111 1111 1111 1111, 和 4111111111111111 所有驗證都相同。這很重要,因為真實的輸入以各種格式到達:從電子表格複製、讀出卡片或從測試夾具中提取。
第二步:閱讀判決書
結果的頂部清楚地告訴您該數字是否有效,如果無效,則會說明原因。下面,分別顯示兩個檢查:Luhn 校驗和是否通過,以及長度是否與檢測到的網路相符。將它們分開就是重點。通過 Luhn 但長度不及格的數字幾乎總是意味著刪除或添加了一個數字,而 Luhn 不及格但長度正確的數字通常意味著一個數字完全錯誤。
第三步:檢查偵測到的網路
該工具顯示它從前綴標識的網路、網路允許的長度以及其安全代碼應該有多長。當您建立表單並想要顯示正確的卡片徽標,或者當您需要知道是否需要三位數或四位數的 CVV 時,這本身就很有用。
步驟 4:複製格式化或屏蔽的號碼
您可以按照網路列印的方式複製分組號碼,或複製隱藏除最後四位數字之外的所有數字的屏蔽版本。蒙面表格是您想要的日誌、螢幕截圖和支援票證中的表格,因為儲存或顯示完整的 PAN 正是那種會給人們帶來合規麻煩的東西。
驗證適合哪裡,又在哪裡停止?
誠實的框架是驗證器是一個過濾器,而不是一個門。它屬於過程的前面,可以廉價地拒絕明顯的垃圾,並且絕不能相信它可以作為下游任何事情的證據。在結帳表格中,運行 Luhn 用戶端可以讓您在用戶完成打字後、按完付費之前標記拼寫錯誤,這是一種更好的體驗,並且可以節省到網關的注定要往返的旅程。在資料管道中,驗證卡片形狀的欄位會在損壞的行到達系統之前捕獲它們,系統會阻塞它們。在測試套件中,您需要通過驗證的數字,以便表單按照生產中的方式運行,這就是已發布的測試數字的目的。
它不做的是授權,這值得直言不諱。有效號碼不是工作卡。該工具無法檢查餘額,無法確認帳戶存在,並且與任何銀行沒有連接。它也不能也不應該產生與真實帳戶綁定的號碼。它提供的樣本號碼是支付提供者發布的標準測試值,這些測試值具有 Luhn 有效性,並且可以精確地通過網絡檢查,以便開發人員可以行使他們的表格,但映射到不收取任何費用。如果您正在建立任何涉及真實支付的內容,則卡片是否可以收費的實際驗證應透過您的支付處理器在伺服器端進行,並且卡片資料本身應該進行標記化,以便您自己的系統永遠不會儲存原始 PAN。客戶端驗證是禮貌的前門,而不是金庫。
這與在伺服器上驗證相比如何?
兩者都有一席之地,並且回答不同的問題。 Luhn 和前綴檢查的客戶端驗證是即時且私密的,它會在用戶提交之前提供反饋,並且不會花費您任何費用。它的限制在於它只知道結構。透過支付處理器進行伺服器端驗證是唯一可以確認卡片真實且收費的東西,但它需要網路請求,每次授權嘗試可能需要花費金錢,並且它發生在用戶承諾提交之後。合理的設計使用兩者:瀏覽器免費捕獲拼字錯誤和形狀錯誤,伺服器在用戶付款時進行一項重要的檢查。跳過客戶端檢查會使表格感覺很慢;跳過伺服器檢查意味著您從未真正驗證過任何內容。如果您正在為此類工作組裝更廣泛的套件,則 開發人員生產力工具 綜述涵蓋了往往與其共存的其他實用程式。
相關工具和進一步閱讀
卡驗證器很少單獨旅行。當您強化表單或資料管道時,您通常也會產生識別碼、雜湊值並檢查其他類型的輸入。這 哈希生成器 當您需要對值進行指紋識別而不是驗證其形狀時,您會得到什麼,以及 密碼強度檢查器 應用相同的"在瀏覽器中測量它,切勿將其發送到任何地方"憑證原則。在網路方面, IP子網路計算器 是任何建造結帳基礎設施的人的配套工具。
對於更廣泛的背景, 資料隱私和線上工具 指南解釋了為什麼運行敏感檢查客戶端很重要,以及 編碼工具指南 將驗證器置於開發人員其餘部分的上下文中'每日套件。 toolz。dev 上的所有內容都在您的瀏覽器中運行,這就是卡號可以安全貼到其中的全部原因:它永遠不會離開您的裝置。
常見問題
Luhn 演算法檢查什麼?
Luhn 演算法是一個 mod-10 校驗和,可驗證數字沒有輸入錯誤。它從右側每隔一位數字加倍,從九以上的任何結果中減去九,對所有數字求和,並確認總數可以被十整除。它捕獲每個個位數錯誤和幾乎每個兩個相鄰數字的交換,但它是校驗和,而不是安全功能,並且不能證明卡片是真實的。
有效號碼是否意味著該卡有效?
否。有效號碼僅表示數字結構正確,因此校驗和通過且長度與網路相符。帳戶是否存在、有餘額或仍然有效只能由發卡機構在實際授權期間確認。結構有效性是預過濾器,而不是可用卡的證明。
如何從號碼中偵測到卡片品牌?
品牌是從第一位數字(發行人識別號碼)讀取的。 Visa 開頭為 4,Mastercard 開頭為 51-55 或 2221-2720,American Express 開頭為 34 或 37,依此類推。每個網路也只允許一定的總長度,因此驗證器會檢查前綴和長度並報告其匹配的網路。
在此工具中輸入卡號安全嗎?
是的。該號碼完全在您的瀏覽器中處理,並且永遠不會上傳、記錄或傳輸。您可以透過斷開網路連線來確認這一點,因為驗證器在沒有連線的情況下繼續工作。也就是說,您仍然應該避免在任何不需要的地方貼上真實的卡號,而更喜歡發布測試號碼進行開發。
為什麼我的真卡通過了 Luhn 但未能通過長度檢查?
這通常意味著在打字時刪除或添加了一個數字。 Luhn 校驗和可能會巧合地通過多個錯誤的長度,因此該工具會根據檢測到的網路獨立檢查長度。重新輸入完整號碼,兩張支票應一起通過。
什麼是測試卡號碼以及它們為何存在?
測試卡號,例如 4111 1111 1111 1111 由支付提供者發布,以便開發人員可以執行結帳表格。它們具有 Luhn 有效性並通過網路檢查,因此表單的行為與生產時完全相同,但它們不會映射到真實帳戶,並且永遠無法收費。它們是在任何您可能想輸入真實卡片的地方使用的正確方法。
CVV和卡號有什麼差別?
卡號是標識帳戶的長主帳號。 CVV、CVC 或 CID 是簡短的安全代碼,大多數網路為三位數字,美國運通為四位數字,與號碼分開列印。此工具僅驗證卡號;它不會檢查發行人在交易期間驗證的安全代碼。
此驗證器可以產生有效的信用卡嗎?
不。它只檢查您輸入的號碼,並且無法產生與即時帳戶綁定的號碼。它提供的樣本號碼是標準發布的測試值,沒有到達真實帳戶。為真實卡片產生數字不是結構驗證器可以做的事情,也不是該工具嘗試的事情。
