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 신용카드 데이터의 마스킹 로직을 검토하는 것이 재미있었음.
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 신용카드 데이터의 마스킹 로직을 검토하는 것이 재미있었음.