ISO 8583: Ngôn ngữ của thẻ tín dụng

 (increase.com)
3 điểm bởi GN⁺ 2024-12-19 | 1 bình luận | Chia sẻ qua WhatsApp
  • ISO 8583 là tiêu chuẩn trao đổi thông điệp theo thời gian thực giữa các mạng thẻ tín dụng
  • Tiêu chuẩn này định nghĩa các thông điệp phát sinh khi chạm thẻ tại thiết bị điểm bán hoặc nhấp vào "Mua" trên mạng
  • Ban đầu, POS hoặc ATM trực tiếp tạo thông điệp, nhưng כיום cách làm phổ biến là chuyển đổi sang định dạng cấp cao như JSON rồi mới chuyển sang ISO 8583
  • Cấu trúc thông điệp đơn giản nhưng triển khai chi tiết thì phức tạp, đồng thời có tính linh hoạt để tương thích giữa các mạng

Định dạng thông điệp cơ bản

Chỉ báo loại thông điệp (Message Type Indicator)

  • Mã 4 chữ số biểu thị loại thông điệp (ví dụ: 0100 là yêu cầu phê duyệt)
  • Giúp bên nhận xác định các trường được kỳ vọng
  • Cách tuần tự hóa có thể khác nhau tùy mạng (BCD, ASCII, v.v.)

Bitmap

  • Biểu thị sự hiện diện của các trường
  • 1 nghĩa là trường có mặt, 0 nghĩa là trường không có
  • Kích thước 8 byte, biểu diễn tối đa 64 trường

Phần tử dữ liệu (Data Elements)

  • Các trường được tuần tự hóa sau bitmap
  • Trường độ dài cố định luôn có cùng kích thước, còn trường độ dài biến đổi sẽ kèm thông tin độ dài
  • Cách mã hóa trường có thể dùng ASCII, BCD, nhị phân, v.v.

Cấu trúc thông điệp lồng nhau

  • Tiêu chuẩn ISO 8583 cho phép mạng bao gồm dữ liệu tùy biến riêng theo từng mạng
  • Thông điệp lồng nhau có thể được triển khai dưới dạng bảng, bitmap hoặc định dạng TLV (Tag-Length-Value)

Bảng

  • Mọi trường đều được bao gồm với độ dài cố định
  • Để giảm lãng phí dung lượng, cũng hỗ trợ thêm các trường con có độ dài biến đổi

Thông điệp bitmap

  • Dùng bitmap để biểu thị sự hiện diện của từng trường con
  • Tránh lãng phí dung lượng khi một trường không tồn tại

Thông điệp TLV

  • Các trường được tuần tự hóa thành bộ ba thẻ, độ dài và giá trị
  • Có thể mở rộng và không phụ thuộc vào thứ tự

Thiết kế parser

  • Parser ISO 8583 bắt đầu từ việc phân tích bitmap và định nghĩa cách tuần tự hóa của từng trường
  • Cần xem xét xử lý thông điệp lồng nhau và khác biệt triển khai theo từng mạng
  • Sử dụng hệ thống kiểu Sorbet của Ruby để định nghĩa các lớp thông điệp an toàn
  • Có thể thiết lập trường độ dài cố định và biến đổi, cách padding, v.v.

Xử lý lỗi

  • Khi parse trường thất bại, hệ thống được thiết kế để vẫn có thể parse trường tiếp theo
  • Duy trì việc tuần tự hóa thông điệp đồng thời xử lý lỗi cục bộ
  • Dừng xử lý thông điệp khi xảy ra lỗi nghiêm trọng

Kết luận

  • Tiêu chuẩn ISO 8583 đã liên tục phát triển kể từ khi được định nghĩa vào năm 1987 để đáp ứng nhu cầu của nhiều mạng khác nhau
  • Increase hỗ trợ xử lý các thông điệp ISO 8583 để người dùng có thể tập trung vào phát triển sản phẩm
  • Có thể tham khảo tài liệu API hoặc liên hệ đội ngũ Increase

Bài viết liên quan

