Getnet DocsGetnet Docs

Arquitetura do POS Integrado

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

A arquitetura do POS Integrado define como um sistema de automação comercial se comunica com um terminal de pagamento de forma controlada e programática. O sistema de automação de caixa integra a Integrated POS Library, que se comunica com o Connector App instalado no terminal POS. O Connector App aciona o Payment App em cada operação.

Componentes da arquitetura

A arquitetura do POS Integrado é composta pelos seguintes componentes:

Sistema de automação comercial

O sistema de automação comercial (caixa registradora, ERP ou software de PDV) integra a Integrated POS Library. Ele inicia operações de pagamento, fornece parâmetros como valor, parcelas e planos, e trata as respostas estruturadas retornadas pelo POS. Ele nunca se comunica diretamente com o Payment App em execução no terminal.

Integrated POS Library

A Integrated POS Library atua como ponte de comunicação entre o sistema de automação e o terminal POS. Suas responsabilidades incluem:

  • Estabelecer o canal de comunicação com o terminal
  • Gerenciar o ciclo de vida da conexão
  • Serializar requisições e desserializar respostas
  • Expor uma API unificada por meio da instância do Connector

A biblioteca abstrai as diferenças de transporte. Isso permite que a mesma lógica de negócio funcione em vários modelos de conexão. No modo SDK, a biblioteca alcança o terminal por USB ou HTTP. No Cloud2Cloud, ela alcança um terminal remoto pela nuvem da Getnet, que repassa cada comando ao mesmo Connector App. Os componentes e o fluxo de execução abaixo são idênticos nos dois modos.

Connector App (lado do POS)

No dispositivo POS, um Connector App dedicado escuta os comandos enviados pelo sistema de automação. Quando um comando é recebido:

  1. O Connector App recebe o comando e trata o roteamento no nível de transporte
  2. Ele inicia o Payment App internamente
  3. Ele encaminha os parâmetros da operação
  4. Ele aguarda o resultado da operação

Esse processo ocorre de forma transparente, sem intervenção do operador.

Payment App

O Payment App valida a requisição — campos obrigatórios e regras de negócio — antes de iniciar o fluxo da transação. Em seguida, ele executa a operação financeira em si. Isso inclui o processamento de cartão ou QR code, a validação com adquirentes e emissores, a interação do usuário na tela do terminal e a geração do recibo.

Quando a operação termina, o Payment App retorna o resultado ao Connector App. O Connector App então envia a resposta estruturada de volta ao sistema de automação.

Fluxo de execução

Do ponto de vista da arquitetura, toda operação segue esta sequência:

  1. O sistema de automação envia um comando por meio da Integrated POS Library
  2. O Connector App recebe e processa o comando
  3. O Payment App executa a operação
  4. O resultado é propagado de volta ao sistema de automação

Esse fluxo de ciclo fechado mantém os sistemas sincronizados e evita estados ambíguos no terminal.

Escopo operacional

A arquitetura define uma sequência de invocação predefinida: inicializar o connector (CreateHttp, CreateUsb ou CreateCloud), validar o dispositivo (Polling), executar as operações no dispositivo e liberar os recursos (Close). A arquitetura permite fluxos totalmente ou parcialmente integrados, conforme os parâmetros enviados pelo sistema de automação. Os fluxos de ativação e reconexão garantem a confiabilidade nas operações do dia a dia.

Todos os componentes e o fluxo de execução acima estão especificados nesta documentação.

Próximos passos