ISO 8583: ภาษาของบัตรเครดิต

 (increase.com)
3 คะแนน โดย GN⁺ 2024-12-19 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • 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 เริ่มจากการวิเคราะห์บิตแมปและนิยามการทำซีเรียลไลซ์ของแต่ละฟิลด์
  • ต้องคำนึงถึงการจัดการข้อความแบบซ้อนและความต่างของการติดตั้งใช้งานในแต่ละเครือข่าย
  • ใช้ ระบบชนิดข้อมูล Sorbet ของ Ruby เพื่อกำหนดคลาสข้อความที่ปลอดภัย
  • สามารถตั้งค่าฟิลด์แบบความยาวคงที่และความยาวแปรผัน รวมถึงการเติมแพดดิ้งได้

การจัดการข้อผิดพลาด

  • ออกแบบให้ยังพาร์สฟิลด์ถัดไปได้เมื่อการพาร์สฟิลด์หนึ่งล้มเหลว
  • รองรับการจัดการข้อผิดพลาดบางส่วนโดยยังคงการทำซีเรียลไลซ์ของข้อความไว้
  • หากเกิดข้อผิดพลาดร้ายแรง จะหยุดการประมวลผลข้อความ

บทสรุป

  • มาตรฐาน ISO 8583 ได้พัฒนาอย่างต่อเนื่องนับตั้งแต่ถูกกำหนดขึ้นในปี 1987 เพื่อตอบโจทย์ความต้องการของเครือข่ายที่หลากหลาย
  • Increase ช่วยจัดการข้อความ ISO 8583 เพื่อให้ผู้ใช้โฟกัสกับการพัฒนาผลิตภัณฑ์ของตนได้
  • สามารถดูเอกสาร API หรือสอบถามได้ที่ ทีม Increase

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-12-19
ความเห็นจาก Hacker News

  • Visa และ Mastercard ไม่ได้ใช้งาน ISO 8583 ในแบบที่เป็นมาตรฐานเดียวกัน แต่ละบริษัทออกเอกสารยาวหลายพันหน้าเพื่ออธิบายวิธีใช้ฟิลด์มาตรฐานและวิธีใส่ข้อมูลกรรมสิทธิ์ลงในข้อความ แพลตฟอร์มจัดการ/ออกบัตรส่วนใหญ่ซ่อนความซับซ้อนนี้ไว้ได้ดี การเปลี่ยนไปใช้ ISO 20022 เป็นการปรับปรุงในทางที่ดี แต่มีโอกาสน้อยที่จะผ่านเกณฑ์ ROI

  • รูปแบบของโปรโตคอลประเภทนี้ (ชนิดข้อความ, บิตแมปนิยามฟิลด์, ชุดค่าความยาวคงที่และแปรผัน) เป็นเรื่องปกติในยุคที่มันถูกพัฒนาขึ้น ฝั่งผู้รับต้องระวังตรวจสอบความยาวฟิลด์แบบไดนามิกและไม่อ่านเลยจุดสิ้นสุดของข้อความ อย่างไรก็ตาม ปัญหาเหล่านี้เป็นสิ่งที่เข้าใจกันดีแล้วในปัจจุบัน

  • น่าหงุดหงิดที่มาตรฐาน ISO 8583 ไม่ได้ระบุวิธีเข้ารหัสฟิลด์หรือชนิดข้อความอย่างชัดเจน ส่งผลให้ผู้รับอาจได้รับชุดไบต์สุ่มที่ไม่สามารถตีความข้อความได้

  • ช่วงนี้มีการพูดคุยเรื่องการชำระเงินเยอะมาก และ patio11 ก็ทำคอนเทนต์ได้ยอดเยี่ยม เมื่อ 25 ปีก่อนไม่มีเว็บไซต์อธิบายแบบเห็นภาพเช่นนี้ อย่างที่คอมเมนต์อื่นพูดถึง EBCDIC การสลับข้าม endian เป็นเรื่องซับซ้อน เคยมีประสบการณ์สนุก ๆ ช่วงต้นยุค 2000 ตอนร่วมงานกับบัตร Discover เพื่อเพิ่มฟิลด์ GUID เข้าไปในสเปก ISO8583

  • ระบบการเงินเป็นหนึ่งในสมรภูมิของการเปลี่ยนแปลง มีคนจำนวนมากที่ยังไม่ตระหนักถึงการเปลี่ยนแปลงเหล่านี้ บริษัทเทคโนโลยีรายใหญ่เป็นเจ้าของ ecosystem การชำระเงินของตนเอง จึงควรให้ข้อมูลเชิงลึกแก่คนที่ยังไม่เห็นภาพ บางประเทศก็กำลังเดินตามแนวโน้มนี้

  • Charles Stross อาจเสียสติไปนิดหน่อยเพราะมาตรฐาน ISO 8583 และนั่นอาจเป็นสาเหตุที่ทำให้เขาเขียน Accelerando มาตรฐานนี้น่าจะเป็นมาตรฐานใหม่ที่เข้ามาแทนโปรโตคอลกำกวมจากยุค 70

  • เป็นบทความที่อธิบายได้ดีมากว่าเหตุใด ISO20022 จึงควรมาแทน 8583 โดยเฉพาะในภูมิภาคที่เครือข่ายผูกขาดของ M/V ไม่ได้ครองตลาด บัตรเครดิตสามารถนำไปใช้ในระบบการชำระเงินแบบใหม่ร่วมกับบัญชีเครดิตที่ธนาคารให้บริการได้ สามารถทำการชำระเงินระหว่างบัญชีแบบทันที และธุรกรรมต้นทุนต่ำราคาคงที่ได้

  • สนุกดีที่ได้เห็นวิธีต่าง ๆ ในการเลี่ยงข้อจำกัดของ ISO 8583 ช่วงหลังมีการใช้วิธีส่งข้อมูลเพิ่มเติมที่อยู่นอกธุรกรรมการชำระเงินผ่านการเรียก API ก่อน/หลังข้อความ ISO กันมากขึ้น ซึ่งช่วยลดเวลาออกสู่ตลาด แต่ก็อาจก่อให้เกิดรูปแบบความล้มเหลวใหม่ ๆ ได้

  • ฟอร์แมตนี้น่าสนใจดี ตอนวิเคราะห์ข้อความ ISO-8583 จะรู้สึกเหมือนได้เห็นประวัติศาสตร์คลี่ออกต่อหน้า ข้อความที่ฉันวิเคราะห์เป็น BCD ไม่ใช่ EBCDIC แต่ในฟิลด์หนึ่งมี XML อยู่ และใน XML ก็มี JSON อยู่ ทุกครั้งที่มีการขยายข้อความก็สะท้อนเทรนด์ของแต่ละยุคสมัย

  • ต่างจาก Visa และ Mastercard การแจ้งเตือนธุรกรรมของ AMEX เกิดขึ้นแทบจะทันที ทันทีที่รูดบัตร การแจ้งเตือนก็เด้งขึ้นมาบนโทรศัพท์/นาฬิกา ราวกับเวทมนตร์ ดูเหมือนว่า V/MC จะมีหลายชั้นที่ AMEX ไม่มี

  • ประสบความสำเร็จอย่างมากกับ iso8583 ที่ใช้ไลบรารี Go

  • การรีวิวลอจิกการมาสก์ข้อมูลบัตรเครดิต ISO 8583 ใน system log ที่ถูกเข้ารหัสด้วย base64 (หรือเข้ารหัสด้วย base64 ที่ถูกเข้ารหัสด้วย EBCDIC อีกชั้น) เป็นเรื่องที่น่าสนุกดี