Connection Models
The Integrated POS groups its transports into two connection modes: SDK (USB / HTTP) for a terminal on the same local network or cable, and Cloud2Cloud for a remote terminal reached through the Getnet cloud. The transport mechanisms differ, but every connection exposes the same functional behavior through a unified Connector instance.
| Model | Transport | Creation method | Typical use | Key consideration |
|---|---|---|---|---|
| SDK — USB / Serial | Direct physical link (serial) | CreateUsb | POS next to automation system; no or limited network | Cable disconnect drops the channel; re-establish required |
| SDK — Network (HTTP) | Wi-Fi or Ethernet (HTTP) | CreateHttp | Same local network; most common deployment | Network stability and reconnection logic matter |
| Cloud2Cloud | Cloud-mediated (remote) | CreateCloud | Remote or distributed terminals; no local network access | Depends on an external cloud service; handle latency and reconnection |
SDK mode (USB / HTTP)
The SDK mode connects to a terminal on the same local network or cable. It offers two transports.
USB / serial connection
The USB connection model establishes a direct physical link between the automation system and the POS terminal using a serial interface. It is typically used when the POS is physically close to the automation system, network connectivity is restricted or unavailable, or a dedicated, stable connection is required. Communication is direct point-to-point, with no dependency on network infrastructure; you need local device access and permissions and use CreateUsb to initialize the connection. USB connections are sensitive to physical interruptions—if the cable is disconnected, the channel is lost and must be re-established.
Network connection (HTTP)
The network connection model uses HTTP over Wi-Fi or Ethernet to communicate with the POS terminal. This is the most common deployment model and suits environments where the automation system and terminal are on the same network. Communication runs over the local network, supports IPv4 and IPv6, and uses CreateHttp to establish the connection, allowing flexible placement of devices. Network stability is critical; temporary interruptions may require reconnection logic, especially when setup parameters are involved.
Cloud2Cloud connection
The Cloud2Cloud connection lets the automation system drive a terminal it cannot reach on the local network. Your backend sends commands to the Getnet cloud, which relays them to the remote terminal running in Integrated POS mode. Use CreateCloud to open the channel; no hostname or port is required, because the cloud routes each command to the registered terminal. This mode suits remote or distributed deployments where the terminal and the automation system run in different locations. Cloud connections depend on an external service, so plan for latency and reconnection.
Unified Connector abstraction
Regardless of the connection model used, a Connector instance is always returned, the same device operation functions are available, business logic remains unchanged, and the communication lifecycle is identical. This abstraction allows partners to switch connection models without refactoring payment logic.
Choosing a connection model
The choice depends on physical deployment constraints, network availability and reliability, security and operational requirements, and scalability needs. All models are fully compliant with the Integrated POS specification and supported equally by the integration libraries.
For full parameter details and examples per connection type, see the specific connection guides.
Next steps
- See Integrated POS Architecture for how the Connector fits into the overall flow.
- Follow the Quick Start to run your first payment using HTTP or another model.