▲

GN⁺: ISO 8583: 신용카드의 언어

 (increase.com)
2P by neo 2일전 | favorite | 댓글 1개
  • ISO 8583은 신용카드 네트워크 간에 이루어지는 실시간 메시지 교환 표준
  • 이 표준은 판매 시점 장치에서 카드를 터치하거나 온라인에서 "구매"를 클릭할 때 발생하는 메시지를 정의함
  • 초기에는 POS 또는 ATM이 직접 메시지를 생성했으나, 현재는 JSON 같은 고수준 형식으로 변환 후 ISO 8583로 전환하는 방식이 주로 사용됨
  • 메시지 구조는 간단하지만 세부 구현은 복잡하며 네트워크 간 호환성을 위해 유연성을 가짐

기본 메시지 형식

메시지 타입 표시자 (Message Type Indicator)

  • 4자리 코드로 메시지 유형을 나타냄 (예: 0100은 승인 요청)
  • 수신자가 예상 필드를 파악하는 데 도움을 줌
  • 네트워크별로 직렬화 방식이 다를 수 있음 (BCD, ASCII 등)

비트맵 (Bitmap)

  • 필드 존재 여부를 나타냄
  • 1은 필드가 존재함을, 0은 필드가 없음을 표시
  • 8바이트 크기로 최대 64개의 필드를 나타냄

데이터 요소 (Data Elements)

  • 비트맵 이후에 필드가 직렬화됨
  • 고정 길이 필드는 항상 동일한 크기, 가변 길이 필드는 길이 정보가 포함됨
  • 필드의 인코딩 방식은 ASCII, BCD, 이진수 등이 사용됨

중첩 메시지 구조

  • ISO 8583 표준은 네트워크가 네트워크별 사용자 정의 데이터를 포함할 수 있도록 허용함
  • 중첩 메시지는 테이블, 비트맵, TLV(Tag-Length-Value) 형식으로 구현될 수 있음

테이블

  • 모든 필드가 고정 길이로 포함됨
  • 공간 낭비를 줄이기 위해 가변 길이 서브필드를 추가로 지원

비트맵 메시지

  • 각 하위 필드의 존재 여부를 비트맵으로 표시
  • 필드가 없는 경우 공간 낭비를 방지

TLV 메시지

  • 필드가 태그, 길이, 값의 튜플로 직렬화됨
  • 순서에 구애받지 않고 확장 가능

파서 설계

  • ISO 8583 파서는 비트맵 분석 및 각 필드 직렬화 정의로 시작
  • 중첩 메시지 처리 및 네트워크별 구현 차이를 고려해야 함
  • Ruby의 Sorbet 타입 시스템을 사용해 안전한 메시지 클래스를 정의
  • 고정 길이와 가변 길이 필드, 패딩 처리 등을 설정할 수 있음

오류 처리

  • 필드 파싱 실패 시 다음 필드 파싱이 가능하도록 설계
  • 메시지 직렬화를 유지하며 부분적인 오류를 처리
  • 치명적인 오류 발생 시 메시지 처리를 중단

결론

  • ISO 8583 표준은 1987년에 정의된 이후 지속적으로 발전하며 다양한 네트워크 요구를 충족해 옴
  • Increase는 ISO 8583 메시지를 처리하여 사용자 제품 개발에 집중할 수 있도록 도움
  • API 문서를 참조하거나 Increase 팀에 문의 가능
▲
neo 2일전  [-]
Hacker News 의견

  • Visa와 Mastercard는 ISO 8583을 표준화된 방식으로 구현하지 않음. 각 회사는 수천 페이지의 문서를 발행하여 표준 필드 사용 방법과 독점 데이터를 메시지에 포함하는 방법을 설명함. 대부분의 카드 관리/발급 플랫폼은 이를 잘 추상화함. ISO 20022로의 전환은 긍정적인 개선이지만, ROI 기준을 충족할 가능성은 낮음.

  • 프로토콜 유형(메시지 유형, 필드 정의 비트맵, 고정 및 가변 길이 값 세트)은 개발 당시에는 일반적이었음. 수신 측에서 동적 필드 길이를 검증하고 메시지 끝을 넘어 읽지 않도록 주의해야 함. 그러나 이러한 문제는 이제 잘 이해되고 있음.

  • ISO 8583 표준이 필드나 메시지 유형을 인코딩하는 방법을 명시하지 않는 것이 당황스러움. 이로 인해 수신자가 메시지를 이해할 수 없는 무작위 바이트 세트를 받을 수 있음.

  • 최근 결제 관련 논의가 많고 patio11이 훌륭한 콘텐츠를 제공함. 25년 전에는 이런 시각적 설명 웹사이트가 없었음. EBCDIC을 언급한 다른 댓글처럼, 엔디언 간의 전환은 복잡함. 2000년대 초 Discover 카드와 협력하여 ISO8583 사양에 GUID 필드를 추가한 경험이 재미있었음.

  • 금융 시스템은 변화의 전장 중 하나임. 많은 사람들이 이러한 변화를 인식하지 못하고 있음. 대형 기술 기업들이 자체 결제 생태계를 소유하고 있어, 이를 인식하지 못한 사람들에게 통찰을 제공해야 함. 일부 국가는 이러한 흐름을 따르고 있음.

  • Charles Stross가 ISO 8583 표준 때문에 약간 미쳤고, 그것이 Accelerando를 쓰게 된 원인일 수 있음. 이 표준은 70년대의 모호한 프로토콜을 대체한 새로운 표준일 가능성이 높음.

  • ISO20022가 8583을 대체할 이유를 설명하는 훌륭한 기사임. 특히 M/V 독점 네트워크가 지배하지 않는 지역에서. 신용카드는 새로운 결제 시스템에서 은행이 제공하는 신용 계좌와 함께 구현될 수 있음. 계좌 간 즉시 결제, 저비용 고정 가격 거래 등이 가능함.

  • ISO 8583의 제한을 우회하는 다양한 방법을 보는 것이 재미있었음. 최근에는 ISO 메시지 전/후에 API 호출을 통해 결제 거래 외부의 추가 정보를 전달하는 방법이 많이 사용됨. 시장 출시 시간을 단축하지만 새로운 실패 모드를 초래할 수 있음.

  • 이 형식은 재미있었음. ISO-8583 메시지를 분석할 때 역사가 펼쳐지는 것을 볼 수 있었음. 내가 분석한 메시지는 EBCDIC이 아닌 BCD였음. 그러나 한 필드에는 XML이 포함되어 있었고, XML에는 JSON이 포함되어 있었음. 메시지를 확장할 때마다 연도의 유행을 반영함.

  • Visa와 Mastercard와 달리 AMEX 거래 알림은 거의 즉시 발생함. 카드를 스와이프하자마자 휴대폰/시계에 알림이 뜨는 것이 마법 같음. V/MC가 가지고 있는 레이어가 AMEX에는 없는 것 같음.

  • Go 라이브러리를 사용한 iso8583에서 많은 성공을 거두었음.

  • 시스템 로그에 base64로 인코딩된(혹은 EBCDIC으로 인코딩된 base64로 인코딩된) ISO 8583 신용카드 데이터의 마스킹 로직을 검토하는 것이 재미있었음.

답변달기