신용카드 검증 (Luhn + 브랜드)

카드 번호(PAN)에는 브랜드별 발급사 식별 번호와 계좌 번호, 마지막 룬 검사 숫자가 들어 있습니다. 이 툴은 세 가지를 합니다. 앞자리로 브랜드를 감지하고(비자, 마스터카드, 아멕스, 디스커버, JCB, 다이너스, 유니온페이, 마에스트로), 길이가 그 브랜드 규격과 맞는지 확인하며, 룬 모듈로 10 검사를 돌립니다. 결제 대행사가 보기 전에 오타와 뻔한 가짜를 걸러 내는 클라이언트 측 폼 검증에 씁니다.

룬 알고리즘은 사람이 실제로 저지르는 실수를 잡아냅니다. 1950년대에 그러라고 설계됐기 때문입니다. 한 자리 오류는 전부 검사에 걸리고, 인접한 두 자리를 바꿔 치는 경우도 거의 다 걸립니다. 번호를 잘못 입력하는 가장 흔한 두 가지가 그것입니다. 알아 둘 예외가 있습니다. 09와 90을 맞바꾸면 통과하는데, 두 배로 만드는 단계에서 둘이 같은 값으로 옮겨지기 때문입니다. 룬이 보지 못하는 유일한 자리바꿈입니다.

이 검사가 알려 주지 못하는 것은 그 카드가 존재하는지입니다. 올바른 길이의 무작위 번호 중 대략 열에 하나가 우연히 룬을 통과하므로, 브랜드도 맞고 길이도 맞고 검사도 유효하면서 어디에도 계좌가 없는 번호일 수 있습니다. 그것은 발급사에 대한 승인 요청만이 답할 수 있고, 브라우저에서 도는 어떤 것도 할 수 없습니다. 통과를 오타가 없다는 증거로만 여기고 그 이상으로 보지 마십시오.

브랜드 접두사는 움직입니다. 발급사 식별 번호는 배정되고 재배정되며 대역이 추가되고, 클라이언트 코드에 박아 넣은 표는 요란하게 실패하는 대신 조용히 낡아 갑니다. 증상은 정상적인 새 카드가 알 수 없는 브랜드로 보고되는 것입니다. 그것을 근거로 결제를 거절하면 낡은 표가 매출 손실로 바뀌는데, 그래서 브랜드 감지는 화면에 속하고 결정에는 절대 속하지 않습니다.

카드 번호는 규제 대상 데이터입니다. PCI DSS가 PAN의 저장과 전송을 규율하며, 이 툴이 전부 페이지 안에서 돌고 아무것도 보내지 않는 이유가 그것입니다. 실제 결제 폼이라면 번호를 자기 서버가 아니라 결제 대행사가 호스팅하는 입력 필드로 넘겨야 하는 이유이기도 합니다.