Getnet DocsGetnet Docs

Integrated POS Mode and Terminal Lifecycle

View as MarkdownView this page as plain textOpen in ChatGPTAsk questions about this pageOpen in ClaudeAsk questions about this pageOpen in PerplexityAsk questions about this page
Connect to CursorUse these docs in CursorConnect to VS CodeUse these docs in VS Code

This page describes the controlled operational state of the terminal when it is driven by the automation system and the lifecycle states from an integration perspective.

What is Integrated POS mode

Integrated POS Mode is a controlled operational state of the payment terminal in which all payment-related interactions are driven programmatically by a commercial automation system. When Integrated POS Mode is active, the terminal stops accepting direct user navigation between applications and listens exclusively for commands sent through the Integrated POS communication channel. This ensures transactional consistency, security, and synchronization between the automation system and the POS device.

Integrated POS mode

When a terminal enters Integrated POS Mode:

  • The terminal listens for commands issued by the automation system
  • Manual access to other applications is restricted
  • Payment operations can only be initiated programmatically
  • All interactions occur through the Connector and Payment Apps

Terminal lifecycle states

From an integration perspective, the terminal transitions through well-defined lifecycle states:

  1. Normal POS Mode (Standalone) — The default state where the terminal operates independently and does not accept integrated commands.
  2. Activation — The user enables Integrated POS Mode on the terminal and chooses a connection model.
  3. Standby (Integrated POS Mode) — The terminal is connected, validated via Polling, and waiting for commands from the automation system.
  4. Processing — The terminal is executing a specific function (e.g., Sale, Refund, Reports).
  5. Deactivation — The terminal exits Integrated POS Mode and returns to Normal POS Mode, either via a SwitchToNormalPos command or manually.

Reconnecting (recovery): If a device operation returns code 5, the terminal has reset its connection — for example after a reboot or a dropped link — and needs to re-establish it. This can happen at any time after a drop, not only right after activation. Re-run Polling on the same Connector, resend the setup parameters, then retry the command. See Polling and Reconnection.

The Connector lifecycle

You create a Connector with one of the factory methods — CreateHttp, CreateUsb, or CreateCloud — and it follows a predictable lifecycle:

  1. Create — Open the connection to the terminal. In Cloud2Cloud, CreateCloud opens a channel to the Getnet cloud, which relays commands to the remote terminal.
  2. Polling — Send a Polling command to validate the connection and confirm the terminal reached Standby.
  3. Operate — Issue transaction commands, such as Sale, Refund, or Reports, while the terminal stays in Integrated POS Mode.
  4. Close — Release the Connector when work is done. Closing ends the session cleanly.

When you read accounting fields such as AccountingDate from responses, treat them as part of the operate phase. The terminal returns them while it processes commands in Integrated POS Mode.

Exiting Integrated POS mode

The terminal returns to Normal POS Mode when you send a SwitchToNormalPos command, or when the user exits manually. After deactivation, the terminal no longer accepts integrated commands until you activate it again and re-establish the connection.