This guide describes Signal's basic concepts, usage, settings, and use as a library.

This document is under development.

Signal provides graphical and programmatic interfaces for sending e-commerce card transactions to card processing systems. It sends transactions using the ISO-8583 E-pay protocol rather than through a PSP. Signal can be used for payment system certification testing, system checks and configuration in test environments, and application development.

Signal provides three interfaces to a shared transaction-processing core:

• GUI — an interactive workspace where you prepare transactions, use tools, and inspect results. It stays open for your next action.
• CLI — a job runner that takes launch options and input files, performs the requested work, and normally exits when finished.
• HTTP API — an interface for other applications to send transactions and control Signal through HTTP requests. It runs within a GUI or CLI instance; in GUI mode, it can operate alongside the window.

The shared core and the way these interfaces work together are described in How Signal works.

If you have any questions about Signal, contact the author. Your feedback and suggestions help shape Signal's development.

• For use in test environments only. Signal implements only basic security checks
• Signal does not currently support byte fields
• The GUI has been tested only on Windows 10/11 x64
• The application and this documentation are under development

• New features

  • Color customization with live preview
  • Resizable field and log panels
  • Drag-and-drop support for transactions and configuration data
  • Undo and redo in the complex field constructor
  • Specification recovery from backups
  • Version-specific guided tour of interface changes
  • Application-wide debug logging
  • Error dialog with a stack trace for unexpected errors

• Updates

  • Improved interface, keyboard navigation and error reporting
  • Consistent configuration updates across GUI and API
  • Core code cleanup and reliability improvements

• Fixed

  • TCP message handling and response matching
  • Configuration and specification saving issues
  • Various editing, display and connection shutdown issues

Signal's central concept is a shared transaction-processing core, accessible through three interfaces: GUI, CLI, and HTTP API. The interface determines how you give Signal instructions and receive results. The core provides the transaction handling behind those instructions: field generation and validation, ISO 8583 encoding and decoding, host communication, and tracking requests and responses.

The processing host does not need to know whether a transaction originated in the GUI, CLI, or API. It receives an ISO 8583 message from Signal and returns its response over the host connection. The core decodes that response and matches it to the request; the interface determines how the result is presented or returned.

The diagram shows the interfaces of a single Signal instance. The HTTP API has its own request/response interface, but it is hosted within a GUI or CLI process. Dashed arrows labelled Start API show that either launch mode can start the API; solid arrows show transaction requests and results through the shared core. In GUI mode, the window and API can work concurrently. In CLI mode, Signal either executes transaction commands or hosts the API with --api-mode. All paths use the same host connection; the diagram does not imply that GUI and CLI command execution run together in one process.

Each interface receives work from a client. A GUI user gives individual commands through the window and its tools, with feedback after each action. A CLI user or script supplies launch options and input files; Signal uses those instructions to assemble and execute a job. An API client supplies HTTP requests.

The GUI and CLI have different lifecycles. The GUI is an ongoing workspace for a person: you prepare a transaction, send it, inspect the result, and continue working. Completing an operation does not close the application; the window remains available for the next user action. When enabled, the API can handle requests alongside that interactive work.

The CLI executes a job defined by its launch options. It takes the supplied parameters and transaction files, performs the requested work, and normally exits when that work is complete, including any required response waits. Each run has a CLI Job ID, recorded in its begin and finish log markers. A CLI job can contain one transaction or a sequence of transactions; it is not a persistent interactive workspace.

Some jobs are deliberately long-running: --repeat continues processing transactions, while --api-mode keeps Signal available for HTTP requests. These jobs remain active until stopped, typically with Ctrl + C. They retain the same Job ID for the entire run.

The core uses the active configuration and specification to interpret transaction data and communicate with the processing host. Its shared capabilities include:

• Generating field values and checking transactions against specification rules.
• Encoding transactions into ISO 8583 messages and decoding incoming messages, including complex fields.
• Maintaining the host connection, sending messages, tracking transactions, and matching responses to requests.
• Supporting reversals, keep-alive sending, and logging.

For example, an operator can prepare a purchase in the GUI, a script can submit a transaction file through the CLI, or an API client can post a Transaction JSON object. Each route reaches the same underlying transaction-processing capabilities. The interface still matters: available controls, validation triggers, and the way results are presented differ. See When validation runs for those distinctions.

The API operates within a running Signal instance. You can enable it alongside the GUI or start it through CLI API mode. It uses that instance's active configuration, specification, host connection, and transaction queue.

For example, if Signal is running with the GUI and API enabled, an API request to disconnect the processing host affects the connection used by that GUI. The API is a way to operate the same application, not a separate connection to the processor. In CLI API mode, this relationship is unchanged; the application simply runs without its graphical window.

The HTTP API and the host connection are different links: an API client talks to Signal over HTTP, while Signal exchanges ISO 8583 messages with the processing host over TCP. Starting another Signal process creates another running instance; it does not attach a CLI to an already open GUI.

This shared-core design describes how the application works today. Direct use as a Python library is being reworked and is not presented here as an additional supported interface.

The GUI is Signal's interactive workspace for preparing, sending, and investigating test transactions. You can build a message field by field, load an existing example, change a few values, and examine the response without writing a script or making API requests. The window remains open after each operation so that you can continue testing.

Start signal.exe to open the GUI. Before sending, configure the processing host through Tools → Settings and make sure the active specification matches that host. A supplied transaction is a starting point; its merchant, terminal, and card data may need to be adjusted for your test environment.

1. Open Tools → Settings and check the processing host address and port. Review the specification settings if your environment uses a different specification.
2. Use Open file to load a prepared transaction, or work with the default message already displayed. Select the intended message type (MTI).
3. Review the field values and Generate selections. Disable fields you want to omit from this test and check any complex fields.
4. Choose Message → Validate to check the current fields. Read any findings in the table and log before continuing.
5. Use [Re]connect if needed and check the connection indicator. Echo-Test can be used to test a message exchange with the configured host.
6. Select Send, or press Ctrl + Enter, to send the active tab's transaction. Inspect the response and any errors in the log.
7. Adjust the message for the next test, or use Save file to keep a reusable copy.

A connection indicator confirms the connection state, not the outcome of a financial transaction. Likewise, successful sending does not mean that the host approved the transaction: inspect the response code and response fields.

The main window brings message preparation and transaction diagnostics into one workspace.

Drag the divider between the field table and log panel to give more space to the part you are working with. Signal saves the panel proportions for later use.

Use the + control to create another transaction tab. Double-click a tab name to rename it, for example to Visa Purchase or MasterCard Payout. The Main tab stays available; additional tabs can be closed with their close controls.

Select the intended tab before editing or sending: Send uses the current tab's message. Tabs are separate message workspaces within one Signal instance, not separate connections to the processing host. Changing the host configuration affects the instance as a whole.

Saving is explicit. Use Save file to preserve a message you want to reuse; leaving it open in a tab is not a substitute for saving a transaction file.

The field table shows field numbers, values, lengths, specification descriptions, and properties such as Generate or JSON mode. Expand a complex field to inspect its nested subfields. Length displays help you see the effect of edits, while the specification determines the permitted content and encoding.

Use Message → Reset to reload the default message and Message → Clear to clear the editor. Save any message you need before replacing it.

Press Ctrl + F to focus the search line. Search by field number, value, or description to narrow the visible tree. Clear the search text to show all fields again.

Search changes what is visible, not what is sent. A field hidden by the search filter is still part of the message unless it is disabled or removed.

Select Generate for supported fields whose values should be created automatically when sending. This is useful for timestamps, trace numbers, retrieval references, and other values that vary between transactions. Leave generation off when the test requires an exact value.

Signal generates the selected values during sending and updates the GUI with the generated data. Consequently, a generated value can differ from the value displayed before you pressed Send. The active specification and field settings determine which generation behavior is available.

Automatic validation can highlight problems while you edit or prevent sending when an error is found. Its behavior depends on the validation settings and mode. For an explicit check, use Message → Validate or Ctrl + Alt + V; this checks enabled fields even when automatic checks are disabled.

Validation checks message data against Signal's rules. It does not predict the host's financial decision. See Field validation for the checks, severity modes, and differences between editing and sending.

Open Tools → Construct field when you need to inspect or build the contents of a complex field separately. The constructor lets you work with nested field data and its encoded string representation using the active specification.

The example shows field 47 — Proprietary Data Field. The upper tree contains its subfields, including the nested 227 — Service Location group. The lower pane contains the encoded string representation. Use To String to build the string from the tree, or To JSON to parse the string into the tree. The field selector at the top determines which field you are working with.

Use Field Data → Get from main window to bring field data into the constructor. After editing and reviewing it, use Field Data → Apply to main window to transfer the result back. Working in the constructor is a preparation step; applying a field does not send a transaction.

This is especially useful for deeply nested data such as field 47, where tag widths and length prefixes are difficult to maintain by hand. See Complex fields representation for how nested values are interpreted.

Send prepares the active transaction, generates selected fields, performs the configured outgoing checks, and passes the message to the shared core for sending. An error can stop the operation before anything reaches the host; the log explains the failure.

After sending, follow the transaction ID and the received response in the log. Review the response MTI, response code, and relevant field values. When troubleshooting, keep the surrounding connection and validation messages as well as the transaction data.

The Log menu provides Clear log and Copy log. Clearing the panel does not erase the stored log file. See Logging for file storage, detail levels, and browser-based live viewing.

The Reverse menu provides three workflows:

For Other and Set reversal fields, the dialog lets you enter the original transaction ID in the upper field or select a transaction from the session queue below. Queue entries show the transaction ID and UTRNNO to help identify the original exchange. The ID identifies the original transaction, not the new reversal.

Select OK to continue with the action you chose: Other builds and sends the reversal, while Set reversal fields places the prepared data in the editor. Cancel closes the dialog without proceeding.

A reversal depends on the original transaction and the reversal definitions in the active specification. It is a new exchange with the host, not an editor undo action. If Signal cannot find a suitable original transaction or reversal MTI, it reports the problem instead of sending.

Repeat schedules repeated transaction sending using the selected interval. This is useful when testing repeated requests without pressing Send each time. Stop repetition through its menu when the test is complete; the GUI remains open for further work.

Keep alive controls separate keep-alive sending, using its own template and interval. Echo-Test sends an explicit connection-test message. These controls serve different purposes from repeating a financial transaction; they do not establish that a purchase will be approved.

The supplied message templates are described under Default messages.

Use Open file to load saved transactions. You can also drop transaction files or supported transaction text onto the transaction editor. Use the normal file controls when choosing an explicit file format or destination.

Save file can save the current tab or export all tabs in JSON, INI, or DUMP format. Use JSON when you want a structured, reusable transaction example. The Print menu displays message representations and other diagnostic data in the output panel; printing a representation does not send the message or save a file.

See Transaction data files for file formats and Data models for JSON structures.

Use Tools → API → Start, Stop, or Restart to control the HTTP API. When it is running, Help → API Specification opens its interactive documentation.

The window remains usable while the API handles requests. Both operate on the same Signal instance: for example, disconnecting the processing host through the API also changes the connection available to the GUI. See How Signal works and HTTP Transaction API.

This workflow uses the GUI to complete one test and preserve its results. Use transaction data and a specification appropriate to your test host; the Transaction example illustrates a financial purchase with nested field 47.

1. Prepare the purchase. Open your purchase JSON file in a tab and give the tab a descriptive name. Verify MTI 0200, the purchase processing code, amount, currency, and terminal and merchant data. Review the generation selections before sending.
2. Validate and connect. Use Message → Validate, resolve relevant findings, and verify the host connection. A connection alone does not establish that the message data is correct.
3. Send once. Press Send and note the transaction ID in the log. Read the matched host response and its response code. If the host does not respond, investigate the connection and timeout messages before deciding whether to send another request.
4. Prepare the reversal. If the transaction is eligible for reversal in the active specification, use Reverse → Set reversal fields, select the original transaction, and confirm. Signal loads the reversal into the editor so that you can inspect it before sending. Save the purchase template before replacing its editor contents if you need to keep it.
5. Send and inspect the reversal. Review the generated reversal fields, then press Send. Examine the reversal's own host response; the original response does not establish that the reversal succeeded.
6. Preserve the test. Save reusable transaction inputs with Save file and copy or retain the log showing both exchanges. Record the configuration and specification used if the test needs to be reproducible.

This sequence is a test procedure, not a guarantee of approval or reversal success. Those outcomes are determined by the processing host.

Open Tools → Specification to inspect the rules behind the transaction editor: field definitions, complex-field structure, allowed values, generation properties, and message types. This is where you adapt Signal to a specification, rather than edit the data of a particular transaction.

