After many years of dealing with banks, processors and people related to payments I still get to hear it from time to time. It goes like this:
My question: "What's the application protocol used by the X entity?"
The response: "ISO8583".
As if that says it all! It's true that the knowledge than an application protocol is based on ISO8583 does convey some information. I immediately know that there's going to be a jumble of fields whose presence is defined by a bitmap of some sort. I know that I'll have to deal with things like processing code, STAN, RRN, POS code and other related fields that I may have dealt with before in the past. I also know that I have a good parsing facility at my disposal and I can use it to implement the protocol.
But that's about it. Some people indicate that application protocols based on ISO8583 are dialects of a protocol. Although this sometimes appears to be a legitimate analogy, I would say that ISO8583 defines the consonants and vowels of a language. People that speak the same language with different dialects can communicate after a fashion. They'll find some common ground, a verbal subset with common meaning to them both.
Computers speaking different flavors of ISO8583 cannot communicate at all. It only takes one tiny bit of difference to throw everything out the window. ASCII or EBCDIC? How is the bitmap packed? Is that LLVar or LLLVar? Is this field mandatory, optional or conditional and what's the condition defining its presence or absence? What's that private data field, I don't know how to decode it!
Questions like these have to be, not only answered, but also asked. I've seen application protocols based on ISO8583 that are crafted for POS transactions only. Or ATM transactions only. There are ISO8583-based protocols that cater for a multitude of transactions and there are others that handle only balance inquiry and cash advance. Given the structure, capabilities and degree of configuration of your ISO8583 parser, some ISO8583-based application protocols may be implemented in a couple of weeks. Others may need several months. Being based on ISO8583 doesn't tell the whole tale.
Computers speaking different flavors of ISO8583 cannot communicate at all. It only takes one tiny bit of difference to throw everything out the window. ASCII or EBCDIC? How is the bitmap packed? Is that LLVar or LLLVar? Is this field mandatory, optional or conditional and what's the condition defining its presence or absence? What's that private data field, I don't know how to decode it!
Questions like these have to be, not only answered, but also asked. I've seen application protocols based on ISO8583 that are crafted for POS transactions only. Or ATM transactions only. There are ISO8583-based protocols that cater for a multitude of transactions and there are others that handle only balance inquiry and cash advance. Given the structure, capabilities and degree of configuration of your ISO8583 parser, some ISO8583-based application protocols may be implemented in a couple of weeks. Others may need several months. Being based on ISO8583 doesn't tell the whole tale.
No comments:
Post a Comment