ISO 8583: क्रेडिट कार्ड की भाषा

 (increase.com)
3 पॉइंट द्वारा GN⁺ 2024-12-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • ISO 8583 क्रेडिट कार्ड नेटवर्कों के बीच होने वाले रीयल-टाइम संदेश आदान-प्रदान का मानक है
  • यह मानक उन संदेशों को परिभाषित करता है जो point-of-sale डिवाइस पर कार्ड टैप करने या ऑनलाइन "खरीदें" पर क्लिक करने पर उत्पन्न होते हैं
  • शुरुआत में POS या ATM सीधे संदेश बनाते थे, लेकिन अब आमतौर पर उन्हें JSON जैसे उच्च-स्तरीय फ़ॉर्मैट में बदलकर फिर ISO 8583 में परिवर्तित किया जाता है
  • संदेश संरचना सरल है, लेकिन उसका विस्तृत implementation जटिल है और नेटवर्कों के बीच compatibility के लिए लचीलापन रखता है

मूल संदेश फ़ॉर्मैट

Message Type Indicator

  • 4 अंकों का कोड संदेश के प्रकार को दर्शाता है (उदाहरण: 0100 authorization request है)
  • यह प्राप्तकर्ता को अपेक्षित fields पहचानने में मदद करता है
  • serialization का तरीका नेटवर्क के अनुसार अलग हो सकता है (BCD, ASCII आदि)

Bitmap

  • यह field की उपस्थिति को दर्शाता है
  • 1 का अर्थ field मौजूद है, 0 का अर्थ field नहीं है
  • 8-byte आकार में अधिकतम 64 fields दर्शाए जा सकते हैं

Data Elements

  • fields को bitmap के बाद serialize किया जाता है
  • fixed-length fields हमेशा एक ही आकार के होते हैं, जबकि variable-length fields में लंबाई की जानकारी शामिल होती है
  • fields के encoding के लिए ASCII, BCD, binary आदि का उपयोग होता है

Nested message structure

  • ISO 8583 मानक नेटवर्कों को network-specific custom data शामिल करने की अनुमति देता है
  • nested messages को table, bitmap, TLV(Tag-Length-Value) फ़ॉर्मैट में implement किया जा सकता है

Table

  • सभी fields fixed length में शामिल होते हैं
  • जगह की बर्बादी कम करने के लिए variable-length subfields का अतिरिक्त समर्थन होता है

Bitmap message

  • प्रत्येक subfield की उपस्थिति bitmap से दर्शाई जाती है
  • field न होने पर जगह की बर्बादी रोकी जा सकती है

TLV message

  • fields को tag, length, value के tuple के रूप में serialize किया जाता है
  • क्रम पर निर्भर हुए बिना इसका विस्तार किया जा सकता है

Parser design

  • ISO 8583 parser की शुरुआत bitmap analysis और प्रत्येक field की serialization definition से होती है
  • nested messages की processing और नेटवर्क-विशिष्ट implementation के अंतर को ध्यान में रखना पड़ता है
  • Ruby के Sorbet type system का उपयोग करके सुरक्षित message classes परिभाषित की जाती हैं
  • fixed-length और variable-length fields, padding handling आदि को configure किया जा सकता है

Error handling

  • field parsing विफल होने पर भी अगला field parse किया जा सके, ऐसा design किया जाता है
  • message serialization को बनाए रखते हुए आंशिक errors को handle किया जाता है
  • गंभीर error होने पर message processing रोक दी जाती है