The editor supports read-only inspection, searching, field and MTI settings, loading specifications, and backups. Changes to the draft are installed only when applied. See Specification settings for the complete workflow, including session-only and permanent application and recovery from backups.

Open Tools → Settings to configure the application. The tabs group general connection and startup settings, field behavior, specification settings, API settings, and appearance.

The General tab shown here groups three kinds of settings:

The values shown are an example configuration, not a list of required defaults. Use the other tabs for Fields, Specification, API, and Theme settings.

Settings govern the running application rather than a single transaction tab. Review them when moving to another processing environment or changing validation, generation, logging, or API behavior. The Theme tab provides a preview for appearance changes. See Configuration for the saved configuration and individual options.

The Fields tab separates message preparation from validation. Its upper group controls how Signal generates and presents transaction data:

The lower Validation group controls automatic checks. Data validation enabled is the common switch; the next three checkboxes select checks while editing, before sending, and after receiving. Violation processing mode determines how findings are classified. See When validation runs and Violation mode for the precise behavior, including manual and API checks.

The screenshot shows one selected configuration, not mandatory or default values.

For a shortcut reference covering the main window and its editors, use Help → Hotkeys or the table below.

Shortcuts apply to the active window. A dash means that no application shortcut is assigned in that window.

In the Configuration window, use Ctrl + PgDn and Ctrl + PgUp to switch to the next or previous tab.

When editing transaction fields in the Main Window or Complex Field Constructor, Tab and Shift + Tab commit the current edit and move to the next or previous editable field number or value.

In the Specification Window:

• Arrow keys move between cells.
• Tab / Shift + Tab move between editable cells and checkbox options, committing any active edit.
• Enter / F2 start editing the selected text cell. Typing also starts an edit.
• Space toggles the selected checkbox when the option is editable.

Signal has a built-in HTTP web API for managing transactions, configuring the application, and retrieving information.

The API is supported by both the command-line and graphical user interfaces. It runs in a separate thread, so you can use the GUI and API at the same time.

To run the API without the GUI and control Signal remotely, see Running and controlling Signal through the API.

Paths are relative to the running Signal API server. Send JSON request bodies with Content-Type: application/json.

*In immediate-response mode (api.wait_remote_host_response = false), transaction endpoints return only a transport-level acceptance status and the request ID, not the transaction result from the remote host. With response waiting enabled, Signal returns the host response if the specification defines a response MTI; otherwise, it returns the same acceptance message.

See the interactive documentation at /openapi for request and response schemas.

For error bodies, see API operation errors and request validation errors.

Signal includes Swagger UI for browsing the API endpoints, inspecting request and response schemas, and sending requests directly from your browser.

Start Signal with the API enabled, then open http://127.0.0.1:7777/openapi on the same computer. If you use a different API port, replace 7777 with the configured port. To access another Signal instance, replace 127.0.0.1 with that computer's reachable address.

1. Expand an endpoint. For a first check, use GET /api/connection to inspect the connection status.
2. Select Try it out.
3. Enter any required parameters or request body. For transaction requests, see the Data models for examples.
4. Select Execute. Swagger UI displays the request URL, HTTP response code, and response body.

Requests run against the active Signal instance. Sending a transaction or changing configuration here has the same effect as calling that endpoint from another API client.

Swagger UI reads the OpenAPI schema served by the running application at /openapi.json. For a compact endpoint summary, see Short API reference. The separate /api/documentation endpoint serves the user guide.

Signal provides a Postman collection and an accompanying environment for working with its HTTP API:

The files are distributed together in an archive in common/data/postman; see Postman files in Data storage.

The supplied collection and environment are legacy resources that need to be updated and verified against Signal v0.21. Until then, use the Short API reference for the documented endpoints, request bodies, and responses.

CLI mode sends transactions from files or runs the HTTP API without opening the GUI. Run commands from the Signal application directory so that relative configuration, data and resource paths resolve correctly.

Start CLI commands with signal.exe --console or signal.exe -c, followed by the required options. Other operating options do not select CLI mode on their own; without a console-mode argument, Signal starts the GUI. All command examples below explicitly select CLI mode.

signal.exe --console [options]
signal.exe --console --help

In PowerShell, use ./signal.exe when running the executable from the current directory. The commands below use signal.exe, as in Command Prompt or when the executable is on PATH. Quote paths containing spaces and filename patterns.

Keep -c as a separate argument: the launcher looks for an exact -c or --console token. Use signal.exe -c -r -i 2, not signal.exe -cri 2. Long options are recommended for readable scripts.

usage: signal.exe [-h] -c [-d DIR] [-a ADDRESS] [-p PORT] [-r]
                  [--log-file LOG_FILE] [-l LOG_LEVEL] [--no-print]
                  [-i INTERVAL] [--parallel] [--config-file CONFIG_FILE]
                  [-f FILE] [-t TIMEOUT] [--about] [-e] [--default] [-v]
                  [--print-config] [--api-mode] [-s SPECIFICATION]

Signal v0.21

options:
  -h, --help            show this help message and exit
  -c, --console         Run Signal in Command Line Interface mode
  -d DIR, --dir DIR     Directory with transaction files to parse. Signal will
                        try to parse them one by one
  -a ADDRESS, --address ADDRESS
                        Host TCP/IP address
  -p PORT, --port PORT  TCP/IP port to connect to
  -r, --repeat          Repeat transactions after sending
  --log-file LOG_FILE   Set log file path. Default common/log/signal.log
  -l LOG_LEVEL, --log-level LOG_LEVEL
                        Debug level: DEBUG, INFO, WARNING, ERROR, CRITICAL,
                        NOTSET. Uses the configuration value when omitted
  --no-print            Do not print the log to the screen
  -i INTERVAL, --interval INTERVAL
                        Wait time in seconds before sending the next
                        transaction
  --parallel            Send transactions without waiting for previous
                        responses
  --config-file CONFIG_FILE
                        Set configuration file path
  -f FILE, --file FILE  File or filename pattern to parse
  -t TIMEOUT, --timeout TIMEOUT
                        Response timeout in seconds
  --about               Show information about Signal
  -e, --echo-test       Send echo-test
  --default             Send default transaction message
  -v, --version         Print current version of Signal
  --print-config        Print configuration parameters
  --api-mode            Run Signal in API mode
  -s SPECIFICATION, --specification SPECIFICATION
                        Set the path to a custom specification JSON file

• --file, --dir, --default and --echo-test select the input files. These options can be combined. Without an input option, Signal sends no transactions.
• Directory and pattern matches are collected once at startup. Their processing order is not guaranteed. If order matters, run individual file commands in the required sequence.
• A file that cannot be parsed is logged and skipped. An unmatched filename pattern contributes no files.
• By default, Signal waits for a matching response before proceeding to the next file. No response wait is performed for an MTI without a defined response. --interval adds a delay after this wait, so it is not a fixed request rate.
• --parallel skips the per-transaction response wait. Signal can finish after the last send without waiting for outstanding responses; use sequential mode when each response must be collected.
• --repeat reprocesses the selected files until Ctrl+C is pressed. Do not combine it with --api-mode.
• In API mode, Signal skips file processing and remains available for HTTP requests. --address and --port select the processing host, not the API listener. API settings are described in ApiModel.

Signal loads --config-file before constructing the CLI. Address, port and log-level overrides apply only to the running process and do not rewrite that configuration file. --print-config shows the effective configuration, including these overrides.

A custom --specification is applied in memory. If it cannot be loaded, Signal logs the error and continues with the default specification. Check the log before relying on a custom specification in an automated scenario.

License acceptance may be requested on first use, including in CLI mode. --no-print does not bypass that prompt. Use information options (--about, --version, --print-config) one at a time; they do not prevent file processing or API startup if those options are also supplied.

CLI API mode runs Signal without the graphical interface and lets you operate that same Signal instance through HTTP requests. The CLI starts the application; the API then provides controls for its host connection, configuration, specification, and transactions.

Run this command from the Signal application directory:

signal.exe --console --api-mode

Complete the license acceptance prompt if it appears. Once the API has started, leave this console running and use another terminal, a browser with Swagger UI, or an API client to interact with Signal.

This is a long-running CLI job. It remains active between requests and does not exit after sending a transaction. Press Ctrl + C in the original console to stop it.

The API listener uses api.address and api.port from the configuration. With the default port, its local URL is http://127.0.0.1:7777. To use a separate saved configuration:

signal.exe --console --api-mode --config-file "C:/Signal/config/test.json"

The CLI options --address and --port configure the transaction-processing host, not the HTTP API listener. The two connections serve different purposes: your API client sends HTTP requests to Signal, and Signal sends ISO 8583 transactions to the processing host.

In API mode, file-processing options such as --file, --dir, and --default do not send transactions at startup; Signal skips that work and waits for API requests. Do not combine --api-mode with --repeat.

The following examples use curl.exe from a second Windows terminal and the default local API address. Replace the address and port if your API configuration differs.

First, inspect the connection to the transaction-processing host:

curl.exe "http://127.0.0.1:7777/api/connection"

To connect to the host using Signal's current connection settings:

curl.exe -X POST "http://127.0.0.1:7777/api/connection/open"

Then submit a financial transaction from a file containing a valid Transaction:

curl.exe -X POST "http://127.0.0.1:7777/api/transactions" -H "Content-Type: application/json" --data-binary "@C:/transactions/purchase.json"

The response depends on api.wait_remote_host_response: Signal either waits for the host response or returns an acceptance message. An acceptance message does not establish that the host approved the transaction; see Short API reference.

You can continue managing this instance without restarting the CLI job:

For configuration changes, retrieve the current configuration, edit the returned JSON, and submit the complete Config object with PUT /api/config. This replaces the configuration rather than patching individual fields, and accepted changes are saved to the active configuration file. See the API reference for request models and responses for all operations.

Disconnecting the processing host leaves the API server running. You can reconnect through the API later. There is no API endpoint for terminating the CLI process; stop the job with Ctrl + C in its console.

By default, Signal writes logs to the console and common/log/signal.log. The log level comes from the configuration unless --log-level is supplied. Use --log-file to choose another destination or --no-print to suppress console logging.

The log includes a command-line job ID in its begin/finish markers, transaction IDs, connection events and processing errors. DEBUG output also includes diagnostic operation details. --version and --print-config use INFO logging and can be hidden by a higher log level or --no-print.

A CLI job is one execution of Signal in command-line mode: from starting the application with a command to finishing that run. The job includes the work requested by that command, such as loading a transaction file, connecting to the host, sending the transaction, and waiting for its response. One job can process one transaction or multiple transactions.

A job can be a short command that finishes automatically, or a long-running process that stays active until you stop it with Ctrl + C:

All three are CLI jobs. A job's lifetime covers the entire run, however short or long it is.

Each CLI job has a unique Job ID, generated automatically as a UUID. Signal writes this ID at the beginning of the job in a Begin log message and repeats the same ID at the end in a Finish message. A new command-line process gets a new Job ID; you do not need to supply one.

Suppose C:/transactions/purchase.json contains a financial transaction using the Transaction model. Run the following command from the Signal application directory:

signal.exe --console --file "C:/transactions/purchase.json" --log-level INFO

This starts one CLI job. Signal loads the file and, if validation and the connection allow it, sends the transaction to the configured host and waits for a response or timeout before finishing.

The following abbreviated log illustrates the job boundaries and the transaction processed within them. Other messages, including connection events and the response or any errors, are omitted:

2026-09-13 00:41:12.084 | [INFO]    | ## Begin command line job ID e21ab311-5912-4b58-83b4-6ee7f5ee2270 ##
...
Processing file purchase.json
Processing transaction ID [20260913_004112_123456789]
... transaction processing and response messages ...
2026-09-13 00:41:13.545 | [INFO]    | ## Finish command line job ID e21ab311-5912-4b58-83b4-6ee7f5ee2270 ##

The matching UUIDs show where this job starts and ends. The Transaction ID identifies the individual transaction inside the job. If the command processes several files, their transaction IDs appear within the same job boundaries.

To investigate a run, search the log for its Job ID and read the messages between its Begin and Finish markers. The Job ID appears in these boundary messages, not on every log line.

With --repeat, all repetition cycles belong to the same job and keep the same Job ID until the process stops. With --api-mode, the job is the CLI run hosting the API; individual HTTP requests do not start new CLI jobs.

Finish means that the CLI job ended, not that every transaction succeeded. Check the transaction responses and errors to determine the result. A run interrupted with Ctrl + C can also write a finish marker during shutdown. A forced termination or an early startup failure may leave no finish marker.

