Integrated POS Architecture

The Integrated POS architecture defines how a commercial automation system communicates with a payment terminal in a controlled, programmatic way. The cash register automation system integrates the Integrated POS Library, which communicates with the Connector App installed on the POS terminal; the Connector App triggers the Payment App for each operation.

Architectural Components

The Integrated POS architecture is composed of the following components:

Commercial Automation System

The commercial automation system (cash register, ERP, or POS software) integrates the Integrated POS Library, initiates payment-related operations, supplies parameters such as amount, installments, and plans, and handles the structured responses returned by the POS. It never communicates directly with the Payment App running on the terminal.

Integrated POS Library

The Integrated POS Library acts as the communication bridge between the automation system and the POS terminal. Its responsibilities include:

  • Establishing the communication channel with the terminal
  • Managing connection lifecycle
  • Serializing requests and deserializing responses
  • Exposing a unified API through the Connector instance

The library abstracts transport differences, allowing the same business logic to work across multiple connection models. In the SDK mode, the library reaches the terminal over USB or HTTP. In Cloud2Cloud, it reaches a remote terminal through the Getnet cloud, which relays each command to the same Connector App. The components and execution flow below are identical in both modes.

Connector App (POS Side)

On the POS device, a dedicated Connector App listens for incoming commands from the automation system. When a command is received:
  1. The Connector App receives the command and handles transport-level routing
  2. It launches the Payment App internally
  3. It forwards the operation parameters
  4. It waits for the operation result

This process happens transparently, without operator intervention.

Payment App

The Payment App validates the request — required fields and business rules — before starting the transaction flow. It then executes the financial operation itself, including card or QR code processing, validation with acquirers and issuers, user interaction on the terminal screen, and receipt generation.

Once the operation is completed, the Payment App returns the result to the Connector App, which then sends the structured response back to the automation system.

Execution Flow

From an architectural perspective, every operation follows this sequence:

  1. The automation system sends a command through the Integrated POS Library
  2. The Connector App receives and processes the command
  3. The Payment App executes the operation
  4. The result is propagated back to the automation system

This closed-loop flow keeps systems synchronized and avoids ambiguous terminal states.

Operational Scope

The architecture defines a predefined invocation sequence: initialize the connector (CreateHttp, CreateUsb, or CreateCloud), validate the device (Polling), execute device operations, then release resources (Close). The architecture allows fully or partially integrated flows depending on whether parameters are sent by the automation system. Activation and reconnection flows ensure reliability during daily operations.

All components and the execution flow above are specified in this documentation.

Next Steps

  • Review Connection Models for the SDK (USB / HTTP) and Cloud2Cloud options.
  • Follow the Quick Start to run your first Integrated POS payment.

On this page

Integrated POS Architecture