निष्कर्ष

  • ISO 8583 मानक 1987 में परिभाषित होने के बाद से लगातार विकसित हुआ है और विभिन्न नेटवर्क आवश्यकताओं को पूरा करता आया है
  • Increase, ISO 8583 messages को संभालने में मदद करता है ताकि उपयोगकर्ता product development पर ध्यान केंद्रित कर सकें
  • API documentation देखें या Increase टीम से संपर्क करें

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-12-19
Hacker News राय

  • Visa और Mastercard ISO 8583 को मानकीकृत तरीके से लागू नहीं करते। हर कंपनी हज़ारों पन्नों के दस्तावेज़ जारी करती है, जिनमें बताया जाता है कि standard fields का उपयोग कैसे करना है और proprietary data को messages में कैसे शामिल करना है। ज़्यादातर card management/issuance platforms इसे अच्छी तरह abstract कर देते हैं. ISO 20022 की ओर बदलाव एक सकारात्मक सुधार है, लेकिन ROI के हिसाब से इसके मानक पूरे होने की संभावना कम है.

  • प्रोटोकॉल का प्रकार (message types, field definition bitmaps, fixed और variable length value sets) इसके विकसित होने के समय आम था। receiver side पर dynamic field lengths को validate करना होता है और यह ध्यान रखना होता है कि message के अंत से आगे पढ़ाई न हो। लेकिन अब इन समस्याओं को अच्छी तरह समझा जा चुका है.

  • यह हैरान करने वाला है कि ISO 8583 standard यह निर्दिष्ट नहीं करता कि fields या message types को encode कैसे किया जाए। इसकी वजह से receiver को random bytes का ऐसा set मिल सकता है जिसे वह समझ ही न पाए.

  • हाल में payments को लेकर बहुत चर्चा हुई है और patio11 बेहतरीन content देता है। 25 साल पहले इस तरह की visual explanation websites नहीं थीं। EBCDIC का ज़िक्र करने वाली दूसरी comment की तरह, endianness के बीच conversion जटिल होता है। 2000s की शुरुआत में Discover card के साथ काम करते हुए ISO8583 spec में GUID field जोड़ने का अनुभव दिलचस्प था.

  • financial systems बदलाव के बड़े युद्धक्षेत्रों में से एक हैं। बहुत से लोग इन बदलावों को पहचान नहीं रहे हैं। बड़ी tech companies अपने खुद के payment ecosystems की मालिक हैं, इसलिए जो लोग इसे नहीं समझते उन्हें इस बारे में insight दी जानी चाहिए। कुछ देश इस रुझान का अनुसरण कर रहे हैं.

  • Charles Stross शायद ISO 8583 standard की वजह से थोड़ा पागल हो गया था, और संभव है कि उसी ने उसे Accelerando लिखने के लिए प्रेरित किया हो। यह standard शायद 70s के अस्पष्ट protocols की जगह लाने वाला नया standard था.

  • यह एक शानदार लेख है जो समझाता है कि ISO20022, 8583 की जगह क्यों ले सकता है, खासकर उन क्षेत्रों में जहाँ M/V proprietary networks हावी नहीं हैं। credit cards को नए payment systems में बैंकों द्वारा दिए गए credit accounts के साथ लागू किया जा सकता है। account-to-account instant payments और कम-लागत fixed-price transactions संभव हैं.

  • ISO 8583 की सीमाओं को bypass करने के अलग-अलग तरीके देखना मज़ेदार था। हाल के समय में ISO messages के पहले/बाद API calls के ज़रिए payment transaction के बाहर की अतिरिक्त जानकारी भेजने का तरीका बहुत इस्तेमाल हो रहा है। इससे time-to-market घटता है, लेकिन नए failure modes भी पैदा हो सकते हैं.

  • यह format मज़ेदार था। ISO-8583 messages को parse करते समय इतिहास खुलता हुआ दिखता था। जिन messages का मैंने विश्लेषण किया, वे EBCDIC नहीं बल्कि BCD थे। लेकिन एक field में XML था, और XML के अंदर JSON था। हर बार जब message को expand किया गया, उसमें उस दौर का trend झलकता था.

  • Visa और Mastercard के विपरीत, AMEX transaction alerts लगभग तुरंत आते हैं। कार्ड swipe करते ही फ़ोन/घड़ी पर alert आ जाना जादू जैसा लगता है। लगता है V/MC में जो layers हैं, वे AMEX में नहीं हैं.

  • Go library का उपयोग करके iso8583 में मुझे काफ़ी सफलता मिली है.

  • system logs में base64-encoded (या EBCDIC-encoded base64-encoded) ISO 8583 credit card data की masking logic की समीक्षा करना दिलचस्प था.