Getnet DocsGetnet Docs

Arquitectura del TPV 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

La arquitectura del TPV Integrado define cómo un sistema de automatización comercial se comunica con un terminal de pago de forma controlada y programática. El sistema de automatización comercial integra la Integrated POS Library, que se comunica con la Connector App instalada en el terminal TPV. La Connector App activa la Payment App en cada operación.

Componentes de la arquitectura

La arquitectura del TPV Integrado se compone de los siguientes componentes:

Sistema de automatización comercial

El sistema de automatización comercial (caja registradora, ERP o software de TPV) integra la Integrated POS Library. Inicia las operaciones relacionadas con los pagos y envía parámetros como el importe, las cuotas y los planes. También procesa las respuestas estructuradas que devuelve el TPV. Nunca se comunica directamente con la Payment App que se ejecuta en el terminal.

Integrated POS Library

La Integrated POS Library actúa como puente de comunicación entre el sistema de automatización y el terminal TPV. Sus responsabilidades incluyen:

  • Establecer el canal de comunicación con el terminal
  • Gestionar el ciclo de vida de la conexión
  • Serializar las solicitudes y deserializar las respuestas
  • Exponer una API unificada a través de la instancia del Connector

La biblioteca abstrae las diferencias de transporte. Así, la misma lógica de negocio funciona en varios modelos de conexión. En el modo SDK, la biblioteca llega al terminal por USB o HTTP. En Cloud2Cloud, llega a un terminal remoto a través de la nube de Getnet. La nube reenvía cada comando a la misma Connector App. Los componentes y el flujo de ejecución descritos abajo son idénticos en ambos modos.

Connector App (lado del TPV)

En el dispositivo TPV, una Connector App dedicada escucha los comandos entrantes del sistema de automatización. Cuando recibe un comando:

  1. La Connector App recibe el comando y gestiona el enrutamiento a nivel de transporte
  2. Inicia internamente la Payment App
  3. Reenvía los parámetros de la operación
  4. Espera el resultado de la operación

Este proceso ocurre de forma transparente, sin intervención del operador.

Payment App

La Payment App valida la solicitud —campos obligatorios y reglas de negocio— antes de iniciar el flujo de la transacción. Luego ejecuta la operación financiera en sí. Esto incluye el procesamiento de tarjeta o código QR, la validación con adquirentes y emisores, la interacción del usuario en la pantalla del terminal y la generación de recibos.

Una vez completada la operación, la Payment App devuelve el resultado a la Connector App. La Connector App envía entonces la respuesta estructurada al sistema de automatización.

Flujo de ejecución

Desde una perspectiva arquitectónica, cada operación sigue esta secuencia:

  1. El sistema de automatización envía un comando a través de la Integrated POS Library
  2. La Connector App recibe y procesa el comando
  3. La Payment App ejecuta la operación
  4. El resultado se propaga de vuelta al sistema de automatización

Este flujo de bucle cerrado mantiene los sistemas sincronizados y evita estados ambiguos del terminal.

Alcance operativo

La arquitectura define una secuencia de invocación predefinida: inicializar el connector (CreateHttp, CreateUsb o CreateCloud), validar el dispositivo (Polling), ejecutar las operaciones del dispositivo y liberar los recursos (Close). La arquitectura permite flujos total o parcialmente integrados, según si el sistema de automatización envía los parámetros. Los flujos de activación y reconexión garantizan la fiabilidad durante la operación diaria.

Todos los componentes y el flujo de ejecución descritos arriba se especifican en esta documentación.

Siguientes pasos