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 Data models for how to load transaction data in each Signal operating mode.
Transaction format
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 |
If the Signal GUI cannot identify a transaction file by its extension, it tries each supported format. See the data exchange chapter for details.
Transaction data model
JSON
The table below describes the Transaction data fields. Transaction is the internal data model, so other formats, such as DUMP and INI, are converted to it for further processing.
| Field | Type | Required | Default value | Contains | Validation | Valid example |
|---|---|---|---|---|---|---|
| message_type | str[int] | Yes | - | Transaction Message Type Identifier | Length is exactly 4 Digits only Field exists in the specification |
0200 |
| max_amount | str[int] | No | 100 | Maximum generated transaction amount | Digits only | 100 |
| generate_fields | list[str[int]] | No | [ ] | Numbers of fields to generate | Digits only | ["4", "11", "37"] |
| data_fields | dict[str, str | dict] | Yes | - | JSON-like representation of transaction fields | According to the field specification | |
JSON transaction example
INI
Transaction fields can also be represented in INI format. Learn more about INI here.
INI files contain sections, options, and option values.
Enclose all option values in square brackets, like [this].
All field numbers in the [MESSAGE] section must start with F, for example F002.
An INI transaction contains up to three sections.
| Section | Required | Contains |
|---|---|---|
| [MTI] | Yes | Transaction Message Type Identifier |
| [CONFIG] | No | Transaction configuration parameters, such as MAX_AMOUNT and GENERATE_FIELDS |
| [MESSAGE] | Yes | Message body containing field values |
Fill in the sections according to the data model below.
| Section | Option | Type | Required | Default value | Contains | Validation | Valid example |
|---|---|---|---|---|---|---|---|
| [MTI] | MTI | str[int] | Yes | - | Transaction Message Type Identifier | Length is 4, digits only, exists in the specification | [0200] |
| [CONFIG] | MAX_AMOUNT | str[int] | No | 100 | Maximum generated transaction amount | Digits only | [100] |
| [CONFIG] | GENERATE_FIELDS | list[int] | No | [ ] | Numbers of fields to generate before sending the 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
The ConfigParser library requires percent signs in option values to be escaped: write %% instead of %.
Refer to the ConfigParser docs for details.
INI transaction example
DUMP
A dump is a hex-encoded transaction message, ready to be sent to a remote host over TCP/IP. It can occupy a single line or multiple lines. The ASCII representation on the right is optional; Signal does not read it.
Transaction dumps can be used in GUI or CLI mode. You can also generate a dump using the GUI or API tools.
A dump contains raw transaction data, with no configuration or other additional fields. The MTI, bitmap, and all field values must be calculated in advance.