8583 Messages (RPM)

1 8583 Packet 1.1 packet format

The ISO 8583 Financial Transaction information packet consists of three segments, such as the information type (MSG_TYPE_ID), one or more bitmaps (Bit_map), and a sequence of data elements in the order described by the bitmap (ELEMENTS).

The information type is a 4-digit numeric field that describes the categories and functions of each transaction information, with the first two digits indicating the category of information, such as authorization information, financial transaction information, management information, and so on. In a financial system, the definition of information type should be unique and no ambiguity. When the inter-network transaction has different information type definitions, the type conversion processing should be done before and after the exchange message is sent.

Bitmaps are composed of 64-bit binary bits, each of which represents the existence or absence of a data element corresponding to the bit phase with 1 or a decimal. The first bit of the bitmap is 1 o'clock, which represents a 64-bit bitmap followed by an extended 64-bit bitmap. This implementation specification does not use an extended bitmap.

The data element refers to the actual content of a data item in a transaction, whether the data element exists in the packet and where it is stored is determined by the corresponding bit bits in the bitmap. Some data elements have fixed lengths, and some data elements are variable. A data element with a variable length type should append a prefix byte that indicates the length before the actual data.

1.2 Symbol definition

This specification uses the following identifiers to describe the properties of the data elements:

1.2.1 General description

Marker	Description
A	Plain alphabetic characters
N	Pure numeric characters
An	alphabetic and numeric characters
Ans	Letters, numbers, and special characters
Z	Second track and third track data on track
B	Binary data (count by bit)

1.2.2 Length Properties

Marker	Description
Numerical	Fixed-length data elements
.. Numerical	Variable length data element, maximum length specified in this specification
Llvar	Indicates that the field contains two characters indicating its length in 1-99 The child field between, "LL" indicates the length of the data
Lllvar	Indicates that the field contains three characters indicating its length in 1-999 Sub-Fields between, "LLL" for data length

1.2.3 Data Element values

ASCII indicates that the field is in ASCII notation, and the length is calculated in bytes.

BCD indicates that the field is represented by a BCD code, that is, every four bits represents a data bit.

BIN binary data, the length is represented by a bit bit.

1.2.4 Data Properties

Marker	Description
M	Required Options
ME	Force equal return items
O	Options available
C1	When the key is pressed
C2	This item is available when you swipe
16	The response must exist if the request is present
C3	This item is available when you have a password keyboard

1.2.5 Data Item Usage rules

A) all independent data items are computed in whole bytes.

b) N-type data items represented by the BCD code (Binary code Decimal), odd-length (fixed-length) n-type data items with byte boundaries right, left 0, and example 1234567 for 01234567 total of 4 bytes. Variable-length n-type data (such as the master account domain) is left-bound at the byte boundary, 0 on the right, and 1234567 for example: 1234570 for a total of 4 bytes.

c) The length field of a variable-length data item, treated as an n-type number of independent data items. The example ll represents a byte for ll, and LLL represents a total of 2 bytes for 0lll.

D) The z-type data item is similar to the N-type data item, which is 16 binary data.

e) ans or an data item is ASCII character or binary data.

1.2.6-bit diagram

The second part of the message is one or two bitmaps, each of which consists of a 64-bit (bit), each of which is used to indicate whether the corresponding data field in the message appears (1) or does not appear (0). If there is a second bitmap, the first bit bit01 of the primary bitmap (the first one) must be 1.

The following represents the condition of the first bitmap:

Bit 1	Bit 2	Bit 3	Bit 4	...	Bit 64
Domain 1 ' 0 '	Domain 2 Master Account	Domain 3 Processing code	Domain 4 Transaction amount	Domain...	Domain 64 Message Authentication Code

The following is a scenario that contains two bitmaps:

Bit 1	Bit 2	Bit 3	Bit 4	...	Bit 64
Domain 1 ' 1 '	Domain 2 Master Account	Domain 3 Processing code	Domain 4 Transaction amount	Domain...	Domain 64 Message Authentication Code

Bit 65	Bit 66	Bit 67	Bit 68	...	Bit 128
Domain 65 ' 0 '	Domain...	Domain...	Domain...	Domain...	Domain 128 Message Authentication Code

Each message message must contain a primary bitmap, but only the domain between the 66th domain and the 128 domain exists, and the second one is included.

1.3 Solution 8583 Example

There are ISO8583 messages as follows (hexadecimal notation):