1 bình luận

 
GN⁺ 2024-12-19
Ý kiến Hacker News

  • Visa và Mastercard không triển khai ISO 8583 theo cách được chuẩn hóa. Mỗi công ty phát hành hàng nghìn trang tài liệu để giải thích cách dùng các trường tiêu chuẩn và cách đưa dữ liệu độc quyền vào thông điệp. Hầu hết các nền tảng quản lý/phát hành thẻ đều trừu tượng hóa việc này khá tốt.

  • Kiểu giao thức này (loại thông điệp, bitmap định nghĩa trường, tập giá trị độ dài cố định và biến đổi) vốn khá phổ biến vào thời điểm nó được phát triển. Bên nhận phải cẩn thận xác thực độ dài trường động và tránh đọc vượt quá phần cuối thông điệp. Tuy nhiên, các vấn đề này giờ đã được hiểu khá rõ.

  • Thật khó hiểu khi tiêu chuẩn ISO 8583 không quy định cách mã hóa các trường hay loại thông điệp. Điều này có nghĩa là bên nhận có thể nhận được một tập byte ngẫu nhiên mà họ không thể hiểu nổi.

  • Gần đây có rất nhiều thảo luận liên quan đến thanh toán, và patio11 đã đưa ra nội dung rất xuất sắc. Cách đây 25 năm chưa có những trang web giải thích trực quan như thế này. Như một bình luận khác có nhắc đến EBCDIC, việc chuyển đổi giữa các endian rất phức tạp. Tôi từng có trải nghiệm thú vị khi làm việc với thẻ Discover vào đầu những năm 2000 để thêm trường GUID vào đặc tả ISO8583.

  • Các hệ thống tài chính là một trong những chiến trường của sự thay đổi. Nhiều người không nhận ra những chuyển biến này. Các công ty công nghệ lớn đang sở hữu hệ sinh thái thanh toán riêng, nên cần cung cấp góc nhìn cho những người chưa nhận ra điều đó. Một số quốc gia cũng đang đi theo xu hướng này.

  • Charles Stross có lẽ đã hơi phát điên vì tiêu chuẩn ISO 8583, và đó có thể là nguyên nhân khiến ông viết Accelerando. Có khả năng đây là tiêu chuẩn mới dùng để thay thế các giao thức mơ hồ từ thập niên 70.

  • Đây là một bài viết rất hay giải thích vì sao ISO20022 nên thay thế 8583, đặc biệt ở những khu vực không bị các mạng độc quyền M/V thống trị. Thẻ tín dụng có thể được triển khai trong các hệ thống thanh toán mới cùng với tài khoản tín dụng do ngân hàng cung cấp. Có thể thực hiện thanh toán tức thời giữa các tài khoản và giao dịch chi phí thấp với mức giá cố định.

  • Thật thú vị khi thấy nhiều cách khác nhau để lách qua các giới hạn của ISO 8583. Gần đây, người ta dùng khá nhiều cách truyền thêm thông tin ngoài giao dịch thanh toán thông qua các lệnh gọi API trước/sau thông điệp ISO. Cách này rút ngắn thời gian đưa sản phẩm ra thị trường nhưng có thể tạo ra những kiểu lỗi mới.

  • Định dạng này thật thú vị. Khi phân tích các thông điệp ISO-8583, bạn có thể thấy cả một dòng lịch sử hiện ra. Các thông điệp tôi phân tích là BCD chứ không phải EBCDIC. Nhưng một trường lại chứa XML, và bên trong XML có JSON. Mỗi lần mở rộng thông điệp đều phản ánh trào lưu của từng thời kỳ.

  • Không giống Visa và Mastercard, thông báo giao dịch của AMEX đến gần như ngay lập tức. Vừa quẹt thẻ là điện thoại/đồng hồ đã hiện thông báo, cảm giác như phép màu. Có vẻ như những lớp mà V/MC có thì AMEX không có.

  • Tôi đã đạt được nhiều thành công với iso8583 dùng thư viện Go.

  • Thật thú vị khi phải rà soát logic che giấu dữ liệu thẻ tín dụng ISO 8583 trong log hệ thống, vốn được mã hóa base64 (hoặc mã hóa base64 rồi lại được mã hóa bằng EBCDIC).