Transaction
Transaction data
The Transaction data model is the central dataset used by Signal to represent payment transactions. Each request and response is represented as a separate Transaction object
Signal receives transactions from multiple sources (files, API, TCP sockets, GUI), converts them into the internal Transaction model, processes them in the Signal Core, and routes them to the appropriate destination
After processing, the Transaction can be converted to a target format and returned via various interfaces, such as a GUI, an API response, CLI output, or a TCP connection
See here how to read the transaction data in any Signal run mode
Transaction format
The signal supports three transaction data formats
| Data format | File extension | Supported in | Comment |
|---|---|---|---|
| JSON | .json |
GUI, CLI, API | Recommended transaction data format |
| DUMP | .dump or .txt |
GUI, CLI | |
| INI | .ini |
GUI, CLI |
In case when the Signal GUI incoming transaction file cannot be recognized by the incoming file extension the Signal will try to parse the transaction as every known format. See details in data exchange chapter
Transaction data model
JSON
The Transaction data fields representation. The Transaction dataset is the target format of data, so all the others formats, e.g., DUMP or INI, will be converted to Transaction for future data processing
| Field | Type | Required | Default value | Contains | Validation | Valid example |
|---|---|---|---|---|---|---|
| message_type | str[int] | Yes | - | Transaction Message Type Identifier | Length is exact 4 Digits only Field exists in Specification |
0200 |
| max_amount | str[int] | No | 100 | Maximum generated transaction amount | Digits only | 100 |
| generate_fields | list[str[int]] | No | [ ] | Field numbers to generate | Digits only | ["4", "11", "37"] |
| data_fields | dict[str, str | dict] | Yes | - | JSON-like transaction data fields representation | According to the field specification | |
JSON transaction example
INI
INI transaction fields representation. See more about INI format here
INI format contains the following parts: sections, options, and options values
All the options values should be put in square brackets like [this]
All the fields numbers in the section [MESSAGE] must start from F. E.g. F002
INI transaction data contains up to three sections
| Section | Required | Contains |
|---|---|---|
| [MTI] | Yes | Transaction Message Type Identifier |
| [CONFIG] | No | Transaction configuration params such as MAX_AMOUNT and GENERATE_FIELDS |
| [MESSAGE] | Yes | Message body, contains data fields values |
The sections should be filled according to the data model
| Section | Option | Type | Required | Default value | Contains | Validation | Valid example |
|---|---|---|---|---|---|---|---|
| [MTI] | MTI | str[int] | Yes | - | Transaction Message Type Identifier | lenght is 4, digits only, exists in Specification | [0200] |
| [CONFIG] | MAX_AMOUNT | str[int] | No | 100 | Maximum generated transaction amoun | Digits only | [100] |
| [CONFIG] | GENERATE_FIELDS | list[int] | No | [ ] | Field numbers to generate before send transaction | Digits only | [4, 11, 37] |
| [MESSAGE] | FNNN where NNN is field number | str | yes | - | Transaction data fields | According to the field specification | F002 = [4000000000000000]F003 = [000000];...;... |
% Substitution
Due to ConfigParser library restrictions the sign % in options values must be written as double percent, %% only
Refer to the ConfigParser docs for details
INI transaction example
DUMP
Dump is a hex-encoded transaction message, ready to be sent to a remote host over TCP/IP. It can be set as a single string or a multi-string value. The right side in ASCII representation is optional, and the Signal never reads it
The transaction data in dump representation can be used in GUI or CLI mode. You can also generate the dump using the GUI or API tools
The dump is raw transaction data, so there is no configuration or any other additional fields. MTI, Bitmap, and all the field values should be pre-calculated