Getnet DocsGetnet Docs

Polling and Reconnection

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 explains how Integrated POS handles validation, reconnection, and resilience when communication is interrupted or the terminal state is uncertain.

What are polling and reconnection

Polling is the command used to verify whether the POS terminal is available and ready to receive commands from the automation system. Reconnection refers to the behaviour and flows that apply when communication is lost or when you use setup parameters (e.g. friendly name) during connector creation in SDK-based connections. Robust handling of these scenarios maintains transactional integrity and prevents inconsistent terminal states.

Executing polling

Call the Polling method on the Connector instance before initiating any device operation. A successful response — Code 0 with Connected true — confirms the terminal is available and ready to process operations. Run Polling before each operation to avoid sending commands to an unready terminal.

Reconnection scenarios

The terminal may reset its connection state — for example after a reboot, a network drop, a USB disconnection, or a temporary cloud/service interruption. When this happens, a device operation (such as Sale) returns code 5. Code 5 is the reconnection signal, and it can occur at any time after a drop — not only at startup.

To recover, keep the same Connector instance — do not create a new one:

  1. Call Polling again on the existing Connector.
  2. When Polling returns code 0, resend the setup parameters, because reconnection resets the terminal configuration.
  3. Resend the command that returned code 5.

This flow is identical across the SDK (USB / HTTP) and Cloud2Cloud modes.

  • Quick Start — Step 2 uses Polling to validate the terminal before a sale.
  • Connection Models — Choose USB, network, or cloud; reconnection behaviour varies by model.
  • For Polling parameters/return and Reconnection Flow details, see the connectivity and error handling sections of this documentation.