Both boundary messages use the INFO log level, so a higher threshold can hide them. --no-print suppresses console output but does not itself disable file logging. By default, look in common/log/signal.log, or in the file selected with --log-file. If you run multiple Signal processes concurrently, use a separate log file for each to keep their messages from interleaving.

python -c 'from common.core.toolkit.sv_emulator import SvEmulator, IsoConfig; SvEmulator(IsoConfig(ADDRESS="127.0.0.1", PORT=16678)).run()'

{
  "message_type": "0200",
  "generate_fields": [
    "7",
    "11",
    "12",
    "37"
  ],
  "data_fields": {
    "2": "4111111111111111",
    "3": "000000",
    "4": "000000001250",
    "7": "0912164500",
    "11": "123456",
    "12": "260912164500",
    "14": "2912",
    "18": "8999",
    "22": "810",
    "37": "123456789012",
    "41": "70000826",
    "42": "000000010000866",
    "43": "TEST SHOP                   >Limassol>CY",
    "47": {
      "033": "5",
      "227": {
        "01": "Limassol",
        "03": "CYP",
        "04": "3101"
      }
    },
    "49": "978"
  }
}

.\signal.exe --console --file purchase.json --address 127.0.0.1 --port 16678 --timeout 10 --log-level INFO --log-file cli-purchase.log

& 'C:/Users/admin/AppData/Local/Programs/Python/Python312/python.exe' '-c' 'from common import signal' '--console' '--config-file' 'C:\Users\admin\Documents\Codex\2026-09-09\new-chat\work\cli-example\config.json' '--file' 'C:\Users\admin\Documents\Codex\2026-09-09\new-chat\work\cli-example\purchase.json' '--address' '127.0.0.1' '--port' '16678' '--timeout' '10' '--log-level' 'INFO' '--log-file' 'C:\Users\admin\Documents\Codex\2026-09-09\new-chat\work\cli-example\transaction.log'

13.09.2026 09:47:05 [INFO] Press CTRL+C to exit
13.09.2026 09:47:05 [INFO] 
13.09.2026 09:47:05 [INFO] ## Begin command line job ID 0b09be13-c5c4-4b1f-9ee8-5eaf8cc85ccc ##
13.09.2026 09:47:05 [INFO] 
13.09.2026 09:47:05 [INFO] Processing file purchase.json
13.09.2026 09:47:05 [INFO] Processing transaction ID [20260913_094705_4414127154]
13.09.2026 09:47:05 [WARNING] Host disconnected. Trying to establish the connection
13.09.2026 09:47:05 [INFO] Connecting to 127.0.0.1:16678
13.09.2026 09:47:05 [INFO] Connection ESTABLISHED
13.09.2026 09:47:05 [INFO] 
13.09.2026 09:47:05 [INFO] [TRANS_ID][20260913_094705_4414127154]
13.09.2026 09:47:05 [INFO] [MSG_TYPE][0200]
13.09.2026 09:47:05 [INFO] [BITMAP  ][2, 3, 4, 7, 11, 12, 14, 18, 22, 37, 41, 42, 43, 47, 49]
13.09.2026 09:47:05 [INFO] [Primary Account Number                      ][002][016][411111••••••1111]
13.09.2026 09:47:05 [INFO] [Processing code                             ][003][006][000000]
13.09.2026 09:47:05 [INFO] [Transaction amount                          ][004][012][000000001250]
13.09.2026 09:47:05 [INFO] [Transmission date and time MMDDhhmmss       ][007][010][0913094705]
13.09.2026 09:47:05 [INFO] [System Trace Audit Number                   ][011][006][036217]
13.09.2026 09:47:05 [INFO] [Transaction local date and time YYMMDDhhmmss][012][012][260913094705]
13.09.2026 09:47:05 [INFO] [Primary account number expiration date YYMM ][014][004][••••]
13.09.2026 09:47:05 [INFO] [Merchant Category Code                      ][018][004][8999]
13.09.2026 09:47:05 [INFO] [Point of Service Date Code                  ][022][003][810]
13.09.2026 09:47:05 [INFO] [Retrieval Reference Number                  ][037][012][022835964681]
13.09.2026 09:47:05 [INFO] [Card Acceptor Terminal Identification       ][041][008][70000826]
13.09.2026 09:47:05 [INFO] [Merchant Identification                     ][042][015][000000010000866]
13.09.2026 09:47:05 [INFO] [Card Acceptor Name and Location             ][043][040][TEST SHOP                   >Limassol>CY]
13.09.2026 09:47:05 [INFO] [Proprietary Data Field                      ][047][072][03300152270270108Limassol0303CYP0404310107202620260913_094705_4414127154]
13.09.2026 09:47:05 [INFO] [Pos Cardholder presence                     ][047.033][001][5]
13.09.2026 09:47:05 [INFO] [Service Location City Name                  ][047.227.01][008][Limassol]
13.09.2026 09:47:05 [INFO] [Service Location Country                    ][047.227.03][003][CYP]
13.09.2026 09:47:05 [INFO] [Service Location Postal Code                ][047.227.04][004][3101]
13.09.2026 09:47:05 [INFO] [External Transaction ID                     ][047.072][026][20260913_094705_4414127154]
13.09.2026 09:47:05 [INFO] [Transaction currency code                   ][049][003][978]
13.09.2026 09:47:05 [INFO] 
13.09.2026 09:47:05 [INFO] Outgoing transaction ID [20260913_094705_4414127154] sent
13.09.2026 09:47:05 [INFO] 
13.09.2026 09:47:06 [INFO] Incoming transaction ID [20260913_094705_4414127154] received
13.09.2026 09:47:06 [INFO] 
13.09.2026 09:47:06 [INFO] [TRANS_ID][20260913_094706_0711034337]
13.09.2026 09:47:06 [INFO] [UTRNNO  ][165406721]
13.09.2026 09:47:06 [INFO] [MSG_TYPE][0210]
13.09.2026 09:47:06 [INFO] [BITMAP  ][2, 3, 4, 7, 11, 12, 14, 18, 22, 37, 38, 39, 41, 42, 43, 47, 49]
13.09.2026 09:47:06 [INFO] [Primary Account Number                      ][002][016][411111••••••1111]
13.09.2026 09:47:06 [INFO] [Processing code                             ][003][006][000000]
13.09.2026 09:47:06 [INFO] [Transaction amount                          ][004][012][000000001250]
13.09.2026 09:47:06 [INFO] [Transmission date and time MMDDhhmmss       ][007][010][0913094705]
13.09.2026 09:47:06 [INFO] [System Trace Audit Number                   ][011][006][036217]
13.09.2026 09:47:06 [INFO] [Transaction local date and time YYMMDDhhmmss][012][012][260913094705]
13.09.2026 09:47:06 [INFO] [Primary account number expiration date YYMM ][014][004][••••]
13.09.2026 09:47:06 [INFO] [Merchant Category Code                      ][018][004][8999]
13.09.2026 09:47:06 [INFO] [Point of Service Date Code                  ][022][003][810]
13.09.2026 09:47:06 [INFO] [Retrieval Reference Number                  ][037][012][022835964681]
13.09.2026 09:47:06 [INFO] [Authorization ID code                       ][038][006][3MGRP2]
13.09.2026 09:47:06 [INFO] [Authorization response code                 ][039][002][00]
13.09.2026 09:47:06 [INFO] [Card Acceptor Terminal Identification       ][041][008][70000826]
13.09.2026 09:47:06 [INFO] [Merchant Identification                     ][042][015][000000010000866]
13.09.2026 09:47:06 [INFO] [Card Acceptor Name and Location             ][043][040][TEST SHOP                   >Limassol>CY]
13.09.2026 09:47:06 [INFO] [Proprietary Data Field                      ][047][087][03300152270270108Limassol0303CYP0404310107202620260913_094705_4414127154064009165406721]
13.09.2026 09:47:06 [INFO] [Pos Cardholder presence                     ][047.033][001][5]
13.09.2026 09:47:06 [INFO] [Service Location City Name                  ][047.227.01][008][Limassol]
13.09.2026 09:47:06 [INFO] [Service Location Country                    ][047.227.03][003][CYP]
13.09.2026 09:47:06 [INFO] [Service Location Postal Code                ][047.227.04][004][3101]
13.09.2026 09:47:06 [INFO] [External Transaction ID                     ][047.072][026][20260913_094705_4414127154]
13.09.2026 09:47:06 [INFO] [SVFE UTRNNO Unic Transaction Number         ][047.064][009][165406721]
13.09.2026 09:47:06 [INFO] [Transaction currency code                   ][049][003][978]
13.09.2026 09:47:06 [INFO] 
13.09.2026 09:47:06 [INFO] Transaction ID [20260913_094705_4414127154] matched, response time seconds: 1.164
13.09.2026 09:47:06 [INFO] Connection DISCONNECTED
13.09.2026 09:47:06 [INFO] ## Finish command line job ID 0b09be13-c5c4-4b1f-9ee8-5eaf8cc85ccc ##

Signal v0.21 | Sep 2026

Use only on test environment

  Version v0.21

  Released in Sep 2026

  Developed by Fedor Ivanov

  Contact fedornivanov@gmail.com

signal.exe --console --print-config logs the selected configuration path and the current JSON configuration between the Configuration parameters and End of configuration parameters markers. See Config for its structure and a complete JSON example.

Press Ctrl+C to stop a running batch or API session. Signal stops its timers, closes the host connection and stops the API before exiting. A normal CLI run returns 0; Ctrl+C returns 130. Startup/configuration failures can return 100, and argument-parser errors return 2. A zero exit code alone does not prove that every transaction succeeded: parsing and transaction errors can be logged without changing the final exit code. Check the transaction results and log as well.

The Signal library functionality is currently being reworked and will be available in future versions. The previous documentation is retained below as a historical archive. It is not a supported integration guide for v0.21; do not use its code examples as current implementation instructions.

from common.core.data_models.Config import Config
from common.core.enums.TermFilesPath import TermFilesPath
from common.core.tools.Terminal import Terminal
from common.core.data_models.Transaction import Transaction
from common.core.tools.FieldsGenerator import FieldsGenerator

"""
The Signal library minimal code example - sends the single transaction from the default file

This script does not run QApplication and QEventLoop. Due to that, the script cannot wait for the answer, also the 
signal-slot model cannot be used

The code examples is ready to begin without any changes
"""

# Create Config object. The Config is a crucial data object, contains basic settings for all the application
config: Config = Config.parse_file(TermFilesPath.CONFIG)
# After the config is created you can set the parameters as you prefer
# e.g.: config.host.port = 16677 and so on

# The Terminal - toolkit of the application, which will be used for sending the transaction
terminal: Terminal = Terminal(config)

# This object will update transaction fields to avoid transaction duplicates
data_generator = FieldsGenerator()

# Parse default transaction file
transaction: Transaction = Transaction.parse_file(TermFilesPath.DEFAULT_FILE)

# Update fields dynamic values such as ID, date and so on
transaction: Transaction = data_generator.set_generated_fields(transaction)

# Send the previously-made transaction to the host
terminal.send(transaction)

# exit

from PyQt6.QtCore import QCoreApplication, QTimer
from common.core.data_models.Config import Config
from common.core.enums.TermFilesPath import TermFilesPath
from common.core.tools.Terminal import Terminal
from common.core.data_models.Transaction import Transaction
from common.core.tools.FieldsGenerator import FieldsGenerator
from common.core.tools.Logger import Logger

"""
A bit more complex example, with usage PyQt6 features, logging, and so on

This script not runs QApplication and QEventLoop. Due to that, the script will wait for the answer, also the 
signal-slot model can be used
 
This example illustrates the creation of the PyQt application, which is run and ready for interaction in PyQt style

The code examples is ready to begin without any changes
"""

# The objects preparation

# In case when your solution does not use GUI it is required to create QCoreApplication and set in on the Terminal
application = QCoreApplication([])  # Create the Signal PyQt application

# Create Config object. The Config is a crucial data object, contains basic settings for all the application
config: Config = Config.parse_file(TermFilesPath.CONFIG)
# After the config is created you can set the parameters as you prefer
# e.g.: config.host.port = 16677 and so on

# The Terminal - toolkit of the application, which will be used for sending the transaction
terminal: Terminal = Terminal(config=config, application=application)  # Send previously-made QCoreApplication

# Set the default screen logger up
Logger().create_logger()

# This object will update transaction fields to avoid transaction duplicates
data_generator = FieldsGenerator()

# Parse default transaction file
transaction: Transaction = Transaction.parse_file(TermFilesPath.DEFAULT_FILE)

# Update fields dynamic values such as ID, date and so on
transaction: Transaction = data_generator.set_generated_fields(transaction)

