Getnet DocsGetnet Docs

Arquitectura

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

Get Central (TPVPC) opera como una capa intermediaria entre la lógica de negocio local de un comercio y la infraestructura de pagos de Redsys. Esta arquitectura está diseñada para descargar las complejidades de la gestión de hardware y la seguridad financiera de la aplicación principal de Punto de Venta (POS).

Componentes del sistema

El ecosistema consta de tres capas arquitectónicas principales que trabajan en sincronización para procesar una transacción.

1. La aplicación del comercio (POS)

El software de alto nivel donde reside la lógica de negocio. Es responsable de iniciar las solicitudes de transacción enviando payloads XML estructurados al TPVPC. La aplicación POS no maneja datos en bruto de la tarjeta, lo que reduce significativamente sus requisitos de seguridad.

2. El TPVPC

Este componente actúa como el “cerebro” de la integración. Existe como una biblioteca nativa (DLL/SO) o como un servicio local. Gestiona la conexión física con el PIN pad a través de puertos serie o USB, gestiona la comunicación SSL/TLS con el servidor de Redsys y aplica las reglas de negocio definidas en el protocolo XML.

3. El PIN pad (hardware)

El dispositivo físico donde el cliente interactúa con su tarjeta e introduce su PIN. En esta arquitectura, el PIN pad sirve como un punto de entrada seguro, cifrando los datos sensibles en origen antes de transmitirlos a través del TPVPC a la red financiera.

Ciclo de vida del flujo de datos

Un ciclo de datos típico comienza cuando la aplicación POS envía una solicitud XML al TPVPC. El TPVPC valida la estructura XML y la traduce en instrucciones a nivel de hardware para el PIN pad.

  1. Iniciación: El POS envía el comando XML.
  2. Interacción: El TPVPC activa el PIN pad; el cliente inserta la tarjeta/PIN.
  3. Cifrado: El PIN pad cifra los datos sensibles y los pasa al TPVPC.
  4. Transmisión: El TPVPC abre un canal SSL seguro hacia Redsys y transmite el payload.
  5. Respuesta: El TPVPC recibe la respuesta de autorización/denegación, actualiza la pantalla del PIN pad y devuelve un resultado XML procesado al POS.

Beneficios de la arquitectura

Esta arquitectura ofrece varios beneficios:

  • Lógica Desacoplada: separa las reglas de negocio del procesamiento de pagos, para facilitar las actualizaciones de software y los cambios de hardware.
  • Reducción de Alcance: los datos sensibles se cifran dentro del PIN pad, de modo que los datos de la tarjeta nunca llegan a la estación de trabajo POS.
  • Protocolo Unificado: la comunicación basada en XML se mantiene consistente, sea el hardware subyacente un terminal de escritorio o un quiosco desatendido.

Próximos pasos

Para continuar con tu integración, explora los siguientes recursos de implementación: