Streams

Financial transactions hosts simulators at iso8583.info site can use HTTPS or TCP/IP socket protocols communication streams.

SSL for TCP/IP streams can be enabled by your request.

As acquirers hosts or switch systems might implement wide range of communication streams we implemented for our online authorisation hosts only most used.

Current list of streams:

HTTPS_MSGHTTPS: POST/GET [ASCII/HEX message]

TCP_Len2BIN_BINMSGTCP/IP socket: Length prefix [Binary message length, 2 Bytes]+[Binary message]

TCP_Len4HEX_MSGTCP/IP socket: Length prefix [Hexadecimal message length, 4 HEX characters]+[ASCII/HEX message]

TCP_Len4NUM_MSGTCP/IP socket: Length prefix [Numeric message length, 4 digits]+[ASCII/HEX message]

TCP_MSG_CRTCP/IP socket: Mac line [ASCII/HEX message]+[CR]

TCP_MSG_CR_LFTCP/IP socket: Dos/Windows line [ASCII/HEX message]+[CR LF]

TCP_MSG_LFTCP/IP socket: Unix line [ASCII/HEX message]+[LF]

TCP_STX_MSG_ETXTCP/IP socket: [STX]+[ASCII/HEX message]+[ETX]

TCP_STX_BINMSG_ETXTCP/IP socket: [STX]+[Binary message]+[ETX]

Please contact support@iso8583.info if you require another types of communication streams.

Stream names

Streams names constructed with several parts. Below is the alpabetical list of these parts with explanations of meanings.

ASCIIString with printable characters.

BINHere it meant the Message in Binary format as it is storred in memory.
Due to non-printable characters in message body our on-site parsers require Hexadecimal message value.
Binary messages in other words is buffer of Bytes with printable and non-printable characters.

BinarySame as BIN.

BINMSGSame as BIN.

CRCarriage return is non-printing control character with hex code "0x0D". In programming languages known as escape sequence "\r".

ETXEnd-of-Text is non-printing control character with hex code "0x03".

HEXString with Hexadecimal characters ("0"-"9", "a"-"f", "A"-"F").

HexadecimalSame as HEX.

HTTPSStream use Hypertext Transfer Protocol Secure (HTTPS) protocol. You may send single financial Request Message with HTTP POST or GET Request Methods.
In case success message processing you will receive Host Reply Message in HTTP Response Body with successful status code "200".
In case unexpected or faulty Request Message you will receive HTTP Response with error status code "500".
In case incorrect Host tool URL or host settings misconfiguration you will receive HTTP Response with error status codes "404", "503" or "505".

Len2BINBinary message length, 2 Bytes.
For example message with 123 bytes length will be 0x7B in HEX. It should be sent with zerro padding as 2 Bytes Binary buffer 0x"007B".

Len4HEXHexadecimal message length, 4 HEX characters as ASCII string.
For example message with 123 bytes length will be 0x7B in HEX. It should be sent with zerro padding as ASCII string like "007B" or same in Binary buffer 0x"30303742".

Len4NUMDecimal or numeric message length, 4 Digits characters as ASCII string ("0"-"9").
For example message with 123 bytes length should be sent with zerro padding as ASCII string like "0123" or same in Binary buffer 0x"30313233".

LFLine feed is non-printing control character with hex code "0x0A". In programming languages known as escape sequence "\n".

MSGHere it meant the message in format as it is used in iso8583.info on-site message parsers.
In case parser require ASCII message then for Host Stream expected to use also ASCII message format.
In case parser require Hexadecimal dump of message then for Host Stream expected to use exactly this Hexadecimal message value, without delimiters, only HEX characters [0-9a-fA-F].

STXStart-of-Text is non-printing control character with hex code "0x02".

TCPStream use Transmission Control Protocol. It is RAW or simple Socket protocol. As Request Message may contain any characters these TCP streams require Length or Start/End identifiers.

Multiple financial requests

At the moment all streams supporting only single message request and reply. It was implemented to release resources at our host environment to other connections.

In other words to send next financial message request your client application must initiate another connection.

Transactions history

Host environment do not store transaction data in long-term databases. Sub-sequence transactions like Sale and then Sale-Reversal will be processed without looking up original transaction.

Only valid message requests and responses for last 24 hours available under host settings. These temporary transactions can be cleaned from memory without notices.

Please request support if you require deep communication or message analysys.


Email to support@iso8583.info. Available test hosts simulators