# Create a delayed start timer. This workaround will help to begin the task after the application is started
timer = QTimer()  # This timer will be processed in QEventloop right after the application is executed
timer.setSingleShot(True)  # It signals once the application start
timer.timeout.connect(lambda: terminal.send(transaction))  # Transaction will be one of the first events
timer.start(0)  # Signals timeout immediately

# Finally run the application, which begin the QEventloop and send the transaction
# Due to the part below the application proceed to work, processing PyQt events and signals
terminal.run()  # Run the QCoreApplication

Signal uses Pydantic models to parse, validate and serialize API data. These models define the expected fields, types and validation rules. See the official Pydantic documentation on models for details.

Data models define the fields, value types and structure that Signal accepts or returns through the API. Most request and response bodies are JSON. Nested models describe objects inside a larger request, not separate endpoints. The tables below distinguish required fields from optional fields and show model defaults; these defaults may differ from the values in your saved configuration.

Examples are valid model data. Transaction validation also depends on the active ISO specification. Response-only models are illustrated with response bodies, not input requests.

Request body for sending, conversion and validation; also the transaction response model. The example is a financial purchase request (MTI 0200) for EUR 12.50 using a test card number. Use strings for field values, including numeric values. Request and response examples follow the same schema, but runtime fields need not be supplied by the caller. API output may omit internal fields and may mask secrets or expand subfields according to the API configuration.

{
  "message_type": "0200",
  "generate_fields": [
    "7",
    "11",
    "12",
    "37"
  ],
  "data_fields": {
    "2": "4111111111111111",
    "3": "000000",
    "4": "000000001250",
    "7": "0912164500",
    "11": "123456",
    "12": "260912164500",
    "14": "2912",
    "18": "8999",
    "22": "810",
    "37": "123456789012",
    "41": "70000826",
    "42": "000000010000866",
    "43": "TEST SHOP                   >Limassol>CY",
    "47": {
      "033": "5",
      "227": {
        "01": "Limassol",
        "03": "CYP",
        "04": "3101"
      }
    },
    "49": "978"
  }
}

Response only: acknowledgement used when Signal does not wait for a host response. The request ID is not the transaction ID.

{
  "status": "Transaction request successfully accepted. Request ID: 5eeeaed2-b21d-4d77-aabf-52c595f64035"
}

Request body for opening or restarting a connection, and response body for connection endpoints. Send only host and port to select a destination; the status in the example illustrates a response. An omitted body uses configured connection settings.

{
  "host": "127.0.0.1",
  "port": 16677
}

{
  "host": "127.0.0.1",
  "port": 16677,
  "status": "Connected"
}

Full configuration object used by GET and PUT /api/config. PUT replaces the configuration; it is not a partial update. Retrieve the current object, edit the required values and send it back. The example is a complete configuration. Changing API listen settings requires an API restart; a new processing host takes effect on the next connection.

{
  "host": {
    "host": "127.0.0.1",
    "port": 16677,
    "keep_alive_mode": false,
    "keep_alive_interval": 300,
    "header_length": 2,
    "header_length_exists": true
  },
  "terminal": {
    "process_default_dump": true,
    "connect_on_startup": true,
    "load_remote_spec": false,
    "show_license_dialog": false,
    "run_api": true
  },
  "debug": {
    "level": "INFO",
    "clear_log": true,
    "parse_subfields": true,
    "backup_storage_depth": 10,
    "backup_storage_depth_exists": true,
    "reduce_keep_alive": true,
    "print_description": true
  },
  "validation": {
    "validation_enabled": true,
    "validate_window": true,
    "validate_incoming": true,
    "validate_outgoing": true,
    "validation_mode": "WARNING"
  },
  "fields": {
    "max_amount": 1000,
    "max_amount_limited": true,
    "build_fld_90": true,
    "send_internal_id": true,
    "json_mode": true,
    "hide_secrets": true,
    "auto_sort": false
  },
  "specification": {
    "rewrite_local_spec": false,
    "remote_spec_url": "",
    "backup_storage_depth": 10,
    "manual_input_mode": false,
    "backup_storage": true,
    "backup_on_startup": true,
    "backup_on_shutdown": true
  },
  "api": {
    "address": "0.0.0.0",
    "port": 7777,
    "wait_remote_host_response": true,
    "waiting_timeout_seconds": 10,
    "hide_secrets": true,
    "parse_subfields": true
  },
  "theme": {
    "treeColor": "#F0F0F0",
    "windowColor": "#F0F0F0",
    "consoleColor": "#012E4F"
  }
}

Nested model used by Config.

{
  "host": "127.0.0.1",
  "port": 16677,
  "keep_alive_mode": false,
  "keep_alive_interval": 300,
  "header_length": 2,
  "header_length_exists": true
}

Nested model used by Config.

{
  "process_default_dump": true,
  "connect_on_startup": true,
  "load_remote_spec": false,
  "show_license_dialog": false,
  "run_api": true
}

Nested model used by Config.

{
  "level": "INFO",
  "clear_log": true,
  "parse_subfields": true,
  "backup_storage_depth": 10,
  "backup_storage_depth_exists": true,
  "reduce_keep_alive": true,
  "print_description": true
}

Nested model used by Config.

{
  "validation_enabled": true,
  "validate_window": true,
  "validate_incoming": true,
  "validate_outgoing": true,
  "validation_mode": "WARNING"
}

Nested model used by Config.

{
  "max_amount": 1000,
  "max_amount_limited": true,
  "build_fld_90": true,
  "send_internal_id": true,
  "json_mode": true,
  "hide_secrets": true,
  "auto_sort": false
}

Nested model used by Config.

{
  "rewrite_local_spec": false,
  "remote_spec_url": "",
  "backup_storage_depth": 10,
  "manual_input_mode": false,
  "backup_storage": true,
  "backup_on_startup": true,
  "backup_on_shutdown": true
}

Nested model used by Config.

{
  "address": "0.0.0.0",
  "port": 7777,
  "wait_remote_host_response": true,
  "waiting_timeout_seconds": 10,
  "hide_secrets": true,
  "parse_subfields": true
}

Nested model used by Config.

{
  "treeColor": "#F0F0F0",
  "windowColor": "#F0F0F0",
  "consoleColor": "#012E4F"
}

Complete ISO specification used by GET and PUT /api/specification. PUT replaces the specification. The small example is structurally valid and intended to illustrate the model; it is not a complete payment-processing specification. For normal updates, retrieve and edit the current specification.

{
  "name": "Minimal echo-test specification",
  "mti": [
    {
      "request": "0800",
      "response": "0810",
      "description": "Network management",
      "is_reversible": false,
      "reversal_mti": ""
    }
  ],
  "fields": {
    "11": {
      "field_number": "11",
      "field_path": [
        "11"
      ],
      "min_length": 6,
      "max_length": 6,
      "var_length": 0,
      "tag_length": 0,
      "generate": true,
      "reversal": true,
      "matching": true,
      "alpha": false,
      "numeric": true,
      "special": false,
      "reserved_for_future": false,
      "description": "Trace number"
    }
  },
  "utrnno_path": [
    "11"
  ]
}

Nested model used by the ISO specification.

{
  "request": "0800",
  "response": "0810",
  "description": "Network management",
  "is_reversible": false,
  "reversal_mti": ""
}

Nested model used by the ISO specification.

{
  "field_number": "11",
  "field_path": [
    "11"
  ],
  "min_length": 6,
  "max_length": 6,
  "var_length": 0,
  "tag_length": 0,
  "generate": true,
  "reversal": true,
  "matching": true,
  "alpha": false,
  "numeric": true,
  "special": false,
  "reserved_for_future": false,
  "description": "Trace number"
}

Additional rules attached to an ISO field. Empty lists disable their corresponding checks. Some stored properties are GUI options or legacy metadata rather than API validation rules; these are identified below.

{
  "valid_values": [
    "000000",
    "200000"
  ]
}

Logical rules inside Validators.field_type_validators. Set a date format together with the allowed past/present/future flags when validating dates.

{
  "date_format": "%Y%m%d",
  "past": true,
  "present": true,
  "future": true
}

Response only: common body for API operation errors. Request-schema errors use a different detail array, described below.

{
  "detail": "Transaction not found"
}

Response from GET /api/transactions. This is an object keyed by transaction ID, not a JSON array.

{
  "example-transaction": {
    "message_type": "0800",
    "data_fields": {
      "11": "123456"
    },
    "trans_id": "example-transaction"
  }
}

Response from POST /api/transactions/validate.

[]

Response only: HTTP 422 when a path parameter, query parameter or JSON body does not match the endpoint schema. This differs from transaction validation messages returned by /api/transactions/validate.

{"detail":[{"type":"missing","loc":["query","to_format"],"msg":"Field required","input":null}]}

These values belong in the URL, not in the request body.

POST /api/transactions/convert?to_format=INI HTTP/1.1
Host: 127.0.0.1:7777
Content-Type: application/json

{"message_type":"0800","data_fields":{"11":"123456"}}

The specification defines the message types, field hierarchy, encoding lengths and validation rules used to build and parse ISO 8583 E-pay messages. It must match the processing host's protocol. Signal needs a valid specification for transaction processing.

Open the Specification window from the main window. The editor works with a draft: opening a file or editing a field does not install that draft until you apply it. The JSON structure is described in EpaySpecModel, with separate tables for its nested models.

Read only mode is enabled when the window opens. Clear it to edit fields or use the add, remove, undo and redo controls. Hide reserved for future hides reserved fields without removing them from the specification. Search matches field numbers and descriptions; while searching, the reserved-field filter is not reapplied.

The table displays fields and subfields as a tree. Expand a complex field to inspect its children. Drag the divider above the log to adjust the space available to the table.

A checkbox with a dash can indicate a predefined or protected setting, such as Generated or the PAN's Secret flag. It does not necessarily mean that the setting is off.

Generation is not limited to random values: Signal also generates amounts, dates/times according to configured field formats, and internal transaction IDs. See Fields and the transaction's generate_fields option.

For example, the bundled specification defines the following hierarchy:

The parent data includes the encoded tags, length prefixes and values of its children. You do not insert those prefixes into nested JSON manually: Signal builds them from the specification. See the financial Transaction example for this hierarchy in a request body.

Keyboard navigation and shortcuts are listed in Windows hotkeys.

Use the Apply menu after checking the draft:

Before replacing the active specification, Signal creates or reuses a backup of the previous valid specification. In recovery mode, it backs up the repaired candidate instead. If validation, backup or saving fails, the new draft is not installed. Correct the reported errors and apply again.

The Set Spec menu has two different actions:

• Set local specification reloads the standard local file and applies it to the current session.
• Set remote specification fetches the configured remote document into the editor. Review it and choose Apply to install it.

Loading another document replaces the editor's draft. Apply or copy any draft you need to retain before loading a different file or using Set Spec.

Do Backup backs up the current active specification, not unsaved edits in the table. Backup Dir opens common/data/spec_backup. Backups are JSON files named spec_backup_<timestamp>_<suffix>.json. If the latest backup already contains the same specification, Signal reuses it instead of creating a duplicate.

Configure automatic backup and retention options on the Specification tab of the Configuration window:

To restore a backup:

1. Choose Open File and select a backup JSON file.
2. Review its fields and MTI settings.
3. Choose Apply → For current session to try it, or Apply → Permanently to save it as the active specification file.

If the specification is damaged, Signal can offer valid backups or let you repair recoverable data in the editor. Invalid values remain visible for correction; a draft with unresolved errors cannot be applied. If no usable backup exists, open a corrected specification file.

The standard local file is common/data/settings/specification.json. A remote source must return a complete EpaySpecModel JSON document to a GET request. Configure its URL on Configuration → Specification.

The endpoint should return HTTP 200 and UTF-8 JSON with Content-Type: application/json. If the request fails, Signal logs the error and retains the previously available specification. A broken local specification is not repaired merely by a failed remote request.

A static web server can serve the specification JSON; no special API is required. Alternatively, use the small Python server below.

1. Place a valid specification.json beside signal_spec.py.
2. Save the example below as signal_spec.py and run python signal_spec.py.
3. Open http://127.0.0.1:4242/specification to check the JSON response.
4. Put that URL in Signal's remote specification setting. For access from another computer, change SERVER_ADDRESS to a suitable listen address and use the server's reachable address in Signal; 127.0.0.1 refers to the machine running Signal.

import json
from http import HTTPStatus
from http.server import BaseHTTPRequestHandler, HTTPServer
from pathlib import Path

SERVER_ADDRESS = "127.0.0.1"
PORT = 4242
URL_PATH = "/specification"
FILE = Path(__file__).with_name("specification.json")