(TPDU, message header, application data), C0 C0 98 11 (bitmap) 00 00 00 00 00 00 00 00 01 00 03 49 02 1 (in) 0 (10) 5D 15 11 10 00 00 35 36 38 35 32 33 31 34 32 33 35 32 31 34 35 32 36 38 35 39 32 33 C6 4D 7E 9E 9E 20 00 00 00 00 00 00 00 00 13 22 00 00 08 00 05 00 36 37 41 32 32 39 39 41

1.3.1 First Step

The message structure of the POS Center on the POS terminal consists of TPDU5 bytes, six bytes of the message header, and 2 bytes of application data in three parts:

--TPDU Description: A length of 10 bytes, compressed with BCD code as a value of 5 bytes length.

--Application Data Description: The general length is 4 bytes, compressed with BCD code as a value of 2 bytes of length. So the first five bytes in the above message are TPDU, i.e. 60 00 03 00 00

The header occupies six bytes, or 60 31 00 31 07 30 Application Data takes 2 bytes, or 02 00 is "0200"

1.3.2 Second Step

To parse a bitmap:

First take the 14th byte, that is, 0x30, into the binary 0011 0000, in the first bit of the byte is 0 (left to right) to indicate that the current message only includes 64 fields, that is, starting from the current byte 8 bytes is a bitmap (including the current byte), if you want to include 128 fields, the bit is 1.

Now into the critical bitmap analysis, we now take the 8 bytes representing the bitmap, which is C0 C0 98 11,

Convert to binary:

00110000 00100000 00000100 11000000 00100000 11000000 10011000 00010001

The position of 1 in the bitmap is represented by the corresponding domain, in the above bits from left to right there are 3rd, 4th, 11th, 22nd, 25th, 26th, 35th, 41st, 42nd, 49th, 52nd, 53rd, 60th, 64th bit.

The following start the data in these fields, first analysis 3 domain, 3 domain for transaction processing code, compressed into BCD code after 3 bytes, we start from a bitmap of 8 bytes after the beginning of 3 bytes, that is 00 00 00, after decompression is "000000", the specific meaning here is not described.

4 domain for the transaction amount, compressed into BCD code after the fixed length of 6 bytes, the same 6 bytes, that is 00 00 00 00 00 01, that is, the amount of 0.01 yuan, the specific conversion reference specification.

The 11 domain is the card-side system tracking number (serial number), compressed into BCD code for a fixed length of 3 bytes, the same time take 3 bytes, that is 00 03 49, or 000349.

22 Domain for the service point input mode code, compressed into BCD code occupies a fixed length of 2 bytes, the same way take 2 bytes, that is 02 10, because the 22 domain itself accounted for only 3 bytes, compression left, right, 0, so the conversion to "021", the specific meaning is no longer described.

25 domain is the service point condition code, compressed into the BCD code occupies a fixed length of 1 bytes, the same time take 1 bytes, that is 00, converted to "00", "00" represents the normal submission.

26 Domain for the service point PIN acquisition code, compressed into BCD code to 1 bytes, the same time take 1 bytes, that is, 12, converted to "12", indicating that the service point device is allowed to enter the maximum length of the personal password plaintext is 12.

The solution of the 35 domain is not fixed length, so the processing method is different, first take a byte, that is, 30, converted to "30", indicating that the second track data occupies 30 bytes, take a continuous 15 bytes that is the ten-year-long 5D 15 11 10, 10 00 00, this data is not in The description of the line.

41 domain for the card machine Terminal Identification Code, accounting for 8 bytes of fixed-length domain, take 35 36 38 35 32 33 31 34.

42 domain is a card-side identifier, accounting for 15-byte fixed-length fields, 32 33 35 32 31 34 35 32 36 38 35 39 32 33 36.

The 49 domain is the trading currency code, which accounts for 3 bytes of fixed-length fields, taking 31 35 36.

52 Domain for personal Identification code data, accounting for 8 bytes of fixed-length binary number field, take C6 4D 7E 9E 9E.

53 Domain for security control information, compressed into BCD code accounted for 8 byte fixed length domain, take 20 00 00 00 00 00 00 00. 60 domain is a custom domain, for indefinite long domain, take the length first (compress into BCD code occupies two bytes), namely 00 13, convert to 13 namely 60 domain occupies 13 bytes, compress into BCD code occupies 7 bytes, take 22 00 00 08 00 05 00.

The 64 domain is the message identification code, which takes up 8 bytes and takes the last eight bytes 36 37 41 32 32 39 39 41.

8583 Messages (RPM)