Arquitectura HAL
El hardware POS varía según el fabricante, pero el software de pagos de Getnet necesita hablar con todos los dispositivos de la misma forma. La arquitectura HAL (Hardware Abstraction Layer) es como Getnet resuelve eso: un contrato fijo que cualquier fabricante puede implementar. Las capas superiores nunca necesitan saber qué hardware están manejando.
Qué es la arquitectura HAL
La arquitectura tiene cuatro capas, y cada una depende solo de la que está debajo:
- SDK PagoNxt — el SDK que los socios de Getnet integran en sus propias aplicaciones. Llama a las funciones de hardware mediante dos bibliotecas:
libposemv(procesamiento EMV) ylibposdigital(acceso general al hardware). - Middleware App — se sitúa entre el SDK y tu servicio. Recibe las llamadas de
libposemvylibposdigitaly las reenvía al servicio del fabricante que esté instalado en el dispositivo. libhalservice— la biblioteca de interfaces AIDL que Getnet entrega a los fabricantes. Define todos los métodos que la Middleware App puede llamar, sin definir cómo funcionan.- Manufacturer Service App — tu implementación de
libhalservice, con el nombre de paquetecom.pagonxt.hal.platform.service. Es la única capa que conoce el hardware real de tu dispositivo.
Una petición nace en la capa SDK PagoNxt y atraviesa la Middleware App sin cambios. Termina en la Manufacturer Service App instalada en ese dispositivo concreto. La respuesta vuelve por el mismo camino.
Por qué existe la capa de middleware
Sin un contrato compartido, las aplicaciones de los socios de Getnet necesitarían código específico para cada fabricante de POS que quisieran soportar. La Middleware App elimina esa necesidad: llama a los mismos métodos independientemente del dispositivo. Tu Manufacturer Service App es el único lugar donde vive el comportamiento específico del dispositivo.
Eso también aísla los cambios. Getnet puede actualizar la Middleware App o el SDK PagoNxt sin tocar tu implementación, siempre que sigas implementando las interfaces que define libhalservice. De la misma forma, puedes cambiar cómo tu dispositivo maneja una lectura de tarjeta o un trabajo de impresión. Eso nunca afecta a la Middleware App ni a ninguna aplicación de socio por encima de ella.
De qué es responsable tu servicio
Tu Manufacturer Service App es dueña de toda interacción con el dispositivo físico: leer tarjetas, imprimir recibos, manejar el beeper y los LED, leer la cámara y reportar estadísticas de uso. La Middleware App nunca accede al hardware directamente. Solo llama a las interfaces que tu servicio expone y espera una respuesta con la forma que esas interfaces definen.
La interfaz EMV sigue el mismo patrón, pero con más estado. En lugar de una única llamada y respuesta, funciona como una máquina de estados que tu servicio y la Middleware App recorren juntos. Consulta Máquina de estados EMV para ese flujo.
Recursos relacionados
- Visión general de fabricantes POS — dónde encaja esta arquitectura en el proceso de homologación.
- Configuración de la integración HAL — nombre de paquete, interfaces requeridas y el Intent de vinculación.
- Referencia de interfaces de servicio — todos los métodos que tu servicio puede implementar.