Iso8583 message encoding and decoding [closed]

问题:

My question is based on ISO8583 Transaction message standard. My problem statement is to develop an app which will decode the ISO8583 message which is provided as a input in HEX format.

for ex : my input = 0200B2200000001000000000000000800000201234000000010000011072218012345606A5DFGR021ABCDEFGHIJ 1234567890

Using jPOS library i am parsing this hex code and output is as follows : MTI : 0200 Field-3 : 201234 Field-4 : 000000010000 Field-7 : 0110722180 Field-11 : 123456 Field-44 : A5DFGR Field-105 : ABCDEFGHIJ 1234567890

Now this parsed output i want to decode i.e i want to convert it into the string format. I want to know what exactly it conveys, like if it is a balance inquiry or a transaction request etc.

so , my question is , is there any tool available to understand the hex code of iso8583 message?

回答1:

There are big list of dialects based on ISO 8583 specifications from 1987, 1993 and 2003 years. Modified protocols use the mix of ASCII, Binary, BCD, EBCDIC data in the fields.

Your message sample looks similar to OmniPay Host to Host implementation, except Field 105 which is not used by this specification.

Without additional modifications it was parsed by the online tool at https://iso8583.info/lib/OmniPay/H2H/msg

Use your message "binary" representation:

0000: 30 32 30 30 42 32 32 30 │ 30 30 30 30 30 30 31 30  0200B22000000010
0010: 30 30 30 30 30 30 30 30 │ 30 30 30 30 30 30 38 30  0000000000000080
0020: 30 30 30 30 32 30 31 32 │ 33 34 30 30 30 30 30 30  0000201234000000
0030: 30 31 30 30 30 30 30 31 │ 31 30 37 32 32 31 38 30  0100000110722180
0040: 31 32 33 34 35 36 30 36 │ 41 35 44 46 47 52 30 32  12345606A5DFGR02
0050: 31 41 42 43 44 45 46 47 │ 48 49 4A 20 31 32 33 34  1ABCDEFGHIJ 1234
0060: 35 36 37 38 39 30       │                          567890

Here are some garbage in the original message, but it is not the fault of parsers. ))

--- # Cheef's parser (Limited version - 5 levels deep only)
- msg:  # OmniPay H2H message
   MTI: "0200" # Message Type ID.
   DE000: "B220000000100000" # Primary bitmap  // 1.3.4.7.11.44.
 - BM0:  # Fields at Primary Bitmap
    DE001: "0000000000800000" # Secondary bitmap  // 105.
  - DE003:  # PC
     S01: "20" # Transaction Code.  // Refund
     S02: "12" # Account, from.
     S03: "34" # Account, to.
    DE004: "000000010000" # Amount, transaction.  // 10000
  - DE007:  # Date and time, transmission
     date: "0110" # Date, local transmission.  // 2015.01.10
     time: "722180" # Time, local transmission.  // 00:22:20
    DE011: "123456" # STAN.
  - DE044:  # Additional response data
     len: "06"
   - val: 
      RFU: "A5DFGR"

The online parsers defined for several dialects, so you can play with your messages data and analyze results.

回答2:

Your example input looks like a standard ASCII ISO-8583 input string and not in HEX or binary format of any kind. So if all of your input looks like that a large chunk of your problem is already solved.

As far as understanding what you have there is numerous amounts of publicly available information specific to decoding ISO-8583 message formats and their values. For most of them they generally follow the standard field formats but may have custom defined field values unique to the specification. The biggest exception to this is VISA and MasterCard, but the regional ones in the US generally are pretty close to ISO-8583-87.

The Wikipedia page and the jPOS documentation I would assume would give you a bulk of the documentation you are looking for as to things like "What is field 44?". I have been maintaining and looking at different organizations ISO-8583 specifications for about 15 years and you usually have to get the specific vendor specification directly from them for all of the variations of the data and unique data processing specific to the interface. There are a few out there that are publicly available that are pretty easily found by searching for "ISO-8583 .PDF" on Google as well.

The catch is most specifications, and especially the original ISO-8583 specification from the ISO organization itself do not contain examples of what specific transactions look like. Though if you know data element 003's content you should be able to logically assemble many basic message types to at least identify the transaction types (i.e. 310000 = Balance Inquiry from Default) for your parser program, the catch will be knowing all of the supporting fields and their corresponding fields specific to that entities specification that are required to really make heads or tails of it, but using some common sense too you can piece it together.

Once one is super familiar with ISO-8583 you can usually look at a block of text like you have above that has no binary in it and mentally parse most of it to get an idea of what type of transaction it is without a bitmap sometimes even if you are familiar with that specific variant.