class SpecHandler(BaseHTTPRequestHandler):
    def do_GET(self):
        if self.path != URL_PATH:
            self.send_error(HTTPStatus.NOT_FOUND)
            return

        try:
            text = FILE.read_text(encoding="utf-8")
            json.loads(text)
            body = text.encode("utf-8")
        except (OSError, UnicodeError, ValueError):
            self.send_error(HTTPStatus.INTERNAL_SERVER_ERROR,
                            "Cannot read a valid specification JSON file")
            return

        self.send_response(HTTPStatus.OK)
        self.send_header("Content-Type", "application/json; charset=utf-8")
        self.send_header("Content-Length", str(len(body)))
        self.end_headers()
        self.wfile.write(body)


if __name__ == "__main__":
    with HTTPServer((SERVER_ADDRESS, PORT), SpecHandler) as server:
        try:
            server.serve_forever()
        except KeyboardInterrupt:
            pass

Signal checks transaction data against the active specification: field structure, lengths, allowed characters and optional business rules. These checks help detect malformed test data; passing them does not mean that the processing host will approve the transaction.

Configure basic rules in the Specification window and additional rules through Field Params for the selected field. Configure when validation runs and how violations are handled on Configuration → Fields. Apply specification changes before relying on the new rules.

An empty value and an absent field are different. The specification does not contain a mandatory-field list for each MTI, so these checks do not establish that every field required by the processing host is present. Disabled GUI fields are skipped by the GUI field check and excluded from the transaction being built.

Request-model validation and ISO encoding checks are separate from configurable field validation. Disabling field validation does not make malformed JSON, an unknown MTI, broken length prefixes or otherwise unencodable data valid.

Select a field in the Specification window and open Field Params. The rules are stored in Validators and its nested LogicalValidators object.

Patterns are literal, case-sensitive strings, not regular expressions. An empty list disables its rule. When several rules are configured, the value must satisfy each active rule.

For example, this validators object permits only the two specified processing codes:

{
  "valid_values": ["000000", "200000"]
}

This is a nested rules object for an ISO field, not a complete transaction or specification request.

For date validation, set the format and at least one allowed date range. A format of %Y%m%d compares whole dates; %y%m%d%H%M%S includes seconds. With a format that omits the year, the comparison uses the parsed values for that format rather than the full original timestamp.

For example, this field_type_validators object accepts valid calendar dates today or in the future:

{
  "date_format": "%Y%m%d",
  "past": false,
  "present": true,
  "future": true
}

Use field_type_validators.date_format for active date checks. Merely setting the semantic field_type does not replace the logical check flags. Legacy properties such as top-level date_format, min_value, max_value and possible_values do not enforce their implied checks in the current API field validator; see the model table.

The validation_mode setting controls the severity of field-validation findings.

In the current implementation, FLEXIBLE selects severity from the first non-empty validation category. With mixed findings, a later critical finding may therefore be reported at warning severity. Use ERROR when every reported violation must block an outgoing transaction.

These modes do not override JSON schema errors, specification installation checks or transport/encoding failures. Incoming validation has different handling, described below.

Signal can check field values while you edit a message, before sending it, or after receiving a response. These are separate checks: enabling one does not enable the others. You can also request a check explicitly in the GUI or through the API.

The following options belong to the configuration's validation object. In the GUI, validation settings are available under Configuration → Fields.

validation_enabled is the common on/off switch for the automatic checks described below. Each check requires both this switch and its own option to be true.

For example, with validation_enabled: true, validate_window: false, and validate_outgoing: true, Signal skips automatic value checks while you edit, but checks the transaction when you send it. Whether a finding blocks sending depends on the validation mode.

Setting validation_enabled to false disables these automatic checks, regardless of the three individual options. It does not disable parsing, API request-schema validation, or the explicit checks described below. Keep-alive transactions skip the automatic outgoing and incoming checks.

Press Ctrl + Alt + V in the main window to check the current message without sending it. Signal checks enabled leaf fields, marks problems in the table, and writes details to the log. Disabled fields are skipped.

This shortcut forces a check even when automatic validation is turned off. For example, you can leave checks during editing disabled and use the shortcut when you are ready to review the message.

Submitting a transaction for sending. Signal validates the transaction before dispatching it, independently of validation_enabled and validate_outgoing. A validation error prevents dispatch and produces an HTTP 422 response. A warning is logged and processing continues. The validation mode determines how findings are classified.

Checking a transaction without sending it. Send a transaction to POST /api/transactions/validate. The endpoint returns a JSON list of validation messages, or [] if no findings are reported. Reported field-validation findings are returned with HTTP 200; this endpoint does not dispatch the transaction.

The API also checks the structure and types of request data. An invalid request body can therefore produce HTTP 422 before field validation runs, including on the validation-only endpoint. These request-schema errors have a different response body from field-validation findings.

Complex fields may contain nested JSON objects or their encoded string representation. The validator follows the active specification and validates the leaf values. An encoded complex field must first be split successfully; malformed tags or length prefixes can fail during parsing before normal field checks complete.

For example, an error in the city inside field 47 may identify the path 47.227.01. The tag widths and length prefixes come from the specification, not from a validation mode. See Complex field lengths and the Transaction example.

The recursive value validator primarily checks leaf fields. Checks on the complete encoded message and length prefixes belong to the parser and serializer; a clean field-validation result is not a substitute for correct encoding.

Field Params also provides padding and case-conversion options. In the GUI these can change a field value before it is validated; they are not additional acceptance rules.

API request values are not automatically transformed by the GUI formatting options. Send the intended value explicitly. Automatic field generation is also separate: when Generate is selected, Signal produces the value before the applicable outgoing processing steps.

field_type_validators.do_not_validate skips value checks for the selected field. Known v0.21 defect: in the current recursive validator, it can also clear findings accumulated earlier in the same validation pass. Do not use it when you need a complete report of all transaction violations.

Manual entry mode is a legacy specification setting whose control is hidden in the current Configuration window. It is not a supported replacement for the validation switches described above.

The configuration defines how a Signal instance behaves: which processing host it uses, how it prepares and validates transactions, what it logs, and how its API responds. It applies across the instance, including all GUI tabs and any API running alongside them.

Transaction files hold individual messages. The specification defines the protocol's fields and MTIs. The configuration selects application behavior; it does not replace either of those documents.

Use the Settings Window for everyday GUI changes. This section explains configuration files, saving, and runtime behavior; the Config model provides the complete JSON structure and field reference.

Signal normally reads common/data/settings/config.json. The adjacent default_config.json is a baseline template used by the GUI's settings-reset action and to initialize a fresh executable distribution.

For example, keep a separate configuration for a test environment and run:

signal.exe --console --api-mode --config-file "C:/Signal/config/test.json"

Create the alternative file by copying a working configuration, then adjust its settings. A complete Config JSON example is also available in the model reference. Close the instance before editing its file manually: Signal does not continuously reload external file changes, and later saves can overwrite them.

The JSON configuration contains the following groups. GUI tabs may combine options from several groups; for example, General includes host, logging, and startup settings.

The processing-host connection and API listener are separate: host.host / host.port identify the ISO endpoint, while api.address / api.port identify Signal's HTTP listener. Likewise, fields.hide_secrets and api.hide_secrets control different output paths; enabling one does not enable the other.

In the GUI, open Tools → Settings, make your changes, and select OK to apply and save them. Cancel discards the uncommitted settings dialog changes. Theme actions that explicitly apply a theme take effect separately; canceling the dialog does not undo an already applied theme.

Through the API, retrieve the current configuration with GET /api/config, edit the returned object, and submit the complete configuration with PUT /api/config. This is a replacement, not a partial update. Accepted changes are saved to the active configuration file and are visible to the other interfaces of the same instance.

Through CLI launch options, --address, --port, and --log-level override the loaded configuration for that run without immediately saving those overrides. --print-config prints the effective configuration. If you later save the complete configuration through the API, its current values, including runtime overrides, become persistent.

Signal validates the configuration before saving and replaces the file only after writing the new contents successfully. If saving fails, inspect the reported error and file permissions; do not assume the requested change was saved.

Validation, field behavior, and other consumers use the active configuration. Logging and keep-alive settings also have runtime update handling. However, saving settings does not mean that every startup action is repeated or every existing connection is recreated.

After changing the processing-host address or port, reconnect to use the new destination. After changing the HTTP listener address or port, restart the API. In GUI mode, use Tools → API → Restart; in CLI API mode, stop and relaunch the job. Startup options describe launch behavior, so changing them is not a substitute for explicitly starting a service or loading a message now.

For specification loading and application rules, see Specification settings. For automatic validation, see When validation runs.

Reset all settings, on the General tab, loads baseline values into the settings dialog. Review them and select OK to apply and save, or Cancel to discard the reset.

The current implementation preserves the processing-host address and port, API address and port, remote specification URL, and local-specification rewrite preference during this reset. It does not replace transaction files or specification contents. Reset theme is a separate action for appearance changes.

Keep a copy of a working configuration before moving to another environment. Restoring that file and restarting Signal restores the saved settings, but does not restore a previous session's transaction queue.

Transaction files are intended to store and exchange transaction data. Engineers can use them to share a test case, reproduce a reported issue, compare message contents, or hand a prepared transaction to a colleague without re-entering every field. The same files also provide reusable input for GUI work and CLI jobs.

When sharing a file, identify the specification and relevant environment settings used to interpret it. Include the response or log separately when the purpose is to explain the outcome of an exchange: a transaction input file alone does not capture the full test history.

Signal supports JSON, INI, and textual DUMP files. All three are parsed into a Transaction object; the file format does not select a different processing engine or disable validation.

The active specification is required when parsing transaction files. JSON can represent nested subfields directly; INI stores the corresponding encoded complex-field content. Signal generates tags and length prefixes when exporting nested data using the specification. Choosing INI does not bypass validation or remove the need for correct complex-field encoding.

Prefer JSON for a reusable test template. DUMP preserves encoded message content, but does not carry all the template options, such as the list of fields to regenerate.

The examples below represent the same financial purchase (MTI 0200), including nested data in field 47. They use test data and the bundled specification. The JSON and INI examples enable generation of fields 7 (transmission date and time), 12 (local transaction date and time), and 37 (retrieval reference number). Signal refreshes these values during file loading and sending rather than reusing the illustrative values below. This helps avoid stale timestamps and repeated references; host duplicate checks may require other fields to be regenerated as well.

Save as purchase.json. Field values remain strings, preserving leading zeros. Field 47 uses nested objects; its tags and length prefixes are added during encoding.

{
  "message_type": "0200",
  "generate_fields": [
    "7",
    "12",
    "37"
  ],
  "data_fields": {
    "2": "4111111111111111",
    "3": "000000",
    "4": "000000001250",
    "7": "0912164500",
    "11": "123456",
    "12": "260912164500",
    "14": "2912",
    "18": "8999",
    "22": "810",
    "37": "123456789012",
    "41": "70000826",
    "42": "000000010000866",
    "43": "TEST SHOP                   >Limassol>CY",
    "47": {
      "033": "5",
      "227": {
        "01": "Limassol",
        "03": "CYP",
        "04": "3101"
      }
    },
    "49": "978"
  }
}

Save as purchase.ini. [CONFIG] holds generation options, [MTI] selects the message type, and [MESSAGE] holds field values. The value of F047 is the encoded form of the nested JSON field above. This example was produced by Signal's INI serializer; the square brackets around values are part of its format.

[CONFIG]
MAX_AMOUNT = [100]
GENERATE_FIELDS = [7, 12, 37]
[MTI]
MTI = [0200]
[MESSAGE]
F002 = [4111111111111111]
F003 = [000000]
F004 = [000000001250]
F007 = [0912164500]
F011 = [123456]
F012 = [260912164500]
F014 = [2912]
F018 = [8999]
F022 = [810]
F037 = [123456789012]
F041 = [70000826]
F042 = [000000010000866]
F043 = [TEST SHOP                   >Limassol>CY]
F047 = [03300152270270108Limassol0303CYP04043101]
F049 = [978]

Save as purchase.dump. The hexadecimal columns represent the encoded message bytes; the right-hand column is a readable representation. Keep the spacing and line breaks when copying this format. Generate it with Signal rather than manually calculating its bitmap and length prefixes.

