iso8583 | ISO-8583 Message Parser | Serialization library

Seems like the message is binary encoded and you weren't expecting that? Or the other way around, maybe (message is ASCII encoded and you're trying to read it as binary encoded)

Question 1: Your packet protocol doesn't fit with erlang's packet protocol, so I think you need to read from the socket in raw mode by specifying {packet, raw} or equivalently {packet, 0}, see https://erlang.org/doc/man/inet.html#packet.

I'm not sure how you are using handle_info() to read from the socket. Are you setting {active, true} so that data sent to the socket lands in the genserver's mailbox? If so, I don't think that will work because {active, true} tells erlang to automatically read N bytes from the socket, where N is specfied by {packet, N} when you open the socket. In your case, N will be 4. Erlang then uses the integer contained in those 4 bytes, let's call it MsLen, to read MsLen bytes from the socket. Erlang then combines all the chunks it reads from the socket into one complete message and places the complete message in the genserver's mailbox. However, your MsLen will be wrong because it's not an unsigned integer, rather it's an ascii encoded integer. Therefore, I think you need to open the socket in passive mode, {active, false}, read the first four bytes using gen_tcp:recv(), decode to get the integer length, then call gen_tcp:recv() again to read that many bytes from the socket.

Or, you could specify {active, true} and {packet, raw} so that any data sent to the socket will land in the genserver's mailbox. In that case, a message will consist of whatever size chunk happened to be sent to the socket by the underlying transport mechanism. So, you would need to use a loop around a receive block to keep extracting messages from the mail box until you got enough bytes for a complete message.

Question 2: When you open a socket in active mode, {active, true}, erlang automatically reads N number of bytes from the socket, where N is specified in {packet, N}, then erlang combines the chunks into a complete message and places the message in the process mailbox, which can only be read by a receive clause. Calling gen_tcp:recv() reads from the socket, which is of no help in that case. See details here: Erlang client-server example using gen_tcp is not receiving anything.

Specifying {active, once} tells erlang to open the socket with {active, true} for one message, then the socket switches to {active, false} or passive mode. In passive mode, a process needs to read directly from the socket by calling gen_tcp:recv(). You can specify {active, once} when you want to prevent a hostile actor from flooding the socket with millions of messages, which in turn would fill up the process mailbox and cause the process to crash. Will a hostile actor be able to flood the socket with millions of messages?

Question: 3 Synchronous with what? When you use ! to send a message to a genserver process, the message send is asynchronous because the process that sent the message does not wait for any type of response from the genserver process, so execution continues unabated in the sending process. With a genserver, we don't ask whether handle_call() is asynchronous, instead we ask whether the process that calls gen_server:call() is asynchronous with the genserver process. The process that calls gen_server:call() stops execution and waits for a response from the genserver process, so we say that the process that called gen_server:call() is synchronous with the genserver process.

Is a process that calls gen_tcp:send() asynchronous with the genserver process? gen_tcp:send() returns ok or an error message, so it does not wait for a reply from the genserver process, so a process that calls gen_tcp:send() is asynchronous with the genserver process.

Yes you can, as long as you agree with the other party the length of the length field.

In ISO8583, V2003 there are some fields defined as LLLLVAR such as DE 34 and 43 defined also in jPOS CMF.

I'm not sure it's defined in v87 of ISO8583 since I don't have the spec, which is on what the Wikipedia page is based on.

Either way the Wikipedia page is not fully comprehensive on the standard.

For odd lengths, the values are left-padded, not right-padded. So the first nibble is ignored, not the last one.

I'm sorry it's not clear in the documentation. I'll amend it to specify this.

Unfortunately this is a question you should ask to your acquirer. The usual is that you populate all the data you have, especially because some of them may be used for risk management rather than cryptogram calculation. List of mandatory data elements is usually longer than what is required purely for cryptogram generation. Second thing is that your application should not interpret proprietary data elements like Issuer Application Data unless you are required (remember there are other card application specifications and you might have trouble differentiating them on the acceptance side). Side note - AID is not IAD, 9F10 is not CVR.