Hexadecimal data encoding

[eraad]

Hi! This is not a bug but a doubt I have. The server I'm connecting to expects to receive the ISO data in hexadecimal encoding.

Do you have plans to support this?

Thanks

[juks]

Hi Eduardo!

Could you please give some more detailed specification? Do you mean entire string to be sent as HEX code equivalent, or do you mean the integer strings to be represented as hexademical? For instance, the MTI of 0200 to be exactly 0x0200, but not 0xC8.

If there an opporunity for you to provide a clear example — that will be perfect. You can do the encoding thanformation of simple echo or terminal init message and then send it netcat so see it is correct.

Does this case mean you had no chance to make the SocketServer useful for you? Sure I will implement this when it is clear.

[eraad]

Hi Igor, thank you for the quick response.

Our bank asks to encode alphanumeric, numeric and alphabetic characters in hexadecimal. So the MTI which I now sent as 0200, they ask it to be sent as 30323030. In the case of the PAN, for example now is 55 55 55 55 55 55 44 44 and they ask it to be sent as 3535 3535 3535 3535 3535 3535 3434 3434.

I was trying via netcat but haven't got any response from their host either so I guess I'm missing something.

Would it be as simple as transforming 0800 2020000000800000 000000 000001 3239313130303031 to 30383030 32303230303030303030383030303030 303030303030 303030303031 33323339333133313330333033303331?

Eduardo

[juks]

Eduardo, what kind of system is the ISO host runned with?

I guess it is always better to have a easy check that shows the system is alive, the connection is up and the dialect is correct. If you say alphanumeric, numeric and alphabetic — it means nearly "every kind of data".

There might be several reasons you get no response from the host:

• The host is set to use ISO8583 headers
• The host is configured for different data representation or the data format is incorrect
• The merchant or terminal ID you provide within the packets are incorrect or unknown for the host

In case your bank runs OpenWay host, the following link might be helpful for you in your debugging: https://iso8583.info/lib/OpenWay/POS/msg

I really think it will save you lots of time if, before doing any actual development, you will have your host answering the short echo/terminal init message sent simply by hand with the payload, predefined by you in a text file.

When we get some understanding of what can be done, the new feature with proper configuration option can be added to the code.

[eraad]

Thanks for the feedback Igor, I will do my homework and get back to you when I have more hard data!

[juks]

You welcome! Would be nice to make this project able help more people to step over this 8583 headache.

[eueung]

@juks igor, just a newbie question, how to use SocketQueue with ISO header (something like ISO001000017)

is it currently supported?

Many thanks for your awesome work igor.

EM

[juks]

Hi Eueung!

There is the “useLengthHeader” parameter that controls the presence of ISO8583 2-byte length header. Means SocketQueue will prepend each message sent to the ISO-host with it's byte lengh.

Eg: for the message containing 100 bytes, the header will be 0100.

If you deal with a system set to use headers of other format, I think it will be no problem to implement. But there has to be some clear case with the specification of header format. Also I suggest to confirm the format using test exchange with the system using custom message sent from console as described here: https://github.com/juks/SocketQueue/tree/master/sample_payloads

[eueung]

@juks thanks for your quick response igor, ... if you don't mind, one more question :-)

if I just want to append a static header for every upstream iso messages, can I just modify Iso8583Packet.prototype.getRawMessage and add the string between the return values e.g. lengthHeader.toString() + 'ISO001000017' + this.rawData;?

[juks]

Eueung, I can implement the static header configuration parameter, but do you have any specification on your header contents? It does not look to be really “static”. Eg: 17 might be packet length or something else.

[juks]

@eueung Please check out the new branch https://github.com/juks/SocketQueue/tree/feature_static_header where the new parameter "useStaticHeader” is introduced. So you may run SocketQueue with the following options: --useStaticHeader="ISO001000017" --useLengthHeader=false

[eueung]

@juks , awesome! many thanks igor.

Our remote system is very specific, the header field is intended for versioning, status, originator (1) and responder id (7). But it seems it isn't very functional yet i.e. we always use the same header.

[juks]

Hi @eueung! Did you succeed with the communication? Just wondering if you have any feedback as going to merge the branch into master.

[eueung]

@juks hi igor,

I ended up writing my own small parser, since it seems the format is unusual, might be incompatible with current version of sq ... my first intention was to use your socketqueue to emit 0200 & 0800 messages and debug responses. Apart from the custom header issue, they use binary bitmap encoded as 0/1 characters .. anyway thanks for your help igor, hope to have time to continue exploration with your socketqueue ..

EM

[juks]

@eueung, thanks for your feedback! If it will not bother you too much, could you please create feature requests for implementing the configuration options for the differences that you have noticed?

[eueung]

@juks, did you mean a separate new issue for this ?

EM

[juks]

@eueung Yes. If you can provide actual case data (with no private information) — that would be perfect.

[eueung]

@juks , sure, let me first check how to present a similar (but fake) case