30.32.30.30.72.34.44.00.08.E2.80.00.31.36.34.31    0200........1641
31.31.31.31.31.31.31.31.31.31.31.31.31.31.30.30    1111111111111100
30.30.30.30.30.30.30.30.30.30.30.30.31.32.35.30    0000000000001250
30.39.31.32.31.36.34.35.30.30.31.32.33.34.35.36    0912164500123456
32.36.30.39.31.32.31.36.34.35.30.30.32.39.31.32    2609121645002912
38.39.39.39.38.31.30.31.32.33.34.35.36.37.38.39    8999810123456789
30.31.32.37.30.30.30.30.38.32.36.30.30.30.30.30    0127000082600000
30.30.31.30.30.30.30.38.36.36.54.45.53.54.20.53    0010000866TEST S
48.4F.50.20.20.20.20.20.20.20.20.20.20.20.20.20    HOP             
20.20.20.20.20.20.3E.4C.69.6D.61.73.73.6F.6C.3E          >Limassol>
43.59.30.34.30.30.33.33.30.30.31.35.32.32.37.30    CY04003300152270
32.37.30.31.30.38.4C.69.6D.61.73.73.6F.6C.30.33    270108Limassol03
30.33.43.59.50.30.34.30.34.33.31.30.31.39.37.38    03CYP04043101978

The DUMP is a static snapshot of the illustrated values, intended for format inspection. It does not carry generate_fields: before resending a loaded dump, enable generation of fields 7, 12, and 37 in the GUI, or convert it to JSON/INI and set their generation options. Reusing its timestamps and references unchanged can cause an expired or duplicate transaction rejection.

The DUMP contains the encoded MTI and message fields. It does not preserve all JSON metadata or generation options, so these formats are equivalent for the message content, not for every property of a reusable template.

In the GUI, use Open file or Ctrl + O and select the transaction file. You can also drop transaction files or supported text onto the editor. Choose the intended tab and preserve any existing message before replacing it.

Signal selects a parser from recognized extensions: .json, .ini, or .dump. For an unknown extension it attempts the supported parsers in turn. A recognized extension containing the wrong format can fail directly, so use the correct extension. Older .dmp names rely on format detection rather than a dedicated extension mapping.

Loading prepares the editor; it does not send the transaction. Values listed for generation may be regenerated during file loading and again during sending. Turn generation off for fields whose exact supplied values must be retained.

To process a file through the CLI:

signal.exe --console --file "C:/transactions/purchase.json"

Unlike opening a file in the GUI, this command starts a job that processes and sends the transaction. See CLI examples for multiple files and repetition.

To save the active GUI tab, choose Save file → Current tab, select JSON, INI, or DUMP in the file dialog, and provide a filename. To export several open messages, choose All tabs as JSON, All tabs as INI, or All tabs as DUMP and select a destination directory. Signal derives the individual filenames from the tab names.

Give tabs distinct, descriptive names before exporting them together and use a separate directory when preserving an earlier test set. Review the log for save failures: transaction validation runs before saving, errors prevent saving, and warnings can be logged while saving continues.

A saved message is reusable transaction input, not an archive of the complete session or proof of the host's result. Save the relevant log separately when you need evidence of an exchange. Print displays a representation in the output panel; it does not save a file.

Signal stores its configuration, message templates, dictionaries, and other application data in common/data. This directory is accessible to the user: open it in a file manager to inspect files, adjust templates, or copy settings and specification backups when needed. In the executable distribution, keep the external common directory beside signal.exe and launch Signal from that folder.

The structure below includes supplied files and directories populated during use. Paths in the following subsections are relative to common/data.

common/data/
├── static/                  # Documentation assets
├── default/             Default message and connection-test templates
├── api_transactions/    Templates for predefined API transactions
├── dictionary/          Country, currency, and merchant category data
├── license/             License agreement and local acceptance record
├── settings/            Configuration and local specification
├── spec_backup/         Saved specification versions
├── postman/             Postman collection archive
└── style/               GUI assets and saved panel layout

Close Signal before manually editing saved settings so that later application saves do not overwrite your changes. Keep a copy of the original file and preserve its expected format; see Data models. Use the GUI settings and specification editor for routine changes.

The default directory contains transaction templates used by the application.

These files use the Transaction model. You can adjust their field values to match your test environment and active specification. Keep the filenames unchanged: Signal uses these paths to locate the templates.

The api_transactions directory contains a separate set of templates for the predefined API endpoints.

Each file describes a Transaction. Signal reads the corresponding template when handling a predefined transaction request. Editing default/echo-test.json, for example, does not change the API template in api_transactions/echo-test.json.

The dictionary directory contains reference datasets for country, currency, and merchant category codes.

Keep the existing JSON structure when updating reference entries. Field lengths, allowed characters, and other specification rules are stored separately in settings/specification.json.

Known v0.21 defect: the currency dictionary path points to countries.json instead of currencies.json. Editing currencies.json therefore does not currently update the currency dictionary loaded by Signal.

The license directory contains two files with different purposes:

Signal maintains the acceptance record through the license dialog. A fresh distribution does not include another user's acceptance record; the file is saved during use.

The settings directory holds the saved application configuration and local specification.

Changing default_config.json does not immediately change the active configuration. Similarly, editing the local specification does not change a specification already loaded into memory. A configured remote source can also determine which specification Signal uses; see Specification settings.

The spec_backup directory stores specification snapshots as JSON files. Signal creates the directory when saving a backup if it does not already exist.

Filenames follow the pattern spec_backup_YYYYMMDD_HHMMSS_XXXXX.json: a timestamp followed by a five-digit suffix. Each file contains a specification snapshot, not a copy of all application settings or transactions.

Use Backup Spec in the specification window to save the active specification and Backup Dir to open the folder. Load a backup through Open File, then review and apply it. Unsaved editor changes are not part of a backup of the active specification.

Signal avoids creating a duplicate of the latest unchanged snapshot. Retention is controlled by specification.backup_storage and specification.backup_storage_depth; when backup storage is disabled, Signal still retains one valid snapshot. Copy any version you want to keep permanently outside this folder so that rotation does not remove it.

The postman directory stores the Postman collection and environment for working with the Signal HTTP API. The collection contains saved API requests; the environment holds the variables used by those requests. See Postman collection in the API section for a description of both components.

The existing archive, Signal_v0.20_postman_collection.zip, contains SignalAPI.postman_collection.json and SignalAPIenv.postman_environment.json. Both resources need to be updated and verified against Signal v0.21 before they can be presented as current.

The style directory contains icons, logos, control graphics, and other GUI resources. It also holds layout files created or updated during use:

Theme colors are saved in the configuration's theme section, not in appearance.json. In executable builds, visual assets are bundled with the application, while saved layout files are written outside the bundle. The external folder may therefore contain fewer resource files than the source project.

The static directory contains documentation assets. The guide source is stored separately in common/doc/signal_user_guide.md; the build script generates common/doc/signal_user_guide.html with the images embedded.

Application logs are stored separately in common/log, outside common/data.

Signal records connection events, transaction processing, validation findings, API activity, and errors. Use the log to follow a transaction from sending to response, investigate a failed operation, or review a CLI job.

The application writes to common/log/signal.log by default. The GUI console and CLI console display messages while Signal is running; the file keeps a record for later inspection. The same file is available through the API's browser log tools when the API is running.

Set debug.level in the configuration, or use --log-level for a CLI run. The level is a minimum severity: INFO, for example, includes INFO, WARNING, ERROR, and CRITICAL messages, but excludes DEBUG.

For example, to collect diagnostic output for one transaction:

signal.exe --console --file "C:/transactions/purchase.json" --log-level DEBUG

Choose INFO for routine use and enable DEBUG when investigating a specific issue. See Hide secrets before sharing diagnostic output.

The default log directory is common/log, separate from common/data. Signal appends messages to the active log; starting another run does not create a separate file automatically. To select a different file for a CLI run:

signal.exe --console --api-mode --log-file "C:/Signal/log/api-session.log"

Use a separate filename for each concurrent process to keep their output from interleaving. --no-print suppresses CLI console output but does not itself disable file logging.

The 10 MB threshold and ZIP format are fixed by the implementation; they are not configuration options. Retention cleanup takes place during rotation. Copy archives elsewhere if they must be preserved beyond the retention limit.

Clearing the GUI log panel does not erase the log file. Likewise, debug.clear_log clears the main GUI log panel before a non-keep-alive transaction sent through the GUI; it does not truncate stored history.

Start Signal with the API enabled, either in the GUI or through CLI API mode. With the default API port, use these addresses on the same computer:

For example, if Signal runs at 192.168.0.3 on port 7777, open http://192.168.0.3:7777/api/log/live to watch its log update online.

Replace 127.0.0.1 and 7777 with the reachable Signal address and configured API port when appropriate. Both views read the current active file, not the rotated ZIP archives. They can include earlier runs still present in that file.

Custom log file limitation: both browser views currently read common/log/signal.log directly. They do not follow a CLI --log-file override. If you selected another file, inspect it directly; the browser may show older messages from the default file instead. If the default file does not exist, the plain-text endpoint returns an empty body.

To save a snapshot through the API:

curl.exe "http://127.0.0.1:7777/api/log/raw?print=false" -o "signal-log-snapshot.txt"

The print=false parameter suppresses Signal's normal API request log entry for that retrieval.

Open /api/log/live to follow activity while sending requests from another terminal or API client. The page retrieves the current log once per second and highlights DEBUG, INFO, WARNING, and ERROR labels.

The viewer reloads the active file rather than maintaining a separate history. After rotation, the page shows the new active log; older entries remain in the ZIP archives subject to retention. Pausing the viewer does not preserve a snapshot, so save one separately if needed.

The following configuration options control the amount of transaction detail:

Formatted transaction output includes identifiers such as TRANS_ID, the MTI (MSG_TYPE), the bitmap, and field data. Use the transaction ID to follow a particular exchange. In CLI mode, Job ID markers identify the boundaries of the overall run; one job can contain many transactions.

For troubleshooting, capture the operation at DEBUG, note its transaction or job ID, and keep the surrounding connection and error messages as well as the transaction itself. The GUI, CLI, and file outputs use different timestamp and presentation formats; differences in formatting do not indicate different events.

Enable fields.hide_secrets to mask sensitive values in formatted transaction logging. Signal uses the active specification's Secret properties, including those of nested fields. For a normal-length PAN in field 2, it keeps the first six and last four characters visible and replaces the middle characters with dots. Other fields marked secret are masked across their full value.

Masking is applied to a copy used for presentation. It does not change the transaction sent to the host and does not remove values from existing log files.

This is not a universal log-redaction setting. In particular, DEBUG transaction dumps are produced separately and are not masked by this option. Review logs and archives for sensitive data before sharing them, even when Hide secrets is enabled.

The following limitations are confirmed in the current implementation and described where they affect usage:

Earlier documentation also reported an extra console window on GUI startup, problems with fields absent from the specification, and host Format Error responses when sending field 62. These reports have not been revalidated here against v0.21 and should not be treated as confirmed current defects or universal host behavior. Include the transaction, specification, and relevant log when reporting a reproducible issue.

The text version of Signal's logo:

  ::::::::  :::::::::::  ::::::::   ::::    :::      :::      :::        
 :+:    :+:     :+:     :+:    :+:  :+:+:   :+:    :+: :+:    :+:        
 +:+            +:+     +:+         :+:+:+  +:+   +:+   +:+   +:+        
 +#++:++#++     +#+     :#:         +#+ +:+ +#+  +#++:++#++:  +#+        
        +#+     +#+     +#+   +#+#  +#+  +#+#+#  +#+     +#+  +#+        
 #+#    #+#     #+#     #+#    #+#  #+#   #+#+#  #+#     #+#  #+#        
  ########  ###########  ########   ###    ####  ###     ###  ########## 

  Simplified ISO generation algorithm v0.21 | Released in September 2026

The main idea behind Signal is to make simple things easy to do. It aims to simplify complex everyday tasks for people who work with ISO 8583 OLTP services.

Signal is not a PSP or SmartVista emulator and does not aim to replicate these systems. It is closer to a simplified card payment terminal, designed around the everyday needs of card processing support teams.

Written in Python 3.12 using the PyQt6 and Pydantic packages.

Signal is distributed as free software under the GNU/GPL license. You must accept the license agreement to use Signal.

Learn more on the GNU license page and in the free software Wikipedia article, listed in Resources.

Refer to the supplied license agreement for the terms of use and distribution. Contact the author with licensing questions.

 GNU GENERAL PUBLIC LICENSE Version 3, 29 June 2007
 
 Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
 Everyone is permitted to copy and distribute verbatim copies
 of this license document, but changing it is not allowed.

                            Preamble

  The GNU General Public License is a free, copyleft license for
software and other kinds of works.

  The licenses for most software and other practical works are designed
to take away your freedom to share and change the works.  By contrast,
the GNU General Public License is intended to guarantee your freedom to
share and change all versions of a program--to make sure it remains free
software for all its users.  We, the Free Software Foundation, use the
GNU General Public License for most of our software; it applies also to
any other work released this way by its authors.  You can apply it to
your programs, too.

  When we speak of free software, we are referring to freedom, not
price.  Our General Public Licenses are designed to make sure that you
have the freedom to distribute copies of free software (and charge for
them if you wish), that you receive source code or can get it if you
want it, that you can change the software or use pieces of it in new
free programs, and that you know you can do these things.

  To protect your rights, we need to prevent others from denying you
these rights or asking you to surrender the rights.  Therefore, you have
certain responsibilities if you distribute copies of the software, or if
you modify it: responsibilities to respect the freedom of others.

  For example, if you distribute copies of such a program, whether
gratis or for a fee, you must pass on to the recipients the same
freedoms that you received.  You must make sure that they, too, receive
or can get the source code.  And you must show them these terms so they
know their rights.

  Developers that use the GNU GPL protect your rights with two steps:
(1) assert copyright on the software, and (2) offer you this License
giving you legal permission to copy, distribute and/or modify it.

  For the developers' and authors' protection, the GPL clearly explains
that there is no warranty for this free software.  For both users' and
authors' sake, the GPL requires that modified versions be marked as
changed, so that their problems will not be attributed erroneously to
authors of previous versions.

  Some devices are designed to deny users access to install or run
modified versions of the software inside them, although the manufacturer
can do so.  This is fundamentally incompatible with the aim of
protecting users' freedom to change the software.  The systematic
pattern of such abuse occurs in the area of products for individuals to
use, which is precisely where it is most unacceptable.  Therefore, we
have designed this version of the GPL to prohibit the practice for those
products.  If such problems arise substantially in other domains, we
stand ready to extend this provision to those domains in future versions
of the GPL, as needed to protect the freedom of users.

  Finally, every program is threatened constantly by software patents.
States should not allow patents to restrict development and use of
software on general-purpose computers, but in those that do, we wish to
avoid the special danger that patents applied to a free program could
make it effectively proprietary.  To prevent this, the GPL assures that
patents cannot be used to render the program non-free.

  The precise terms and conditions for copying, distribution and
modification follow.

                       TERMS AND CONDITIONS

  0. Definitions.

  "This License" refers to version 3 of the GNU General Public License.

  "Copyright" also means copyright-like laws that apply to other kinds of
works, such as semiconductor masks.

  "The Program" refers to any copyrightable work licensed under this
License.  Each licensee is addressed as "you".  "Licensees" and
"recipients" may be individuals or organizations.

  To "modify" a work means to copy from or adapt all or part of the work
in a fashion requiring copyright permission, other than the making of an
exact copy.  The resulting work is called a "modified version" of the
earlier work or a work "based on" the earlier work.

  A "covered work" means either the unmodified Program or a work based
on the Program.

  To "propagate" a work means to do anything with it that, without
permission, would make you directly or secondarily liable for
infringement under applicable copyright law, except executing it on a
computer or modifying a private copy.  Propagation includes copying,
distribution (with or without modification), making available to the
public, and in some countries other activities as well.

  To "convey" a work means any kind of propagation that enables other
parties to make or receive copies.  Mere interaction with a user through
a computer network, with no transfer of a copy, is not conveying.

  An interactive user interface displays "Appropriate Legal Notices"
to the extent that it includes a convenient and prominently visible
feature that (1) displays an appropriate copyright notice, and (2)
tells the user that there is no warranty for the work (except to the
extent that warranties are provided), that licensees may convey the
work under this License, and how to view a copy of this License.  If
the interface presents a list of user commands or options, such as a
menu, a prominent item in the list meets this criterion.

  1. Source Code.

  The "source code" for a work means the preferred form of the work
for making modifications to it.  "Object code" means any non-source
form of a work.

  A "Standard Interface" means an interface that either is an official
standard defined by a recognized standards body, or, in the case of
interfaces specified for a particular programming language, one that
is widely used among developers working in that language.

  The "System Libraries" of an executable work include anything, other
than the work as a whole, that (a) is included in the normal form of
packaging a Major Component, but which is not part of that Major
Component, and (b) serves only to enable use of the work with that
Major Component, or to implement a Standard Interface for which an
implementation is available to the public in source code form.  A
"Major Component", in this context, means a major essential component
(kernel, window system, and so on) of the specific operating system
(if any) on which the executable work runs, or a compiler used to
produce the work, or an object code interpreter used to run it.

  The "Corresponding Source" for a work in object code form means all
the source code needed to generate, install, and (for an executable
work) run the object code and to modify the work, including scripts to
control those activities.  However, it does not include the work's
System Libraries, or general-purpose tools or generally available free
programs which are used unmodified in performing those activities but
which are not part of the work.  For example, Corresponding Source
includes interface definition files associated with source files for
the work, and the source code for shared libraries and dynamically
linked subprograms that the work is specifically designed to require,
such as by intimate data communication or control flow between those
subprograms and other parts of the work.

  The Corresponding Source need not include anything that users
can regenerate automatically from other parts of the Corresponding
Source.

  The Corresponding Source for a work in source code form is that
same work.

  2. Basic Permissions.

  All rights granted under this License are granted for the term of
copyright on the Program, and are irrevocable provided the stated
conditions are met.  This License explicitly affirms your unlimited
permission to run the unmodified Program.  The output from running a
covered work is covered by this License only if the output, given its
content, constitutes a covered work.  This License acknowledges your
rights of fair use or other equivalent, as provided by copyright law.

  You may make, run and propagate covered works that you do not
convey, without conditions so long as your license otherwise remains
in force.  You may convey covered works to others for the sole purpose
of having them make modifications exclusively for you, or provide you
with facilities for running those works, provided that you comply with
the terms of this License in conveying all material for which you do
not control copyright.  Those thus making or running the covered works
for you must do so exclusively on your behalf, under your direction
and control, on terms that prohibit them from making any copies of
your copyrighted material outside their relationship with you.

  Conveying under any other circumstances is permitted solely under
the conditions stated below.  Sublicensing is not allowed; section 10
makes it unnecessary.

  3. Protecting Users' Legal Rights From Anti-Circumvention Law.

  No covered work shall be deemed part of an effective technological
measure under any applicable law fulfilling obligations under article
11 of the WIPO copyright treaty adopted on 20 December 1996, or
similar laws prohibiting or restricting circumvention of such
measures.

  When you convey a covered work, you waive any legal power to forbid
circumvention of technological measures to the extent such circumvention
is effected by exercising rights under this License with respect to
the covered work, and you disclaim any intention to limit operation or
modification of the work as a means of enforcing, against the work's
users, your or third parties' legal rights to forbid circumvention of
technological measures.

  4. Conveying Verbatim Copies.

  You may convey verbatim copies of the Program's source code as you
receive it, in any medium, provided that you conspicuously and
appropriately publish on each copy an appropriate copyright notice;
keep intact all notices stating that this License and any
non-permissive terms added in accord with section 7 apply to the code;
keep intact all notices of the absence of any warranty; and give all
recipients a copy of this License along with the Program.

  You may charge any price or no price for each copy that you convey,
and you may offer support or warranty protection for a fee.

  5. Conveying Modified Source Versions.

  You may convey a work based on the Program, or the modifications to
produce it from the Program, in the form of source code under the
terms of section 4, provided that you also meet all of these conditions:

    a) The work must carry prominent notices stating that you modified
    it, and giving a relevant date.

    b) The work must carry prominent notices stating that it is
    released under this License and any conditions added under section
    7.  This requirement modifies the requirement in section 4 to
    "keep intact all notices".

    c) You must license the entire work, as a whole, under this
    License to anyone who comes into possession of a copy.  This
    License will therefore apply, along with any applicable section 7
    additional terms, to the whole of the work, and all its parts,
    regardless of how they are packaged.  This License gives no
    permission to license the work in any other way, but it does not
    invalidate such permission if you have separately received it.

    d) If the work has interactive user interfaces, each must display
    Appropriate Legal Notices; however, if the Program has interactive
    interfaces that do not display Appropriate Legal Notices, your
    work need not make them do so.

  A compilation of a covered work with other separate and independent
works, which are not by their nature extensions of the covered work,
and which are not combined with it such as to form a larger program,
in or on a volume of a storage or distribution medium, is called an
"aggregate" if the compilation and its resulting copyright are not
used to limit the access or legal rights of the compilation's users
beyond what the individual works permit.  Inclusion of a covered work
in an aggregate does not cause this License to apply to the other
parts of the aggregate.

  6. Conveying Non-Source Forms.

  You may convey a covered work in object code form under the terms
of sections 4 and 5, provided that you also convey the
machine-readable Corresponding Source under the terms of this License,
in one of these ways:

    a) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by the
    Corresponding Source fixed on a durable physical medium
    customarily used for software interchange.

    b) Convey the object code in, or embodied in, a physical product
    (including a physical distribution medium), accompanied by a
    written offer, valid for at least three years and valid for as
    long as you offer spare parts or customer support for that product
    model, to give anyone who possesses the object code either (1) a
    copy of the Corresponding Source for all the software in the
    product that is covered by this License, on a durable physical
    medium customarily used for software interchange, for a price no
    more than your reasonable cost of physically performing this
    conveying of source, or (2) access to copy the
    Corresponding Source from a network server at no charge.

    c) Convey individual copies of the object code with a copy of the
    written offer to provide the Corresponding Source.  This
    alternative is allowed only occasionally and noncommercially, and
    only if you received the object code with such an offer, in accord
    with subsection 6b.

    d) Convey the object code by offering access from a designated
    place (gratis or for a charge), and offer equivalent access to the
    Corresponding Source in the same way through the same place at no
    further charge.  You need not require recipients to copy the
    Corresponding Source along with the object code.  If the place to
    copy the object code is a network server, the Corresponding Source
    may be on a different server (operated by you or a third party)
    that supports equivalent copying facilities, provided you maintain
    clear directions next to the object code saying where to find the
    Corresponding Source.  Regardless of what server hosts the
    Corresponding Source, you remain obligated to ensure that it is
    available for as long as needed to satisfy these requirements.

    e) Convey the object code using peer-to-peer transmission, provided
    you inform other peers where the object code and Corresponding
    Source of the work are being offered to the general public at no
    charge under subsection 6d.

  A separable portion of the object code, whose source code is excluded
from the Corresponding Source as a System Library, need not be
included in conveying the object code work.

  A "User Product" is either (1) a "consumer product", which means any
tangible personal property which is normally used for personal, family,
or household purposes, or (2) anything designed or sold for incorporation
into a dwelling.  In determining whether a product is a consumer product,
doubtful cases shall be resolved in favor of coverage.  For a particular
product received by a particular user, "normally used" refers to a
typical or common use of that class of product, regardless of the status
of the particular user or of the way in which the particular user
actually uses, or expects or is expected to use, the product.  A product
is a consumer product regardless of whether the product has substantial
commercial, industrial or non-consumer uses, unless such uses represent
the only significant mode of use of the product.

  "Installation Information" for a User Product means any methods,
procedures, authorization keys, or other information required to install
and execute modified versions of a covered work in that User Product from
a modified version of its Corresponding Source.  The information must
suffice to ensure that the continued functioning of the modified object
code is in no case prevented or interfered with solely because
modification has been made.

  If you convey an object code work under this section in, or with, or
specifically for use in, a User Product, and the conveying occurs as
part of a transaction in which the right of possession and use of the
User Product is transferred to the recipient in perpetuity or for a
fixed term (regardless of how the transaction is characterized), the
Corresponding Source conveyed under this section must be accompanied
by the Installation Information.  But this requirement does not apply
if neither you nor any third party retains the ability to install
modified object code on the User Product (for example, the work has
been installed in ROM).

  The requirement to provide Installation Information does not include a
requirement to continue to provide support service, warranty, or updates
for a work that has been modified or installed by the recipient, or for
the User Product in which it has been modified or installed.  Access to a
network may be denied when the modification itself materially and
adversely affects the operation of the network or violates the rules and
protocols for communication across the network.

  Corresponding Source conveyed, and Installation Information provided,
in accord with this section must be in a format that is publicly
documented (and with an implementation available to the public in
source code form), and must require no special password or key for
unpacking, reading or copying.

  7. Additional Terms.

  "Additional permissions" are terms that supplement the terms of this
License by making exceptions from one or more of its conditions.
Additional permissions that are applicable to the entire Program shall
be treated as though they were included in this License, to the extent
that they are valid under applicable law.  If additional permissions
apply only to part of the Program, that part may be used separately
under those permissions, but the entire Program remains governed by
this License without regard to the additional permissions.

  When you convey a copy of a covered work, you may at your option
remove any additional permissions from that copy, or from any part of
it.  (Additional permissions may be written to require their own
removal in certain cases when you modify the work.)  You may place
additional permissions on material, added by you to a covered work,
for which you have or can give appropriate copyright permission.

  Notwithstanding any other provision of this License, for material you
add to a covered work, you may (if authorized by the copyright holders of
that material) supplement the terms of this License with terms:

    a) Disclaiming warranty or limiting liability differently from the
    terms of sections 15 and 16 of this License; or

    b) Requiring preservation of specified reasonable legal notices or
    author attributions in that material or in the Appropriate Legal
    Notices displayed by works containing it; or

    c) Prohibiting misrepresentation of the origin of that material, or
    requiring that modified versions of such material be marked in
    reasonable ways as different from the original version; or

    d) Limiting the use for publicity purposes of names of licensors or
    authors of the material; or

    e) Declining to grant rights under trademark law for use of some
    trade names, trademarks, or service marks; or

    f) Requiring indemnification of licensors and authors of that
    material by anyone who conveys the material (or modified versions of
    it) with contractual assumptions of liability to the recipient, for
    any liability that these contractual assumptions directly impose on
    those licensors and authors.

  All other non-permissive additional terms are considered "further
restrictions" within the meaning of section 10.  If the Program as you
received it, or any part of it, contains a notice stating that it is
governed by this License along with a term that is a further
restriction, you may remove that term.  If a license document contains
a further restriction but permits relicensing or conveying under this
License, you may add to a covered work material governed by the terms
of that license document, provided that the further restriction does
not survive such relicensing or conveying.

  If you add terms to a covered work in accord with this section, you
must place, in the relevant source files, a statement of the
additional terms that apply to those files, or a notice indicating
where to find the applicable terms.

  Additional terms, permissive or non-permissive, may be stated in the
form of a separately written license, or stated as exceptions;
the above requirements apply either way.

  8. Termination.

  You may not propagate or modify a covered work except as expressly
provided under this License.  Any attempt otherwise to propagate or
modify it is void, and will automatically terminate your rights under
this License (including any patent licenses granted under the third
paragraph of section 11).

  However, if you cease all violation of this License, then your
license from a particular copyright holder is reinstated (a)
provisionally, unless and until the copyright holder explicitly and
finally terminates your license, and (b) permanently, if the copyright
holder fails to notify you of the violation by some reasonable means
prior to 60 days after the cessation.

  Moreover, your license from a particular copyright holder is
reinstated permanently if the copyright holder notifies you of the
violation by some reasonable means, this is the first time you have
received notice of violation of this License (for any work) from that
copyright holder, and you cure the violation prior to 30 days after
your receipt of the notice.

  Termination of your rights under this section does not terminate the
licenses of parties who have received copies or rights from you under
this License.  If your rights have been terminated and not permanently
reinstated, you do not qualify to receive new licenses for the same
material under section 10.

  9. Acceptance Not Required for Having Copies.

  You are not required to accept this License in order to receive or
run a copy of the Program.  Ancillary propagation of a covered work
occurring solely as a consequence of using peer-to-peer transmission
to receive a copy likewise does not require acceptance.  However,
nothing other than this License grants you permission to propagate or
modify any covered work.  These actions infringe copyright if you do
not accept this License.  Therefore, by modifying or propagating a
covered work, you indicate your acceptance of this License to do so.

  10. Automatic Licensing of Downstream Recipients.

  Each time you convey a covered work, the recipient automatically
receives a license from the original licensors, to run, modify and
propagate that work, subject to this License.  You are not responsible
for enforcing compliance by third parties with this License.

  An "entity transaction" is a transaction transferring control of an
organization, or substantially all assets of one, or subdividing an
organization, or merging organizations.  If propagation of a covered
work results from an entity transaction, each party to that
transaction who receives a copy of the work also receives whatever
licenses to the work the party's predecessor in interest had or could
give under the previous paragraph, plus a right to possession of the
Corresponding Source of the work from the predecessor in interest, if
the predecessor has it or can get it with reasonable efforts.

  You may not impose any further restrictions on the exercise of the
rights granted or affirmed under this License.  For example, you may
not impose a license fee, royalty, or other charge for exercise of
rights granted under this License, and you may not initiate litigation
(including a cross-claim or counterclaim in a lawsuit) alleging that
any patent claim is infringed by making, using, selling, offering for
sale, or importing the Program or any portion of it.

  11. Patents.

  A "contributor" is a copyright holder who authorizes use under this
License of the Program or a work on which the Program is based.  The
work thus licensed is called the contributor's "contributor version".

  A contributor's "essential patent claims" are all patent claims
owned or controlled by the contributor, whether already acquired or
hereafter acquired, that would be infringed by some manner, permitted
by this License, of making, using, or selling its contributor version,
but do not include claims that would be infringed only as a
consequence of further modification of the contributor version.  For
purposes of this definition, "control" includes the right to grant
patent sublicenses in a manner consistent with the requirements of
this License.

  Each contributor grants you a non-exclusive, worldwide, royalty-free
patent license under the contributor's essential patent claims, to
make, use, sell, offer for sale, import and otherwise run, modify and
propagate the contents of its contributor version.

  In the following three paragraphs, a "patent license" is any express
agreement or commitment, however denominated, not to enforce a patent
(such as an express permission to practice a patent or covenant not to
sue for patent infringement).  To "grant" such a patent license to a
party means to make such an agreement or commitment not to enforce a
patent against the party.

  If you convey a covered work, knowingly relying on a patent license,
and the Corresponding Source of the work is not available for anyone
to copy, free of charge and under the terms of this License, through a
publicly available network server or other readily accessible means,
then you must either (1) cause the Corresponding Source to be so
available, or (2) arrange to deprive yourself of the benefit of the
patent license for this particular work, or (3) arrange, in a manner
consistent with the requirements of this License, to extend the patent
license to downstream recipients.  "Knowingly relying" means you have
actual knowledge that, but for the patent license, your conveying the
covered work in a country, or your recipient's use of the covered work
in a country, would infringe one or more identifiable patents in that
country that you have reason to believe are valid.

  If, pursuant to or in connection with a single transaction or
arrangement, you convey, or propagate by procuring conveyance of, a
covered work, and grant a patent license to some of the parties
receiving the covered work authorizing them to use, propagate, modify
or convey a specific copy of the covered work, then the patent license
you grant is automatically extended to all recipients of the covered
work and works based on it.

  A patent license is "discriminatory" if it does not include within
the scope of its coverage, prohibits the exercise of, or is
conditioned on the non-exercise of one or more of the rights that are
specifically granted under this License.  You may not convey a covered
work if you are a party to an arrangement with a third party that is
in the business of distributing software, under which you make payment
to the third party based on the extent of your activity of conveying
the work, and under which the third party grants, to any of the
parties who would receive the covered work from you, a discriminatory
patent license (a) in connection with copies of the covered work
conveyed by you (or copies made from those copies), or (b) primarily
for and in connection with specific products or compilations that
contain the covered work, unless you entered into that arrangement,
or that patent license was granted, prior to 28 March 2007.

  Nothing in this License shall be construed as excluding or limiting
any implied license or other defenses to infringement that may
otherwise be available to you under applicable patent law.

  12. No Surrender of Others' Freedom.

  If conditions are imposed on you (whether by court order, agreement or
otherwise) that contradict the conditions of this License, they do not
excuse you from the conditions of this License.  If you cannot convey a
covered work so as to satisfy simultaneously your obligations under this
License and any other pertinent obligations, then as a consequence you may
not convey it at all.  For example, if you agree to terms that obligate you
to collect a royalty for further conveying from those to whom you convey
the Program, the only way you could satisfy both those terms and this
License would be to refrain entirely from conveying the Program.

  13. Use with the GNU Affero General Public License.

  Notwithstanding any other provision of this License, you have
permission to link or combine any covered work with a work licensed
under version 3 of the GNU Affero General Public License into a single
combined work, and to convey the resulting work.  The terms of this
License will continue to apply to the part which is the covered work,
but the special requirements of the GNU Affero General Public License,
section 13, concerning interaction through a network will apply to the
combination as such.

  14. Revised Versions of this License.

  The Free Software Foundation may publish revised and/or new versions of
the GNU General Public License from time to time.  Such new versions will
be similar in spirit to the present version, but may differ in detail to
address new problems or concerns.

  Each version is given a distinguishing version number.  If the
Program specifies that a certain numbered version of the GNU General
Public License "or any later version" applies to it, you have the
option of following the terms and conditions either of that numbered
version or of any later version published by the Free Software
Foundation.  If the Program does not specify a version number of the
GNU General Public License, you may choose any version ever published
by the Free Software Foundation.

  If the Program specifies that a proxy can decide which future
versions of the GNU General Public License can be used, that proxy's
public statement of acceptance of a version permanently authorizes you
to choose that version for the Program.

  Later license versions may give you additional or different
permissions.  However, no additional obligations are imposed on any
author or copyright holder as a result of your choosing to follow a
later version.

  15. Disclaimer of Warranty.

  THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS" WITHOUT WARRANTY
OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO,
THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM
IS WITH YOU.  SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF
ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

  16. Limitation of Liability.

  IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS
THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY
GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE
USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF
DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS),
EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF
SUCH DAMAGES.

  17. Interpretation of Sections 15 and 16.

  If the disclaimer of warranty and limitation of liability provided
above cannot be given local legal effect according to their terms,
reviewing courts shall apply local law that most closely approximates
an absolute waiver of all civil liability in connection with the
Program, unless a warranty or assumption of liability accompanies a
copy of the Program in return for a fee.

                     END OF TERMS AND CONDITIONS

            How to Apply These Terms to Your New Programs

  If you develop a new program, and you want it to be of the greatest
possible use to the public, the best way to achieve this is to make it
free software which everyone can redistribute and change under these terms.

  To do so, attach the following notices to the program.  It is safest
to attach them to the start of each source file to most effectively
state the exclusion of warranty; and each file should have at least
the "copyright" line and a pointer to where the full notice is found.

    <one line to give the program's name and a brief idea of what it does.>
    Copyright (C) <year>  <name of author>

    This program is free software: you can redistribute it and/or modify
    it under the terms of the GNU General Public License as published by
    the Free Software Foundation, either version 3 of the License, or
    (at your option) any later version.

    This program is distributed in the hope that it will be useful,
    but WITHOUT ANY WARRANTY; without even the implied warranty of
    MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
    GNU General Public License for more details.

    You should have received a copy of the GNU General Public License
    along with this program.  If not, see <https://www.gnu.org/licenses/>.

Also add information on how to contact you by electronic and paper mail.

  If the program does terminal interaction, make it output a short
notice like this when it starts in an interactive mode:

    <program>  Copyright (C) <year>  <name of author>
    This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
    This is free software, and you are welcome to redistribute it
    under certain conditions; type `show c' for details.

The hypothetical commands `show w' and `show c' should show the appropriate
parts of the General Public License.  Of course, your program's commands
might be different; for a GUI interface, you would use an "about box".

  You should also get your employer (if you work as a programmer) or school,
if any, to sign a "copyright disclaimer" for the program, if necessary.
For more information on this, and how to apply and follow the GNU GPL, see
<https://www.gnu.org/licenses/>.

  The GNU General Public License does not permit incorporating your program
into proprietary programs.  If your program is a subroutine library, you
may consider it more useful to permit linking proprietary applications with
the library.  If this is what you want to do, use the GNU Lesser General
Public License instead of this License.  But first, please read
<https://www.gnu.org/licenses/why-not-lgpl.html>

• ISO 8583 Wikipedia page
• Payment service provider Wikipedia page
• GNU license page
• Free software Wikipedia page
• Qt documentation
• Pydantic documentation

The project was designed and developed around the everyday needs of banking systems support engineers. It has helped save thousands of working hours and meet hundreds of deadlines. The basic monetization principle is that Signal is always free for everyone, regardless of how it is used. The primary purpose of its licensing and copyright terms is to protect free use.

However, the project needs your support. You can contribute your time by working on the project or make a voluntary donation directly to the author.

⚠️ All donations are strictly voluntary.

The project needs help with:

• Code review, architecture development, and advice
• Documentation writing and translation
• Feedback and ideas
• Testing, especially automated tests and unit tests
• Financial support through the BTC wallet

bc1qs2jaqpnse9qgzz9y9wyns50km0f5x4wxe8cggs

Designed and developed by Fedor Ivanov

If you have any questions, feel free to contact the author directly.